Hi all --
I seem to have discovered an inconsistency in the semantics of object
comparison between plain old Python instances and ExtensionClass
instances. (I've cc'd python-dev because it looks as though one *could*
blame Python for the inconsistency, but I don't really understand the
guts of either Python or ExtensionClass enough to know.)
Here's a simple script that shows the difference:
class Simple:
def __init__ (self, data):
self.data = data
def __repr__ (self):
return "<%s at %x: %s>" % (self.__class__.__name__,
id(self),
`self.data`)
def __cmp__ (self, other):
print "Simple.__cmp__: self=%s, other=%s" % (`self`, `other`)
return cmp (self.data, other)
if __name__ == "__main__":
v1 = 36
v2 = Simple (36)
print "v1 == v2?", (v1 == v2 and "yes" or "no")
print "v2 == v1?", (v2 == v1 and "yes" or "no")
print "v1 == v2.data?", (v1 == v2.data and "yes" or "no")
print "v2.data == v1?", (v2.data == v1 and "yes" or "no")
If I run this under Python 1.5.2, then all the comparisons come out true
and my '__cmp__()' method is called twice:
v1 == v2? Simple.__cmp__: self=<Simple at 1b5148: 36>, other=36
yes
v2 == v1? Simple.__cmp__: self=<Simple at 1b5148: 36>, other=36
yes
v1 == v2.data? yes
v2.data == v1? yes
The first one and the last two are obvious, but the second one only
works thanks to a trick in PyObject_Compare():
if (PyInstance_Check(v) || PyInstance_Check(w)) {
...
if (!PyInstance_Check(v))
return -PyObject_Compare(w, v);
...
}
However, if I make Simple an ExtensionClass:
from ExtensionClass import Base
class Simple (Base):
Then the "swap v and w and use w's comparison method" no longer works.
Here's the output of the script with Simple as an ExtensionClass:
v1 == v2? no
v2 == v1? Simple.__cmp__: self=<Simple at 1b51c0: 36>, other=36
yes
v1 == v2.data? yes
v2.data == v1? yes
It looks as though ExtensionClass would have to duplicate the trick in
PyObject_Compare() that I quoted, since Python has no idea that
ExtensionClass instances really should act like instances. This smells
to me like a bug in ExtensionClass. Comments?
BTW, I'm using the ExtensionClass provided with Zope 2.1.4. Mostly
tested with Python 1.5.2, but also under the latest CVS Python and we
observed the same behaviour.
Greg
ActiveState announces four new Python-related projects (PythonDirect,
Komodo, Visual Python, ActivePython).
PythonLabs announces four planet-sized-brains are going to be working on
the Python implementation full time.
PythonWare announces PythonWorks.
Is that the sound of pieces falling into place or of a rumbling
avalanche "warming up" before obliterating everything in its path?
--
Paul Prescod - ISOGEN Consulting Engineer speaking for himself
"I want to give beauty pageants the respectability they deserve."
- Brooke Ross, Miss Canada International
Would there be interest in adding the python-ldap module
(http://sourceforge.net/project/?group_id=2072) to the
core distribution ?
If yes, I think we should approach David Leonard and
ask him if he is willing to donate the lib (which is
in the public domain) to the core.
FYI, LDAP is a well accepted standard network protocol for
querying address and user information.
An older web page with more background is available at:
http://www.it.uq.edu.au/~leonard/dc-prj/ldapmodule/
--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/
On Wed, 31 May 2000, Ka-Ping Yee wrote:
> Hey, i admit it's a bit primitive, but it seems significantly
> better than nothing. The software people at ILM have coped
> with it fairly well for a year, and for the most part we like it.
I'm not sure about the requirements - particularly, submissions and
correspondence about bugs via email, which my zope "tracker" doesn't do -
but the tracker may be worth looking at, also:
http://www.zope.org/Members/klm/SoftwareCarpentry
(See the prototype tracker, mentioned there, or my "tracker tracker" at
http://www.zope.org/Members/klm/Tracker , for flagrant, embarrassing
exposure of the outstanding tracker complaints...)
(I haven't had the time to take care of the tracker as i would like, or to
look at how tracker and roundup could inform eachother - but i haven't
even gotten as far as examining that. I get the feeling they take fairly
different approaches - which could mean neat synergy, or total
disconnection. Ping, any thoughts?)
Ken
klm(a)digicool.com
I think that we need a forum somewhere between comp.lang.python and
pythondev. Let's call it python-lang.
By virtue of being buried on the "sigs" page, python-lang would be
mostly only accessible to those who have more than a cursory interest in
Python. Furthermore, you would have to go through a simple
administration procedure to join, as you do with any mailman list.
Appropriate topics of python-lang would be new ideas about language
features. Participants would be expected and encouraged to use archives
and FAQs to avoid repetitive topics. Particular verboten would be
"ritual topics": indentation, case sensitivity, integer division,
language comparisions, etc. These discussions would be redirected loudly
and firmly to comp.lang.python.
Python-dev would remain invitation only but it would focus on the day to
day mechanics of getting new versions of Python out the door.
--
Paul Prescod - ISOGEN Consulting Engineer speaking for himself
"Hardly anything more unwelcome can befall a scientific writer than
having the foundations of his edifice shaken after the work is
finished. I have been placed in this position by a letter from
Mr. Bertrand Russell..."
- Frege, Appendix of Basic Laws of Arithmetic (of Russell's Paradox)
On Wed, May 31, 2000 at 01:49:17PM -0400, Jeremy Hylton wrote:
>I'm actually more worried about the second. It's been a while since I
>read c.l.py and I'm occasionally disappointed to miss out on
>seemingly interesting threads. On the other hand, there is no way I
>could manage to read or even filter the volume on that list.
Really? I read it through Usenet with GNUS, and it takes about a half
hour to go through everything. Skipping threads by subject usually
makes it easy to avoid uninteresting stuff.
I'd rather see python-dev limited to very narrow, CVS-tree-related
material, such as: should we add this module? is this change OK?
&c... The long-winded language speculation threads are better left to
c.l.python, where more people offer opinions, it's more public, and
newsreaders are more suited to coping with the volume. (Incidentally,
has any progress been made on reviving c.l.py.announce?)
OTOH, newbies have reported fear of posting in c.l.py, because they
feel the group is too advanced, what with everyone sitting around
talking about coroutines and SNOBOL string parsing. But I think it's
a good thing if newbies see the high-flown chatter and get their minds
stretched. :)
--amk
"Barry A. Warsaw" wrote:
>
> ...
>
> I agree. I think anybody who'd be interested in python-lang is
> already going to be a member of python-dev
Huh? What about Greg Ewing, Amit Patel, Martijn Faassen, William
Tanksley, Mike Fletcher, Neel Krishnaswami, the various stackless
groupies and a million others. This is just a short list of people who
have made reasonable language suggestions recently. Those suggestions
are going into the bit-bucket unless one of us happens to notice and
champion it here. But we're too busy thinking about 1.6 to think about
long-term ideas anyhow.
Plus, we hand down decisions about (e.g. string.join) and they have the
exact, parallel discussion over there. All the while, anyone from
PythonDev is telling them: "We've already been through this stuff. We've
already discussed this." which only (understandably) annoys them more.
> and any discussion will
> probably be crossposted to the point where it makes no difference.
I think that python-dev's role should change. I think that it would
handle day to day implementation stuff -- nothing long term. I mean if
the noise level on python-lang was too high then we could retreat to
python-dev again but I'd like to think we wouldn't have to. A couple of
sharp words from Guido or Tim could end a flamewar pretty quickly.
--
Paul Prescod - ISOGEN Consulting Engineer speaking for himself
"I want to give beauty pageants the respectability they deserve."
- Brooke Ross, Miss Canada International
I just looked at Jeremy Hylton's warts posting
at <http://starship.python.net/crew/amk/python/writing/warts.html>
It reminded me that one feature I really, really want in Python 3000
is the ability to declare constants. Assigning to a constant should
raise an error.
Is this on the to-do list?
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>
What, then is law [government]? It is the collective organization of
the individual right to lawful defense."
-- Frederic Bastiat, "The Law"
Another one for the combined distutils/python-dev braintrust; apologies
to those of you on both lists, but this is yet another distutils issue
that treads on python-dev territory.
The problem is this: some module distributions need to install files
other than code (modules, extensions, and scripts). One example close
to home is the Distutils; it has a "system config file" and will soon
have a stub executable for creating Windows installers.
On Windows and Mac OS, clearly these should go somewhere under
sys.prefix: this is the directory for all things Python, including
third-party module distributions. If Brian Hooper distributes a module
"foo" that requires a data file containing character encoding data (yes,
this is based on a true story), then the module belongs in (eg.)
C:\Python and the data file in (?) C:\Python\Data. (Maybe
C:\Python\Data\foo, but that's a minor wrinkle.)
Any disagreement so far?
Anyways, what's bugging me is where to put these files on Unix.
<prefix>/lib/python1.x is *almost* the home for all things Python, but
not quite. (Let's ignore platform-specific files for now: they don't
count as "miscellaneous data files", which is what I'm mainly concerned
with.)
Currently, misc. data files are put in <prefix>/share, and the
Distutil's config file is searched for in the directory of the distutils
package -- ie. site-packages/distutils under 1.5.2 (or
~/lib/python/distutils if that's where you installed it, or ./distutils
if you're running from the source directory, etc.). I'm not thrilled
with either of these.
My inclination is to nominate a directory under <prefix>lib/python1.x
for these sort of files: not sure if I want to call it "etc" or "share"
or "data" or what, but it would be treading in Python-space. It would
break the ability to have a standard library package called "etc" or
"share" or "data" or whatever, but dammit it's convenient.
Better ideas?
Greg
--
Greg Ward - "always the quiet one" gward(a)python.net
http://starship.python.net/~gward/
I have many CHARTS and DIAGRAMS..
from comp.lang.python:
> Thanks for the info. This choice of name is very confusing, to say the least.
> I used commandline completion with __buil TAB, and got __builtins__.
a simple way to avoid this problem is to change global_matches
in rlcompleter.py so that it doesn't return this name. I suggest
changing:
if word[:n] == text:
to
if word[:n] == text and work != "__builtins__":
Comments?
(should we do a series of double-blind tests first? ;-)
</F>
"People Propose, Science Studies, Technology Conforms"
-- Don Norman
