Re: [Python-Dev] PEP 355 status

Thanks for your reply, that's the kind of info I was looking for to decide what to do. Good enough, I'll move on then. Thanks -- Luis P Caamano Atlanta, GA USA On 9/29/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I would recommend not using it. IMO it's

[Python-Dev] PEP 355 status

ntation in http://wiki.python.org/moin/PathModule names the class 'path' instead of 'Path', which seems like a source of name conflict problems. How would you recommend one starts using it now, as is or renaming class path to Path? Thanks

Re: [Python-Dev] possible use of __decorates__ in functools.decorator

saving the original caller via a sys._getframe(2) call in the decorator factory. Sorry for the noise. -- Luis P Caamano Atlanta, GA USA ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: ht

[Python-Dev] possible use of __decorates__ in functools.decorator

== 14) return Is there a way to do this without the __decorates__ attribute? -- Luis P Caamano Atlanta, GA USA ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.pyth

Re: [Python-Dev] Variant of removing GIL.

#x27;t get me wrong, I love the language and I'm always grateful for all the hard work you guys put in developing such great language and implementation. -- Luis P Caamano Atlanta, GA USA ___ Python-Dev mailing list Python-Dev@python.org http://mai

Re: [Python-Dev] Variant of removing GIL.

On 9/17/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 12:32 PM 9/17/2005 -0400, Luis P Caamano wrote: > >My point is that not yielding speedups on multiprocessors > >and hurting performance on uniprocessors is not a good > >or valid reason to drop free-threading

Re: [Python-Dev] Variant of removing GIL.

hat contributed to the decision of not keeping Greg's free threading changes. My point is that not yielding speedups on multiprocessors and hurting performance on uniprocessors is not a good or valid reason to drop free-threading. -- Luis P Caamano Atlanta, GA USA ___

Re: [Python-Dev] PEP 340 - possible new name for block-statement

have to choose a keyword, "block" has that "stop" connotation that will certainly confuse more than a few but I doubt people would go with "bracket_with." I certainly hope no-keyword is possible. -- Luis P Caamano Atlanta, GA USA __

[Python-Dev] About block statement name alternative

racket_with synchronized(lock): bracket_with opening(filename) as f: yield f bracket_with synchronized_opening("/etc/passwd", myLock) as f: for line in f: print line.rstrip() Or for that matter, "block_with", as in: b

Re: [Python-Dev] Re: anonymous blocks

erator finishes, the > interpreter leaves the block statement." > > Is it understandable so far? > I've been skipping most of the anonymous block discussion and thus, I only had a very vague idea of what it was about until I read this explanation. Yes, it is understandable --

[Python-Dev] os.urandom uses closed FD (sf 1177468)

  We're running into the problem described in bug 1177468, where urandom tries to use a cached file descriptor that was closed by a daemonizing function.   A quick fix/workaround is to have os.urandom open /dev/urandom everytime it gets called instead of using the a cached fd.   Would that create a