Re: [Python-Dev] New Py_UNICODE doc
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 UTF-16 is a valid option for both of these things, but supporting the CEF does not imply supporting the CES. All of your complaints would be valid if we claimed that Python supported the UTF-16 CES, but the language itself only needs to support a CEF that everyone understands how to work with. It is widely recognized, I believe, that the general level of unicode support exposed to Python users is somewhat lacking when it comes to high surrogate pairs. I'd love for us to fix that problem, or, better yet, integrate something like ICU, but this isn't that discussion. > - unicodedata doesn't work for 2-char strings containing a surrogate > pairs, nor integers. Therefore it is impossible to get any data on > chars > 0x. > - there are no methods for determining if something is a surrogate > pair and turning it into a integer codepoint. > - Given that unicodedata doesn't work, I doubt also that .toupper/etc > work right on surrogate pairs, although I haven't tested. > - As has been noted before, the regexp engine doesn't properly treat > surrogate pairs as a single unit. > - Is there a method that is like unichr but that will work for > codepoints > 0x? > > I'm sure there's more as well. I think it's a mistake to consider > python to be implementing UTF-16 just because it properly > encodes/decodes surrogate pairs in the UTF-8 codec. Users should understand (and we should write doc to help them understand), that using 2-byte wide unicode support in Python means that all operations will be done on Code Units, and not Code Points. Once you understand this, you can work with the data that is given to you, although it's certainly not as nice as what you would have come to expect from Python. (For example, you can correctly construct a regexp to find the surrogate pair you're looking for by using the constituent code units). -- Nick ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Py_UNICODE doc
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 point is doing > that in pure Python (because if I had to write an extension module, > I could just as well do the entire lexical analysis in C, without > any regular expressions). You can write such a codec in Python, but C will of course be more efficient. The whole point is that for things that you will likely use a lot in your application, it is better to have one efficient implementation than dozens of duplicate re character sets embedded in compiled re-expressions. > Any kind of associative/indexed table for this task consumes a lot > of memory, and takes quite some time to initialize. Right - which is why an algorithmic approach will always be more efficient (in terms of speed/memory tradeoff) and these *can* support surrogates. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 11 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python continually calling sigprocmask() on FreeBSD 5
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 seen from the following ktrace(1) dump: > > 673 python 0.07 CALL sigprocmask(0x3,0,0x811d11c) > 673 python 0.05 RET sigprocmask 0 > 673 python 0.09 CALL sigprocmask(0x1,0,0x8113d1c) > 673 python 0.05 RET sigprocmask 0 > etc.. > > This is using Python 2.4.1. > Any clue about why this is happening? In a word, no. As far as I am aware, there are no calls whatsoever to sigprocmask in Python 2.4.1 (there were in 2.3.X, but these were connected to threads and the mentioned script doesn't use them). So you need to do some digging of your own. > (Please include me to the recipients for any reply, as I'm not > subscribed) OK, but there's always Gmane if you just want to watch python-dev for a bit. Cheers, mwh -- . <- the pointyour article -> . |- a long way | -- Christophe Rhodes, ucam.chat ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
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__. You don't need to make that translation, though. Instead, you can just reraise the passed in exception inside the __exit__() method: def __exit__(self, *exc_info): try: try: if exc_info: raise exc_info[0], exc_info[1], exc_info[2] except: pass else: pass finally: pass However, the __exit__() method does allow you to switch to using if statements if that makes more sense (or would be more efficient). For instance, these are possible __exit__ methods for a locking() statement template and a transaction() statement template: # locking's exit method def __exit__(self, *exc_info): self.lock.release() if exc_info: raise exc_info[0], exc_info[1], exc_info[2] # transaction's exit method def __exit__(self, *exc_info): if exc_info: self.db.rollback() raise exc_info[0], exc_info[1], exc_info[2] else: self.db.commit() 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 This version cleans up the semantics a lot, so that the examples actually work as intended, and there is One Obvious Way to do things like suppressing exceptions (i.e. don't reraise them in the __exit__() method). It also specifically addresses the question of using two methods in the protocol versus four, and shows how an arbitrary try statement can be converted to a statement template. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
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. However, one thing immediately struck me: if __exit__ gets an exception and does not re-raise it, it is silently ignored. This seems like a bad idea - the usual "errors should not pass silently" applies. I can very easily imagine statement templates accidentally eating KeyboardInterrupt or SystemExit exceptions. 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 recorded. And if there aren't any good reasons, this behaviour should probably be changed. Paul. PS Apologies if I missed the discussion of this in the PEP - as I say, I've only skimmed it so far. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python continually calling sigprocmask() on FreeBSD 5
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 sigprocmask(), as can be seen from the following ktrace(1) dump: >> >>673 python 0.07 CALL sigprocmask(0x3,0,0x811d11c) >>673 python 0.05 RET sigprocmask 0 >>673 python 0.09 CALL sigprocmask(0x1,0,0x8113d1c) >>673 python 0.05 RET sigprocmask 0 >>etc.. >> >>This is using Python 2.4.1. >>Any clue about why this is happening? > > > In a word, no. > > As far as I am aware, there are no calls whatsoever to sigprocmask in > Python 2.4.1 (there were in 2.3.X, but these were connected to threads > and the mentioned script doesn't use them). So you need to do some > digging of your own. As I noted in a followup to the FreeBSD list where this came up, this appears to be a consequence of FreeBSD's Python port being configure'ed with the "-with-fpectl" option. This option uses setjmp()/longjump() around floating point ops for FP exception management, and it is the setjmp()/longjmp() in the FreeBSD threaded C libs that calls sigprocmask() as above. This option was certainly required for FreeBSD 4.x and earlier, where SIGFPE wasn't masked by default (at least that's my understanding of why the option was required...). I have the understanding that starting with 5.0 or 5.1, FreeBSD now does mask SIGFPE by default and so this option may not be necessary in this environment. A FreeBSD list member with a 5.3 system tested the microbenchmark that exposed the issue with a Python interpreter built without "-with-fpectl" and the performance issue disappeared. It is not yet clear whether it is appropriate that the port be changed to drop this configure option. Regards, Andrew. - Andrew I MacIntyre "These thoughts are mine alone..." E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Kernel panic writing to /dev/dsp with cmpci driver
thanx and regards duraivel ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] CHANGE BayPIGgies: May *THIRD* Thurs
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]) <*> http://www.pythoncraft.com/ "And if that makes me an elitist...I couldn't be happier." --JMS ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
[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, and I'm willing to reduce the functionality somewhat. It would help if you could support this. In particular, while I like the use case transactional() (example 3 in PEP 340) enough to want some indicator of success or failure, I don't see the point of having separate __except__, __else__ and __finally__ entry points. It's unclear how these would be mapped to the generator API, and whether more than one could be called e.g. what if __else__ raises an exception itself -- will __finally__ be called? I'm sure that could be specified rigorously, but I'm not so sure that it is going to be useful and clear. I see several possible levels of information that could be passed to the __exit__ call: (1) None. This is insufficient for the transactional() use case. (2) Only a bool indicating success or failure. This is sufficient for the transactional() use case. (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/bugs in __exit__() and should be avoided by robust __exit__() methods. (4) Like (3), but also distinguish between non-local gotos (break/continue/return), exceptions, and normal completion of BLOCK. (I'm not sure that this is really different from (3).) What do you think? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 2.4 set objects and cyclic garbage
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. Thanks to my colleague Matt Messier for finding this. kick-me-if-i'm-smoking-something-ly y'rs, -Barry http://sourceforge.net/tracker/index.php?func=detail&aid=1200018&group_id=5470&atid=305470 cycle.py Description: application/python signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
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/bugs in __exit__() and should be
>avoided by robust __exit__() methods.
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.:
class Attempt(object):
def __init__(self,type,last=False):
self.type = type
self.last = last
def __enter__(self): pass
def __exit__(self,*exc):
if exc and not last and issubclass(exc[0],self.type):
# suppress exception
return True
def retry(count, type=Exception):
attempt = Attempt(type)
for i in range(count-1):
yield attempt
yield Attempt(type, True)
# usage:
for attempt in retry(3):
do attempt:
somethingThatCouldFail()
and:
class logging_exceptions(object):
def __init__(self,logger): self.logger = logger
def __enter__(self): pass
def __exit__(self,*exc):
if exc:
# log and suppress error
self.logger.error("Unexpected error", exc_info=exc)
return True
while True:
do logging_exceptions(my_logger):
processEvents()
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
[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 stops an exception from propagating outward is worth an explicit try/except clause, so the reader knows what is happening. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
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 clearer using an explicit try/except? >IMO anything that actually stops an exception from propagating outward >is worth an explicit try/except clause, so the reader knows what is >happening. I thought the whole point of PEP 340 was to allow abstraction and reuse of patterns that currently use "try" blocks, including "except" as well as "finally". So, if you're only going to allow try/finally abstraction, wouldn't it make more sense to call it __finally__ instead of __exit__? That would make it clearer that this is purely for try/finally patterns, and not error handling patterns. As for whether they're written more clearly using an explicit try/except, I don't know. Couldn't you say exactly the same thing about explicit try/finally? For that matter, if you used function calls, doesn't it produce the same issue, e.g.: def retry(count,exc_type=Exception): def attempt(func): try: func() except exc_type: pass for i in range(count-1): yield attempt yield lambda f: f() for attempt in retry(3): attempt(somethingThatMightFail) Is this bad style too? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
> >[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/except? > >IMO anything that actually stops an exception from propagating outward > >is worth an explicit try/except clause, so the reader knows what is > >happening. [Phillip] > I thought the whole point of PEP 340 was to allow abstraction and reuse of > patterns that currently use "try" blocks, including "except" as well as > "finally". Indeed it was. But I'm getting a lot of pushback on the PEP so I'm exploring a simpler proposal with a more limited use case -- that of PEP 310, basically. Note that generators written for this new proposal do not contain try/finally or try/except (and don't need it); they simply contain some actions before the yield and some actions after it, and the with/do/block/stmt statement takes care of calling it. > So, if you're only going to allow try/finally abstraction, > wouldn't it make more sense to call it __finally__ instead of > __exit__? That would make it clearer that this is purely for try/finally > patterns, and not error handling patterns. I don't think the name matteres that much; __exit__ doesn't particularly mean "error handling" to me. I think PEP 310 proposed __enter__ and __exit__ and I was just following that; I've also thought of __enter__/__leave__ or even the nostalgic __begin__/__end__. > As for whether they're written more clearly using an explicit try/except, I > don't know. Couldn't you say exactly the same thing about explicit > try/finally? For try/finally we have a large body of use cases that just scream for abstraction. I'm not convinced that we have the same for try/except. Maybe the key is this: with try/finally, the control flow is unaffected whether the finally clause is present or not, so hiding it from view doesn't matter much for understanding the code; in fact in my mind when I see a try/finally clause I mentally translate it to something that says "that resource is held for the duration of this block" so I can stop thinking about the details of releasing that resource. try/except, on the other hand, generally changes the control flow, and there is much more variety in the except clause. I don't think the need for abstraction is the same. > For that matter, if you used function calls, doesn't it > produce the same issue, e.g.: > > def retry(count,exc_type=Exception): > def attempt(func): > try: func() > except exc_type: pass > for i in range(count-1): > yield attempt > yield lambda f: f() > > for attempt in retry(3): > attempt(somethingThatMightFail) > > Is this bad style too? Yes (not to mention that the retry def is unreadable and that the 'attempt' callable feels magical). There are many ways of coding retry loops and seeing the bottom two lines (the use) in isolation doesn't give me an idea of what happens when the 3rd attempt fails. Here, EIBTI. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
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): if exc and not last and issubclass(exc[0],self.type): # suppress the exception raise None This seems clearer than "return True". Shane ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
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 exceptions using a new idiom: > > def __exit__(self,*exc): > if exc and not last and issubclass(exc[0],self.type): > # suppress the exception > raise None > >This seems clearer than "return True". Nice, although perhaps a little too cute. But it's moot as Guido has vetoed the whole idea. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Unifying try-except and try-finally
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: > try: > A > finally: > B > except IOError: >C > > A more flexible approach would be to allow finally at the beginning or > ending of the try statement. A more flexible approach would be to > allow both, or even finally clauses mixed in. > > To me, that's the ugly portion of this proposal, it's quite arbitrary. > And the alternatives I posted have their own brands of ugly. I strongly disagree. It makes sense to me, anyway, that "finally" can only be the final clause and that it always does exactly what it says: execute as the final bit of the try statement. 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. > Concisely, this is an arbitrary shortcut for an idiom that already > exists. It seems to me that this shortcut would be redundant if PEP > 340 or something with similar functionality was accepted. I do see your point here and I'll be curious to see how this shapes up (given the lengthy discussion going on about this tricky proposal). But I also feel that the unification of try/except and try/finally is truly an improvement to the language. To me it feels like a simplification -- it removes an artificial, annoying and unnecessary split. -- Russell ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Unifying try-except and try-finally
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 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 want to see how nastly documenting try/except/finally can get. And they don't even have an else clause! ;-) STeVe [1]http://java.sun.com/docs/books/jls/download/langspec-3.0.pdf -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
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 recorded. And if there aren't any good reasons, this behaviour > should probably be changed. This is a good point - it's one of the things I changed in the simplification of the semantics between 1.3 and 1.4 (previously the behaviour was much as you describe). The gist is that the alternative is to require an __exit__() method to raise TerminateBlock in order to suppress an exception. Then the call to __exit__() in the except clause needs to be wrapped in a try/except TerminateBlock/else, with the else reraising the exception, and the except clause suppressing it. The try/except around BLOCK1 has to have a clause added to reraise TerminateBlock so that it isn't inadvertently suppressed when it is raised by user code (although that may be a feature, not a bug! - I'll have to think about that one) Basically, it's possible to set it up that way, but it was a little ugly and hard to explain. "It's suppressed if you don't reraise it" is very simple, but makes it easier (too easy?) to inadvertently suppress exceptions. If people are comfortable with a little extra ugliness in the semantic details of 'do' statements in order to make it easier to write correct __exit__() methods, then I'm happy to change it back (I think I just talked myself into doing that, actually). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
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 finally clauses, not arbitrary exception handling. I believe he's misinterpreting the cause of the pushback against PEP 340 (I think it was the looping that was found objectionable, not the ability to suppress exceptions), but *shrug* :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
[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 pushback against PEP 340 (I think it was the > looping that was found objectionable, not the ability to suppress exceptions), > but *shrug* :) I realize that the pushback was against looping, but whereas in the PEP 340 proposal general exception handling comes out naturally, it feels as an ugly wart in the modified PEP 310 proposal. Plus I think the use cases are much weaker (even PEP 340 doesn't have many use cases for exception handling -- the only one is the auto-retry example). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Unifying try-except and try-finally
[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 > want to see how nastly documenting try/except/finally can get. And > they don't even have an else clause! ;-) Fine with me. Can I go ahead and approve this now before someone proposes to add a new keyword? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
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-statement was simply:
stmt = EXPR1
try:
stmt_enter = stmt.__enter__
stmt_exit = stmt.__exit__
except AttributeError:
raise TypeError("User defined statement template required")
VAR1 = stmt_enter() # Omit 'VAR1 =' if no 'as' clause
exc = ()
try:
try:
BLOCK1
except:
exc = sys.exc_info()
finally:
stmt_exit(*exc)
would this make any of the examples impossible to write? All you have
to do to suppress an exception is to not reraise it in __exit__.
These semantics would make a normally completed BLOCK1 look like a
BLOCK1 exited through return, break or continue, but do we have any
use cases that actually need this distinction? I couldn't see any,
but I've been reading *way* too many PEP 310/340 posts so probably my
eyes are just tired. ;-)
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):
raise exc[0], exc[1], exc[2]
That would mean that if any nonzero object was returned from __exit__,
the exception would be reraised.
But, like I say, I've been reading this thread way too much, so I'm
probably just missing the TerminateBlock use cases. =)
STeVe
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
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): >raise exc[0], exc[1], exc[2] > > That would mean that if any nonzero object was returned from __exit__, > the exception would be reraised. Oops. This should have been: finally: if not stmt_exit(*exc): raise exc[0], exc[1], exc[2] This would mean that if a function returned None (or any other "False" object) the exception would be reraised. Suppressing the reraising of the exception would require returning a nonzero object. STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking off Enhanced Iterators PEP from PEP 340
[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 > Enhanced Iterators PEP is first, the remainder of PEP 340 follows it.) Thanks Steven! I've finally found the few minutes it takes to check in your changes. All: the proposal of the extended continue statement, which passes a value to yield, is now separated off into PEP 342, Enhanced Iterators. (I noticed I snuck in another syntactic change, making yield without an expression legal. I'm updating PEP 342 now to add that explicitly.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
[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:
> raise TypeError("User defined statement template required")
>
> VAR1 = stmt_enter() # Omit 'VAR1 =' if no 'as' clause
> exc = ()
> try:
> try:
> BLOCK1
> except:
> exc = sys.exc_info()
> finally:
> stmt_exit(*exc)
>
> would this make any of the examples impossible to write? All you have
> to do to suppress an exception is to not reraise it in __exit__.
But this use case would contain a trap for the unwary user who is
writing an __exit__ method -- they have to remember to re-raise an
exception if it was passed in, but that's easy to forget (and slightly
tricky since you have to check the arg count or whether the first
argument is not None).
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__(self, filename): self.filename = filename
def __enter__(self): self.f = open(self.filename); return self.f
def __exit__(self, *args): self.f.close()\
And do EXPR as VAR: BLOCK would mentally be translated into
itr = EXPR
VAR = itr.__enter__()
try: BLOCK
finally: itr.__exit__(*sys.exc_info()) # Except sys.exc_info() isn't
defined by finally
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
[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__(self, filename): self.filename = filename > def __enter__(self): self.f = open(self.filename); return self.f > def __exit__(self, *args): self.f.close()\ > > And do EXPR as VAR: BLOCK would mentally be translated into > > itr = EXPR > VAR = itr.__enter__() > try: BLOCK > finally: itr.__exit__(*sys.exc_info()) # Except sys.exc_info() isn't > defined by finally Yeah, that's what I wanted to do too. That should be about what my second suggestion did. Slightly updated, it looks like: stmt = EXPR1 VAR1 = stmt.__enter__() exc = () # or (None, None, None) if you prefer try: try: BLOCK1 except: exc = sys.exc_info() finally: if stmt.__exit__(*exc) is not None: raise exc[0], exc[1], exc[2] The only difference should be that with the above semantics if you return a (non-None) value from __exit__, the exception will be suppressed (that is, it will not be reraised). Means that if you want to suppress an exception, you have to add a return statement (but if you want exceptions to be reraised, you don't have to do anything.) I suggest this only because there were a few suggested use-cases for suppressing exceptions. OTOH, almost all my uses are just try/finally's so I'm certainly not going to cry if that last finally instead looks like: finally: stmt.__exit__(*exc) raise exc[0], exc[1], exc[2] =) STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?
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): self.f = open(self.filename); return self.f > def __exit__(self, *args): self.f.close()\ > > And do EXPR as VAR: BLOCK would mentally be translated into > > itr = EXPR > VAR = itr.__enter__() > try: BLOCK > finally: itr.__exit__(*sys.exc_info()) # Except sys.exc_info() isn't > defined by finally In this example locking's __enter__ does not return anything. Would do EXPR: BLOCK also be legal syntax? -eric ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
