Re: [Python-Dev] defaultdict and on_missing()
Greg Ewing wrote: > Nick Coghlan wrote: > >> I wouldn't mind seeing one of the early ideas from PEP 340 being >> resurrected some day, such that the signature for the special method >> was "__next__(self, input)" and for the builtin "next(iterator, >> input=None)" > > Aren't we getting an argument to next() anyway? > Or was that idea dropped? PEP 342 opted to extend the generator API instead (using "send") and leave the iterator protocol alone for the time being. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making ascii the default encoding
Neal Norwitz wrote: > PEP 263 states that in Phase 2 the default encoding will be set to > ASCII. Although the PEP is marked final, this isn't actually > implemented. The warning about using non-ASCII characters started in > 2.3. Does anyone think we shouldn't enforce the default being ASCII? > > This means if an # -*- coding: ... -*- is not set and non-ASCII > characters are used, an error will be generated. +1. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 28 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.4.3 for end of March?
So I'm planning a 2.4.3c1 around the 22nd-23rd of March, with a 2.4.3 final a week later. This will be the first release since the svn cutover, which should make things exciting. This is to get things cleared out before we start the cycle of pain - ahem - the 2.5 release cycle. A 2.4.4 would then follow when 2.5 final is done, hopefully October or so... Anyone have any screaming issues with this? Martin's ok to do the Windows release, and the doc build should be fine, too. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict and on_missing()
On 2/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Greg Ewing wrote: > > Nick Coghlan wrote: > > > >> I wouldn't mind seeing one of the early ideas from PEP 340 being > >> resurrected some day, such that the signature for the special method > >> was "__next__(self, input)" and for the builtin "next(iterator, > >> input=None)" > > > > Aren't we getting an argument to next() anyway? > > Or was that idea dropped? > > PEP 342 opted to extend the generator API instead (using "send") and leave the > iterator protocol alone for the time being. One of the main reasons for this was the backwards compatibility problems at the C level. The C implementation doesn't take an argument. Adding an argument would cause all sorts of code breakage and possible segfaults (if there's 3rd party code calling tp_next for example). In 3.0 we could fix this. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] with-statement heads-up
I just realized that there's a bug in the with-statement as currently checked in. __exit__ is supposed to re-raise the exception if there was one; if it returns normally, the finally clause is NOT to re-raise it. The fix is relatively simple (I believe) but requires updating lots of unit tests. It'll be a while. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with-statement heads-up
On 2/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I just realized that there's a bug in the with-statement as currently > checked in. __exit__ is supposed to re-raise the exception if there > was one; if it returns normally, the finally clause is NOT to re-raise > it. The fix is relatively simple (I believe) but requires updating > lots of unit tests. It'll be a while. Hmm. My understanding was that __exit__ was *not* to reraise it, but was simply given the opportunity to record the exception-in-progress. Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with-statement heads-up
On 2/28/06, Mike Bland <[EMAIL PROTECTED]> wrote: > On 2/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > I just realized that there's a bug in the with-statement as currently > > checked in. __exit__ is supposed to re-raise the exception if there > > was one; if it returns normally, the finally clause is NOT to re-raise > > it. The fix is relatively simple (I believe) but requires updating > > lots of unit tests. It'll be a while. > > Hmm. My understanding was that __exit__ was *not* to reraise it, but > was simply given the opportunity to record the exception-in-progress. Yes, that's what the PEP said. :-( Unfortunately the way the PEP is specified, the intended equivalence between writing a try/except in a @contextmanager-decorated generator and writing things out explicitly is lost. The plan was that this: @contextmanager def foo(): try: yield except Exception: pass with foo(): 1/0 would be equivalent to this: try: 1/0 except Exception: pass IOW with GENERATOR(): BLOCK becomes a macro call, and GENERATOR() becomes a macro definition; its body is the macro expansion with "yield" replaced by BLOCK. But in order to get those semantics, it must be possible for __exit__() to signal that the exception passed into it should *not* be re-raised. The current expansion uses roughly this: finally: ctx.__exit__(*exc) and here the finally clause will re-raise the exception (if there was one). I ran into this when writing unit tests for @contextmanager. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with-statement heads-up
On 2/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 2/28/06, Mike Bland <[EMAIL PROTECTED]> wrote: > > On 2/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > I just realized that there's a bug in the with-statement as currently > > > checked in. __exit__ is supposed to re-raise the exception if there > > > was one; if it returns normally, the finally clause is NOT to re-raise > > > it. The fix is relatively simple (I believe) but requires updating > > > lots of unit tests. It'll be a while. > > > > Hmm. My understanding was that __exit__ was *not* to reraise it, but > > was simply given the opportunity to record the exception-in-progress. > > Yes, that's what the PEP said. :-( > > Unfortunately the way the PEP is specified, the intended equivalence > between writing a try/except in a @contextmanager-decorated generator > and writing things out explicitly is lost. The plan was that this: > > @contextmanager > def foo(): > try: > yield > except Exception: > pass > > with foo(): > 1/0 > > would be equivalent to this: > > try: > 1/0 > except Exception: > pass > > IOW > > with GENERATOR(): > BLOCK > > becomes a macro call, and GENERATOR() becomes a macro definition; its > body is the macro expansion with "yield" replaced by BLOCK. But in > order to get those semantics, it must be possible for __exit__() to > signal that the exception passed into it should *not* be re-raised. > > The current expansion uses roughly this: > > finally: > ctx.__exit__(*exc) > > and here the finally clause will re-raise the exception (if there was one). > > I ran into this when writing unit tests for @contextmanager. This may just be my inexperience talking, and I don't have the code in front of me right this moment, but in my mind these semantics would simplify the original version of my patch, as we wouldn't have to juggle the stack at all. (Other than rotating the three exception objects, that is). We could then just pass the exception objects into __exit__ without having to leave a copy on the stack, and could forego the END_FINALLY. (I *think*.) Does that make sense? Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with-statement heads-up
On 2/28/06, Mike Bland <[EMAIL PROTECTED]> wrote: > On 2/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On 2/28/06, Mike Bland <[EMAIL PROTECTED]> wrote: > > > On 2/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > > I just realized that there's a bug in the with-statement as currently > > > > checked in. __exit__ is supposed to re-raise the exception if there > > > > was one; if it returns normally, the finally clause is NOT to re-raise > > > > it. The fix is relatively simple (I believe) but requires updating > > > > lots of unit tests. It'll be a while. > > > > > > Hmm. My understanding was that __exit__ was *not* to reraise it, but > > > was simply given the opportunity to record the exception-in-progress. > > > > Yes, that's what the PEP said. :-( > > > > Unfortunately the way the PEP is specified, the intended equivalence > > between writing a try/except in a @contextmanager-decorated generator > > and writing things out explicitly is lost. The plan was that this: > > > > @contextmanager > > def foo(): > > try: > > yield > > except Exception: > > pass > > > > with foo(): > > 1/0 > > > > would be equivalent to this: > > > > try: > > 1/0 > > except Exception: > > pass > > > > IOW > > > > with GENERATOR(): > > BLOCK > > > > becomes a macro call, and GENERATOR() becomes a macro definition; its > > body is the macro expansion with "yield" replaced by BLOCK. But in > > order to get those semantics, it must be possible for __exit__() to > > signal that the exception passed into it should *not* be re-raised. > > > > The current expansion uses roughly this: > > > > finally: > > ctx.__exit__(*exc) > > > > and here the finally clause will re-raise the exception (if there was one). > > > > I ran into this when writing unit tests for @contextmanager. > > This may just be my inexperience talking, and I don't have the code in > front of me right this moment, but in my mind these semantics would > simplify the original version of my patch, as we wouldn't have to > juggle the stack at all. (Other than rotating the three exception > objects, that is). We could then just pass the exception objects into > __exit__ without having to leave a copy on the stack, and could forego > the END_FINALLY. (I *think*.) Does that make sense? Yes, it does. Except there's yet another wrinkle: non-local gotos (break, continue, return). The special WITH_CLEANUP opcode that I added instead of your ROT4 magic now considers the following cases: - if the "exception indicator" is None or an int, leave it, and push three Nones - otherwise, replace the exception indicator and the two elements below it with a single None (thus reducing the stack level by 2), *and* push the exception indicator and those two elements back onto the stack, in reverse order. To clarify, let's look at the four cases. I'm drawing the stack top on the right: (return or continue; the int is WHY_RETURN or WHY_CONTINUE) BEFORE: retval; int; __exit__ AFTER: retval; int; __exit__; None; None; None (break; the int is WHY_BREAK) BEFORE: int; __exit__ AFTER: int; __exit__; None; None; None (no exception) BEFORE: None; __exit__ AFTER: None; __exit__; None; None; None (exception) BEFORE: traceback; value; type; __exit__ AFTER: None; __exit__; type; value; traceback The code generated in the finally clause looks as follows: WITH_CLEANUP (this does the above transform) CALL_FUNCTION 3 (calls __exit__ with three arguments) POP_TOP (throws away the result) END_FINALLY (interprets the int or None now on top appropriately) Hope this helps (if not you, future generations :-). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with-statement heads-up
Guido van Rossum wrote: > I just realized that there's a bug in the with-statement as currently > checked in. __exit__ is supposed to re-raise the exception if there > was one; if it returns normally, the finally clause is NOT to re-raise > it. The fix is relatively simple (I believe) but requires updating > lots of unit tests. It'll be a while. So does that mean with statements *will* be able to suppress exceptions now? (If I'm reading the PEP changes right it does, but I haven't finished my coffee yet. . .) I'm not complaining if that's so, as I think allowing it makes the operation of the statement both more useful and more intuitive, but you were originally concerned about the potential for hidden flow control if the context manager could suppress exceptions, as well as the need to remember to write "raise" in the except clauses of context managers. If you changed your mind along the way, that should probably be explained in the PEP somewhere :) Cheers, Nick -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with-statement heads-up
On 2/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > I just realized that there's a bug in the with-statement as currently > > checked in. __exit__ is supposed to re-raise the exception if there > > was one; if it returns normally, the finally clause is NOT to re-raise > > it. The fix is relatively simple (I believe) but requires updating > > lots of unit tests. It'll be a while. > > So does that mean with statements *will* be able to suppress exceptions now? > (If I'm reading the PEP changes right it does, but I haven't finished my > coffee yet. . .) Yes. And unless there are peasants at the gate with pitchforks etc. it will stay that way. :-) > I'm not complaining if that's so, as I think allowing it makes the operation > of the statement both more useful and more intuitive, but you were originally > concerned about the potential for hidden flow control if the context manager > could suppress exceptions, as well as the need to remember to write "raise" in > the except clauses of context managers. Yes, I've changed my mind about that. > If you changed your mind along the way, that should probably be explained in > the PEP somewhere :) I don't know that PEPs benefit from too much "on the one hand, on the other hand, on the third hand" or "and then I changed my mind, and then I changed it back, and then I changed it again". -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with-statement heads-up
Guido van Rossum wrote: >> If you changed your mind along the way, that should probably be explained in >> the PEP somewhere :) > > I don't know that PEPs benefit from too much "on the one hand, on the > other hand, on the third hand" or "and then I changed my mind, and > then I changed it back, and then I changed it again". Heh :) Plus the SVN history and the mailing list archive already provide that record. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with-statement heads-up
At 04:01 PM 2/28/2006, Guido van Rossum wrote: >On 2/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > Guido van Rossum wrote: > > > I just realized that there's a bug in the with-statement as currently > > > checked in. __exit__ is supposed to re-raise the exception if there > > > was one; if it returns normally, the finally clause is NOT to re-raise > > > it. The fix is relatively simple (I believe) but requires updating > > > lots of unit tests. It'll be a while. > > > > So does that mean with statements *will* be able to suppress > exceptions now? > > (If I'm reading the PEP changes right it does, but I haven't finished my > > coffee yet. . .) > >Yes. And unless there are peasants at the gate with pitchforks etc. it >will stay that way. :-) Notice that these semantics break some of the PEP examples. For example, the 'locked' and 'nested' classes now suppress exceptions, and it took a non-trivial study of their code to determine this. This seems to suggest that making suppression the default behavior is a bad idea. I was originally on the side of allowing suppression, but I wanted it to be done by explicitly returning some non-None value, so that suppression would not be the default, implicit behavior. I think I'd prefer not to be able to suppress the errors, than to have errors pass silently unless explicitly re-raised! I don't see a problem with having e.g. __exit__ have to return a flag to suppress the exception; it wouldn't need to change how @contextmanager functions are written. (Implicit suppression is only a problem for people writing __exit__ methods, in other words; all your reasoning about @contextmanager generators is valid, IMO.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] with-statement heads-up
On 2/28/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > Notice that these semantics break some of the PEP examples. For > example, the 'locked' and 'nested' classes now suppress exceptions, > and it took a non-trivial study of their code to determine > this. This seems to suggest that making suppression the default > behavior is a bad idea. I presume you're referring to example 4 (locked as a class), not example 1 (locked as a generator). I'll fix this, and rewrite nested() as a generator (just like what I checked in :-). > I was originally on the side of allowing suppression, but I wanted it > to be done by explicitly returning some non-None value, so that > suppression would not be the default, implicit behavior. I think I'd > prefer not to be able to suppress the errors, than to have errors > pass silently unless explicitly re-raised! I don't see a problem > with having e.g. __exit__ have to return a flag to suppress the > exception; it wouldn't need to change how @contextmanager functions > are written. (Implicit suppression is only a problem for people > writing __exit__ methods, in other words; all your reasoning about > @contextmanager generators is valid, IMO.) Thanks for the validation of the idea -- I ran into this when writing unittests for @contextmanager... I think that providing sufficient *correct* examples will avoid most of the problems. People will clone existing examples (I know *I* did when adding context managers to various modules :-). Changing the API to let __exit__() return something true to suppress the exception seems somewhat clumsy. Re-raising the exception is analogous to the throw() method in PEP 342. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict and on_missing()
Guido van Rossum wrote: > On 2/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > > PEP 342 opted to extend the generator API instead (using "send") and leave > > the > > iterator protocol alone for the time being. > > One of the main reasons for this was the backwards compatibility > problems at the C level. I'm really quite happy either way. Having the functionality available in some way is the important thing. I'd still like to see next(x) / x.__next__() in some form in 3.0 for the sake of consistency, though. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes.from_hex()
Bill Janssen wrote: > bytes -> base64 -> text > text -> de-base64 -> bytes It's nice to hear I'm not out of step with the entire world on this. :-) -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.count is slow
Fredrik Lundh wrote: > > My personal goal in life right now is to stay as > > far away from C++ as I can get. > > so what C compiler are you using ? Gcc, mostly. I don't mind if it's capable of compiling C++, as long as I can choose not to write any. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.count is slow
On 2/28/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Fredrik Lundh wrote: > > > > My personal goal in life right now is to stay as > > > far away from C++ as I can get. > > > > so what C compiler are you using ? > > Gcc, mostly. I don't mind if it's capable of > compiling C++, as long as I can choose not to > write any. That's getting harder and harder though. Recent versions of GCC appear to be implementing C98 by default -- at least I didn't get complaints about declarations placed after non-declarations in the same block from any of the buildbot hosts... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes.from_hex()
On 2/28/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Bill Janssen wrote: > > > bytes -> base64 -> text > > text -> de-base64 -> bytes > > It's nice to hear I'm not out of step with > the entire world on this. :-) What Bill proposes makes sense to me. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes.from_hex()
Greg Ewing wrote: > Bill Janssen wrote: > > > bytes -> base64 -> text > > text -> de-base64 -> bytes > > It's nice to hear I'm not out of step with > the entire world on this. :-) Well, I can certainly understand the bytes->base64->bytes side of thing too. The "text" produced is specified as using "a 65-character subset of US-ASCII", so that's really bytes. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict and on_missing()
[Greg Ewing] > I'd still like to see next(x) / x.__next__() in > some form in 3.0 for the sake of consistency, > though. +1 on modifying next() in Py3.0 to accept the send argument. -1 on the silly renaming to __next__ and adding __builtin__.next(). We have len() because it applies to many different object types. In contrast, next() would apply only to iterables. Foolish consistency is a somewhat weak reason to add a built-in. Also, calls to it.next() need to be as fast as possible. Adding a layer of indirection through __builtin__.next() is a waste. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] C++ for CPython 3? (Re: str.count is slow)
Guido van Rossum wrote: > > Fredrik Lundh wrote: > > > > > > My personal goal in life right now is to stay as > > > > far away from C++ as I can get. > > > > > > so what C compiler are you using ? > > > > Gcc, mostly. I don't mind if it's capable of > > compiling C++, as long as I can choose not to > > write any. > > That's getting harder and harder though. Recent versions of GCC appear > to be implementing C98 by default -- at least I didn't get complaints > about declarations placed after non-declarations in the same block > from any of the buildbot hosts... should we perhaps switch to (careful use of) C++ in 3.0 ? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.count is slow
On Feb 28, 2006, at 6:14 PM, Guido van Rossum wrote: > On 2/28/06, Greg Ewing <[EMAIL PROTECTED]> wrote: >> Fredrik Lundh wrote: >> My personal goal in life right now is to stay as far away from C++ as I can get. >>> >>> so what C compiler are you using ? >> >> Gcc, mostly. I don't mind if it's capable of >> compiling C++, as long as I can choose not to >> write any. > > That's getting harder and harder though. Recent versions of GCC appear > to be implementing C98 by default -- at least I didn't get complaints > about declarations placed after non-declarations in the same block > from any of the buildbot hosts... I don't know whether you meant "C++98" or "C99" in the above, but the default is (mostly) C99, now. If you like, you can still tell it to compile in C89 mode, with --std=c89. C99 contains some of the superficial C++ syntax changes such as // comments and declarations after non-declarations which have long been implemented as non-standard extensions, anyhow, but it's still nothing like C++. As for the question of whether to switch to C++ in 3.0, I'd say probably not, as it's much harder to interface with C++ from other languages than to C. James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.count is slow
> As for the question of whether to switch to C++ in 3.0, I'd say > probably not, as it's much harder to interface with C++ from other > languages than to C. An excellent point, and to my mind conclusive. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes.from_hex()
Bill Janssen wrote: > Well, I can certainly understand the bytes->base64->bytes side of > thing too. The "text" produced is specified as using "a 65-character > subset of US-ASCII", so that's really bytes. But it then goes on to say that these same characters are also a subset of EBCDIC. So it seems to be talking about characters as abstract entities here, not as bit patterns. Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.count is slow
Guido van Rossum wrote: > Recent versions of GCC appear > to be implementing C98 by default -- at least I didn't get complaints > about declarations placed after non-declarations in the same block > from any of the buildbot hosts... As long as it doesn't complain when I *do* put all my declarations before my non-declarations, I can live with that. :-) -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
Fredrik Lundh wrote: > should we perhaps switch to (careful use of) C++ in 3.0 ? I worry that if the Python core becomes dependent on C++, it will force all extensions to be written in C++, too. Not only is this inconvenient for people who don't know C++ or prefer not to use it, but I suspect this would lead to some severe interoperability problems. On most platforms, C code will happily link to just about anything else, but in my experience, C++ code will only interoperate with other C++ code when it's compiled by exactly the same compiler and uses the same runtime system. For another thing, I'm not sure that C++ polymorphism is flexible enough to implement Python's style of polymorphism. Think of all the tricks we play with type objects -- allocating them on the heap, extending them dynamically at runtime, etc. In C++, classes aren't even available as program-accessible entities. So we'd end up implementing our own form of dynamic dispatch anyway, and it would probably look a lot like the current C-based type objects. I don't see that C++ would help much. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict and on_missing()
Raymond Hettinger wrote: > -1 on the silly renaming to __next__ and adding __builtin__.next(). > We have len() because it applies to many different object types. > In contrast, next() would apply only to iterables. And you don't think there are many different types of iterables? You might as well argue that we don't need len() because it "only applies to sequences". There's a practical reason for using the xxx(obj)/obj.__xxx__() pattern -- it provides a lot more flexibility when it comes to future extensions of the protocol. We've used this to good effect already with iter(), which uses __iter__ if it's available, else falls back on another technique. If we had used this pattern with next() from the beginning then, for example, there would have been no problem adding an argument to next(), since the next() function could just have been updated to look for __send__ or something like that, and existing iterators need not have been affected. So the reason I'd like to see this changed in 3.0 is not because of consistency for its own sake, but because it would provide a better basis for future development. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] iterator API in Py3.0
>> -1 on the silly renaming to __next__ and adding __builtin__.next(). >> We have len() because it applies to many different object types. >> In contrast, next() would apply only to iterables. [Greg Ewing] > And you don't think there are many different > types of iterables? Um, I meant iterators and suspect you meant the same -- iow, objects returned by iter(x) that are currently guaranteed to support __iter__() and next() methods (i.e. generator-iterators, not the generator-functions that create them). > So the reason I'd like to see this changed > in 3.0 is not because of consistency for its > own sake, but because it would provide a > better basis for future development. YAGNI. The hypothetical "future development" benefit is even more specious than the appeal for consistency. Let's try to resist mucking-up this simple, elegant, and fast iterface by adding another level of indirection. I'm strongly -1 on this proposal and will likely remain so until shown demonstrable benefits for real use cases that are compelling enough to warrant cluttering and slowing the iterator interface. I usually let this sort of thing slide, but the iterator API is too important for trivial, incompatible, and damaging changes. Looking back at Guido's original rationale for naming the method next() instead of __next__(), http://www.python.org/peps/pep-0234.html , it does not look like any of those reasons will cease to apply in Py3.0. If you want a next() function, it is trivial to write your own pure Python version and leave the API unmolested for everyone else. Since it is already possible to write such a function, I'm curious whether you've had occasion to do so in real code and whether it provided any benefits in terms of consistency or future development flexibility. Most likely, the answer is no. That should be a good indicator that the proposed benefits are illusory. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New test failure on Windows
test test_pep352 failed -- Traceback (most recent call last):
File "C:\Code\python\lib\test\test_pep352.py", line 54, in test_inheritance
self.fail("%s not a built-in exception" % exc_name)
AssertionError: WindowsError (Windows) not a built-in exception
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] .py and .txt files missing svn:eol-style in trunk
These .py and .txt files don't have the svn:eol-style property set. I'm not sure they all _should_, though. Some of them are particularly bizarre, e.g. Lib\email\test\data\msg_26.txt has the svn:mime-type property set to application/octet-stream (WTF?), and then svn refuses to set the eol-style property. .\Lib\bsddb\test\test_1413192.py .\Lib\email\test\data\msg_26.txt .\Lib\email\test\data\msg_44.txt .\Lib\encodings\utf_8_sig.py .\Lib\test\bad_coding2.py .\Lib\test\outstanding_bugs.py .\Lib\test\test_defaultdict.py .\Lib\test\test_exception_variations.py .\Lib\test\test_pep263.py .\Lib\test\test_platform.py .\Lib\test\crashers\coerce.py .\Lib\test\crashers\dangerous_subclassing.py .\Lib\test\crashers\infinite_rec_1.py .\Lib\test\crashers\infinite_rec_2.py .\Lib\test\crashers\infinite_rec_3.py .\Lib\test\crashers\infinite_rec_4.py .\Lib\test\crashers\infinite_rec_5.py .\Lib\test\crashers\loosing_dict_ref.py .\Lib\test\crashers\modify_dict_attr.py .\Lib\test\crashers\recursive_call.py .\Lib\test\crashers\weakref_in_del.py .\Lib\test\crashers\xml_parsers.py .\Lib\xmlcore\etree\cElementTree.py .\Modules\zlib\algorithm.txt .\PC\readme.txt .\PC\testpy.py .\PC\example_nt\readme.txt .\PC\os2vacpp\readme.txt OK, I tried to set eol-style on all of those. svn refused to change these: svn: File 'Lib\email\test\data\msg_26.txt' has binary mime type property svn: File 'Lib\test\test_pep263.py' has binary mime type property svn: File 'PC\readme.txt' has binary mime type property svn: File 'PC\testpy.py' has binary mime type property svn: File 'PC\example_nt\readme.txt' has binary mime type property svn: File 'PC\os2vacpp\readme.txt' has binary mime type property test_pepe263 probably should be binary (it contains "funny characters"). I'll wrestle with the ones under PC/. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Webstats for www.python.org et al.
I finally took the time to set up webalizer on dinsdale.python.org, after the move of the web content from creosote.python.org to dinsdale.python.org last October or November. The apache logs on dinsdale don't go back farther than 25 December, looks like, though. None of my backups have 'em either. I didn't bother regenerate the stats from the logfiles on creosote.python.org because of that, since there would be a two-month gap. We can still compare the last two month's of data to whatever we'll be generating once beta.python.org is final :-) And if anyone happens to have the older dinsdale logs somewhere, I can still regenerate the main stats. I added webstats for all subsites of python.org: http://www.python.org/webstats/ http://beta.python.org/webstats/ http://bugs.python.org/webstats/ http://planet.python.org/webstats/ http://docs.python.org/webstats/ http://doc.python.org/webstats/ http://svn.python.org/webstats/ and even http://www.pythonlabs.com/webstats/ (not working right now, not sure why) http://www.jpython.org/webstats/ (not working because of the global redirect) I think I'll merge doc.python.org and docs.python.org tomorrow. (And maybe add the doc/docs.python.org stats to www.python.org's stats after prepending '/doc' to all URLs, but that's a fair bit of work.) I'd also like to add a stats.python.org with direct listings of all those stats, unless someone sees a reason not to. The svn.python.org stats include only http- and https-traffic, not svn+ssh traffic (the authenticated, read-write traffic.) They're pretty interesting to look at, though, particularly the extreme dip in access on the 27th and 28th of February :) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using and binding relative names (was Re: PEP forBetter Control of Nested Lexical Scopes)
[Alex Martelli] >> We stole list comprehensions and genexps from Haskell [Greg Ewing] > The idea predates Haskell, I think. I first saw it in > Miranda, and it may have come from something even > earlier -- SETL, maybe? Haskell indeed took list comprehensions from SETL. SETL in turn took them from much earlier standard notation in set theory, related to the oddly named (but not universally so named) "axiom of comprehension". genexps were more directly taken from Icon, but tying them into Python's iteration protocol is a powerful twist not directly present in Icon. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using and binding relative names (was Re: PEP forBetter Control of Nested Lexical Scopes)
[Alex Martelli] >> We stole list comprehensions and genexps from Haskell [Greg Ewing] > The idea predates Haskell, I think. I first saw it in > Miranda, and it may have come from something even > earlier -- SETL, maybe? Haskell indeed took list comprehensions from SETL. SETL in turn adopted them from pre-computer standard notation in set theory, related to the oddly named (but not universally so named) "axiom of comprehension". genexps were more directly taken from Icon (because of the "generator" part). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict and on_missing()
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > And you don't think there are many different > types of iterables? You might as well argue > that we don't need len() because it "only > applies to sequences". Since you mention it..., many people *have* asked on c.l.p why len() is a builtin function rather than a method of sequences (and other collections) (as .len, not .__len__). Some have suggested that it should be the latter. The answers justifying the status quo have been twofold. 1. Before 2.2, not all builtin sequence types had methods (str and tuple), so they could not have a .len method. (This begs the question of why not, but that is moot now.) - whereas .next came in with the universalization of methods. 2. Before the addition of list comprehensions, a function could be mapped much more easily than a method - whereas now we do have list comps and even this works >>> [i.__add__(2) for i in range(3)] [2, 3, 4] - I can imagine wanting to map len to, for instance, a list of strings more easily than I can imagine a reason to map next/.next to a list of iterators, and if I did, I am willing to use the list comp form. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Webstats for www.python.org et al.
"Thomas Wouters" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I added webstats for all subsites of python.org: > > http://www.python.org/webstats/ > http://beta.python.org/webstats/ > http://bugs.python.org/webstats/ > http://planet.python.org/webstats/ > http://docs.python.org/webstats/ > http://doc.python.org/webstats/ > http://svn.python.org/webstats/ Since the first and last months are incomplete, I would consider plotting daily averages for each month instead of totals. tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
Fredrik Lundh schrieb: >should we perhaps switch to (careful use of) C++ in 3.0 ? > > > I can't see many advantages in moving to C++, but a lot of disadvantages: - Size increase, especially when we start using templates - Performance decrease - Problems with name mangling together with dynamic loading and cross module API's - Everything has to be build with the same compiler, binaries created with different compilers can't interoperate - Possibly all extensions modules have to be (re)written in C++ - Moving to C++ will change Python's well known API substantially --- IMHO, if a Python major version change implies to forget everything that has been established over the years, ignoring backward compaibility, breaking nearly every Python script, than we should definitely find another name for it, or I will stay with Python 2 for the rest of my life. --- Ulli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Webstats for www.python.org et al.
Thomas Wouters wrote: > I added webstats for all subsites of python.org: > > http://www.python.org/webstats/ what's that "Java/1.4.2_03" user agent doing? (it's responsible for 10% of all hits in january/february, and 20% of the hits today...) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
