The PEP has been rejected.
-Brett
On 8/25/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/25/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> > I wish Fredrik would chime in. He would
> > have something pithy, angry, and incisive to say about this.
>
> Raymond, I'm sick of the abuse
Andrew Koenig wrote:
>>A closure based accumulator (using Scheme):
>>
>>(define (accum n)
>> (lambda (incr)
>> (set! n (+ n incr))
>> n))
>>(define s (accum 0))
>>(s 1) ; -> 1 == 0+1
>>(s 5) ; -> 6 == 1+5
>>
>>So I thought the generator version might look like:
>>
>>def accum(n):
>> while
> A closure based accumulator (using Scheme):
>
> (define (accum n)
> (lambda (incr)
>(set! n (+ n incr))
>n))
> (define s (accum 0))
> (s 1) ; -> 1 == 0+1
> (s 5) ; -> 6 == 1+5
>
> So I thought the generator version might look like:
>
> def accum(n):
> while 1:
> incr =
On 8/25/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Guido> It's never too early to start deprecating a feature we know will
> Guido> disappear in 3.0.
>
> Though if it's a widely used feature the troops will be highly annoyed by
> all the deprecation warnings. (Or does deprecatio
On 8/25/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I do have a followup question on the style thing. (I'll leave others to
> answer MAL's question about optimization.) If I want to raise an exception
> without an argument, which of the following is the proper form?
>
> raise ValueErr
MAL> I must have missed this one:
That's because it was brief and to the point, so the discussion lasted for
maybe three messages. Also, someone told us you were on holiday so we
thought we could squeak it through without you noticing. Darn those
Aussies. Late on the pydev summary again!
Guido> It's never too early to start deprecating a feature we know will
Guido> disappear in 3.0.
Though if it's a widely used feature the troops will be highly annoyed by
all the deprecation warnings. (Or does deprecation not coincide with
emitting warnings?)
Skip
_
Phillip J. Eby wrote:
> At 02:10 PM 8/25/2005 -0500, Ian Bicking wrote:
>
>>I was trying to translate a pattern that uses closures in a language
>>like Scheme (where closed values can be written to) to generators using
>>PEP 342, but I'm not clear exactly how it works; the examples in the PEP
>>ha
At 02:10 PM 8/25/2005 -0500, Ian Bicking wrote:
>I was trying to translate a pattern that uses closures in a language
>like Scheme (where closed values can be written to) to generators using
>PEP 342, but I'm not clear exactly how it works; the examples in the PEP
>have different motivations. Sinc
I was trying to translate a pattern that uses closures in a language
like Scheme (where closed values can be written to) to generators using
PEP 342, but I'm not clear exactly how it works; the examples in the PEP
have different motivations. Since I can't actually run these examples,
perhaps s
Raymond Hettinger wrote:
>>Deprecation means your code will still work I hope every book that
>>documents "except:" also adds "but don't use this except under very
>>special circumstances".
>>
>>I think you're overreacting (again), Raymond. 3.0 will be much more
>>successful if we can introduce man
Guido van Rossum wrote:
> On 8/25/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>
>>I wish Fredrik would chime in. He would
>>have something pithy, angry, and incisive to say about this.
>
>
> Raymond, I'm sick of the abuse. Consider the PEP rejected.
>
Perhaps you should go for the £10
[PLEASE IGNORE PREVIOUS EMAIL... I HIT [Send] BY MISTAKE]
Guido:
> But how about the following compromise: make it a silent deprecation
> in 2.5, and a full deprecation in 2.6.
Reinhold Birkenfeld:
> That said, I think that unless it is a new feature (like with statements)
> transitions to Pytho
Guido:
> But how about the following compromise: make it a silent deprecation
> in 2.5, and a full deprecation in 2.6.
Reinhold Birkenfeld:
> That said, I think that unless it is a new feature (like with statements)
> transitions to Python 3.0 shouldn't be enforced in the 2.x series. With 3.0,
> e
On 8/25/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I wish Fredrik would chime in. He would
> have something pithy, angry, and incisive to say about this.
Raymond, I'm sick of the abuse. Consider the PEP rejected.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Raymond Hettinger wrote:
>... I propose that the transition plan be as simple as introducing
> BaseException. This allows people to write code that will work on both
> 2.x and 3.0. It doesn't break anything.
>
> The guidance for cross-version (2.5 to 3.0) code would be:
>
> * To catch all but
> > Also, as we learned with apply(), even if
> > ignored, the deprecation machinery has a tremendous runtime cost.
None
> > of this will make upgrading to Py2.5 an attractive option.
>
> Not in this case; bare except: can be flagged by the parser so the
> warning happens only once per compilatio
Raymond Hettinger wrote:
>> Deprecation means your code will still work I hope every book that
>> documents "except:" also adds "but don't use this except under very
>> special circumstances".
>>
>> I think you're overreacting (again), Raymond. 3.0 will be much more
>> successful if we can introdu
On Wed, Aug 24, 2005 at 09:11:18PM +0200, Dieter Maurer wrote:
> Neil Schemenauer <[EMAIL PROTECTED]> writes on Mon, 22 Aug 2005 15:31:42
> -0600:
> > The code was fixed by changing
> > the line "header = str(header)" to:
> >
> > if isinstance(header, unicode):
> > hea
On 8/25/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>[...] AFAICT, there is no other way to broadly
> catch exceptions not derived from Exception.
But there is rarely a need to do so. I bet you that 99 out of 100 bare
excepts in the stdlib could be replaced by "except Exception" without
break
> > Walter Dörwald wrote:
> >>At least it would remove the quadratic number of calls to
> >>_PyUnicodeUCS2_IsLinebreak(). For each character it would be called only
> >>once.
> Martin v. Löwis wrote:
> > Correct. However, I very much doubt that this is the cause of the
> > slowdown.
> Walter Dörw
Hi Martin (and everyone else); thanks for your mail. The N*N/2
invocations would explain why we saw such a large number of invocations
--- thanks for figuring it out. W.r.t. how we're invoking our script:
> > But if you're using CGI, you're importing your source on every
> > invocation.
>
> Well
The following message is a courtesy copy of an article
that has been posted to comp.lang.python as well.
Neil Schemenauer <[EMAIL PROTECTED]> writes on Mon, 22 Aug 2005 15:31:42 -0600:
> ...
> Some code may require that str() returns a str instance. In the
> standard library, only one suc
On Thu, Aug 25, 2005 at 11:58:48AM -0400, Raymond Hettinger wrote:
> Deprecation is only warranted if the interim substitute works --
> AFAICT, there is no other way to broadly catch exceptions not
> derived from Exception.
This seems to get to the heart of the problem. I'm no fan of bare
excepts
> Deprecation means your code will still work I hope every book that
> documents "except:" also adds "but don't use this except under very
> special circumstances".
>
> I think you're overreacting (again), Raymond. 3.0 will be much more
> successful if we can introduce many of its features into 2.
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::
> >
> > raise SomeException("
On 8/25/05, Sjoerd Mullender <[EMAIL PROTECTED]> wrote:
> There is an important point, though. Recently I read complaints about
> the lack of backward compatibility in Python on the fedora-list (mailing
> list for users of Fedora Core). Somebody asked what language he should
> learn and people an
On 8/25/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> It's only an overstatement if Guido didn't mean what he said. If bare
> except clauses are deprecated in 2.x, it WILL affect tons of existing
> code and invalidate a portion of almost all Python books.
Deprecation means your code will sti
Michael Chermside wrote:
> Raymond writes:
>
>>Efforts to improve Py3.0 have spilled
>>over into breaking Py2.x code with no compensating benefits. [...]
>>We don't have to wreck 2.x in order to make 3.0 better.
>
>
> I think you're overstating things a bit here.
There is an important point, th
> > Efforts to improve Py3.0 have spilled
> > over into breaking Py2.x code with no compensating benefits. [...]
> > We don't have to wreck 2.x in order to make 3.0 better.
>
> I think you're overstating things a bit here.
It's only an overstatement if Guido didn't mean what he said. If bare
exc
Raymond writes:
> Efforts to improve Py3.0 have spilled
> over into breaking Py2.x code with no compensating benefits. [...]
> We don't have to wreck 2.x in order to make 3.0 better.
I think you're overstating things a bit here.
> Remember, the ONLY benefit from the whole PEP is that in 3.0, it w
> > OK, I'm convinced. Let's drop bare except for Python 3.0, and
> > deprecate them until then, without changing the meaning.
> >
>
> Woohoo
That's no cause for celebration. Efforts to improve Py3.0 have spilled
over into breaking Py2.x code with no compensating benefits. Bare
except clauses a
I must have missed this one:
>
> Style for raising exceptions
>
>
> Guido explained that these days exceptions should always be raised as::
>
> raise SomeException("some argument")
>
> instead of::
>
> raise SomeException, "some
Here's August Part One. As usual, if anyone can spare the time to proofread
this, that would be great! Please send any corrections or suggestions to
Steve (steven.bethard at gmail.com) and/or me, rather than cluttering the
list. Ta!
=
Announcements
=
---
Guido van Rossum <[EMAIL PROTECTED]> writes:
> On 8/24/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
>> I really hope string exceptions can be killed off before 3.0. They
>> should be fully deprecated in 2.5.
>
> But what about class exceptions that don't inherit from Exception?
> That will take
35 matches
Mail list logo
