Calendar() class can not be initialized

Bug #1302963 reported by b3nmore
84
This bug affects 29 people
Affects Status Importance Assigned to Milestone
parsedatetime (Ubuntu)
Fix Released
Medium
Unassigned
Nominated for Trusty by Thomas Ward

Bug Description

Using the simple example from upstreams readme (https://github.com/bear/parsedatetime) raises an error:

$python
>>> import parsedatetime.parsedatetime as pdt
>>> cal = pdt.Calendar()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/dist-packages/parsedatetime/__init__.py", line 216, in __init__
    self.ptc = Constants()
  File "/usr/lib/python2.7/dist-packages/parsedatetime/__init__.py", line 1733, in __init__
    self.locale = pdtLocales['icu'](self.localeID)
  File "/usr/lib/python2.7/dist-packages/parsedatetime/pdt_locales.py", line 151, in __init__
    self.icu = pyicu.Locale(localeID)
icu.InvalidArgsError: (<type 'icu.Locale'>, '__init__', (None,))

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in parsedatetime (Ubuntu):
status: New → Confirmed
Revision history for this message
Greg Lutostanski (lutostag) wrote :

parsedatetime has an optional dependency on a specific version python-pyicu, which is not documented -- it seems that the current trusty version 1.5-2ubuntu4 does not play nice.

Workaround is to explicity disable pyicu, for example use:

import parsedatetime.parsedatetime as pdtal = pdt.Calendar()
cal = pdt.Calendar(pdt.Constants(usePyICU=False))

I'll dig and see if I can come up with the exact pyicu version dependency parsedatetime expects.

Changed in parsedatetime (Ubuntu):
importance: Undecided → Medium
Changed in parsedatetime (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
bear (bear42) wrote :

Technically I made it so that any version of PyICU will work but from what I see of that bug it appears that something has changed in the parameters.

Removing PyICU completely would break things for the folks who are using parsedatetime for non-US languages - do you want me to fix this bug with the most recent version of PyICU (or the version you tell me is needed for Ubuntu?)

Revision history for this message
Greg Lutostanski (lutostag) wrote :

Hi bear,

Good point, looks like disabling PyICU is not a good workaround then.

If we can get it to work with the python-pyicu version (1.5) currently in trusty I think that would be best for now. I know its quite a bit outdated, I will look into getting that updated to a more recent version as well.

If getting it to work with 1.5 turns out to be a debacle, comment here and we'll look for a better solution.

I am willing to test the changes on my end if need be.

BTW, this is such a useful package, I love it :). Thanks!

Revision history for this message
bear (bear42) wrote :

Glad it is still useful!

I will schedule some time tonight or tomorrow to get it up to at least PyICU 1.5 and report back

Revision history for this message
bear (bear42) wrote :

I am having troubling in stalling pyicu-1.7 from the tarball - is there a v1.5 plus ppa available that I can use?

Revision history for this message
Greg Lutostanski (lutostag) wrote :

I don't think you need to install pyicu-1.7, the released packages for pyicu are at https://launchpad.net/ubuntu/+source/pyicu

I can setup a ppa if needed. But if you are on trusty or saucy you should just be able to:
apt-get install python-pyicu
and then go about seeing if a fix works.

What release are you testing on?

also, feel free to ping me on irc if desired.

terrin (terrin-oculon)
description: updated
Revision history for this message
icactus (itrapkus) wrote :

Looks like this is also part of an old problem with parsedatetime. (https://github.com/maebert/jrnl/issues/52)

I just updated parsedatetime and everything works now:

sudo pip install --upgrade parsedatetime

Revision history for this message
Greg Lutostanski (lutostag) wrote :

Glad to hear it was updated upstream.

The two commits that need to be cherry-picked into a patch for the deb from upstream git repo at https://github.com/bear/parsedatetime.git to fix this directly are:
51d47dd57a8ac
692168f4bd336

Also making a note that this package needs to be updated in debian as well.

Revision history for this message
Andrés (cyver-yo) wrote :

The icactus' workaround may need that you install pip first.

sudo apt-get install python-pip

then you can upgrade parsedatetime.

Revision history for this message
Jackson Doak (noskcaj) wrote :

This is fixed in debian, i'll sync it soon

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package parsedatetime - 1.2-1

---------------
parsedatetime (1.2-1) unstable; urgency=medium

  * Team upload.

  [ Jakub Wilk ]
  * Use canonical URIs for Vcs-* fields.

  [ Jackson Doak ]
  * Sync from ubuntu. Closes: #485054 #717991
  * Bump standards-version to 3.9.5 (no changes)
  * Use dh and debhelper 9 for building

  [ Vincent Cheng ]
  * Remove obsolete patches.

 -- Jackson Doak <email address hidden> Mon, 02 Jun 2014 14:08:43 +1000

Changed in parsedatetime (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
JAPrufrock (rwcarlson) wrote :

Got it! Thank you, thank you, thank you.

Revision history for this message
Giulio Malventi (giulio-people) wrote :

Still valid on 14.04.

Revision history for this message
eric (vongesell) wrote :

On 14.04 pip --upgrade parsedatetime appears to work. Additionally installing from sources with latest version works. Just make certain you dont have old copies of the library laying around. Then actual route I got to the fix involved removing the library from /usr/lib and /usr/local/lib and then installing via pip. To check the solution via sources I installed the version installed via pip and installed then from sources. So both options worked for me on 14.04

Revision history for this message
Unit 193 (unit193) wrote :

parsedatetime 1.4-1~ubuntu14.04.1 has now been backported to Trusty (LP: #1510329)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.