Mailman 3 March 2005 - Python-Dev

Adding any() and all()
by Guido van Rossum 16 Mar '05

16 Mar '05

See my blog: http://www.artima.com/forums/flat.jsp?forum=106&thread=98196 Do we even need a PEP or is there a volunteer who'll add any() and all() for me? -- --Guido van Rossum (home page: http://www.python.org/~guido/)

26 38

BRANCH FREEZE for 2.4.1rc2 at 2005-03-18 0000 UTC
by Anthony Baxter 16 Mar '05

16 Mar '05

The release24-maint branch should be considered FROZEN as at 0000 UTC on 2005-03-18 - in other words, in about 11 hours time. Allegedly this is around 1900 on the 17th for the US East Coast. I'll post again once it's unfrozen. From here, we'll be aiming at a 2.4.1 final for the 29th - straight after PyCon. I'll post again when the branch is available for checkins. And I'll repeat my request for people to be ultra-conservative with checkins to the branch until 2.4.1 final is out. If in doubt, ping me first. Those contact details again: AIM: anthonyatekit Jabber: anthonyatekit(a)jabber.org IRC: #python-dev on Freenode. Thanks, Anthony -- Anthony Baxter <anthony(a)python.org> It's never too late to have a happy childhood.

2 1

(no subject)
by Michael Chermside 16 Mar '05

16 Mar '05

Nick Coghlan writes: > Patch against current CVS added to SF with the behaviour: > > def update_meta(self, other): > self.__name__ = other.__name__ > self.__doc__ = other.__doc__ > self.__dict__.update(other.__dict__) Nice... thanks. But I have to ask: is this really the right set of metadata to be updating? Here are a few things that perhaps ought be copied by update_meta: f.__name__ (already included) f.__doc__ (already included) f.__dict__ (already included) f.__module__ (probably should include) f.func_code.co_filename (to match f.__name__, but I'd leave it alone) there's also the annoying fact that in IDLE (and in some other python-aware IDEs) one can see the argument signature for a function as a "tool tip" or other hint. Very handy that, but if a decorator is applied then all you will see is "func(*args, **kwargs)" which is less than helpful. I'm not sure whether this CAN be duplicated... I believe it is generated by examining the following: f.func_code.co_argcount f.func_code.co_varnames f.func_code.co_flags & 0x4 f.func_code.co_flags & 0x8 ...and I suspect (experimentation seems to confirm this) that if you mangle these then the code object won't work correctly. If anyone's got a suggestion for fixing this, I'd love to hear it. -- Michael Chermside

5 7

comprehension abbreviation (was: Adding any() and all())
by Jim Jewett 15 Mar '05

15 Mar '05

Barry: > Ping's suggested list comprehension abbreviation, i.e.: > [x in seq if x] == [x for x in seq if x] > might help. Note that the last x shouldn't have to be x. [x in seq if f(x)] is by far my most common syntax error, and [x for x in seq if f(x)] is always what I want instead.

11 15

RE: [Python-Dev] Rationale for sum()'s design?
by Batista, Facundo 15 Mar '05

15 Mar '05

[Guido van Rossum] #- 3.0 is soon?!? *You* should answer this, ;) . Facundo Bitácora De Vuelo: http://www.taniquetil.com.ar/plog PyAr - Python Argentina: http://pyar.decode.com.ar/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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] Rationale for sum()'s design?
by Michael Chermside 15 Mar '05

15 Mar '05

Tim writes: > I'd personally be delighted if sum() never worked on anything other > than numbers. Guido writes: > I think the conclusion should be that sum() is sufficiently > constrained by backwards compatibility to make "fixing" it impossible > before 3.0. But in 3.0 I'd like to fix it so that the 2nd argument is > only used for empty lists. Guido, I find myself far more convinced by Tim's suggestion than yours. This all started with your claim that sum() was a replacement for most reduce() uses. We all agree that it works fine for summing up numbers. We all agree it DOESN'T work for any case where the operator isn't __add__. So trying to make it work well for non-numbers is just arguing over whether it replaces 75% of all reduce() uses, or 85% of them. Who cares? Remember, *ANY* use of sum() can be replaced by a simple, readable, three line for loop: total = <starting-value> for i in <list-of-values> total += i And for that matter, other uses of reduce are similarly easy to write as a loop. I'm not saying reduce() is useless, just that it's not worthwhile to expend effort trying to cover every last use case with things like sum() or product() -- one can always write the loop instead. What I think is MORE important is that sum() have predictable behavior in the degenerate cases. And by "predictable", I mean predictable by a newbie user or one someone who hasn't looked at the docs for sum() for the past year and mostly remembers what it does only because the name is so blatantly obvious. _IF_ we follow Tim's advice and think of sum() as designed to add up numbers (as the name implies), then the corner cases are obvious: summing a list of 1 item should return the item, and summing a list of 0 items should return 0. If we think of sum as a form of reduce() that operates only on the __add__ operator, then we need to make other choices for these corner cases, and the people using it to add numbers will suffer the small indignity of having to recall how the corner case works. Honestly, the only case I even remotely care about is concatenating strings -- as far as _I_ am concerned, everyone else can just write out the loop or provide their own "sum_matrix()" method. And if I understand correctly, there's no plan to make sum() "just work" for concatenating strings (besides which, we'd still need to handle the empty list). So I'm in favor of REMOVING the second argument of sum() for python 3000, unless it was kept purely for "backward compatibility" reasons, which would be defeated by changing it's behavior. (And if this doesn't convince you, then so be it... this isn't a particularly important issue.) -- Michael Chermside

2 1

RE: [Python-Dev] Rationale for sum()'s design?
by Batista, Facundo 15 Mar '05

15 Mar '05

[Guido van Rossum] #- > 1. When omitting the second argument, would supplying an #- empty list return 0, #- > None or raise an exception? #- #- Good question... I'd go for None: - Is a good default for a non-existing argument. - If won't get None from sum() in other case (unless you do sum(None), but you should be aware of that). . Facundo Bitácora De Vuelo: http://www.taniquetil.com.ar/plog PyAr - Python Argentina: http://pyar.decode.com.ar/

1 0

can we stop pretending _PyTyple_Lookup is internal?
by Michael Hudson 15 Mar '05

15 Mar '05

It's needed to implement things that behave like instance methods, for instance, and I notice that at at least some point in the past Zope3 has used the function with a note attached saying "Guido says this is OK". Also, the context is that I want to submit a patch to PyObjC using the function, and doing a little digging revealed that PyObjC already has a copy & paste copy of _PyType_Lookup, presumably to avoid using an internal API. I don't think this does anyone any good. Thoughts? Cheers, mwh -- 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

3 3

Exception needed: Not enough arguments to PyArg_ParseTuple
by Edward C. Jones 14 Mar '05

14 Mar '05

I had PyArg_ParseTuple(args, "s#s#i:compare", &p1, &bytes1, &p2, &bytes2) in a program. There are not enough arguments to PyArg_ParseTuple. Does PyArg_ParseTuple know how many arguments it is getting? If so, I suggest that an exception should be raised here.

3 2

RE: [Python-Dev] Python2.4.1c1 and win32com
by Leeuw van der, Tim 14 Mar '05

14 Mar '05

Bug has been filed with id 1163244. regards, --Tim -----Original Message----- From: "Martin v. Lowis" [mailto:martin@v.loewis.de] Sent: Saturday, March 12, 2005 3:12 PM To: Leeuw van der, Tim Cc: python-dev(a)python.org Subject: Re: [Python-Dev] Python2.4.1c1 and win32com Leeuw van der, Tim wrote: > The generated files crash the Python interpreter with Python 2.4 > > Under Python 2.4.1c1, They give a syntax error!? [...] So I think this needs to be investigated; please submit a bug report, including the Python file that causes the crash. Regards, Martin

1 0