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
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 reaso
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:
[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 you
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
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
> > snipp
[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
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, don’t raise Syntax
error in Python 2.4.2. Is it
[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 scri
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 we
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
t
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 me
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
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 underscor
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 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 rat
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
> someti
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, th
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 /home/splitscreen/src/python/py
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 (__main__.Com
[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
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__(), http://www.python.o
[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 P
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 Pytho
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 bui
[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 m
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 comprehensio
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 wa
> "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> unfort
29 matches
Mail list logo