Mailman 3 August 2004 - Python-Dev

Re: [Python-Dev] Re: 2.4a2, and @decorators
by Edward Loper Aug. 3, 2004

Aug. 3, 2004

> It's also entirely possible that "most people" were happy with the way > things were going and chose not to post... > > My personal opinion is that the pie syntax is acceptable, and the > continuing debate is doing harm and providing no enlightenment. +1. (Thanks to the people who've devoted so much thought and energy to figuring out the best decorator syntax; I, for one, will be happy to have it available.) -Edward

1 0

RE: [Python-Dev] Fix import errors to have data
by Delaney, Timothy C (Timothy) Aug. 3, 2004

Aug. 3, 2004

Tim Peters wrote: > [Delaney, Timothy C (Timothy)] >> OK - the problem as I see it is that a given module that exists, but >> raises ImportError, only raises ImportError *once*, whereas it really >> should raise ImportError every time > > Jim's after something different, while the problem you're thinking > about is more general than just ImportError. When an import of an > existing module fails for *any* reason, subsequent attempts to import > the same module succeed. For example, Good point. This is the same as not wanting modules in an insane state in sys.modules. I've just gone back over Jim's original email, and it is a different case being talked about there - specifically, determining if an ImportError was thrown by the module that was specifically being imported, rather than something it imports. However, I don't see the utility of that. I definitely can't think of a use case for it. OTOH, ensuring that if *any* exception is thrown when importing a module, it will not appear in sys.modules (and the exception is raised each time you try to import) is IMO a very useful property, and I think would solve what I think is Jim's issue at the root. Tim Delaney

7 21

PEP 309 (partial function application)
by Paul Moore Aug. 3, 2004

Aug. 3, 2004

Should this go into 2.4a2? It's marked as "accepted" in the PEP list, and an implementation exists as SF patch 941881. Paul -- The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair. -- Douglas Adams

2 1

RE: [Python-Dev] Re: PEP 324 (process module)
by Michael Chermside Aug. 3, 2004

Aug. 3, 2004

Guido writes: > I believe ActiveState's Trent Mick has released something > along these lines. Does your proposed API match theirs? Peter replies: [...] > So, the chances of getting our modules API-compatible are very small. I'll note that my impression is that Peter's module is not aiming to be particularly innovative in terms of implementation, it's primary "feature" is having a decent API. And my impression is that it has been well received on c.l.py (for instance, I often see it recommended in response to newbie questions). He got a lot of input during the PEP process and tried to incorporate it. Last time I tried it there were still a few windows issues (docs say these have been resolved), but I thought the API was well-designed. And popen2 isn't. -- Michael Chermside

3 2

RE: [Python-Dev] 2.4a2, and @decorators
by Michael Chermside Aug. 3, 2004

Aug. 3, 2004

James Knight writes: > However, it seems as if this restriction creates a new class of > expression for no gain. It is true enough that *most* python > expressions aren't useful to write after a @, but that's also > true of a > lot of other places an expression can be used (e.g. before a () of a > function call. A list comprehension can never result in a callable > object. An arithmetic operation usually won't.). > > The only real necessary restriction on the @ operator is that its > argument be callable and take a single argument. Many > expressions could > return a callable object. Why not let them? Is it really > worth having a > special case just to SyntaxError expressions that sometimes won't > result in an appropriate callable? > > Things someone might want to do, ordered roughly from most reasonable > to least reasonable ;) > @foo().bar() > @foo or bar > @mydecorators['foo'] > @lambda f: foo(f) or bar(f) > > Why disallow these forms? It seems quite difficult, especially, to > explain why the first one does not, or should not, work. Yeah... what he said. Seriously, a well-designed programming language has very strong orthogonality. A few simple concepts should suffice. "an expression" is an existing production which is well-known to users and well understood. I agree that using complex expressions in a decorator leads to difficult-to-read code, but I would STILL like it to be possible, just so I don't have to remember (or teach) decorators as a special case. -- Michael Chermside

1 0

Re: [Python-checkins] python/dist/src/Lib/test test_threadsignals.py, 1.2, 1.3
by Michael Hudson Aug. 3, 2004

Aug. 3, 2004

fdrake(a)users.sourceforge.net writes: > Update of /cvsroot/python/python/dist/src/Lib/test > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv18587 > > Modified Files: > test_threadsignals.py > Log Message: > add missing import! Oops, sorry! Cheers, mwh -- But maybe I've just programmed in enough different languages to assume that they are, in fact, different. -- Tony J Ibbs explains why Python isn't Java on comp.lang.python

1 0

RE: [Python-Dev] Optimized string concatenation
by Michael Chermside Aug. 3, 2004

Aug. 3, 2004

PLEASE IGNORE PREVIOUS MESSAGE. (I really ought to stop using a mailer which is one accidental click away from sending an unfinished email) Armin writes: > The SF patch http://www.python.org/sf/980695 about making > repeated string > concatenations efficient has been reviewed and is acceptable > on technical grounds. [...] > This leaves open the policy questions: > > * first, is that an implementation detail or a published feature? IMHO, an implementation detail. Specifically, a published feature of CPython, but an implementation detail of the language Python. > * if it is a published feature, what about Jython? And I guess we should ask about Iron Python too. The answer is that they add this optimization if and only if the maintainers of those versions get around to it. Whether it is easily done given the underlying platform is another important consideration. But if we leave it OUT of the language spec then we avoid unnecessarily breaking other implementations. That being said, I'll note that both Jython and Iron Python already use unicode as the basic string type, which is a much bigger change (except to those who manage to use only 7-bit ASCII). > * The patch would encourage a coding style that gives program > that essentially > don't scale with Jython -- nor, for that matter, with 2.3 > or older Yes, but we ALREADY see lots of programs that use that coding style, even though every web page talking about Python optimization lists that as the #1 issue. Whether we like it or not, it seems that especially for novice programmers, the "s = s + x" idiom for accumulating a string is the "obvious" way to do it. Encouraging that may not be good, but going along rather than fighting it seems like a wise idea. > * discussed on SF too is whether we should remove the 'a=a+b' > acceleration > from the patch, keeping only 'a+=b'; see the SF tracker. Hmm... I couldn't think of any reason to limit the optimization to += until I actually went and read the comments in the SF tracker. What I took away from that discussion was that it's possible to optimize "a=a+b", but NOT possible to optimize "a=a+b+c". This is a subtle distinction that is harder to explain to people than simply saying "it only works with +=, not with +". That's a fairly convincing point, so I guess I'm on the fence on this one. > This seems overkill, but should the acceleration be there but > disabled by > default? > > from __future__ import string_concatenate? Absolutely, unconditionally NOT. I'd rather just leave it out. -- Michael Chermside

3 2

RE: [Python-checkins] python/dist/src/Objects listobject.c, 2.218, 2.219
by Raymond Hettinger Aug. 3, 2004

Aug. 3, 2004

> * complain about the unused name. > */ > ! return status, v; > } > > --- 863,867 ---- > * complain about the unused name. > */ > ! return status++, v; Does anyone else see this as perverse? I have to think hard about whether all the compilers are smart enough to optimize this away (probably, but maybe not). More importantly, it is obfuscated C and makes my stomach churn. This particular case introduces several lines for an assertion that is probably not worth the surrounding mess. Does anyone have a better way? Raymond

5 4

RE: [Python-Dev] Optimized string concatenation
by Batista, Facundo Aug. 3, 2004

Aug. 3, 2004

[Armin Rigo] #- s = '' #- for x in y: #- s += some_string(x) #- #- This leaves open the policy questions: #- #- * first, is that an implementation detail or a published feature? Depending on how much slower (if still) is now this idiom against... l = [some_string(x) for x in y] s = ''.join(l) ...maybe we should stop concatenating strings. One or two points of the FAQs should be reviewed, but only after a speed comparison. . 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] Optimized string concatenation
by Michael Chermside Aug. 3, 2004

Aug. 3, 2004

Armin writes: > The SF patch http://www.python.org/sf/980695 about making > repeated string > concatenations efficient has been reviewed and is acceptable > on technical grounds. [...] > This leaves open the policy questions: > > * first, is that an implementation detail or a published feature? IMHO, an implementation detail. Specifically, a published feature of CPython, but an implementation detail of the language Python. > * if it is a published feature, what about Jython? And I guess we should ask about Iron Python too. The answer is that they add this optimization if and only if the maintainers of those versions get around to it. Whether it is easily done given the underlying platform is another important consideration. But if we leave it OUT of the language spec then we avoid unnecessarily breaking other implementations. That being said, I'll note that both Jython and Iron Python already use unicode as the basic string type, which is a much bigger change (except to those who manage to use only 7-bit ASCII). > * The patch would encourage a coding style that gives program > that essentially > don't scale with Jython -- nor, for that matter, with 2.3 > or older Yes, but we ALREADY see lots of programs that use that coding style, even though every web page talking about Python optimization lists that as the #1 issue. Whether we like it or not, it seems that especially for novice programmers, the "s = s + x" idiom for accumulating a string is the "obvious" way to do it. Encouraging that may not be good, but going along rather than fighting it seems like a wise idea. > * discussed on SF too is whether we should remove the 'a=a+b' > acceleration > from the patch, keeping only 'a+=b'; see the SF tracker. Hmm... I couldn't think of any reason to limit the optimization to += until I actually went and read the comments in the SF tracker. What I took away from that discussion was that it's possible to optimize "a=a+b", but NOT possible to optimize "a=a+b+c". This is a subtle distinction that is harder to explain to people than simply saying "it only works with +=, not with +".

1 0