Error in PyDev but not in the standard python interpreter

Fabien fabien.maussion at gmail.com
Tue Jun 24 09:59:16 EDT 2014


Hi Chris,

thanks for the hint. Indeed they are not an instance of the same class:

 >>> isinstance(d1, datetime)
Out[6]: False
 >>> isinstance(d2, datetime)
Out[7]: True

so this is something I should check with the NetCDF4 package developers.

While The python interpreter can compare them, my pydev environment 
can't. Is pydev doing something "better" then python3 "alone"?

Btw, the test case is extracted from the netCDF4package test suite, 
which passes on the linux command line but not on pydev because of this 
one code block...



On 24.06.2014 15:47, Chris Angelico wrote:
> On Tue, Jun 24, 2014 at 11:28 PM, Fabien <fabien.maussion at gmail.com> wrote:
>> So they are two instances of the same object but something in pyDev doesn't
>> want to compare them. Any Hint?
>
> Are they really instances of the same class? One of them comes from
> /usr/local/lib/python3.3/dist-packages/netcdftime.py and the other
> comes from /usr/lib/python3.3/datetime.py - so they might be virtually
> identical (or they might not), but they're not the actual same class,
> and when __lt__ does its isinstance check, it doesn't pass.
>
> The real question is: Why is netCDF4 not using "import datetime" to
> get its datetime? And I think that's best answered with this, lifted
> from the netcdftime.utime docstring [1]:
>
> """
> The datetime instances returned by C{num2date} are 'real' python datetime
> objects if the date falls in the Gregorian calendar (i.e.
> C{calendar='proleptic_gregorian', 'standard'} or C{'gregorian'} and
> the date is after 1582-10-15). Otherwise, they are 'phony' datetime
> objects which are actually instances of C{L{netcdftime.datetime}}.  This is
> because the python datetime module cannot handle the weird dates in some
> calendars (such as C{'360_day'} and C{'all_leap'}) which don't exist in any real
> world calendar.
> """
>
> (Similar info can be found in the docstring for netcdftime.datetime
> itself, but without the examples.)
>
> ISTM netcdftime.datetime should define __lt__() to permit comparisons
> with either others of itself or datetime.datetime objects, but in the
> absence of that, you're stuck with either ensuring that you're working
> with Gregorian dates, or writing your own comparison function.
>
> Good luck!
>
> ChrisA
>
> [1] https://code.google.com/p/netcdf4-python/source/browse/trunk/netcdftime.py?r=1117#522
>




More information about the Python-list mailing list