martin == martin [EMAIL PROTECTED] writes:
martin I don't understand. How can you use a C++ compiler, but
martin not the C++ language?
An abbreviation for those features that aren't in C.
martin As the recent const dilemma shows, C99 and C++98 have,
martin unfortunately,
Greg Ewing wrote:
Ron Adam wrote:
This uses syntax to determine the direction of encoding. It would be
easier and clearer to just require two arguments or a tuple.
u = unicode(b, 'encode', 'base64')
b = bytes(u, 'decode', 'base64')
The point of the exercise was to avoid
Tim Peters wrote:
[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.
[EMAIL PROTECTED] wrote:
Neal I'll do this, except there are some issues:
Neal * Lib/reconvert.py imports regex. Ok to move
regex,regsub,recovert to lib-old?
Neal * ./Demo/pdist/rcslib.py ./Demo/sockets/mcast.py import
regsub
...
Neal * A whole mess of Demos
Hello all,
I've just posted a patch to SF (python.org/sf/1442442) that I thought
I'd bring to everyone's attention. Executive summary: by changing the
behaviour of the unused LIST_APPEND opcode, it's possible to get a 16%
speed boost for list comprehensions.
Currently, list comprehensions are
I think PEP 357 and the corresponding patch (python.org/sf/1436368) ae
looking pretty good, except for one issue:
Currently, when calling the __index__() method on a long with a value
exceeding the boundaries of ssize_t will raise OverflowError. The C
API chooses to clip such values, but the
[Collin Winter]
I've just posted a patch to SF (python.org/sf/1442442) that I thought
I'd bring to everyone's attention. Executive summary: by changing the
behaviour of the unused LIST_APPEND opcode, it's possible to get a 16%
speed boost for list comprehensions.
That was working fine in
On Wed, Mar 01, 2006, Raymond Hettinger wrote:
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__(),
[Aahz]
* As a writer/teacher, I want to be able to say, All Python special
methods have leading and trailing double-underscore. Period, end of
story.
When teaching your classes, do you sense an aversion to using double underscore
methods in regular code? I sense an implied message that
testCompileLibrary (__main__.CompilerTest) ... compiling /home/splitscreen/src/python/python/Lib/dircache.pycompiling /home/splitscreen/src/python/python/Lib/smtplib.pycompiling /home/splitscreen/src/python/python/Lib/pickle.py
ERRORtestFlatten (__main__.CompilerTest) ... oktestLineNo
Yup. It's fixed.
n
--
On 3/3/06, Matthew Fleming [EMAIL PROTECTED] wrote:
testCompileLibrary (__main__.CompilerTest) ... compiling
/home/splitscreen/src/python/python/Lib/dircache.py
compiling
/home/splitscreen/src/python/python/Lib/smtplib.py
compiling
Raymond writes:
The double underscore convention is appropriate where the method is always
invoked magically in normal code and not called directly. The next() method
is
differenct because it is a mixed case, sometimes called magically and
sometimes
called directly. In the latter case, the
On 3/3/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
The double underscore convention is appropriate where the method is always
invoked magically in normal code and not called directly. The next() method
is
differenct because it is a mixed case, sometimes called magically and
sometimes
On Fri, 2006-03-03 at 13:06 -0800, Michael Chermside wrote:
I think it's clear that if a method is invoked magically, it ought to have
underscores; if it is invoked directly then it ought not to. next() is
invoked both ways, so the question is which of the following invariants
we would rather
At 04:09 PM 3/3/2006 -0500, Jeremy Hylton wrote:
I think it is a little odd that next is not spelled __next__, but I
appreciate the reasons given here in particular. Every time I right
.next(), I'm happy that it doesn't have underscores.
But then next(ob) should make you even happier, because
On 3/3/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:09 PM 3/3/2006 -0500, Jeremy Hylton wrote:
I think it is a little odd that next is not spelled __next__, but I
appreciate the reasons given here in particular. Every time I right
.next(), I'm happy that it doesn't have underscores.
It's probably worth mentioning that right now, we don't even come
close to compiling with a C++ compiler. A bunch of the bugs are
shallow (casting result from malloc, that sort of thing) but a bunch
more look a tad uglier. Is this something worth trying to fix? Fixing
the shallow bugs at least
Stephen J. Turnbull wrote:
Doesn't that make base64 non-text by analogy to other look but don't
touch strings like a .gz or vmlinuz?
No, because I can take a piece of base64 encoded data
and use a text editor to manually paste it in with some
other text (e.g. a plain-text (not MIME) mail
Ron Adam wrote:
This would apply to codecs that
could return either bytes or strings, or strings or unicode, or bytes or
unicode.
I'd need to see some concrete examples of such codecs
before being convinced that they exist, or that they
couldn't just as well return a fixed type that you
Greg Ewing wrote:
Ron Adam wrote:
This would apply to codecs that
could return either bytes or strings, or strings or unicode, or bytes or
unicode.
I'd need to see some concrete examples of such codecs
before being convinced that they exist, or that they
couldn't just as well return a
[Oleg Broytmann[
My experience shows that if the developers use different OSes (our team
uses Linux and Windows) it helps very much to set svn:eol-style to native
for all text files - *.py, *.txt, etc, except for files with special
requirements.
Yes.
So I use the following shell script
Hello,
The Python spec states that the from
__future__ import statement can only occur at the beginning of
the file, preceded only by doc strings, comments, empty lines or other future
statements. The following code snippets, however, dont raise Syntax
error in Python 2.4.2. Is it a
[Martin Maly]
The Python spec states that the from __future__ import … statement can
only occur at the beginning of the file, preceded only by doc strings,
comments, empty lines or other future statements. The following code
snippets, however, don't raise Syntax error in Python 2.4.2. Is it a
On 3/3/06, Tim Peters [EMAIL PROTECTED] wrote:
[Martin Maly]
The Python spec states that the from __future__ import … statement can
only occur at the beginning of the file, preceded only by doc strings,
comments, empty lines or other future statements. The following code
snippets,
A few days ago there were rumbling noises that requiring __exit__ to
re-raise the exception (as I amended PEP 343 at the time) could lead
to easily-missed bugs in __exit__ handlers.
After thinking it over I think I agree and I think I'd like to change
the API so that the exception is only ignored
[Tim]
Doesn't look like Guido responded, so I'll channel him and declare
that he intended to agree with me after all ;-)
[Guido]
It was so obvious that you were right I didn't bother to agree at the
time. But yes, I agree.
Of course you do. It was obvious to you, and therefore-- as your
On Wed, 2006-03-01 at 00:17 -0600, Tim Peters wrote:
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
Yeah, there's no reason for that, so I've fixed it.
-Barry
signature.asc
Description:
On Fri, 2006-03-03 at 23:43 -0500, Barry Warsaw wrote:
On Wed, 2006-03-01 at 00:17 -0600, Tim Peters wrote:
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
Yeah, there's no reason for
Raymond Hettinger wrote:
When teaching your classes, do you sense an aversion to using double
underscore methods in regular code? I sense an implied message that
these methods are not intended to be called directly (i.e. the discomfort
of typing x.__setitem__(k,v) serves as a cue to write
29 matches
Mail list logo
