Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #73546

Re: Error in PyDev but not in the standard python interpreter

Show key headers only | View raw

On Tue, Jun 24, 2014 at 11:28 PM, Fabien <fabien.maussion@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

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Error in PyDev but not in the standard python interpreter Fabien <fabien.maussion@gmail.com> - 2014-06-24 15:28 +0200
  Re: Error in PyDev but not in the standard python interpreter Chris Angelico <rosuav@gmail.com> - 2014-06-24 23:47 +1000
    Re: Error in PyDev but not in the standard python interpreter Fabien <fabien.maussion@gmail.com> - 2014-06-24 15:59 +0200
      Re: Error in PyDev but not in the standard python interpreter Chris Angelico <rosuav@gmail.com> - 2014-06-25 00:04 +1000
        Re: Error in PyDev but not in the standard python interpreter Fabien <fabien.maussion@gmail.com> - 2014-06-24 16:27 +0200
          Re: Error in PyDev but not in the standard python interpreter Chris Angelico <rosuav@gmail.com> - 2014-06-25 00:35 +1000
            Re: Error in PyDev but not in the standard python interpreter Fabien <fabien.maussion@gmail.com> - 2014-06-24 17:40 +0200
              Re: Error in PyDev but not in the standard python interpreter Chris Angelico <rosuav@gmail.com> - 2014-06-25 01:58 +1000
              Re: Error in PyDev but not in the standard python interpreter Ethan Furman <ethan@stoneleaf.us> - 2014-06-24 09:02 -0700
      Re: Error in PyDev but not in the standard python interpreter Ethan Furman <ethan@stoneleaf.us> - 2014-06-24 08:08 -0700
  Re: Error in PyDev but not in the standard python interpreter Fabio Zadrozny <fabiofz@gmail.com> - 2014-06-24 10:46 -0300
  Re: Error in PyDev but not in the standard python interpreter Tony the Tiger <tony@tiger.invalid> - 2014-06-28 20:39 +0000

csiph-web