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()
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?
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,
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
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
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
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
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
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
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
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
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
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
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
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
[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
[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
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()
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/
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...)
/F
___
20 matches
Mail list logo
