"FAN" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> You know Jython (Java version of Python) has only a stable version of
> 2.1, and two alpha version was release after 3 years.
> So if it wants to evolve to 2.2 , 2.3 or 2.4 as Python, some detail
> change list was need, and it's
Donovan Baarda <[EMAIL PROTECTED]> wrote:
>
> On Sat, 2005-08-27 at 10:16 -0700, Josiah Carlson wrote:
> > Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [...]
> > Oh, there's a good thing to bring up; regular expressions! re.search
> > returns a match object on success, None on failure. With th
hi, all
You know Jython (Java version of Python) has only a stable version of
2.1, and two alpha version was release after 3 years.
So if it wants to evolve to 2.2 , 2.3 or 2.4 as Python, some detail
change list was need, and it's great if there are some test case
script to test the new implementi
On Sat, 2005-08-27 at 10:16 -0700, Josiah Carlson wrote:
> Guido van Rossum <[EMAIL PROTECTED]> wrote:
[...]
> Oh, there's a good thing to bring up; regular expressions! re.search
> returns a match object on success, None on failure. With this "failure
> -> Exception" idea, shouldn't they raise e
On 8/27/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> With the existance of literally thousands of uses of .find and .rfind in
> the wild, any removal consideration should be weighed heavily - which
> honestly doesn't seem to be the case here with the ~15 minute reply time
> yesterday (just my ob
On 8/27/05, Aahz <[EMAIL PROTECTED]> wrote:
> On Sat, Aug 27, 2005, Guido van Rossum wrote:
> >
> > if vi in ('=',':'):
> > try: pos = optval.index(';')
> > except ValueError: pass
> > else:
> > if pos > 0 and optval[pos-1].isspace():
> > optval = optval[:pos]
>
> IIRC, one of your
On 8/27/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > For reading bytes, I *know* that a lot of code would become uglier if
> > the API changed to raise EOFError exceptions
>
> I had StopIteration in mind. Instead of writing:
>
> while 1:
> block = f.read(20)
> if line
Raymond Hettinger wrote:
> We would use:
> for block in f.readblocks(20):
> . . .
What would be nice is a reader that allows a range
of bytes. Often when you read a chunk, you don't care
about the exact size you get, example uses include the
re-blocking that makes reading from compress
On Sat, Aug 27, 2005, Guido van Rossum wrote:
>
> if vi in ('=',':'):
> try: pos = optval.index(';')
> except ValueError: pass
> else:
> if pos > 0 and optval[pos-1].isspace():
> optval = optval[:pos]
IIRC, one of your proposals for Python 3.0 was that single-line blocks
would be b
On 8/26/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> 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.)
>
Done. Added an "Atomic Types" section
Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On 8/26/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Taking a look at the commits that Guido did way back in 1993, he doesn't
> > mention why he added .find, only that he did. Maybe it was another of
> > the 'functional language additions' tha
[Reinhold Birkenfeld]
> Could anyone else on Windows please try the test_bz2, too?
test_bz2 works fine here, on WinXP Pro SP2, under release and debug
builds, on current CVS HEAD and on current CVS release24-maint branch.
I built those 4 Pythons with the MS compiler, not MinGW.
__
[Tim]
> You probably want "except ValueError:" in all these, not "except
> ValueError():".
Right. I was misremembering the new edict to write:
raise ValueError()
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
[Raymond Hettinger, rewrites some code]
> ...
> --- StringIO.py ---
>
> i = self.buf.find('\n', self.pos)
> if i < 0:
>newpos = self.len
> else:
>newpos = i+1
> . . .
>
>
> try:
>i = self.buf.find('\n', self.pos)
> except ValueError():
>newpos = self.len
> else:
>
[Guido]
> However, after 12 years, I believe that the small benefit of having
> find() is outweighed by the frequent occurrence of bugs in its use.
My little code transformation exercise is bearing that out. Two of the
first four cases in the standard library were buggy :-(
Raymond
___
Okay here is the output of test_bz2 on Python 2.4.1 updated and compiled
fresh from CVS, and on Python 2.4.1 from the source archieve from python.org
(http://www.python.org/ftp/python/2.4.1/Python-2.4.1.tar.bz2).
#-
# P
On Sat, 27 Aug 2005 16:46:07 +0200, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> On 8/27/05, Wolfgang Lipp <[EMAIL PROTECTED]> wrote:
>> i never expected .get()
>> to work that way (return an unsolicited None) -- i do consider this
>> behavior harmful and suggest it be removed.
>
> That's a biz
> For reading bytes, I *know* that a lot of code would become uglier if
> the API changed to raise EOFError exceptions
I had StopIteration in mind. Instead of writing:
while 1:
block = f.read(20)
if line == '':
break
. . .
We would use:
for block in
On 8/26/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Taking a look at the commits that Guido did way back in 1993, he doesn't
> mention why he added .find, only that he did. Maybe it was another of
> the 'functional language additions' that he now regrets, I don't know.
There's nothing functio
A.B., Khalid wrote:
>>>#--- Python 2.4.1 from CVS -#
[test_bz2]
>>>RuntimeError: wrong sequence of bz2 library commands used
>>
>>I don't understand this. The sources for the bz2 modules are exactly equal
>>in both branches.
>
> I know. Even the tests are e
On 8/27/05, Wolfgang Lipp <[EMAIL PROTECTED]> wrote:
> i never expected .get()
> to work that way (return an unsolicited None) -- i do consider this
> behavior harmful and suggest it be removed.
That's a bizarre attitude. You don't read the docs and hence you want
a feature you weren't aware of to
On 8/27/05, Kay Schluehr <[EMAIL PROTECTED]> wrote:
> The discourse about Python3000 has shrunken from the expectation of the
> "next big thing" into a depressive rhetorics of feature elimination.
> The language doesn't seem to become deeper, smaller and more powerfull
> but just smaller.
I unders
Raymond Hettinger wrote:
> [Martin]
>> For another example, file.read() returns an empty string at EOF.
>
> When my turn comes for making 3.0 proposals, I'm going to recommend
> nixing the "empty string at EOF" API. That is a carry-over from C that
> made some sense before there were iterators.
On 8/27/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> --- From ConfigParser.py ---
>
> optname, vi, optval = mo.group('option', 'vi', 'value')
> if vi in ('=', ':') and ';' in optval:
> # ';' is a comment delimiter only if it follows
> # a spacing character
> pos = op
On 8/27/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Martin]
> > For another example, file.read() returns an empty string at EOF.
>
> When my turn comes for making 3.0 proposals, I'm going to recommend
> nixing the "empty string at EOF" API. That is a carry-over from C that
> made some sen
Reinhold Birkenfeld wrote:
#--- Python 2.5a0 from CVS -#
# Result: passes
$ /g/projs/py25/python/dist/src/MinGW/python testbz2.py
#--- Python 2.4.1 from CVS -#
# Result: fails
$ /g/projs/py24/python/dist/src/MinGW/
kay,
your suggestion makes perfect sense for me, i haven't actually tried
the examples tho. guess there could be a find() or index() or
indices() or iterIndices() ??? function 'f' roughly with these arguments:
def f( x, element, start = 0, stop = None, default = _Misfit, maxcount =
None, rever
Wolfgang Lipp wrote:
> > Just because you don't read the documentation and guessed wrong
> > d.get() needs to be removed?!?
>
> no, not removed... never said that.
Fair enough, you proposed to remove the behavior. Not sure how that's
all that much less bad, though...
> implied). the reason of b
FWIW, here are three more comparative code fragments. They are
presented without judgment as an evaluation tool to let everyone form
their own opinion about the merits of each:
--- From CGIHTTPServer.py ---
def run_cgi(self):
"""Execute a CGI script."""
dir, rest = self.cgi_
Terry Reedy wrote:
>>I would object to the removal of str.find().
>
>
> So, I wonder, what is your favored alternative?
>
> A. Status quo: ignore the opportunity to streamline the language.
I actually don't see much benefits from the user perspective. The
discourse about Python3000 has shrunk
MAL> I don't see a need for two or more syntaxes either, but most code
MAL> nowadays uses the second variant (I don't know of any code that
MAL> uses the traceback argument), which puts up a high barrier for
MAL> changes.
Earlier this week I managed to fix all the instances in the
On Sat, 27 Aug 2005 13:01:02 +0200, Just van Rossum <[EMAIL PROTECTED]>
wrote:
> Just because you don't read the documentation and guessed wrong d.get()
> needs to be removed?!?
no, not removed... never said that.
> It's a *feature* of d.get(k) to never raise KeyError. If you need an
> excepti
Wolfgang Lipp wrote:
> On Sat, 27 Aug 2005 12:35:30 +0200, Martin v. Löwis
<[EMAIL PROTECTED]>
> wrote:
> > P.S. Emphasis mine :-)
>
> no, emphasis all **mine** :-) just to reflect i never expected .get()
> to work that way (return an unsolicited None) -- i do consider this
> behavior harmful a
On Sat, 27 Aug 2005 12:35:30 +0200, Martin v. Löwis <[EMAIL PROTECTED]>
wrote:
> P.S. Emphasis mine :-)
no, emphasis all **mine** :-) just to reflect i never expected .get()
to work that way (return an unsolicited None) -- i do consider this
behavior harmful and suggest it be removed.
_wolf
Wolfgang Lipp wrote:
> that's a bug! i had to *test* it to find out it's true! i've been writing
> code for *years* all in the understanding that dict.get(x) acts precisely
> like dict['x'] *except* you get a chance to define a default value.
Clearly, your understanding *all* these years *was* wro
On Sat, 27 Aug 2005 08:54:12 +0200, Martin v. Löwis <[EMAIL PROTECTED]>
wrote:
> with choice 1a): dict.get returns None if the key is not found, even
> though None could also be the value for the key.
that's a bug! i had to *test* it to find out it's true! i've been writing
code for *years* all
A.B., Khalid wrote:
> #--- Python 2.5a0 from CVS -#
> # Result: passes
> $ /g/projs/py25/python/dist/src/MinGW/python testbz2.py
>
>
> #--- Python 2.4.1 from CVS -#
> # Result: fails
> $ /g/projs/py24/python/dist/src
[Martin]
> For another example, file.read() returns an empty string at EOF.
When my turn comes for making 3.0 proposals, I'm going to recommend
nixing the "empty string at EOF" API. That is a carry-over from C that
made some sense before there were iterators. Now, we have the option of
introduci
> > The most important reason for the patch is that looking at the
context
> > diff will provide an objective look at how real code will look
before
> > and after the change. This would make subsequent discussions
> > substantially more informed and less anecdotal.
>
> No, you're just artificiall
Bill Janssen wrote:
>> 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
40 matches
Mail list logo
