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

Groups > comp.lang.python > #73545 > unrolled thread

Error in PyDev but not in the standard python interpreter

Back to article view | Back to comp.lang.python

Contents

  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

#73545 — Error in PyDev but not in the standard python interpreter

Hi,

this is probably not the best place for this topic but I know this forum 
is widely read. I take this opportunity and apology at the same time.

If I run this in my python3 interpreter everything works fine:

mowglie@flappi ~ $ python3
Python 3.3.2+ (default, Feb 28 2014, 00:52:16)
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
 >>> from netCDF4 import num2date
 >>> from datetime import datetime
 >>> d1 = num2date(0, 'days since 1000-01-01', 'standard')
 >>> d2 = datetime(2000, 1, 1)
 >>> print(d1 < d2)
True

But if I run the code in PyDev I get:
     print(d1 < d2)
TypeError: unorderable types: datetime() < datetime.datetime()

When debugging in pyDev, everything looks fine:
 >>> sys.version
Out[28]: '3.3.2+ (default, Feb 28 2014, 00:52:16) \n[GCC 4.8.1]'
 >>> ?d1
Type:       datetime
String Form:1000-01-01 00:00:00
File:       /usr/local/lib/python3.3/dist-packages/netcdftime.py
Docstring:
[...]
 >>> ?d2
Type:       datetime
String Form:2000-01-01 00:00:00
File:       /usr/lib/python3.3/datetime.py
Docstring:
[...]
 >>> d1 < d2
Traceback (most recent call last):
   File 
"/usr/lib/python3/dist-packages/IPython/core/interactiveshell.py", line 
2732, in run_code
     exec(code_obj, self.user_global_ns, self.user_ns)
   File "<ipython-input-29-415dec1be9aa>", line 1, in <module>
     d1 < d2
TypeError: unorderable types: datetime() < datetime.datetime()


So they are two instances of the same object but something in pyDev 
doesn't want to compare them. Any Hint?

Thanks!

Fabien

[toc] | [next] | [standalone]

#73546

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

[toc] | [prev] | [next] | [standalone]

#73547

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@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
>

[toc] | [prev] | [next] | [standalone]

#73548

On Tue, Jun 24, 2014 at 11:59 PM, Fabien <fabien.maussion@gmail.com> wrote:
> 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"?
>

Here's what I'd try:

>>> import sys
>>> sys.modules[d1.__class__.__module__].__file__
>>> sys.modules[d2.__class__.__module__].__file__

Do those in both environments and see where things are actually coming
from. (In PyDev, I expect that to tell you exactly the same file names
as your question-mark inspection tells you, as that'll be how it
obtains the information.) It might be that your module search path is
different.

ChrisA

[toc] | [prev] | [next] | [standalone]

#73550

Hi Chris,

On 24.06.2014 16:04, Chris Angelico wrote:
> Here's what I'd try:
>
>>>> >>>import sys
>>>> >>>sys.modules[d1.__class__.__module__].__file__
>>>> >>>sys.modules[d2.__class__.__module__].__file__

that was it!

netCDF4 has two repositories online, one on google code and one on 
github. I mistakenly installed the old one, then I noticed the new one 
and obviously some old stuffs remained in the dist-packages directory. I 
removed them from my path and everything works fine in pydev now.

Thanks a lot!

Fab

[toc] | [prev] | [next] | [standalone]

#73551

On Wed, Jun 25, 2014 at 12:27 AM, Fabien <fabien.maussion@gmail.com> wrote:
> netCDF4 has two repositories online, one on google code and one on github. I
> mistakenly installed the old one, then I noticed the new one and obviously
> some old stuffs remained in the dist-packages directory. I removed them from
> my path and everything works fine in pydev now.
>
> Thanks a lot!

Awesome! In fact, looking at their github repo (or what seems to be
it) shows that (currently) the most recent change to that file was
exactly what I suggested ought to be done: add rich comparisons to the
phony datetime.

https://github.com/Unidata/netcdf4-python/blob/master/netcdftime.py

Would be nice if there could be some clear indication that this is the
official and current repo. When I went Googling for netCDF4, I found
the other one first, with no indication that the github repo was
better.

ChrisA

[toc] | [prev] | [next] | [standalone]

#73552

On 24.06.2014 16:35, Chris Angelico wrote:
> Would be nice if there could be some clear indication that this is the
> official and current repo.

indeed. Also, the install procedure is a bit dangerous for new python 
users like me. NetCDF4 is out since 2008, it would be great if SciPy 
could support it.

Other related annoying stuff when learning is the good old 2.7 VS 3 problem:

mowglie@flappi ~ $ apt-cache search SciPy
[...]
python-scipy - scientific tools for Python
python3-scipy - scientific tools for Python 3

mowglie@flappi ~ $ apt-cache search python basemap
[...]
python-mpltoolkits.basemap - matplotlib toolkit to plot on map

-> no native python3 package for basemap -> compilation required...

But I'll stick to it. If so many people say it's great for scientific 
computing, python must be great right? ;-)

[toc] | [prev] | [next] | [standalone]

#73553

On Wed, Jun 25, 2014 at 1:40 AM, Fabien <fabien.maussion@gmail.com> wrote:
> Other related annoying stuff when learning is the good old 2.7 VS 3 problem:
>
> mowglie@flappi ~ $ apt-cache search SciPy
> [...]
> python-scipy - scientific tools for Python
> python3-scipy - scientific tools for Python 3
>
> mowglie@flappi ~ $ apt-cache search python basemap
> [...]
> python-mpltoolkits.basemap - matplotlib toolkit to plot on map
>
> -> no native python3 package for basemap -> compilation required...

Wouldn't have the foggiest as regards basemap, it might be that it
actually doesn't support Py3. (Also, it may depend on your exact
distro and version. I confirmed what you see there on Debian Wheezy,
but you might get different results on Debian Sid, or Scibuntu, etc,
etc.) You may want to consider using pip if apt doesn't have what you
want; it might be possible to get basemap that way.

> But I'll stick to it. If so many people say it's great for scientific
> computing, python must be great right? ;-)

Again, I couldn't say (I'm not into the heavy scientific work
myself)... but I can confirm that Python is an excellent language.
Along with Pike (a very similar language but with focus more on
long-running servers), Python holds pride of place in my coding work.
Basically, C is for writing high level languages in, and Python and
Pike are for writing applications. Life is good.

ChrisA

[toc] | [prev] | [next] | [standalone]

#73554

On 06/24/2014 08:58 AM, Chris Angelico wrote:
>
> Basically, C is for writing high level languages in, and Python and
> Pike are for writing applications. Life is good.

+1 QOTW

[toc] | [prev] | [next] | [standalone]

#73555

On 06/24/2014 07:04 AM, Chris Angelico wrote:
>
> Here's what I'd try:
>
>>>> import sys
>>>> sys.modules[d1.__class__.__module__].__file__
>>>> sys.modules[d2.__class__.__module__].__file__
>
> Do those in both environments and see where things are actually coming
> from.

Debugging tips always appreciated.

Thanks, Chris!

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#73549

[Multipart message — attachments visible in raw view] — view raw

Well, it 'appears' to be the same type, but given that the File from one is
different from the other, I think they aren't...

Googling a bit, I found the source:
https://code.google.com/p/netcdf4-python/source/browse/trunk/netcdftime.py?r=1117
and it has a 'datetime' which says: "Phony datetime object which mimics the
python datetime object", now, I'm not sure why it works in the Python shell
but not in the IPython shell integrated in PyDev... You may want to create
a module and do a debug run to step into the 'num2date' call to see what
differs there... (i.e.: I think that if you do isinstance(d1, datetime)
it'll return false, as it seems to be a netcdftime.datetime object).

Best Regards,

Fabio


On Tue, Jun 24, 2014 at 10:28 AM, Fabien <fabien.maussion@gmail.com> wrote:

> Hi,
>
> this is probably not the best place for this topic but I know this forum
> is widely read. I take this opportunity and apology at the same time.
>
> If I run this in my python3 interpreter everything works fine:
>
> mowglie@flappi ~ $ python3
> Python 3.3.2+ (default, Feb 28 2014, 00:52:16)
> [GCC 4.8.1] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from netCDF4 import num2date
> >>> from datetime import datetime
> >>> d1 = num2date(0, 'days since 1000-01-01', 'standard')
> >>> d2 = datetime(2000, 1, 1)
> >>> print(d1 < d2)
> True
>
> But if I run the code in PyDev I get:
>     print(d1 < d2)
> TypeError: unorderable types: datetime() < datetime.datetime()
>
> When debugging in pyDev, everything looks fine:
> >>> sys.version
> Out[28]: '3.3.2+ (default, Feb 28 2014, 00:52:16) \n[GCC 4.8.1]'
> >>> ?d1
> Type:       datetime
> String Form:1000-01-01 00:00:00
> File:       /usr/local/lib/python3.3/dist-packages/netcdftime.py
> Docstring:
> [...]
> >>> ?d2
> Type:       datetime
> String Form:2000-01-01 00:00:00
> File:       /usr/lib/python3.3/datetime.py
> Docstring:
> [...]
> >>> d1 < d2
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/IPython/core/interactiveshell.py",
> line 2732, in run_code
>     exec(code_obj, self.user_global_ns, self.user_ns)
>   File "<ipython-input-29-415dec1be9aa>", line 1, in <module>
>     d1 < d2
> TypeError: unorderable types: datetime() < datetime.datetime()
>
>
> So they are two instances of the same object but something in pyDev
> doesn't want to compare them. Any Hint?
>
> Thanks!
>
> Fabien
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>

[toc] | [prev] | [next] | [standalone]

#73715

On Tue, 24 Jun 2014 15:28:47 +0200, Fabien wrote:

> PyDev

Maybe.

Which version of Python do you use in PyDev? When you create a project, 
you get to choose grammar version. PyDev default might not be what you 
want.

 /Grrr
-- 
          ___                  ___
 (\_--_/)  | _ ._    _|_|_  _   |o _  _ ._
 ( 9  9 )  |(_)| |\/  |_| |(/_  ||(_|(/_|
 stripes are forever - as overripe ferrets

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web