Mailman 3 January 2004 - Python-Dev

PEP 8 addition: Preferred property style?
by Gerrit Holl Jan. 23, 2004

Jan. 23, 2004

Hello, currently, PEP 8 does not have any advice about the preferred style in defining properties. There are only two places in the standard library where they are used (socket.py and xml/dom/minicompat.py), so that doesn't provide much information either. Personally, I don't like the namespace cluttering caused by defining __get, __set and/or __del. Since I saw someone[0] on c.l.py using it, I always use this style: def mtime(): doc = "Modification time" def get(self): return os.path.getmtime(str(self)) def set(self, t): return os.utime(str(self), (self.atime, t)) return get, set, None, doc mtime = property(*mtime()) I like it, because it's very readable for me, and doesn't clutter the namespace. Two questions about this style: - Is it tolerable to use it in the standard library (PrePEP)? - Should it be advised for or against in PEP 8, or neither? Gerrit [0] http://tinyurl.com/2rydd

4 4

RE: [Python-Dev] RE: Hot-To Guide for Descriptors - Nits! :-)
by Chermside, Michael Jan. 22, 2004

Jan. 22, 2004

François Pinard writes: > Would it be more precise to state: > "... new style objects or classes (those for which the meta-class is a > subtype of `type')"? Being sub-classed from object or type is just a > way, among others, for identifying `type' as the meta-class; but being > sub-classed from object is not really required. Raymond Hettinger responds: > Nope, new-style is taken to mean objects/classes inheriting from > object/type. Meta-class objects are neither new-style nor old-style. > While there is room to argue with this arbitrary distinction, it is > consistent with Guido's essay and especially relevant to my article > because most of the rules don't necessarily apply when meta-classes > are used. This is because the machinery for descriptors is > embedded in type.__getattribute__ and object.__getattribute__. > Override or fail to inherit either of these and all bets are off. Really? I realize the utility of having a term for objects-with-a- meta-type-of-type, but I had always understood "new-style" to mean things-that-are-not-old-style-classes. I can live with either definition, but the Python community should make sure that we use the term "new-style class" in a consistent fashion. Did everyone else agree with Raymond so François and I are the odd men out, or is there a larger confusion over how we use the term? -- Michael Chermside This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.

11 18

Hot-To Guide for Descriptors - Nits! :-)
by François Pinard Jan. 22, 2004

Jan. 22, 2004

Hello, Raymond. Cc:ing python-dev, so others can bash me as well! :-) This is about `http://users.rcn.com/python/download/Descriptor.htm'. Before anything else, let me thank you for having written this essay! Please also take all my remarks with a grain of salt or two, as I'm far for pretending I really understand all the matters here. * In `Definition and Introduction', a parenthetical note "(ones that subclass `object' or `type')" qualifies the expression "new style objects or classes". Not being an English speaker, I'm a little mixed up with the plural "ones" and the fact I was expecting "subclasses" instead of "subclass", maybe replacing "ones" by "those" would be clearer. * Another point is that the phrasing suggests that the parenthetical note is a definition for what precedes it. In my understanding, the parenthetical note implies what precedes it, but is not implied by it. A new-style instance may well have no base class at all, only given its meta-class is a subtype of `type'. Would it be more precise to state: "... new style objects or classes (those for which the meta-class is a subtype of `type')"? Being sub-classed from object or type is just a way, among others, for identifying `type' as the meta-class; but being sub-classed from object is not really required. * In `Descriptor Protocol', it might help a bit saying immediately a word or two about the `type=None' argument. Looking down for some hint, the box holding "def __getattribute__(self, key): ..." uses the statement "return v.__get__(None, self)", which I find confusing respective to the `__get__' prototype, as `obj' corresponds to None, and `type=None' likely corresponds to an instance instead of a type. * In `Invoking Descriptors', it might help a bit insisting on the (presumed) fact that `hasattr' itself does not look for descriptors. For symmetry, it would also be nice having two boxes defining `__getattribute__, one for objects, another for classes, instead of only the second one. I was not sure if the assymetry had a purpose, like maybe telling us that the first case may not be expressed using Python. * A little below is a quick description of `super()'. It says that "The call ... searches ... mro ... for the base class ... immediately preceding ...". Should not it be `following' instead of `preceding'? In case yes, than maybe `A' and `B' might be exchanged for clarity. * In `Properties', the box starting with "class Property(object):" raises a few questions. First is the `doc or ""' to defined `self.__doc__', it does not seem that the ` or ""' exists in Python 2.2.1 nor 2.3.2, the __doc__ really defaults to None. Second is that the argument `objtype=None' to `__get__' is unused, and once more, this does not help understanding its purpose, maybe some explanation would be welcome about why it exists and is unneeded in the context of `property'. Third is that on the last line, "self.fdel(obj, value)" was probably meant to be "self.fdel(obj)". -- François Pinard http://www.iro.umontreal.ca/~pinard

3 4

PyCon price schedule correction
by Guido van Rossum Jan. 22, 2004

Jan. 22, 2004

In my previous announcement, I wrote: > This is a reminder that the deadline for early bird registration for > PyCon DC 2004 is February 1, 2004. Early bird registration is $175; > after that, it will be $200 through March 17, then $250 at the door. Unfortunately this gave a too rose-colored view on the not-so-early registration fees. The correct price schedule is: - Early bird (through Feb 1) $175 - Normal reg (until March 17) $250 <-- correction! - Walk-ins $300 <-- correction! To register, visit: http://www.pycon.org/dc2004/register/ I urge everybody coming to the conference to register ASAP -- save yourself or your employer $75!!! You have until February 1st. --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

The os module, unix and win32
by Barry Scott Jan. 22, 2004

Jan. 22, 2004

Why does popen5 needs a C implementation on windows where as on unix it can be implemented in python? Answer: because the unix API is in standard python where as the windows one is not. win32all covers a huge number of API functions, more then would be sane to add to os. But would there be any mileage in added enough from win32all to allow problems like popen5 to be implemented? There is already the _reg module that has some win32 functions in it on the standard install. Barry

10 19

Configure option to change Python's name?
by Jack Jansen Jan. 22, 2004

Jan. 22, 2004

This idea is only half-baked, so please fire away, or tell me to go ahead, or go hide under a stone. I would like a configure option that changes the name of "python" everywhere: in the executable, in the dynamic library name, the MacOSX framework name, etc. This would allow you to have two Pythons on a system that are completely 100% independent of each other. The idea was triggered by Michael Hudson, who wanted to install a debugging-enabled framework build of Python on MacOSX, which shouldn't interfere with the normal Python (either Apple-installed or user-installed). It turns out this is doable through meticulous hacking of the Makefile after configure (and, for now, ignoring the few hardcoded "Python.framework" references in Lib, but those need fixing anyway). For other unix systems a similar approach would work to isolate a debug-python from the normal production python. But then I thought of another use: this would allow you to have a MacPython 2.3.3 distribution as well as the Apple-installed 2.3 distribution without any interference possible. And there are probably similar uses on other platforms. -- Jack Jansen, <Jack.Jansen(a)cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman

5 6

RE: [Python-Dev] Draft: PEP for imports
by Batista, Facundo Jan. 22, 2004

Jan. 22, 2004

Aahz wrote: #- Here are the contenders: #- #- from .foo import #- #- from ...foo import I think the following idea maybe is too radical, but well... I don't use packages, but when I read the tutorial first time, I wondered why, if the packages appeared to solve a 'pack into a directory' problem, the names were joined with '.' instead of '/'. Later I found some other uses to the 'unix path' notation. For example: - Module inside a package: import package/module - Relative import: import ../../otherpack/webmodules/somemodule - Importing a personal module when you have a program in several places but not enough permission to write in the site-packages directory: import /home/facundo/python/modules/myModule (you can do this with "import sys" and "sys.path.append('...')", but seems an overhead to me). Regards, . Facundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVERTENCIA La información contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por la ley. Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no está autorizado a divulgar, copiar, distribuir o retener información (o parte de ella) contenida en este mensaje. Por favor notifíquenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones Personales S.A. o alguna empresa asociada. Los mensajes electrónicos pueden ser alterados, motivo por el cual Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación cualquiera sea el resultante de este mensaje. Muchas Gracias.

4 3

[leadership/opensource] invitation to online survey
by NeXTstep Jan. 22, 2004

Jan. 22, 2004

Dear all, I have just put online a survey addressing the topic of "good leadership in the open-source environment". Basically, my objective is to identify the personal conceptions of good leadership that reside in the minds of the contributors, in terms of leaders' _behaviors_ and _characteristics_. What is a good open-source project leader, from the contributor's point of view? To what extent, those personal believes are shared among developers? Can the contributor's national cultural belonging and level of experience in contributing to open-source projects explain such differences in their idea of what a good leader is? I would really appreciate your participation to the survey! Contribution (completely anonymous) consists in rating a list of statements that may be used to describe the behaviors of an open-source leader. It will take around ten minutes - there aren't any "time-consuming" open ended questions;) Following, the link to the survey: http://freeonlinesurveys.com/rendersurvey.asp?id=49776 If you are interested, I will not miss to email you a link to the final report, when ready ;) (approx, a couple of months from now) Thank you in advance, and don't hesitate to contact me if you have any questions or comments :) Gianluca Bosco g.bosco(a)GETRIDOFTHISinwind.it Denmark Technical University Department of manufacturing engineering and management P.s. Please, feel free to spread the voice about this survey, if you think it's worth :)

1 0

dict.addlist()
by Raymond Hettinger Jan. 22, 2004

Jan. 22, 2004

Here is anidea to kick around: Evolve and eventually replace dict.setdefault with a more specialized method that is clearer, cleaner, easier to use, and faster. d.addlist(k, v) would work like d.setdefault(k, []).append(v) Raymond Hettinger >>> d = dict() >>> for elem in 'apple orange ant otter banana asp onyx boa'.split(): ... k = elem[0] ... d.addlist(k, elem) ... >>> d {'a': ['apple', 'ant', 'asp'], 'b': ['banana', 'boa'], 'o': ['orange', 'otter', 'onyx']} bookindex = dict() for pageno, page in enumerate(pages): for word in page: bookindex.addlist(word, pageno)

12 17

PyCore sprint for 2004?
by Nick Bastin Jan. 22, 2004

Jan. 22, 2004

This may not be the right place for this, but is there not going to be a PyCore sprint at PyDC 2004? I presume at least *some* people here are planning on attending.. ;-) -- Nick

5 6