Guido van Rossum wrote:
> On 8/25/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>
>>I must have missed this one:
>>
>>
>>>
>>>Style for raising exceptions
>>>
>>>
>>>Guido explained that these days exceptions should always be raised as::
>>>
>
Hello there,
The release24-maint check-ins for today contained this typo:
===
RCS file: /cvsroot/python/python/dist/src/Modules/operator.c,v
retrieving revision 2.29
retrieving revision 2.29.4.1
diff -u -d -r2.29 -r2.29.4.1
--- oper
A.B., Khalid wrote:
> Hello there,
>
>
> The release24-maint check-ins for today contained this typo:
>
> ===
> RCS file: /cvsroot/python/python/dist/src/Modules/operator.c,v
> retrieving revision 2.29
> retrieving revision 2.29.4.1
Reinhold Birkenfeld wrote:
>Are you sure that you are calling the newly-built python.exe? It is strange
>that
>the test should pass in interactive mode when it doesn't in normal mode.
>For a confirmation, can you execute this piece of code both interactively
>and
>from a file:
Yes, both Python'
Marc-Andre Lemburg writes:
> This is from a comment in ceval.c:
>
> /* We support the following forms of raise:
> raise ,
> raise ,
> raise , None
> raise ,
> raise , None
> raise ,
> raise , None
>
> An omitted secon
On Friday 26 August 2005 09:15, Michael Chermside wrote:
> Oh my GOD! Are you saying that in order to correctly read Python code
> that a programmer must know all of THAT! I would be entirely
> unsurprised to learn that NO ONE on this list... in fact, no one
> in the whole world could have repr
[EMAIL PROTECTED]
> Update of /cvsroot/python/python/dist/src/Lib/test
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4822/Lib/test
>
> Modified Files:
>test_bz2.py
> Log Message:
> Add list() around xreadlines()
>
>
>
> Index: test_bz2.py
>
Tim Peters wrote:
> [EMAIL PROTECTED]
>> Update of /cvsroot/python/python/dist/src/Lib/test
>> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4822/Lib/test
>>
>> Modified Files:
>>test_bz2.py
>> Log Message:
>> Add list() around xreadlines()
>>
>>
>>
>> Index: test_bz2.py
>>
On 8/25/05, Ian Bicking <[EMAIL PROTECTED]> wrote:
> More generally, I've been doing some language comparisons, and I don't
> like literal but non-idiomatic translations of programming patterns.
True. (But that doesn't mean I think using generators for this example
is great either.)
> So I'm con
Le Vendredi 26 Août 2005 16:57, Guido van Rossum a écrit :
> On 8/25/05, Ian Bicking <[EMAIL PROTECTED]> wrote:
> > More generally, I've been doing some language comparisons, and I don't
> > like literal but non-idiomatic translations of programming patterns.
>
> True. (But that doesn't mean I thin
On Fri, Aug 26, 2005 at 06:21:58PM +0200, Alain Poirier wrote:
> For example, I often use this class to help me in functional programming :
>
> _marker = ()
[...]
You should not use an immutable object here (e.g. the empty tuple is
shared). My preferred idiom is:
_marker = object()
Cheer
Can str.find be listed in PEP 3000 (under builtins) for removal?
Would anyone really object?
Reasons:
1. Str.find is essentially redundant with str.index. The only difference
is that str.index Pythonically indicates 'not found' by raising an
exception while str.find does the same by anomalousl
On 8/26/05, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Can str.find be listed in PEP 3000 (under builtins) for removal?
Yes please. (Except it's not technically a builtin but a string method.)
> Would anyone really object?
Not me.
> Reasons:
>
> 1. Str.find is essentially redundant with str.inde
> Can str.find be listed in PEP 3000 (under builtins) for removal?
FWIW, here is a sample code transformation (extracted from zipfile.py).
Judge for yourself whether the index version is better:
Existing code:
--
END_BLOCK = min(filesize, 1024 * 4)
fpin.seek(filesize - END_B
> Can str.find be listed in PEP 3000 (under builtins) for removal?
> Would anyone really object?
>
> Reasons:
. . .
I had one further thought. In addition to your excellent list of
reasons, it would be great if these kind of requests were accompanied by
a patch that removed the offending cons
"Terry Reedy" <[EMAIL PROTECTED]> wrote:
>
> Can str.find be listed in PEP 3000 (under builtins) for removal?
> Would anyone really object?
I would object to the removal of str.find() . In fact, older versions
of Python which only allowed for single-character 'x in str' containment
tests offere
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 8/26/05, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> Can str.find be listed in PEP 3000 (under builtins) for removal?
>
> Yes please. (Except it's not technically a builtin but a string method.)
To avoid suggesting
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> Can str.find be listed in PEP 3000 (under builtins) for removal?
>
> FWIW, here is a sample code transformation (extracted from zipfile.py).
> Judge for yourself whether the index version is better:
I am sure that
"Josiah Carlson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> "Terry Reedy" <[EMAIL PROTECTED]> wrote:
>>
>> Can str.find be listed in PEP 3000 (under builtins) for removal?
Guido has already approved, but I will try to explain my reasoning a bit
better for you. There are ba
> There are basically two ways for a system, such as a
> Python function, to indicate 'I cannot give a normal response." One (1a)
> is to give an inband signal that is like a normal response except that it
> is not (str.find returing -1). A variation (1b) is to give an inband
> response that
On 8/26/05, Bill Janssen <[EMAIL PROTECTED]> wrote:
> Doubt it. The problem with returning None is that it tests as False,
> but so does 0, which is a valid string index position. The reason
> string.find() returns -1 is probably to allow a test:
>
> if line.find("\f"):
> ... do s
On 8/26/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I had one further thought. In addition to your excellent list of
> reasons, it would be great if these kind of requests were accompanied by
> a patch that removed the offending construct from the standard library.
Um? Are we now requiring
On Saturday 27 August 2005 00:46, Reinhold Birkenfeld wrote:
> > Note that this added a right parenthesis to the start of the line.
> > That creates a syntax error, so this test could not have been tried
> > before checking in. It also causes test_compiler to fail.
>
> Thank you for correcting. Th
Don't know *what* I wasn't thinking :-).
Bill
> On 8/26/05, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > Doubt it. The problem with returning None is that it tests as False,
> > but so does 0, which is a valid string index position. The reason
> > string.find() returns -1 is probably to allow a
"Terry Reedy" <[EMAIL PROTECTED]> wrote:
>
> "Josiah Carlson" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >
> > "Terry Reedy" <[EMAIL PROTECTED]> wrote:
> >>
> >> Can str.find be listed in PEP 3000 (under builtins) for removal?
>
> Guido has already approved,
I noticed, but
Terry Reedy wrote:
> One (1a)
> is to give an inband signal that is like a normal response except that it
> is not (str.find returing -1).
>
> Python as distributed usually chooses 1b or 2. I believe str.find and
> .rfind are unique in the choice of 1a.
That is not true. str.find's choice is
26 matches
Mail list logo
