Mailman 3 November 2002 - Python-Dev

Killing off bdist_dumb
by A.M. Kuchling 16 Nov '02

16 Nov '02

[CC'ed to python-dev, distutils-sig; followups to distutils-sig] In the commentary attached to bug #410541, I suggest removing the bdist_dumb command, because no interesting platforms actually install from zip files. Are there any platforms Python supports, such as Slackware, BeOS, AtheOS, or whatever, where the convention is to do binary installations from .zip files? Any objections to killing bdist_dumb? --amk (www.amk.ca) ROSALIND: My pride fell with my fortune. -- _As You Like It_, I, ii

11 30

RE: [Distutils] Killing off bdist_dumb
by Andrew MacIntyre 15 Nov '02

15 Nov '02

> Andrew, was the use of full paths the problem that kept you > from using it? After revisiting some experiments, I can say that full paths was the issue that kept me from using it. While I note MAL's point about sub-classing, that is only useful from the POV of a module author. My POV is that of a 3rd party who wants to build & distribute installable module binaries to accompany a non-PythonLabs Python binary distribution.

2 1

Re: [Python-Dev] Adopting Optik
by Guido van Rossum 15 Nov '02

15 Nov '02

> > I want to start working on an alpha release of Python 2.3. I'd like > > to be able to release 2.3a1 before Xmas. PEP 283 has a list of things > > to be done. One of the tasks is to adopt Greg Ward's options parsing > > module, Optik. I propose to adopt this under the name "options". Any > > comments? > > What about the discussion in May 2002: > http://mail.python.org/pipermail/getopt-sig/2002-May/000191.html Looking at the code, I think there are too many classes to speak about a single dominant class; then the guideline becomes "use short, lower-case module names". Cute names are against Python's tradition IMO. > Since some projects (for exmaple docutils) already started to use > Optik it is becoming increasingly late for a name change. The docutils author can speak for himself; I think docutils can deal with the change. It's also simple enough to add something like this: try: from options import OptionParse except ImportError: from optik import OptionParse --Guido van Rossum (home page: http://www.python.org/~guido/)

16 29

Adopting Optik
by Guido van Rossum 15 Nov '02

15 Nov '02

I want to start working on an alpha release of Python 2.3. I'd like to be able to release 2.3a1 before Xmas. PEP 283 has a list of things to be done. One of the tasks is to adopt Greg Ward's options parsing module, Optik. I propose to adopt this under the name "options". Any comments? --Guido van Rossum (home page: http://www.python.org/~guido/)

11 16

Re: [getopt-sig] Re: [Python-Dev] Adopting Optik
by Guido van Rossum 15 Nov '02

15 Nov '02

In the choice between optlib and argvparse, argvparse wins by a landslide. But I came up with a better one: optparse! This addresses the argument by several Davids that argv is obscure to newbies. I think it doesn't sound like optimization like optlib does. optparse also seems to be what Ruby uses (it even has an OptionParser class :-), and I found an optparse.tcl on the net too. I also note that the recommended rhythm looks better as from optparse import OptionParser than as from argvparse import OptionParser --Guido van Rossum (home page: http://www.python.org/~guido/)

3 2

Python interface to attribute descriptors
by Phillip J. Eby 15 Nov '02

15 Nov '02

To answer your question about getting attribute names, take a look at: http://cvs.eby-sarna.com/PEAK/src/peak/binding/once.py?rev=1.22&content-typ… It's a working example of a use of a metaclass (ActiveDescriptors) that will "activate" descriptors added to it, and tell them their names. You'll note that the descriptor objects make copies of themselves when activated, if the name given to them differs from the name they "guessed" when they were created. This is so that descriptors can be safely shared and reused in multiple classes (or even the same one) under different names. peak.binding.once is of course just a small part of the PEAK system, but if you want to use the code, you can. You'll need to strip out some of the PEAK specifics like IBindingFactory, EigenRegistry, and importObject, though. Really, probably all you need for what you're doing is this part: class ActiveDescriptors(type): """Type which gives its descriptors a chance to find out their names""" def __init__(klass, name, bases, dict): for k,v in dict.items(): if isinstance(v,ActiveDescriptor): v.activate(klass,k) super(ActiveDescriptors,klass).__init__(name,bases,dict) class ActiveDescriptor(object): """This is just a (simpler sort of) interface assertion class""" def activate(self,klass,attrName): """Informs the descriptor that it is in 'klass' with name 'attrName'""" raise NotImplementedError and then define a base class which has ActiveDescriptors as its metaclass, and use it for all your classes that will use ActiveDescriptor-subclass instances.

1 0

Python interface to attribute descriptors
by Paul F Dubois 15 Nov '02

15 Nov '02

Like a few other people before me, I was trying to understand and exploit attribute descriptors and in so doing encountered two facts: a. The C-API document doesn't document these functions beyond giving their signatures. This is even true in the development version, as far as I can tell. b. There is no Python API; you can define a class with some methods with the right names and signatures and it will come tantalizingly close to working for some purposes but sooner or later you find that you just aren't allowed to play as a first-class citizen from Python. Has anyone already done either of these tasks? On the bright side, I did manage to make a metaclass without my head going critical. Smoke came out my ears, though.

2 3

Printing and __unicode__
by martin＠v.loewis.de 14 Nov '02

14 Nov '02

In c.l.p, Henry Thompson wondered why printing would ignore __unicode__. Consider this: import codecs stream = codecs.open("/tmp/bla","w", encoding="cp1252") class Foo: def __unicode__(self): return u"\N{EURO SIGN}" foo = Foo() print >>stream, foo This succeeds, but /tmp/bla now contains <__main__.Foo instance at 0x4026e68c> He argues that it instead should invoke __unicode__, similar to invoking automatically __str__ when writing to a byte stream. I agree that this is desirable, but I wonder what the best approach would be: A. Printing tries __str__, __unicode__, and __repr__, in this order. B. A file indicates "unicode-awareness" somehow. For a Unicode-aware file, it tries __unicode__, __str__, and __repr__, in order. C. A file indicates that it is "unicode-requiring" somehow. For a unicode-requiring file, it tries __unicode__; if that fails, it tries __repr__ and converts the result to Unicode. Which of these, if any, would be most Pythonish? Regards, Martin

3 19

Re: [Python-Dev] Printing and __unicode__
by Michael Hudson 14 Nov '02

14 Nov '02

martin(a)v.loewis.de (Martin v. Loewis) writes: > "M.-A. Lemburg" <mal(a)lemburg.com> writes: > > > I think that StringIO and cStringIO should be regarded as > > binary streams without any encoding knowledge. It is easy > > enough to wrap these into Unicode aware streams using the > > codecs.StreamReaderWriter class as is done in codecs.open(). > > Then why did you fix that behaviour when you broke it? Because people had come to rely on it and their code broke in the 2.1 -> 2.2 transition. I don't think it was intentional. At least that's what I remember from the time. This argument suggests that we perhaps shouldn't change StringIO again... Cheers, M. -- I wouldn't trust the Anglo-Saxons for much anything else. Given they way English is spelled, who could trust them on _anything_ that had to do with writing things down, anyway? -- Erik Naggum, comp.lang.lisp

1 0

logging docs needed
by Guido van Rossum 14 Nov '02

14 Nov '02

I've checked in Vinay Sajip's logging package. It is documented at http://www.red-dove.com/python_logging.html. I need a volunteer to convert those docs to LaTeX and check them in. --Guido van Rossum (home page: http://www.python.org/~guido/)

4 5