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
"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
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
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
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 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
> 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
"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
"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
"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
"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
> 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
> 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
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?
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 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
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 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
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
>>
[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 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
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
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'
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
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
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::
>>>
>
26 matches
Mail list logo
