Mailman 3 January 2004 - Python-Dev

prePEP "Decimal data type" v0.2
by Batista, Facundo Jan. 5, 2004

Jan. 5, 2004

I finished the second version of the prePEP for the Decimal data type. Sorry for the delay, but I restructured it to new (thanks list), and changing to a new house and deploying GSM in Argentina are not very time-freeing tasks, :p I don't post it to the list because it was blocked in c.l.p because it's size. You can reach it here: http://www.taniquetil.com.ar/facundo/python/prePEP-Decimal-0.2.html I'll appreciate any suggestion. Thank you! . Facundo

2 1

Re: [Python-Dev] Re: PEP 326: A Case for All
by Josiah Carlson Jan. 5, 2004

Jan. 5, 2004

Because All has generated as much disagreement as Some did initially, All is definitely a poor name. None being smaller than all other values was an arbitrary decision, and may not be the case in the future. Relying on it is probably not a good idea - especially considering that most people do not know that it could be used in this way. (Also noted by multiple people) If None should not be relied upon, but the existance of a top and bottom value limit make sense (a few people believe that it does), then really we need two values. Terry Reedy suggested making those objects attributes of the cmp builtin. This has the notable side-benefit of not polluting the builtins namespace (YAY!). Terry also suggested that the attributes be cmp.hi and cmp.lo, which seem to be obvious attribute names for what they are. String representations for them are certainly up for debate, ObjHi/ObjLo, NoneHi/NoneLo, Highest/Lowest, Infinity/NegativeInfinity were offered. My only concern is that eval(repr(cmp.hi)) == cmp.hi and eval(repr(cmp.lo)) == cmp.lo be true, but I am leaning toward Highest/Lowest or hi/lo. The names Infinity and NegativeInfinity seem to suggest numbers. Numbers can have math done on them. Certainly there are a certain set of behaviors that make sense, but then there are others that don't (like Infinity - Infinity). Whatever the top and bottom value limit end up being called, whether or not they should allow math to be done on them is probably up for debate. Independant implementations of the top/bottom idea suffer from the ordering of operands to a comparison function making a difference in the result. This may be a problem when an algorithm is written with one top value in mind, yet another comes in and could gum up the works. I've got another draft of my PEP that addresses the above comments and concerns, and provides examples. I'm going to sleep on it before submitting the changes. - Josiah

3 2

RE: [Python-Dev] New version of installer
by Batista, Facundo Jan. 5, 2004

Jan. 5, 2004

Martin v. Loewis wrote: #- I have put a new version of the installer at #- #- http://www.dcl.hpi.uni-potsdam.de/home/loewis/python2.4.0.12421.msi #- ... #- ... #- I'm particularly interested in whether this can be installed and #- run successfully on Windows 95 (and other W9x versions). If you don't #- have installer, get it from I'll try it on w95. Just to get the test as close as posible to your expectations, should I uninstall Python2.3 first? . 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.

1 0

RE: [Python-Dev] Toowtdi: Datatype conversions
by Robert Brewer Jan. 5, 2004

Jan. 5, 2004

Raymond Hettinger wrote: > Choosing between: > > list(d) or d.keys() > > Which is the one obvious way of turning a dictionary into a list? > IMO, list(d) is it. Except that, "turning a dictionary into a list" as an English phrase is indeterminate--do you want the keys or the values or both? list(d) happens to choose the keys, but that doesn't make it the "one obvious way". If I were being introduced to list() for the first time, I would probably expect/desire it to be lossless, producing something like d.items() instead. > So, one question is whether set() and frozenset() should grow an > analogue to the keys() method: > >>> set('banana').elements() > ['a', 'b', 'n'] I don't think so, for the reason that .keys() is effectively a disambiguator as I just described. With sets, there is no mapping, and therefore no ambiguity. Robert Brewer MIS Amor Ministries fumanchu(a)amor.org

2 1

SF patch 864863: Bisect C implementation
by Raymond Hettinger Jan. 5, 2004

Jan. 5, 2004

Dmitry Vasiliev has submitted a C implementation for the bisect module. My thoughts are to accept it with the following changes: * leave the original code intact for teaching purposes * import the C version from _bisect * make sure the C code is not list specific and will work with any container supporting __len__(), __getitem__(), and insert(). Do you guys have any objections? Raymond Hettinger

10 18

Re: PEP 326: A Case for All
by Josiah Carlson Jan. 5, 2004

Jan. 5, 2004

> PEP 326 reads: > > Users of Python have had the constant None, which represents a lack of > > value, for quite some time (possibly from the beginning, this is > > unknown to the author at the current time). The author believes that > > ``All`` should be introduced in order to represent a functionally > > infinite value, with similar behavior corresponding to None. [Gerrit Holl] > I think the described behavious of None is one of the rarest uses of > None. Actually, I didn't even know of the existence of this behaviour. > I think None is mainly used to show the absence of *anything*: when a > function does not return a value, it return None, when some variable > does not have a value yet, it may be set to None, when a HTTP connection > is not opened yet, it's socket is None, etc. As previously offered by Tim Peters: http://mail.python.org/pipermail/python-dev/2003-December/041374.html The behavior of None being smaller than anything else was a concious decision. The use of All doesn't change the behavior of None. How people end up using All in their algorithms is up to them. Does the Python language restrict the usage of None? Of course not. Just as a function can return None (as a signal to the caller), a function can now return All as a signal to the caller. Further uses of All will be left as an exercise to whomever wants to use it. > > Introducing an ``All`` built-in that works as described does not take > > much effort. A sample Python implementation is included. > > I don't think it is used very often. ``All`` is not a very > straightforward name as well. The implementation is created very > quickly: it can be done much simpler than you did, although it won't be > called All then: > > class Infinity(object): > def __cmp__(self, other): > return 1 The problem with your ``Infinity`` implementation is that it compares greater than itself and doesn't follow the standard python object convention of: a = obj;b = eval(repr(obj));a == b >>> class Infinity(object): ... def __cmp__(self, other): ... return 1 ... >>> I = Infinity() >>> I == I 0 >>> I is I 1 >>> I <__main__.Infinity object at 0x007A5720> The implementation that I offer in the PEP fixes the problem with your ``Infinity`` implementation. > This is usable everywhere you describe. Because ``All`` is not a very > straightforward name, I think the namespace cluttering is worse than the > advantages. To convince me, I think you'll need to come up with a better > name. It isn't ``All`` really, because that makes sence only with > container types, it isn't ``Infinity`` because that makes sense only > with numbers (strings?), so this is the biggest problem of your > proposal. All is a resonably lengthed name for the concept of 'bigger than anything'. This was independantly offered by two developers on the python-dev mailing list: Tim Peters: http://mail.python.org/pipermail/python-dev/2003-December/041337.html David LeBlanc http://mail.python.org/pipermail/python-dev/2003-December/041386.html It also has a similar naming semantic of None. What is the opposite of None (conceptually)? All of course. - Josiah

3 4

New version of installer
by Martin v. Loewis Jan. 4, 2004

Jan. 4, 2004

I have put a new version of the installer at http://www.dcl.hpi.uni-potsdam.de/home/loewis/python2.4.0.12421.msi This fixes all problems I know of, in particular: - pyconfig.h, wininst.exe, and msvcr71.dll are installed - an "Advanced" dialog offers choice of registering extensions, and of all-users-vs-just-me installation If you find further problems, please let me know. I'm particularly interested in whether this can be installed and run successfully on Windows 95 (and other W9x versions). If you don't have installer, get it from http://www.microsoft.com/downloads/release.asp?ReleaseID=17343 Regards, Martin

3 3

Re: [Python-checkins] python/dist/src/Lib timeit.py, 1.15, 1.16
by Guido van Rossum Jan. 4, 2004

Jan. 4, 2004

> Make timings more consistent by temporarily disabling GC. Shouldn't this be an option at best? What if I want to time some code that expects GC to be on? --Guido van Rossum (home page: http://www.python.org/~guido/)

2 2

Enhancing PEP 310 (or conflating, your decision :-)
by Holger Krekel Jan. 4, 2004

Jan. 4, 2004

hello python-dev, and hello Michael and Paul, here are, eventually, some remarks, ideas and food for thought regarding PEP 310. ++ with with yield The 'with' as proposed by PEP 310 implements semantics that you can today implement with a try-finally construct. (see the PEP for explanation). But I think that we can make PEP 310 do better than try-finally in that we can allow yield inside with-blocks. Let's recap PEP 310 quickly: __enter__ is called upon entering a with code block __exit__ is called upon leaving a with code block (should be renamed '__leave__' which i do subsequently :-) Compared to the try-finally statement we explicitely have some crucial information: the __enter__ method which encapsulates the prepare/acquire code for the block. Thus we could specifically allow: with handler(): for x in someiter: yield x and define the semantics so that handler.__enter__ is called every time the generator frame resumes execution and handler.__leave_ when it is suspended/destroyed [*]. (It *may* also be feasible to indicate the specific reason for leaving the code block (suspend/finish) to the __leave__ method or probably better to call another method). PEP325 proposes a coarser-grained "close" method on generators that is triggered when the generator has finished work. In constract, the above semantic extension of PEP 310 allows finer-grained locking as seen when using locks/critical regions as it directly allows yield within try-finally-alike semantics. ++ with and exceptions In an independent consideration, it would be useful if we had a way to react on exceptions from the with-object, say with an __except__ method that retrieves exceptions from 'its' code block. I am not sure, however, that this can be implemented in a straight forward way (Michael commented on this earlier with a similar sentiment IIRC). But it does seem to be a nice abstraction that you can provide an object that encapsulates how you deal with exceptions because you can change exception-handling code in *one* place instead of possibly many scattered try-finally/except-locations. ++ with loops In another independent consideration, we could extend PEP 310 to enable loop-constructs: the __leave__ method returns True if it wants the interpreter to revisit the code-block. Well this one is really more food for thought more than anything else but ... taking and combinining the above ideas we might be able to make with line in file(somefn): # work with line (probably even yield it ...) # the file is guaranteed to be closed here! work with clean semantics. Hmmm, IIRC Armin Rigo had a similar suggestion to reuse the 'for' statement instead of introducing a new with-keyword alltogether. This doesn't sound too far away now, anymore :-) ++ cheers and a happy new year, holger [*] disclaimer: I am not entirely sure if this can be implemented in a straight forward way but it shouldn't be too hard :-)

1 0

Toowtdi: Datatype conversions
by Raymond Hettinger Jan. 4, 2004

Jan. 4, 2004

Choosing between: list(d) or d.keys() Which is the one obvious way of turning a dictionary into a list? IMO, list(d) is it. Which is the fastest? timeit.Timer() says d.keys() is several times faster. So, one question is whether set() and frozenset() should grow an analogue to the keys() method: >>> set('banana').elements() ['a', 'b', 'n'] This speeds-up the uniquification use case but comes at the expense of fattening the API and adding a second way to do it. Another question is whether there should be a method for conversion to a dictionary. Given the absence of use cases, the answer is no, but assuming there were, what would be the right way to go? set.asdict() would be several times faster than dict.fromkeys(s). One bright idea is to make the constructors a little bit smarter so that list(d) would automagically invoke d.keys() whenever d is a dictionary. The problem with this idea is that list creation is separate from list initialization. list.__init__() starts with an existing list and replaces its contents with the initializer. The precludes returning a list built by d.keys(). The situation for dicts is similar although there is a curious difference, dict.__init__() updates rather than replaces the contents of the underlying dictionary. Another bright idea is to support faster datatype conversion by adding an optional __len__() method to the iteration protocol so that list(), tuple(), dict(), and set() could allocate sufficient space for loading any iterable that knows its own length. The advantages are faster type conversion (by avoiding resizing), keeping the APIs decoupled, and keeping the visible API thin. This disadvantage is that it clutters the C code with special case handling and that it doesn't work with generators or custom iterators (unless they add support for __len__). Raymond Hettinger

4 5