Python-Dev May 2000

python-dev@python.org

52 participants
93 discussions

Comparison inconsistency with ExtensionClass
by Greg Ward 06 Jul '00

06 Jul '00

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

4 3

What's that sound?
by Paul Prescod 01 Jun '00

01 Jun '00

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

6 8

Adding LDAP to the Python core... ?!
by M.-A. Lemburg 01 Jun '00

01 Jun '00

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/

4 7

Re: [Python-Dev] SIG: python-lang
by Ken Manheimer 31 May '00

31 May '00

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

2 1

SIG: python-lang
by Paul Prescod 31 May '00

31 May '00

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)

6 12

Re: [Python-Dev] SIG: python-lang
by Andrew M. Kuchling 31 May '00

31 May '00

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

2 1

Re: [Python-Dev] SIG: python-lang
by Paul Prescod 31 May '00

31 May '00

"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

2 1

Constants
by Eric S. Raymond 31 May '00

31 May '00

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"

3 2

Where to install non-code files
by Greg Ward 31 May '00

31 May '00

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

10 20

Q: maybe rlcompleter shouldn't expose __builtins__?
by Fredrik Lundh 31 May '00

31 May '00

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

2 1

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev May 2000