On May 10, 2005, at 7:34 PM, James Y Knight wrote:
> If you're going to call python's implementation UTF-16, I'd consider
> all these very serious deficiencies:
The --enable-unicode option declares a character encoding form (CEF),
not a character encoding scheme (CES). It is unfortunate that U
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>If all you're interested in is the lexical class of the code points
>>in a string, you could use such a codec to map each code point
>>to a code point representing the lexical class.
>
>
> How can I efficiently implement such a codec? The whole p
Suleiman Souhlal <[EMAIL PROTECTED]> writes:
> Hello,
>
> While investigating why the script used in http://docs.freebsd.org/
> cgi/getmsg.cgi?fetch=148191+0+current/freebsd-stable used so much
> system time on FreeBSD 5, I noticed that python is continually
> calling sigprocmask(), as can be
Phillip J. Eby wrote:
> Of course, it's not *really* that simple, because __try__ doesn't exactly
> correspond to 'try:', and it has to return something, but it sure is
> simpler than the mental gymnastics I'd go through to convert
> except/else/finally into "if" statements inside an __exit__.
On 5/11/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I've posted draft 1.4 of my PEP 310/PEP 340 merger PEP (PEP 650, maybe?):
> http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
I've been skipping the discussion, but this is starting to look pretty
good. I'll give it a proper read soon.
Michael Hudson wrote:
> Suleiman Souhlal <[EMAIL PROTECTED]> writes:
>
>>While investigating why the script used in http://docs.freebsd.org/
>>cgi/getmsg.cgi?fetch=148191+0+current/freebsd-stable used so much
>>system time on FreeBSD 5, I noticed that python is continually
>>calling sigprocmas
thanx and regards
duraivel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Reminder:
We will *NOT* be meeting the *SECOND* Thursday (this week, May 12).
Our May meeting will be the *THIRD* Thursday, May 19. This will be our
first meeting at Google, with Alex Martelli's presention on design
patterns. More details soon!
--
Aahz ([EMAIL PROTECTED]) <*>
[Guido]
> > Now it would make more sense to change the syntax to
> >
> > with EXPR as VAR:
> > BLOCK
> >
> > and we have Phillip Eby's proposal.
[Greg]
> Change the 'with' to 'do' and I'd be +1 on this.
Great! But the devil is in the details. I want to reduce the
complexity, a
In setobject.c rev 1.26 + 1.27 Raymond removed gc support from built-in
set objects, claiming in the log message that "sets cannot have
cycles". Yet the attached program creates a cycle that I don't believe
ever gets reclaimed.
Patch 1200018 restores GC support to set objects for Python 2.4. Tha
At 10:00 AM 5/11/2005 -0700, Guido van Rossum wrote:
>(3) Full exception information, with the understanding that when
>__exit__() returns normally, exception processing will resume as usual
>(i.e. __exit__() is called from a finally clause). Exceptions raised
>from __exit__() are considered errors
[Phillip J. Eby]
> FYI, there are still use cases for clearing the exception state in an
> __exit__ method, that might justify allowing a true return from __exit__ to
> suppress the error. e.g.:
[...]
Yes, but aren't those written clearer using an explicit try/except?
IMO anything that actually s
At 10:42 AM 5/11/2005 -0700, Guido van Rossum wrote:
>[Phillip J. Eby]
> > FYI, there are still use cases for clearing the exception state in an
> > __exit__ method, that might justify allowing a true return from __exit__ to
> > suppress the error. e.g.:
>[...]
>
>Yes, but aren't those written cle
> >[Phillip J. Eby]
> > > FYI, there are still use cases for clearing the exception state in an
> > > __exit__ method, that might justify allowing a true return from __exit__
> > > to
> > > suppress the error. e.g.:
> >[...]
[Guido]
> >Yes, but aren't those written clearer using an explicit try/
Phillip J. Eby wrote:
> FYI, there are still use cases for clearing the exception state in an
> __exit__ method, that might justify allowing a true return from __exit__ to
> suppress the error. e.g.:
Maybe __exit__ could suppress exceptions using a new idiom:
def __exit__(self,*exc):
At 12:44 PM 5/11/2005 -0600, Shane Hathaway wrote:
>Phillip J. Eby wrote:
> > FYI, there are still use cases for clearing the exception state in an
> > __exit__ method, that might justify allowing a true return from
> __exit__ to
> > suppress the error. e.g.:
>
>Maybe __exit__ could suppress exce
In article <[EMAIL PROTECTED]>,
Timothy Fitz <[EMAIL PROTECTED]> wrote:
> > No, as except clauses can only occur before the finally clause, and
> > execution
> > should not go backwards.
>
> This restriction feels a bit arbitrary. I can guarantee someone is
> going to flatten this:
>
> try:
>
On 5/11/05, Russell E. Owen <[EMAIL PROTECTED]> wrote:
> I think this would be a useful enhancement. It simplifies the published
> documentation a bit (no need to document try/except as a separate entity
> from try/finally) and I have plenty of cases where I'd like to take
> advantage of it.
I hav
Paul Moore wrote:
> At the very least, there should be a section in "rejected
> alternatives" explaining why it is not appropriate to force reraising
> of exceptions unless explicit action is taken. There could be good
> reasons (as I say, I haven't followed the discussion) but they should
> be rec
Paul Moore wrote:
> PS Apologies if I missed the discussion of this in the PEP - as I say,
> I've only skimmed it so far.
With Guido's latest comments, it looks like this is going to be going into the
"Open Issues" section - his current inclination is that do statements should
only abstract fina
[Nick Coghlan]
> With Guido's latest comments, it looks like this is going to be going into the
> "Open Issues" section - his current inclination is that do statements should
> only abstract finally clauses, not arbitrary exception handling. I believe
> he's
> misinterpreting the cause of the push
[Steven Bethard]
> I have a feeling that it might actually be easier to continue to
> document try/except and try/finally separately and then just give the
> semantics of try/except/finally in terms of the other semantics. Take
> a look at the Java Language Specification[1] (pages 399-401) if you
On 5/11/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> The gist is that the alternative is to require an __exit__() method to raise
> TerminateBlock in order to suppress an exception.
So I didn't see any examples that really needed TerminateBlock to
suppress an exception. If the semantics of a do-
On 5/11/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> If you want the default to be that the exception gets re-raised
> (instead of being suppressed as it is above), I think you could just
> change the finally block to something like:
>
> finally:
> if stmt_exit(*exc):
>r
[Steven Bethard]
> Well, busy-work or not, I took the 20 minutes to split them up, so I
> figured I might as well make them available. It was actually really
> easy to split them apart, and I think they both read better this way,
> but I'm not sure my opinion counts for much here anyway. ;-) (The
[Steven Bethard]
> So I didn't see any examples that really needed TerminateBlock to
> suppress an exception. If the semantics of a do-statement was simply:
>
> stmt = EXPR1
> try:
> stmt_enter = stmt.__enter__
> stmt_exit = stmt.__exit__
> except AttributeError:
>
[Guido]
> Going for all-out simplicity, I would like to be able to write these examples:
>
> class locking:
> def __init__(self, lock): self.lock = lock
> def __enter__(self): self.lock.acquire()
> def __exit__(self, *args): self.lock.release()
>
> class opening:
> def __init__(se
Guido van Rossum wrote:
> class locking:
> def __init__(self, lock): self.lock = lock
> def __enter__(self): self.lock.acquire()
> def __exit__(self, *args): self.lock.release()
>
> class opening:
> def __init__(self, filename): self.filename = filename
> def __enter__(self): se
28 matches
Mail list logo
