[Python-Dev] Bug in from __future__ processing?
Hello, The Python spec states that the “from __future__ import …” statement can only occur at the beginning of the file, preceded only by doc strings, comments, empty lines or other future statements. The following code snippets, however, don’t raise Syntax error in Python 2.4.2. Is it a bug? I am asking whether in IronPython we should try to match behavior of Python compiler, or stick to the language spec. In this case, I believe that we should stick to the spec and report a bug in Python compiler. Thanks Martin Example 1: -- x = 10 / 2 from __future__ import division -- Example 2: -- from sys import * from __future__ import division -- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Semantic of isinstance
Hello Python Dev, I am trying to understand the correct semantic of the isinstance built-in function and while doing so, I came across few cases which raise some questions. 1) First example - a class instance pretends to have different class via __class__. >>> class D(object): ... def getclass(self): ... print "D.getclass" ... return C ... __class__ = property(getclass) ... >>> isinstance(D(), D) True >>> isinstance(D(), C) D.getclass True isinstance in this case returns True to both C and D test. I would expect to see the __class__ property being called in both cases and get: >>> isinstance(D(), D) D.getclass False but that's not the case for some reason. It seems that the __class__ is only accessed in some cases, but not always, leading to what I think is a semantic inconsistency. 2) Second, slightly more complicated example, uses an instance with __bases__ on it as the 2nd parameter to isinstance: class E(object): def getbases(self): print "E.getbases" return () __bases__ = property(getbases) class C(object): def getbases(self): print "C.getbases" return (E,) # C() claims: "E is my base class" __bases__ = property(getbases) class D(object): def getclass(self): print "D.getclass" return C() # D() claims: "C() is my __class__" __class__ = property(getclass) class F(object): pass print "Test 1" print isinstance(D(), E()) # testing against E() instance print "Test 2" print isinstance(D(), E)# testing against E class The output here is: Test 1 E.getbases D.getclass C.getbases False Test 2 D.getclass False In the 2nd test, D.getclass is called to get the __class__ of D(), which returns C() instance. At this point I would expect that C.getbases gets called as __bases__ are retrieved, which would return tuple consisting of E and ultimately produce True result. However, in this case the __bases__ are never accessed on C() (the class of D()). The test_isinstance.py actually tests for similar case. My question is based on what assumptions does the standard Python implementation bypass the access to __bases__, __class__ etc. when evaluating isinstance? Did I happen to come across a bug or an inconsistency in Python implementation, or am I hitting an intentional behavior? Thanks very much for reading and some insights! Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Semantic of isinstance
Thanks for the response. The code snippet I sent deals with new style classes only so I assume that in some cases isinstance falls back to old-style-like handling which then asks for __bases__ and __class__ etc, possibly incorrectly so on new style classes. Thanks again! Martin -Original Message- From: Greg Ewing [mailto:[EMAIL PROTECTED] Sent: Monday, June 26, 2006 8:00 PM To: Martin Maly Cc: python-dev@python.org Subject: Re: [Python-Dev] Semantic of isinstance Martin Maly wrote: >>>>isinstance(D(), D) > > True > >>>>isinstance(D(), C) > > D.getclass > True This looks like a new/old class thing. Presumably once everything is changed over to new-style classes, this inconsistency will go away. And from the current behaviour, it looks like __class__ and __bases__ will be bypassed by isinstance() (unless Guido decides to change that). -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED]+--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] __doc__ behavior in class definitions
Hello Python-Dev, My name is Martin Maly and I am a developer at Microsoft, working on the IronPython project with Jim Hugunin. I am spending lot of time making IronPython compatible with Python to the extent possible. I came across a case which I am not sure if by design or a bug in Python (Python 2.4.1 (#65, Mar 30 2005, 09:13:57)). Consider following Python module: # module begin "module doc" class c: print __doc__ __doc__ = "class doc" (1) print __doc__ print c.__doc__ # module end When ran, it prints: module doc class doc class doc Based on the binding rules described in the Python documentation, I would expect the code to throw because binding created on the line (1) is local to the class block and all the other __doc__ uses should reference that binding. Apparently, it is not the case. Is this bug in Python or are __doc__ strings in classes subject to some additional rules? Thanks Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
