On 8/24/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Aug 24, 2005, at 9:39 PM, Brett Cannon wrote:
> > On 8/24/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >> On 8/24/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> >>> I think it must be the case that raising an object which does not
> >
On Aug 24, 2005, at 9:39 PM, Brett Cannon wrote:
> On 8/24/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On 8/24/05, James Y Knight <[EMAIL PROTECTED]> wrote:
>>> I think it must be the case that raising an object which does not
>>> derive from an exception class must be deprecated as well in
On Wed, 2005-08-24 at 22:33, A.M. Kuchling wrote:
> So, it's time to start considering it for inclusion in the standard
> library. This is a big change to a non-obscure module, so don't feel
> able to make this decision on my own.
>
> I believe the code quality is acceptable, but would appreciat
Gregory K. Johnson, who's been working on the mailbox module in
nondist/sandbox/mailbox for Google's Summer of Code, thinks his
project is essentially complete. He's added the ability to modifying
mailboxes by adding and removing messages, adding test cases for the
new features, and written the co
On 8/24/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> Is there any desire for a __future__ statement that makes it a syntax
> error? How about making 'raise' statements only work with objects
> that inherit from BaseException?
I doubt it. Few people are going to put a __future__ statement in to
m
On 8/24/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/24/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> > Explicit is better than Implicit. I think that in newly written code
> > "except Exception:" is better (more explicit and easier to understand)
> > than "except:" Legacy code that
On 8/24/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/24/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> > I think it must be the case that raising an object which does not
> > derive from an exception class must be deprecated as well in order
> > for "except:" to be deprecated. Otherwise,
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 a while before we can deprecate that.
Anyway, there ha
Reinhold Birkenfeld wrote:
> after adding Oleg Broytmann's findnocoding.py to Tools/scripts, I
> wonder whether the Tools directory is documented at all. There are
> many useful scripts there which many people will not find if they are
> not listed anywhere in the docs.
Christos already mentioned
Am 24.08.2005 um 20:20 schrieb Greg Wilson:
>>> 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
"Reinhold Birkenfeld" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
> Hi,
>
> after adding Oleg Broytmann's findnocoding.py to Tools/scripts, I wonder
> whether the Tools directory is documented at all. There are many useful
> scripts there which many people will not find if they are
Am 24.08.2005 um 21:15 schrieb Martin v. Löwis:
> Walter Dörwald wrote:
>
>
>>> Right. Not sure what people think whether this should still be
>>> supported, but I keep supporting it whenever I think of it.
>>>
>>
>> OK, so should we add this for 2.4.2 or only for 2.5?
>>
>
> You mean, string.unic
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
>> > Hmm, that may not be a killer. I wonder if it is possible to treat
>> > BaseException as a constant (like we do with None) and teach the
>> > compiler to interpret it as catching anything that gets raised so
> that
>> > "except BaseException" w
> > Hmm, that may not be a killer. I wonder if it is possible to treat
> > BaseException as a constant (like we do with None) and teach the
> > compiler to interpret it as catching anything that gets raised so
that
> > "except BaseException" will work like a bare except clause does now.
>
> Sorry
On Wed, 2005-08-24 at 15:15, Raymond Hettinger wrote:
> Hmm, that may not be a killer. I wonder if it is possible to treat
> BaseException as a constant (like we do with None) and teach the
> compiler to interpret it as catching anything that gets raised so that
> "except BaseException" will work
[Guido van Rossum]
> > OK, I'm convinced. Let's drop bare except for Python 3.0, and
> > deprecate them until then, without changing the meaning.
> >
> > The deprecation message (to be generated by the compiler!) should
> > steer people in the direction of specifying one particular exception
> > (e
Walter Dörwald wrote:
>> Right. Not sure what people think whether this should still be
>> supported, but I keep supporting it whenever I think of it.
>
>
> OK, so should we add this for 2.4.2 or only for 2.5?
You mean, string.unicodelinebreaks? I think something needs to be
done to fix the perf
Hello!
On Wed, Aug 24, 2005 at 08:33:02PM +0200, Reinhold Birkenfeld wrote:
> after adding Oleg Broytmann's findnocoding.py to Tools/scripts
What's more, pysource.py is more than just a script - it's a generally
useful module.
Thank you for committing the code.
Oleg.
--
Oleg Broytma
Hi,
after adding Oleg Broytmann's findnocoding.py to Tools/scripts, I wonder
whether the Tools directory is documented at all. There are many useful
scripts there which many people will not find if they are not listed
anywhere in the docs.
Just a thought.
Reinhold
--
Mail address is perfectly
On Wed, 2005-08-24 at 12:38, "Martin v. Löwis" wrote:
> I personally dislike recording the execution path in
> local variables. This is like setting a flag in a loop
> before the break, and testing the flag afterwards.
> You can do this, but the else: clause of the loop is
> just more readable.
A
Martin v. Löwis wrote:
> 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.
>
> Correct. However, I very much doubt that this is the cause of the
> slowdown.
Probably. We'd need a
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.
Correct. However, I very much doubt that this is the cause of the
slowdown.
> The last part of the patch seems to be more related to
M.-A. Lemburg wrote:
> Walter Dörwald wrote:
>
>>I wonder if we should switch back to a simple readline() implementation
>>for those codecs that don't require the current implementation
>>(basically every charmap codec).
>
> That would be my preference as well. The 2.4 .readline() approach
>
On Wed, 2005-08-24 at 07:33, "Martin v. Löwis" wrote:
> Walter Dörwald wrote:
> > Martin v. Löwis wrote:
> >
> >> Walter Dörwald wrote:
[...]
> Actually, on a second thought - it would not remove the quadratic
> aspect. You would still copy the rest string completely on each
> split. So on the fir
On 8/24/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Hey guys, don't give up your bare except clauses so easily.
They are an attractive nuisance by being so much shorter to type than
the "right thing to do".
Especially if they default to something whose use cases are rather
esoteric (i.e. B
On 8/24/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> I think it must be the case that raising an object which does not
> derive from an exception class must be deprecated as well in order
> for "except:" to be deprecated. Otherwise, there is nothing you can
> change "except:" to in order not to
Raymond Hettinger wrote:
> Hey guys, don't give up your bare except clauses so easily.
Yes, Don't give up. I often write code starting with a bare except,
then after it works, stick a raise in it to determine exactly what
exception I'm catching. Then use that to rewrite a more explicit except
Martin v. Löwis wrote:
> Walter Dörwald wrote:
>
>>Martin v. Löwis wrote:
>>
>>>Walter Dörwald wrote:
>>>
I think a maxsplit argument (just as for unicode.split()) would help
too.
>>>
>>>Correct - that would allow to get rid of the quadratic part.
>>
>>OK, such a patch should be rather si
Niko Matsakis wrote:
>>
>> txn = new_transaction()
>> try:
>> txn.begin()
>> rtn = do_work()
>> finally:
>> if exception_occurred():
>> txn.abort()
>> else:
>> txn.commit()
>> return rtn
>>
>
> Couldn't you just do:
>
> txn = new_transaction ()
> try
Niko Matsakis wrote:
> Couldn't you just do:
>
> txn = new_transaction ()
> try:
> complete = 0
> txn.begin ()
> rtn = do_work ()
> complete = 1
> finally:
> if not complete: txn.abort ()
> else: txn.commit ()
>
> and then not need new builtins or anything fancy?
I
Raymond writes:
> Hey guys, don't give up your bare except clauses so easily.
[...]
Raymond:
I agree that when comparing:
// Code snippet A
try:
...
except SomeException:
...
except BaseException:
...
with
// Code snippet B
try:
...
except
>
> txn = new_transaction()
> try:
> txn.begin()
> rtn = do_work()
> finally:
> if exception_occurred():
> txn.abort()
> else:
> txn.commit()
> return rtn
>
Couldn't you just do:
txn = new_transaction ()
try:
complete = 0
txn.begin ()
Barry Warsaw wrote:
> I agree about bare except, but there is a very valid use case for an
> except clause that catches every possible exception. We need to make
> sure we don't overlook this use case. As an example, say I'm building a
> transaction-aware system, I'm going to want to write code l
Hey guys, don't give up your bare except clauses so easily.
They are useful. And, if given the natural meaning of "catch
everything" and put in a natural position at the end of a suite, their
meaning is plain and obvious. Remember beauty counts. I don't think
there would be similar temptation t
On Aug 24, 2005, at 11:10 AM, Guido van Rossum wrote:
> On 8/24/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
>
>> Explicit is better than Implicit. I think that in newly written code
>> "except Exception:" is better (more explicit and easier to
>> understand)
>> than "except:" Legacy code t
On 8/24/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> Explicit is better than Implicit. I think that in newly written code
> "except Exception:" is better (more explicit and easier to understand)
> than "except:" Legacy code that uses "except:" can remain unchanged *IF*
> the meaning of "excep
On Wed, 2005-08-24 at 10:34, James Y Knight wrote:
> I would rather see "except:" be deprecated eventually, and force the
> user to say either except Exception, except BaseException, or even
> better, except ActualExceptionIWantToCatch.
I agree about bare except, but there is a very valid use
On Aug 23, 2005, at 10:41 PM, Raymond Hettinger wrote:
> [Guido van Rossum]
>
>> If we syntactically enforce that the bare except, if present, must be
>> last, would that remove your objection? I agree that a bare except in
>> the middle is an anomaly, but that doesn't mean we can't keep bare
>>
Walter Dörwald wrote:
> Martin v. Löwis wrote:
>
>> Walter Dörwald wrote:
>>
>>> I think a maxsplit argument (just as for unicode.split()) would help
>>> too.
>>
>>
>> Correct - that would allow to get rid of the quadratic part.
>
>
> OK, such a patch should be rather simple. I'll give it a try.
Martin v. Löwis wrote:
> Walter Dörwald wrote:
>
>>I think a maxsplit argument (just as for unicode.split()) would help too.
>
> Correct - that would allow to get rid of the quadratic part.
OK, such a patch should be rather simple. I'll give it a try.
> We should also strive for avoiding the s
Raymond Hettinger writes:
> The latest version of PEP 348 still proposes that a bare except clause
> will default to Exception instead of BaseException. Initially, I had
> thought that might be a good idea but now think it is doomed and needs
> to be removed from the PEP.
Guido writes:
> If we sy
Walter Dörwald wrote:
> I think a maxsplit argument (just as for unicode.split()) would help too.
Correct - that would allow to get rid of the quadratic part.
We should also strive for avoiding the second copy of the line,
if the user requested keepends.
I wonder whether it would be worthwhile to
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>I think it's worthwhile reconsidering this approach for
>>character type queries that do no involve a huge number
>>of code points.
>
>
> I would advise against that. I measure both versions
> (your version called PyUnicode_IsLinebreak2) with the
Martin v. Löwis wrote:
> Walter Dörwald wrote:
>
>>This is caused by the chances to the codecs in 2.4. Basically the codecs
>>no longer rely on C's readline() to do line splitting (which can't work
>>for UTF-16), but do it themselves (via unicode.splitlines()).
>
> That explains why you get an
M.-A. Lemburg wrote:
> I think it's worthwhile reconsidering this approach for
> character type queries that do no involve a huge number
> of code points.
I would advise against that. I measure both versions
(your version called PyUnicode_IsLinebreak2) with the
following code
volatile int result;
Walter Dörwald wrote:
> I wonder if we should switch back to a simple readline() implementation
> for those codecs that don't require the current implementation
> (basically every charmap codec).
That would be my preference as well. The 2.4 .readline() approach
is really only needed for codecs
Walter Dörwald wrote:
> This is caused by the chances to the codecs in 2.4. Basically the codecs
> no longer rely on C's readline() to do line splitting (which can't work
> for UTF-16), but do it themselves (via unicode.splitlines()).
That explains why you get any calls to IsLineBreak; it doesn'
Keir Mierle wrote:
> Hi, I'm working on Argon (http://www.third-bit.com/trac/argon) with Greg
> Wilson this summer
>
> We're having a very strange problem with Python's unicode parsing of source
> files. Basically, our CGI script was running extremely slowly on our
> production
> box (a pokey du
Raymond Hettinger wrote:
> The latest version of PEP 348 still proposes that a bare except clause
> will default to Exception instead of BaseException. Initially, I had
> thought that might be a good idea but now think it is doomed and needs
> to be removed from the PEP.
One thing I assumed was t
> As for the rest, I'm not as sure and it would be helpful to get
> thoughts
> from others on this one. My sense is that blocking the clause from
> appearing in the middle is treating the symptom and not the disease.
+1
It would be better to prohibit bare except entirely (well, presumably
at
50 matches
Mail list logo
