Re: [Python-Dev] python-dev Summary for 2005-03-01 through 2005-03-15 [draft]
[Paul Moore] On Thu, 17 Mar 2005 18:21:33 -0800, Brett C. [EMAIL PROTECTED] wrote: 2.4.1 should be out soon Python 2.4.1c1 is out. Very shortly c2 will be released. Assuming no major issues come up, 2.4 final will be out. You probably mean something like 2.4.1 final will be out shortly afterwards (I don't recall if a date has been confirmed). Yes I did. =) Fixed. -Brett ___ 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
Re: [Python-Dev] Terminology for PEP 343
Resource managed? On 6/30/05, Raymond Hettinger [EMAIL PROTECTED] wrote: With 343 accepted, we can now add __enter__() and __exit__() methods to objects. What term should describe those objects in the documentation? For instance, if the new magic methods are added to decimal.Context(), do we then describe Context objects as withable ;-) The PEP itself doesn't provide much of a clue. The terms template, wrapper, and block are over-broad and do not provide a metaphor for setup/teardown, r entry/exit, or initialization/finalization. Whatever term is selected, it should be well thought-out and added to the glossary. The choice of words will likely have a great effect on learnability and on how people think about the new tool. Raymond ___ 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/brett%40python.org ___ 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
Re: [Python-Dev] Terminology for PEP 343
On 7/1/05, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote: On Friday 01 July 2005 11:44, Phillip J. Eby wrote: Resource managers. Yeah, I was thinking that, but was somewhat ambivalent. But I definately like it better than anything else proposed so far. I say we steal from the C++ and the RAII paradigm and go with RMUW (Resource Management Using 'with'). No need to get cutesy and we already have acronym overload anyway, so one more won't kill us. -Brett ___ 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
Re: [Python-Dev] Chaining try statements: eltry?
On 7/7/05, Tim Peters [EMAIL PROTECTED] wrote: [Guido] OTOH I don't particularly like code that requires flag variables; Me neither; that's indeed why this one isn't a slam dunk. they often make me squirm because the same condition (flag) is tested multiple times where it could be tested just once if more sophisticated flow control (e.g. an else clause :) was available. What burns me (far) more often in practice is simulating a multi-level `break` or `continue`. Then multiple flag variables get introduced, set, and tested multiple times at multiple logical indent levels too. That can also be viewed as stemming from a lack of more sophisticated flow control. One-loop found-it-or-didn't kinds of flag variables have spatial locality that makes them (IME) quite easy to live with, in comparison. How would a PEP to *remove* this feature fare today? Easy: it would be rejected, but with a note that it should be reconsidered for Python 3000. Barry also reiterated this idea and I support removing them in Python 3000. I do use them when I want to know when I break out of a loop prematurely, but I am definitely not a typical use case for experienced users since I basically learned how to program in Python so I didn't have any baggage preventing me from not remembering they existed. Simplifying the basic control flow mechanisms is always good. And as Aahz pointed out, you can use exceptions to break out of a loop easily enough and have code for only when you break out with the exception (maybe we should add a ControlFlowException in Py3000 that all other control flow exceptions, like StopIteration inherit from?). In other words they are not critical and not used frequently from what it sounds like. And even in the cases where they are used they can be reworked to not need them without much hassle. -Brett ___ 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
[Python-Dev] Another SoC student for CVS access
Floris is working on wrapping Hotshot to replace 'profile' and replacing pstats so that there will be no more need for 'profile' and thus take care of the licensing problem. He also hopes to make pstats faster to use. And if we are really lucky, get threading working for Hotshot. It would be great to give him CVS access so he can work in nondist. His username is sirolf . He knows he is not to touch anything outside of his directory in nondist. -Brett ___ 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
Re: [Python-Dev] Another SoC student for CVS access
On 7/7/05, Jeremy Hylton [EMAIL PROTECTED] wrote: On 7/7/05, Brett Cannon [EMAIL PROTECTED] wrote: Floris is working on wrapping Hotshot to replace 'profile' and replacing pstats so that there will be no more need for 'profile' and thus take care of the licensing problem. He also hopes to make pstats faster to use. And if we are really lucky, get threading working for Hotshot. I don't think we actually want to get rid of profile and replace it with hotshot. We want to have both tools available. This is mainly for backup if the original 'profile' is not available. Debian, for instance, leaves out 'profile' because of its licensing. I don't plan on removing 'profile' from CVS or anything. -Brett ___ 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
[Python-Dev] checklist for filing a bug
In order to lower the barrier for reporting bugs, writing patches, and handling CVS commits, I am writing up checklists for each and I will put them up on python.org. The first checklist is for bug reports. All comments welcome. Keep in mind the list is supposed to be short and straight-forward; too wordy and people won't read it. Reporting a Bug +++ For technical question for any step listed, refer to the `dev FAQ`_. #. Make sure the bug is reproducible The bug cannot be a freak occurence and must be reproducible so developers can test against it. #. Isolate bug Come up with a code snippet that is as succinct as possible that triggers the bug consistently. Coding it as a unit test is the best. #. Gather important information Info such as Python version, operating system version, etc.; anything that might have influenced the code that lead to the bug. #. Report the bug on SourceForge_ Create a new tracker item, filling out the ``Category`` and ``Group`` fields. Do not set the ``Assigned To`` or ``Priority`` fields. Upload your code snippet as a file and make sure to click the ``Upload`` button! .. _dev FAQ: http://www.python.org/dev/devfaq.html .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470atid=105470 ___ 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
Re: [Python-Dev] Possible context managers in stdlib
On 7/8/05, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: Hi, I compiled a list of some possible new context managers that could be added to the stdlib. Introducing a new feature should IMO also show usage of it in the distribution itself. That wasn't done with decorators (a decorators module is compiled at the moment, if I'm right), but with context managers, there's certainly room to add some. Of course, my list is excessive, it's only some ideas I got by flying over the stdlib docs. I think that is a good point about decorators. While none of us obviously had extensive experience with decorators when they went into the language we at least knew of a couple use cases that would have been handy and it probably would have been good to have examples for people to work off of. I bet iterators have gotten more play thanks to itertools and all of the built-ins that work with them. I think having basic context managers in a stdlib module that we know for a fact that will be handy is a good idea. We should keep the list short and poignant, but we should have something for people to work off of. The ones I like below for a 'context' module are: * builtins: with open/file * sys: with sys.redirected_std[in|out|err] * decimal: with decimal.Context * os: with os.current_directory * mutex: with mutexobj * threading: with threading.Lock with threading.Condition with threading.Event * bz2/zipfile/tarfile: with ...open -Brett ___ 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
Re: [Python-Dev] Another SoC student for CVS access
This is taking too long, so I am going to have Floris do his dev work somewhere else. Forget about the request. -Brett On 7/7/05, Brett Cannon [EMAIL PROTECTED] wrote: Floris is working on wrapping Hotshot to replace 'profile' and replacing pstats so that there will be no more need for 'profile' and thus take care of the licensing problem. He also hopes to make pstats faster to use. And if we are really lucky, get threading working for Hotshot. It would be great to give him CVS access so he can work in nondist. His username is sirolf . He knows he is not to touch anything outside of his directory in nondist. -Brett ___ 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
Re: [Python-Dev] [Python-checkins] python/dist/src/Miscdevelopers.txt, 1.15, 1.16
On 7/14/05, Raymond Hettinger [EMAIL PROTECTED] wrote: raymond Log Message: raymond Brett requests that Flovis's permissions be dropped. [Skip] Not to put too fine a spin on things, but I think it was more like Brett got tired of waiting for Flovis's permissions to be increased and retracted his original request. Brett and Flovis DID send a private email with a drop request this morning. They have chosen an alternate method of access. Brett's original request was fulfilled within 48 hours. I sent him a confirmation note. Also, there was a concurrent check-in notification for Misc/developers.txt. Additionally, Flovis's id appeared on the SF developer list immediately. If for some reason they did not see any of those three, they could have sent a follow-up note and gotten a fourth confirmation that the job was done. Yeah, I missed all three; I just kept expecting a reply to the python-dev list and wasn't looking for any other signs, so it's my bad. I moved over to Gmail a few weeks ago and I am still working out my Python workflow with it. -Brett ___ 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
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
On 7/28/05, Barry Warsaw [EMAIL PROTECTED] wrote: On Thu, 2005-07-28 at 16:00, Martin v. Löwis wrote: I'd like to see the Python source be stored in Subversion instead of CVS +1 +1 from me as well; single commit numbers for commits across multiple files will be wonderful. , and on python.org instead of sf.net. +0 I know that SF has promised svn access to projects for a long time now, but I haven't heard anything from them in a long time. It's listed under their Strategic Projects but the last update to that news item was back in April. Question: do we wait for SF to make the service available (after getting more up-to-date status and a realistic timetable), or do we go straight to svn.python.org? I say forget SF and we move it. Of course I won't be involved with the migration so me saying this doesn't mean too much. =) 1. Assign passwords for all current committers for use on svn.python.org. User names on SF and svn.python.org should be identical, unless some committer requests a different user name. We've been going with firstname.lastname (with some exceptions -- hi Aahz! :) for the current svn access. Is it better to stay with that convention or to maintain consistency with SF's CVS committer names? Maybe the latter for revision history consistency. I say go with the first.last naming. While this might put committer names out of sync, we could keep a mapping of SF names to the new names in developers.txt for easy referencing. But it would be handy to have actual name references since I know I don't always remember who is whom on SF since some people go with nicks that are not based on their name at all. [SNIP] 4. Convert the CVS repository into two subversion repositories, one for distutils and one for Python. Do we also want to split off nondist and encodings? IWBNI the Python source code proper weren't buried too deep in the directory structure. Note that we might want to provide different access permission to different parts of the repository (but I think we can do that even if we don't split those off into separate repos). Seems like a reasonable thing. Would make it easier for occasional committers as well as people who check out the code just for generating a patch. -Brett ___ 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
[Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
Well, it has been discussed at multiple times in the past and I have promised to write this PEP several times, so I finally found enough time to write a PEP on reorganizing exceptions for Python 3.0 . Key points in this PEP is the reworking the hierarchy, requiring anything raised to inherit from a certain superclass, and to change bare 'except' clauses to catch a specific superclass. The first and last points I expect some contention, but the middle point I expect people are okay with (Guido liked the idea when Paul Prescod brought it up and the only person who didn't like it, Holger, ended up being okay with it when the superclass had a reasonable name). One thing people might not notice is that I have some minor ideas listed in the tree in parentheses. If people have an opinion on the ideas please speak up. Otherwise the other major points of contention are covered in the Open Issues section or will be brought up in the usual trashing of PEPs that cover contraversial changes. And please realize this is for Python 3.0! None of this is being proposed for any version before then (they could be, but that is another PEP entirely). Hopefully this PEP along with Ping's PEP 344 will cover the major ideas for exceptions for Python 3.0 . -Brett -- PEP: XXX Title: Exception Reorganization for Python 3.0 Version: $Revision: 1.5 $ Last-Modified: $Date: 2005/06/07 13:17:37 $ Author: Brett Cannon [EMAIL PROTECTED] Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 28-Jul-2005 Post-History: XX-XXX-XXX Abstract Python, as of version 2.4, has 38 exceptions (including warnings) in the built-in namespace in a rather shallow hierarchy. This list of classes has grown over the years without a chance to learn from mistakes and cleaning up the hierarchy. This PEP proposes doing a reorganization for Python 3000 when backwards-compatibility is not an issue. It also proposes changing bare ``except`` clauses to catch only exceptions inheriting from a specific superclass. Lastly, this PEP proposes, in Python 3000, that all objects to be passed to a ``raise`` statement must inherit from a specific superclass. Rationale = Exceptions are a critical part of Python. While exceptions are traditionally used to signal errors in a program, they have also grown to be used for flow control for things such as iterators. There importance is great. But the organization of the exception hierarchy has not been maintained. Mostly for backwards-compatibility reasons, the hierarchy has stayed very flat and old exceptions who usefulness have not been proven have been left in. Making exceptions more hierarchical would help facilitate exception handling by making catching exceptions much more logical with use of superclasses. This should also help lead to less errors from being too broad in what exceptions are caught in an ``except`` clause. A required superclass for all exceptions is also being proposed [Summary2004-08-01]_. By requiring any object that is used in a ``raise`` statement to inherit from a specific superclass, certain attributes (such as those laid out in PEP 344 [PEP344]_) can be guaranteed to exist. This also will lead to the planned removal of string exceptions. Lastly, bare ``except`` clauses can be made less error-prone [Summary2004-09-01]_. Often people use a bare ``except`` when what they really wanted were non-critical exceptions to be caught while more system-specific ones, such as MemoryError, to pass through and to halt the interpreter. With a hierarchy reorganization, bare ``except`` clauses can be changed to only catch exceptions that subclass a non-critical exception superclass, allowing more critical exceptions to propagate to the top of the execution stack as was most likely intended. Philosophy of Reorganization There are several goals in this reorganization that defined the philosophy used to guide the work. One goal was to prune out unneeded exceptions. Extraneous exceptions should not be left in since it just serves to clutter the built-in namespace. Unneeded exceptions also dilute the importance of other exceptions by splitting uses between several exceptions when all uses should have been under a single exception. Another goal was to introduce any exceptions that were deemed needed to fill any holes in the hierarchy. Most new exceptions were done to flesh out the inheritance hierarchy to make it easier to catch a category of exceptions with a simpler ``except`` clause. Changing inheritance to make it more reasonable was a goal. As stated above, having proper inheritance allows for more accurate ``except`` statements when catching exceptions based on the inheritance tree. Lastly, any renaming to make an exception's use more obvious from its name was done. Having to look up what an exception is meant to be used for because the name does not proper reflect its usage
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/29/05, Robert Brewer [EMAIL PROTECTED] wrote: Brett Cannon wrote: New Hierarchy = Raisable (new; rename BaseException?) +-- CriticalException (new) +-- KeyboardInterrupt +-- MemoryError +-- SystemExit +-- SystemError (subclass SystemExit?) I'd recommend not subclassing SystemExit--there are too many programs out there which expect the argument (e.g. sys.exit(3)) to mean something specific, but that expectation doesn't apply at all to SystemError. Don't forget this is Python 3.0; if it makes more sense we can break code. +-- Exception (replaces StandardError) ... +-- ControlFlowException (new) I'd definitely appreciate ControlFlowException--there are a number of exceptions in CherryPy which should subclass from that. Um, CherryPy 3.0, that is. ;) =) Well, assuming Guido thinks this is enough of a possible use case. +-- LookupError (better name?) SubscriptError, perhaps? But LookupError could become the I didn't find obj X in the container you specified superclass, in which case LookupError is perfect. That's what it's meant for and renaming it GetitemError doesn't exactly clarify it for newbies. =) I doubt something better is going to be found. +-- TypeError +-- AttributeError (subclassing new) Since most attribute access errors can be attributed to an object not being the type that one expects, it makes sense for AttributeError to be considered a type error. Very hmmm. I would have thought it would be a LookupError instead, only because I favor the duck-typing parts of Python. Making AttributeError subclass from TypeError leans toward stronger typing models a bit too much, IMO. This idea has been brought up before on several separate occasions and this subclassing was what was suggested. It seems a decision needs to be made as to whether the lack of an attribute is a failure of using the wrong type of object, just a failure to find something in an object, or a failure to find a name in a namespace. I lean towards the first one, you like the second, and Guido seems to like the third. $20 says Guido's opinion in the end will matter more than ours. =) +-- WeakReferenceError (rename for ReferenceError) This also has a LookupError feel to it. Nope, as Fred explains in his own email. It has been argued that Raisable is a bad name to use since it is not an actual word [python-dev1]_. Perhaps, but compare http://www.onelook.com/?w=raisable to http://www.onelook.com/?w=raiseable. The only sources raiseable has going for it are Dictionary.com (which aggregates lots of questionable sources), Rhymezone, and LookWAYup. I think raisable is the clear winner. And Guido seems fine with it, so unless someone can convince Guido otherwise the PEP will go with Raisable. -Brett ___ 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
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
OK, I withdraw the suggestion of the subclassing of SystemError by SystemExit. -Brett On 7/29/05, Guido van Rossum [EMAIL PROTECTED] wrote: On 7/29/05, Robert Brewer [EMAIL PROTECTED] wrote: +-- SystemExit +-- SystemError (subclass SystemExit?) I'd recommend not subclassing SystemExit--there are too many programs out there which expect the argument (e.g. sys.exit(3)) to mean something specific, but that expectation doesn't apply at all to SystemError. Agreed. SystemExit is used by sys.exit(); SystemError is something completely different, used by the interpreter when it finds an internal invariant is broken. It is one step short of a fatal error -- the latter is used when we have evidence of random memory scribbling, the former when the interpreter is still intact. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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/brett%40python.org ___ 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
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/30/05, Nick Coghlan [EMAIL PROTECTED] wrote: Brett Cannon wrote: +-- ControlFlowException (new) While I like the idea of ControlFlowException as the one obvious way to break out of multiple nested loops, I'm not convinced StopIteration and GeneratorExit should be inheriting from it. However, I'm even less sure StopIteration and GeneratorExit should be in the Exception portion of the hierarchy at all. This is particularly true of GeneratorExit - I would be very concerned if except Exception: were to suppress GeneratorExit. If ControlFlowException was moved up to be a peer of Exception, I'd be much happier with the idea - we would then have four major categories of raisable classes: CriticalException - something is seriously wrong ControlFlowException - an exception is being used to affect control flow in a particular way, and should be intercepted only if you know what that control flow is doing Exception - your every day, run of the mill, exceptions Warning - not really an exception. I can live with this. I was waivering on putting ControlFlowException under CriticalException, but obviously keeping that dichotomy was more important back when bare 'except' clauses were going to be allowed, but now that it looks like they are being removed I am much more open to putting stuff to inherit directly from Raisable. +-- GeneratorExit (introduced by PEP 342 [PEP342]_; subclass StopIteration?) Definitely not. GeneratorExit was added because the following idiom prevents the use of StopIteration or a subclass to reliably terminate a generator: try: yield itr.next() catch StopIteration: pass Good enough for me. +-- LookupError (better name?) +-- IndexError +-- KeyError I don't think there is a particularly strong argument to change the name of LookupError. While Py3K *allows* backwards incompatibility, we shouldn't be gratutitous about it. It looks like the backwards-compatilibity gods are starting to stomp on me; I can sacrifice a renaming to appease them. +-- TypeError +-- AttributeError (subclassing new) +-- NamespaceException (new) +-- UnboundGlobalError (new name for NameError) +-- UnboundLocalError (no longer subclasses UnboundGlobalError which replaces NameError) I'd actually be inclined to make AttributeError a subclass of NameError: +-- NameError +-- AttributeError (subclassing new) +-- UnboundGlobalError (new) +-- UnboundLocalError Current uses of NameError are replaced with UnboundGlobalError. The re-use of NameError reduces the backwards incompatibility, and also concisely summarises the common feature of these three exceptions. Hmm. Well, I think it was either Tim or Barry (or both) who once suggested AttributeError inherit from TypeError, but they have not spoken up nor has anyone else so far supporting the idea. But then again people have argued for LookupError instead. I am going to have to think about this one before I attempt to reply on this topic. RuntimeError Meant to be used when an existing exception does not fit, its usefulness is consider meager in Python 2.4 [exceptionsmodule]_. Also, with the CriticalException/Exception dichotomy, Exception or CriticalException can be raised directly for the same use. Like Guido, I believe RuntimeError is very useful for quick-and-dirty scripts. Also, gratuitous incompatibility should be avoided, even for Py3k. OK, but is the name so great? Yes, it is a runtime error, but it just doesn't hit the point of it being a dirty little exception to use when you don't want to create a new one. How about GenericException or SimpleException? Or are the backwards-compatibility gods going to smack me again for this suggestion and spout something off containing the words not and Perl 6? =) Change the Name of Raisable? It has been argued that Raisable is a bad name to use since it is not an actual word [python-dev1]_. At issue is choosing a name that clearly explains the class' usage. BaseException might be acceptable although the name does not quite make it as explicit as Raisable that the class is not meant to be raised directly. I like Raisable, because it states exactly what the base class indicates: something which can be raised (i.e., used with the raise statement). I'm also unclear on why anyone would say it isn't an actual word: http://dictionary.reference.com/search?q=raisable I think the point was it was not in someone's spell checker. But I consider this point settled since Guido said he was fine with creating a new word. Should Bare ``except`` Clauses be Removed? -- I think Explicit Is Better Than Implicit for this one - a bare except which is not the equivalent of except Raisable would be quite confusing
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/30/05, M.-A. Lemburg [EMAIL PROTECTED] wrote: Brett Cannon wrote: Well, it has been discussed at multiple times in the past and I have promised to write this PEP several times, so I finally found enough time to write a PEP on reorganizing exceptions for Python 3.0 . Key points in this PEP is the reworking the hierarchy, requiring anything raised to inherit from a certain superclass, and to change bare 'except' clauses to catch a specific superclass. The first and last points I expect some contention, but the middle point I expect people are okay with (Guido liked the idea when Paul Prescod brought it up and the only person who didn't like it, Holger, ended up being okay with it when the superclass had a reasonable name). I'm not sure what you meant with the middle, Actually, it was referencing the bare 'except' clauses and changing their semantics. but if this refers to the renaming and reordering of the exception inheritance tree, you can have my -1 on this. I don't have any problem with making all exception inherit from Exception and disallowing bare except clauses. Do you mean all inherit from Exception in order for it be allowed to be passed to 'raise'? So that's a bit inverse of what you've obviously expected :-) If this becomes a theme, yes. But specifically coming from you, MAL, no, not really. =) The reason for my -1 on the renaming and reordering is that it would completely break compatibility of Python 2.x applications with Python 3. Furthermore, there would be next to no chance of writing new applications that run in Python 3 and 2, so you have breakage in both directions. My view of Python 3.0 was that backwards-compatibility would not be a gimme in anyway. I personally am willing to break stuff in the name of clarity, which is the point of this whole endeavour. While I am willing to back off on some the proposed changes, I do think the basic spirit of it is correct. Whether this is desired or not is a different discussion, I just want to point out some important things to consider: When moving from Python 2.x to 3.0, renaming could be solved with the help of some scripts, grep et al. However, there would have to be a good reason for each of these renamings, otherwise this only introduces additional porting overhead. Aliases might be a way to provide soft introduction. Right, so the renaming is not a huge problem. Something that scripts will not be able to help with are changes in the inheritance tree, e.g. if an application catches a ValueError, the programmer might also expect UnicodeErrors to get caught, if the application catches a TypeError, this may not be aware that the TypeError could actually be an AttributeError. Many applications define their own exception classes which then normally inherit from StandardError. In the application itself, you'd then usually use StandardError for the generic catch-all except SystemExit try-excepts. With the new hierarchy, catching Exception (renamed from StandardError) would let e.g. AssertionErrors, SyntaxErrors, etc. that may well have been produced by debugging code or calls to compile() pass through. Right, but if we introduce aliases in Python 2.9 or sooner the transition will be much easier and they will know to rename things. And obviously warnings can be used for people to know that the hierarchy will change. I bet we will put in a PendingDeprecationWarning or SemanticsWarning saying that the inheritance will be different in Python 3.0 . Yes, this will incur more work than had we left it alone, but the whole point of Python 3.0 is to remove quirks. Since exceptions are also used in the interpreter itself for masking certain situations and, of course, in the gazillion 3rd party extensions out there, your proposed change would also have to be applied to C code - where finding such subtleties is even harder than in plain Python. If we fiddle with the exception code raising a Warning will not be too bad for this. Plus you can grep for PyExc_TypeError easily enough to see where you are using classes that have a new inheritance tree. This is all fine, if we really intend to go for complete breakage and basically require that Python 3 applications need to be written from scratch. I for one don't expect Python 2.x code to run automatically without some fiddling. I think saying from scratch is a little strong. I, for one, don't find the existing exception structure all too bad. It has worked for me for many many years without ever having a true need to work around some quirks in the hierarchy. I've had these issues with some 3rd party extensions using the existing Exception class as base-class for their own error classes in cases where a StandardError inheritance would have been much more appropriate, but even there, listing the exceptions in a tuple has so far always helped. Lot's of things just work, but it doesn't mean
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/30/05, James Y Knight [EMAIL PROTECTED] wrote: On Jul 29, 2005, at 11:07 PM, Robert Brewer wrote: I'd recommend not subclassing SystemExit--there are too many programs out there which expect the argument (e.g. sys.exit(3)) to mean something specific, but that expectation doesn't apply at all to SystemError. Yes please make note of this for *all* exception (and otherwise) inheritance. You must ensure that any exception B that inherits from A conforms to A's interface! If that isn't the case, it shouldn't inherit. Lots of people seem to forget this, and it's always a pain in the ass. The reason for requiring inheriting from Raisable is so that the basic interface will be guaranteed for any caught exception. And I don't think that any of the built-ins have any specific attributes sans maybe OSError, but that is a leaf in the inheritance tree so that is not a problem. Don't worry, the interfaces won't change in the middle of a branch. -Brett ___ 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
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/30/05, Nick Coghlan [EMAIL PROTECTED] wrote: M.-A. Lemburg wrote: The reason for my -1 on the renaming and reordering is that it would completely break compatibility of Python 2.x applications with Python 3. Furthermore, there would be next to no chance of writing new applications that run in Python 3 and 2, so you have breakage in both directions. Whether this is desired or not is a different discussion, I just want to point out some important things to consider: When moving from Python 2.x to 3.0, renaming could be solved with the help of some scripts, grep et al. However, there would have to be a good reason for each of these renamings, otherwise this only introduces additional porting overhead. Aliases might be a way to provide soft introduction. Something that scripts will not be able to help with are changes in the inheritance tree, e.g. if an application catches a ValueError, the programmer might also expect UnicodeErrors to get caught, if the application catches a TypeError, this may not be aware that the TypeError could actually be an AttributeError. I think the problems with this can be minimised by avoiding making changes we don't need to. I think only a few changes are needed to get a significantly cleaner structure. Here's a fairly minimal proposal, which is closer to the existing 2.4 structure: Nick, are you going go start subbing in for Tim when he is busy and take my work that I spent hours on, come up with an alternative that took 10 minutes, and have everyone end up loving your newfangled idea 10x more than my original? =) New Hierarchy = Raisable (formerly Exception) +-- CriticalException (new) +-- KeyboardInterrupt +-- MemoryError +-- SystemError +-- ControlFlowException (new) As I have said I am fine with moving ControlFlowException out to here, but it depends if others agree. +-- GeneratorExit +-- StopIteration +-- SystemExit Good point with SystemExit! I am definitely +1 on changing that inheritance. +-- Exception (formerly StandardError) +-- AssertionError +-- AttributeError I am still up for moving AttributeError, but with the amount of arguing going on between where it should go I am not going to be shocked if we go with the status quo. +-- ImportError +-- TypeError +-- WeakReferenceError (formerly ReferenceError) +-- ArithmeticError +-- FloatingPointError +-- DivideByZeroError +-- OverflowError +-- EnvironmentError +-- OSError +-- WindowsError (possibly remove this from builtins) If we are going to lack exceptions for other OSs, I say remove it. No reason Windows should get special treatment with a built-in exception. +-- IOError +-- EOFError +-- LookupError +-- IndexError +-- KeyError +-- NameError +-- UnboundLocalError What about UnboundGlobalError? +-- RuntimeError I still don't like the name. +-- NotImplementedError Interesting idea, but I don't view them as the same. Everyone uses RuntimeError as a Poor Man's Exception, not as an actual runtime error. +-- SyntaxError +-- IndentationError +-- TabError +-- ValueError +-- UnicodeError +-- UnicodeDecodeError +-- UnicodeEncodeError +-- UnicodeTranslateError +-- Warning +-- DeprecationWarning +-- FutureWarning +-- PendingDeprecationWarning Don't like the idea of having DeprecationWarning inherit from PendingDeprecationWarning? -Brett ___ 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
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/30/05, Nick Coghlan [EMAIL PROTECTED] wrote: Brett Cannon wrote: Nick, are you going go start subbing in for Tim when he is busy and take my work that I spent hours on, come up with an alternative that took 10 minutes, and have everyone end up loving your newfangled idea 10x more than my original? =) It's like editing creative writing - I find it far, far easier to take something good and tweak it to make it better, than to come up with something good in the first place ;) You stand on the shoulder of a giant (and I am only partially kidding; people who have met me will get the joke)! +-- Exception (formerly StandardError) +-- AssertionError +-- AttributeError I am still up for moving AttributeError, but with the amount of arguing going on between where it should go I am not going to be shocked if we go with the status quo. Exactly my thought. I had it under NameError for a while, but had difficulty coming up with a case where lumping it in with the lexical scoping errors was actually beneficial. Eventually, the fact that it is easy to add another exception to an except clause, but hard to remove a child you don't want that inherits from a parent you do want persauded me to leave this one alone. I think this one will require BDFL pronouncement to be moved since this already looks like a contested idea. And I don't think Guido is going to care enough to want to see it moved. +-- EnvironmentError +-- OSError +-- WindowsError (possibly remove this from builtins) If we are going to lack exceptions for other OSs, I say remove it. No reason Windows should get special treatment with a built-in exception. True. And the interface looks the same as the normal OSError interface, so it should be possible to replace all uses with a basic OSError. Glad you agree. =) +-- NameError +-- UnboundLocalError What about UnboundGlobalError? I realised this was a misnomer. A failed name lookup actually means: - the name was not in locals - the name was not in any lexically containing scope - the name was not in the module globals - the name was not in builtins The program doesn't know which of those namespaces was *meant* to contain the name - it only knows that none of them actually contained it. This criticism also applies to the current wording of the NameError text used in this situation (which implies the name should have been in the module globals). Now, a case could possibly be made for separate errors for cases like the following: def f(): global x print x # UnboundGlobalError (currently NameError, with usual text) def f(): def g(): print x g() # UnboundFreeVariableError (currently NameError, with specific text) x = 1 Like UnboundLocalError, in both of these cases, the name is potentially known to the compiler - it simply hasn't been bound to anything yet. That was what I was thinking as the use case for UnboundGlobalError. Also, if you read the docs on NameError, it explicitly states that it is for global names that are not found. I am willing to toss in an exception for the failure to find a free variable (although I would call it UnboundFreeError) to flesh this namespace hierarchy out. Then again you could argue you should inherit from each other since a missing local is kind of lack missing the global namespace as well, but that kind of purity just doesn't work for me in this case. [rest of my response to this email is forthcoming] -Brett ___ 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
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/30/05, Nick Coghlan [EMAIL PROTECTED] wrote: Brett Cannon wrote: [SNIP] +-- RuntimeError I still don't like the name. I'm not that fond of it either - but as the builtin exception most likely to be used (abused?) by user code, I expect changing its name would be more pain than it's worth. Maybe, but I am still going to nudge for a change. It might get shot down in the end, but at least I can say I tried. +-- NotImplementedError Interesting idea, but I don't view them as the same. Everyone uses RuntimeError as a Poor Man's Exception, not as an actual runtime error. This particular inheritance is copied from Python 2.4 :) Ah, oops. =) Well, I still don't think they should inherit like that and instead be decoupled. I find the main trick with making RuntimeError more palatable is to avoid thinking of 'runtime' in the sense of 'Python runtime', as in 'Python VM'. That's not what this error is about - a Python VM error is a SystemError. Instead, a RuntimeError is a generic application error - something which happened during happened at program runtime. Right, you shouldn't think that, but isn't that what you thought initially? That is why I want to rename RuntimeError. Renaming RuntimeWarning to SemanticsWarning should help with that distinction. Well, not once the name is changed since people won't know about the former name connection. =) +-- Warning +-- DeprecationWarning +-- FutureWarning +-- PendingDeprecationWarning Don't like the idea of having DeprecationWarning inherit from PendingDeprecationWarning? Not really. Mainly because I'm not sure which way the inheritance should go - I could understand someone wanting to suppress PendingDeprecationWarnings without suppressing DeprecationWarnings. On the other hand, there's your argument that a 'DeprecationWarning is just a PendingDeprecationWarning with a shorter timeframe'. Again, I fell back on the concept that Python's except clause makes it easy to ask for both if you want both, but makes it relatively difficult to undo exception inheritance if it isn't what you want. True, but the hierarchy should still properly reflect increasing severity in my opinion. I am going to push for this; we will see if I get pushed back enough to not do it. -Brett ___ 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
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/30/05, Nick Coghlan [EMAIL PROTECTED] wrote: Phillip J. Eby wrote: I like this a lot, and a good bit of it could actually be done in 2.5, apart from the Exception/StandardError move, assuming also that the renamed errors were also available under their old names. We could probably go so far as to add Raisable to the hierarchy, but I don't think we could actually get quite to your proposed structure without breaking any programs. On the other hand, if we introduce CriticalException and ControlFlowException in 2.5 (inheriting from Exception), and create a new Error base for StandardError, then promote subclassing and catching it instead of Exception, then there will be less to do in 3.0. So, my thoughts for the 2.x series are: Exception CriticalException ControlFlowException Error StandardError If we leave Exception at the top of the hierarchy for Py3k, and use Error to replace StandardError, the hierarchy could look like this: Exception +-- ControlFlowException (new) +-- GeneratorExit +-- KeyboardInterrupt +-- StopIteration +-- SystemExit +-- CriticalError (new) +-- MemoryError +-- SystemError +-- Error (formerly StandardError) +-- AssertionError +-- AttributeError +-- ImportError +-- TypeError +-- WeakReferenceError (formerly ReferenceError) I wouldn't mind using Exception/Error instead of Raisable/Exception - and it seriously reduces the pain of making this transition. Indeed, most of it becomes doable within the 2.x series - the only tricky parts are semantic changes involved with moving the KeyboardInterrupt, MemoryError and SystemError out from under StandardError, and moving EOFError under IOError. I can live with this, but that will require Guido's stamp of approval. So the question is whether or not the Raisable/Exception combination is liked enough that we want to dance through the requisite hoops to get there. Notice that I've classified KeyboardInterrupt as user-initiated control flow and put it under ControlFlowException above. This means that everything under CriticalError and Error actually ends with the word 'Error'. I don't know if I like this change in inheritance. While we do tend to use KeyboardInterrupt as a way to kill a program, is that really control flow, or a critical exception that the program needs to stop because an serious event occurred? I prefer the latter explanation. -Brett ___ 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
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/31/05, Nick Coghlan [EMAIL PROTECTED] wrote: Brett Cannon wrote: Notice that I've classified KeyboardInterrupt as user-initiated control flow and put it under ControlFlowException above. This means that everything under CriticalError and Error actually ends with the word 'Error'. I don't know if I like this change in inheritance. While we do tend to use KeyboardInterrupt as a way to kill a program, is that really control flow, or a critical exception that the program needs to stop because an serious event occurred? I prefer the latter explanation. You're probably right. How does the following reasoning sound: SystemExit, GeneratorExit and StopIteration are all deliberately triggered by certain well-defined elements of normal application code. That is, only certain operations will ever result in a ControlFlowException being raised. KeyboardInterrupt is a better fit with MemoryError and SystemError - something that occurs unexpectedly, at an arbitary point during program execution. That is, a CriticalError may be raised when attempting to execute almost any operation. Yeah, those explanations work for me. I think I am going to have to write an explanation for every exception so its usage is clear. -Brett ___ 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
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/31/05, Willem Broekema [EMAIL PROTECTED] wrote: On 7/31/05, Brett Cannon [EMAIL PROTECTED] wrote: While we do tend to use KeyboardInterrupt as a way to kill a program, is that really control flow, or a critical exception that the program needs to stop because an serious event occurred? I does not seem right to me to think of KeyboardInterrupt as a means to cause program halting. An interpreter could in principle recover from it and resume execution of the program. Same goes for MemoryError as well, but you probably don't want to catch that exception either. The behaviour of the current Python interpreters is that upon encountering an uncaught KeyboardInterrupt (as with any uncaught exception), computation is aborted and a backtrace printed. But that is not how it /must be/ as there might be alternative interpreters that upon encountering an uncaught KeyboardInterrupt will pause execution of the program, but then allow the user to either continue or abort execution, effectively not stopping but pausing the program. Because of this possible recovery, thinking of KeyboardInterrupt as in order to abort the program, the user has caused a keyboard interrupt is wrong; it should be more like just the user has interrupted the computation and whether or not the program is consequently aborted is not predefined. But interpreter termination is not guaranteed for any exception, even SystemError since it can be caught and not re-raised. Plus the common use of hittting ctrl-c while an app is running is to kill it, not to pause the execution. But it doesn't sound like you are arguing against putting KeyboardInterrupt under CriticalException, but just the explanation I gave, right? -Brett ___ 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
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 8/1/05, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote: Nick Coghlan wrote: +-- Exception (formerly StandardError) +-- AttributeError +-- NameError +-- UnboundLocalError +-- RuntimeError +-- NotImplementedError Time to wade in ... I've actually been wondering if NotImplementedError should actually be a subclass of AttributeError. Everywhere I can think of where I would want to catch NotImplementedError, I would also want to catch AttributeError. My main question is whether I would want the reverse to also be true - anywhere I want to catch AttributeError, I would want to catch NotImplementedError. Perhaps instead it should be the other way around - AttributeError inherits from NotImplementedError. This does make some kind of sense - the attribute hasn't been implemented. Both seem to have some advantages, but neither really feels right to me. Thoughts? The problem with subclassing NotImplementedError is you need to remember it is used to signal that a magic method does not work for a specific type and thus should try the __r*__ version. That is not a case, I feel, that has anything to do with attributes but implementation support. I am not going to subclass NotImplementedError unless a huge push for it in a very specific direction. -Brett (who is waiting on a PEP number...) ___ 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
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/3/05, Phillip J. Eby [EMAIL PROTECTED] wrote: At 11:10 PM 8/3/2005 +1000, Nick Coghlan wrote: New exceptions: - Raisable (new base) - ControlFlow (inherits from Raisable) - CriticalError (inherits from Raisable) - GeneratorExit (inherits from ControlFlow) Added inheritance: - Exception from Raisable - StopIteration, SystemExit, KeyboardInterrupt from ControlFlow - SystemError, MemoryError from CriticalError +1 I'd also like to see a Reraisable or something like that to cover both CriticalError and ControlFlow, but it could be a tuple of those two bases rather than a class. But that's just a would be nice feature. Eh, I am not so hot on this idea. I see your argument, Phillip, but I just don't think it will be useful enough to warrant its introduction. Could add to the exceptions module, though. -Brett ___ 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
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/3/05, Guido van Rossum [EMAIL PROTECTED] wrote: So here's a radical proposal (hear the scratching of the finglernail on the blackboard? :-). Start with Brett's latest proposal. Including renaming (I want to know if you support the renamings at all, if I should make them more of an idea to be considered when we get closer to Python 3.0, or just drop them) and the new exceptions? Goal: keep bare except: but change it to catch only the part of the hierarchy rooted at StandardError. Why the change of heart? Backwards-compatibility? Way to keep newbies from choosing Raisable or such as what to catch? - Call the root of the hierarchy Raisable. Fine by me. Will change it before I check in the PEP tonight. - Rename CriticalException to CriticalError (this should happen anyway). I thought I changed that in the latest version. I will change it. - Rename ControlFlowException to ControlFlowRaisable (anything except Error or Exception). No objection from me. - Rename StandardError to Exception. So just ditch StandardError, which is fine by me, or go with Nick's v2 proposal and have all pre-existing exceptions inherit from it? I assume the latter since you said you wanted bare 'except' clauses to catch StandardError. - Make Warning a subclass of Exception. I'd want the latter point even if the rest of this idea is rejected; when a Warning is raised (as opposed to just printing a message or being suppressed altogether) it should be treated just like any other normal exception, i.e. StandardError. Since warnings only become raised if the warnings filter lists it as an error I can see how this is a reasonable suggestion. And if bare 'except' clauses catch StandardError and not Exception they will still propagate to the top unless people explicitly catch Exception or lower which seems fair. -Brett ___ 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
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/3/05, Guido van Rossum [EMAIL PROTECTED] wrote: On 8/3/05, Brett Cannon [EMAIL PROTECTED] wrote: On 8/3/05, Guido van Rossum [EMAIL PROTECTED] wrote: So here's a radical proposal (hear the scratching of the finglernail on the blackboard? :-). Start with Brett's latest proposal. Including renaming (I want to know if you support the renamings at all, if I should make them more of an idea to be considered when we get closer to Python 3.0, or just drop them) and the new exceptions? Most of the renamings sound fine to me. OK, great. I will leave in the new names and the new exceptions. Goal: keep bare except: but change it to catch only the part of the hierarchy rooted at StandardError. Why the change of heart? Backwards-compatibility? Way to keep newbies from choosing Raisable or such as what to catch? The proposal accepts that there's a need to catch all errors that are reasonable to catch: that's why it separates StandardError from the root exception class. So now we're going to recommend that everyone who was using bare 'except:' write 'except StandardError:' instead. So why not have a default? Because you can easily write it without a default. Because of EIBTI? Don't know the acronym (and neither does acronymfinder.com). Seems a weak argument; we have defaults for lots of things. OK. I was fine with bare 'except' clauses to begin with so this is not a huge point of contention for me personally. [SNIP] So just ditch StandardError, which is fine by me, or go with Nick's v2 proposal and have all pre-existing exceptions inherit from it? I assume the latter since you said you wanted bare 'except' clauses to catch StandardError. What do you think? Of course the critical and control flow ones should *not* inherit from it. Well, Nick and Jame's point of tweaking the names so that they more reflect what people expect instead of what they are meant to actually be is interesting. But, in terms of backwards-compatibility, Exception/StandardError is most exacting in terms of matching what already exists. But with renamings I don't know how critical this kind of low-level backwards-compatibility is critical. Personally I just prefer the names Exception/StandardError for unexplained aesthetic reasons. [...brain hums...] OK, I'm changing my mind again about the names again. Exception as the root and StandardError can stay; the only new proposal would then be to make bare 'except:' call StandardError. OK. I will then also leave ControlFlowException as-is. - Make Warning a subclass of Exception. I'd want the latter point even if the rest of this idea is rejected; when a Warning is raised (as opposed to just printing a message or being suppressed altogether) it should be treated just like any other normal exception, i.e. StandardError. Since warnings only become raised if the warnings filter lists it as an error I can see how this is a reasonable suggestion. And if bare 'except' clauses catch StandardError and not Exception they will still propagate to the top unless people explicitly catch Exception or lower which seems fair. Unclear what you mean; I want bare except; to catch Warnings! IOW I want Warning to inherit from whatever the thing is that bare except: catches (if we keep it) and that is the start of all the normal exceptions excluding critical and control flow exceptions. OK, that squares that one away. And it makes sense since you can view Warnings as even less critical exceptions than the non-control and non-critical exceptions and thus should be caught by a default `except' clause. -Brett ___ 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
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/3/05, Russell E. Owen [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Brett Cannon [EMAIL PROTECTED] wrote: New Hierarchy = Exception [SNIP] +-- StandardError [SNIP] +-- EnvironmentError +-- OSError +-- IOError +-- EOFError (new inheritance) [SNIP] I am wondering why OSError and IOError are not under StandardError? This seems a serious misfeature to me (perhaps the posting was just misformatted?). Look again; they are with an inheritance for both of (OS|IO)Error - EnvironmentError - StandardError - Exception. Having one class for normal errors (not exceptions whose sole purpose is to halt the program and not so critical that any continuation is hopeless) sure would make it easier to write code that output a traceback and tried to continue. I'd love it. That is what StandardError is for. -Brett ___ 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
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/3/05, James Y Knight [EMAIL PROTECTED] wrote: On Aug 3, 2005, at 3:00 PM, Guido van Rossum wrote: [...brain hums...] OK, I'm changing my mind again about the names again. Exception as the root and StandardError can stay; the only new proposal would then be to make bare 'except:' call StandardError. I don't see how that can work. Any solution that is expected to result in a usable hierarchy this century must preserve Exception as the object that user exceptions should derive from (and therefore that users should generally catch, as well). There is way too much momentum behind that to change it. Oh, I bet Guido can make them change. =) Look at it this way; going with the Raisable/Exception change and having bare 'except's catch Exception will still lead to a semantic change since CriticalError and ControlFlowException will not be caught. Breakage is going to happen, so why not just do a more thorough change that leads to more breakage? Obviously you are saying to minimize it while Guido is saying to go for a more thorough change. So how much more code is going to crap out with this change? Everything under our control will be fine since we can change it. User-defined exceptions might need to be changed if they inherit directly from Exception instead of StandardError, which is probably the common case, but changing a superclass is not hard. That kind of breakage is not bad since you can easily systematically change superclasses of exceptions from Exception to StandardError without much effort thanks to regexes. I honestly think the requirement of inheriting from a specific superclass will lead to more breakage since you can't grep for exceptions that don't at least inherit from *some* exception universally. -Brett ___ 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
[Python-Dev] Exception Reorg PEP checked in
OK, once the cron job comes around and is run, http://www.python.org/peps/pep-0348.html will not be a 404 but be the latest version of the PEP. Differences since my last public version is that it has BaseException/Exception as the naming hierarchy, Warning inherits from Exception, UserException is UserError, and StandardError inherits from Exception. I also added better annotations on the tree for noticing where inheritance changed and whether it become broader (and thus had a new exception in its MRO) or more restrictive (and thus lost an exception). Basically everything that Guido has brought up today (08-03). I may have made some mistakes changing over to BaseException/Exception thanks to their names being so similar and tossing back in StandardError so if people catch what seems like odd sentences that is why (obviously let me know of the mistake). -Brett ___ 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
Re: [Python-Dev] PEP 348: Exception Reorganization for Python 3.0
On 8/5/05, Raymond Hettinger [EMAIL PROTECTED] wrote: The PEP moves StopIteration out from under Exception so that it cannot be caught by a bare except or an explicit except Exception. IMO, this is a mistake. In either form, a programmer is stating that they want to catch and handle just about anything. There is a reasonable argument that SystemExit special and should float to the top, but that is not the case with StopIteration. When a user creates their own exception for exiting multiple levels of loops or frames, should they inherit from ControlFlowException on the theory that it no different in intent from StopIteration or should they inherit from UserError on the theory that it is a custom exception? I say ControlFlowException. UserError is meant for quick-and-dirty exception usage and not as a base for user error exceptions. If the name is confusing it can be changed to SimpleError. Do you really want routine control-flow exceptions to bypass except Exception. Yes. I suspect that will lead to coding errors that are very difficult to spot (it sure looks like it should catch a StopIteration). I honestly don't think it will. People who are going to care about catching StopIteration are writing custom iterators, not something a newbie will porobably be doing and thus should know to be specific about what exceptions they are catching when they have a specific thing in mind. Be careful with these proposals. While well intentioned, they have ramifications that aren't instantly apparent. Each one needs some deep thought, user discussion, usability testing, and a darned good reason for changing what we already have in the field. Right, which is why this is all in a PEP, so the discussion can happen and the kinks can be worked out. As for the testing, that can happen with __future__ statements, people trying out a patch, or maybe even some testing branch of Python for possible 3000 features. -Brett ___ 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
Re: [Python-Dev] Exception Reorg PEP checked in
On 8/4/05, Nick Coghlan [EMAIL PROTECTED] wrote: Brett Cannon wrote (in the PEP): KeyboardInterrupt inheriting from ControlFlowException KeyboardInterrupt has been a contentious point within this hierarchy. Some view the exception as more control flow being caused by the user. But with its asynchronous cause thanks to the user being able to trigger the exception at any point in code it has a more proper place inheriting from CriticalException. It also keeps the name of the exception from being CriticalError. I think this argues against your own hierarchy, since you _did_ call the parent exception CriticalError. By your argument above, that suggests KeyboardInterrupt doesn't belong there ;) =) Drawback of having names swapped in and out so many times. In practice, whether KeyboardInterrupt inherits from ControlFlowException or CriticalError shouldn't be a big deal - the important thing is to get it out from under Exception and StandardError. In general, probably. At which point, the naming issue is enough to incline me towards christening it a ControlFlowException. It gets all the 'oddly named' exceptions into one place. Good point. I think I would like to see Guido's preference for this since it feels like it should be under CriticalError. Additionally, consider that a hypothetical ThreadExit exception (used to terminate a thread semi-gracefully) would also clearly belong under ControlFlowException. That is, just because something is asynchronous with respect to the currently executing code doesn't necessarily make it an error (yes, I know I argued the opposite point the other day. . .). Another good point. I am leaning towards moving it now, but I still would like to hear Guido's preference, if he has one. -Brett ___ 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
Re: [Python-Dev] Exception Reorg PEP checked in
On 8/4/05, Nick Coghlan [EMAIL PROTECTED] wrote: Since I forgot to mention it in the last couple of messages - this version looks very good. The transition strategy section makes it a lot more meaningful. Great to hear! Brett Cannon wrote (in the PEP): Renamed Exceptions Renamed exceptions will directly subclass the new names. When the old exceptions are instantiated (which occurs when an exception is caught, either by a try statement or by propagating to the top of the execution stack), a PendingDeprecationWarning will be raised. Nice trick with figuring out how to raise the deprecation warning :) (That line was going to read 'Why not just create an alias?', but then I worked out what you were doing, and why you were doing it) Thanks. One case that this doesn't completely address is NameError, as it is the only renamed exception which currently has a subclass. In this case, I think that during the transmition phase, all three of the 'Unbound*Error' exceptions should inherit from NameError, with NameError inheriting from NamespaceError. I believe it should still be possible to get the deprecation warning to work correctly in this case (by not raising the warning when a subclass is instantiated). Ah, didn't think about that issue. Yeah, as long as you don't call a superclass' __init__ it should still work. In the 'just a type' category, WeakReferenceError should still be under StandardError in the hierarchy. Yeah, that is an error from trying adding StandardError back in. -Brett ___ 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
Re: [Python-Dev] Exception Reorg PEP checked in
On 8/4/05, Guido van Rossum [EMAIL PROTECTED] wrote: This does contradict my earlier claim that Python itself doesn't use RuntimeError; I think I'd be happier if it remained RuntimeError. (I think there are a few more uses of it inside Python itself; I don't think it's worth inventing new exceptions for all these.) I just realized that keeping RuntimeError still does not resolve the issue that the name kind of sucks for realizing intrinsically that it is for quick-and-dirty exceptions (or am I the only one who thinks this?). Should we toss in a subclass called SimpleError? -Brett ___ 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
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/5/05, Raymond Hettinger [EMAIL PROTECTED] wrote: [ Guido] One more thing. Is renaming NameError to NamespaceError really worth it? I'd say that NameError is just as clear. +1 on NameError -- it's clear, easy to type, isn't a gratuitous change, and doesn't make you think twice about NamespaceError vs NameSpaceError. OK, I will remove the name change proposal. -Brett ___ 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
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/5/05, Raymond Hettinger [EMAIL PROTECTED] wrote: Also strong -1 on renaming RuntimeWarning to SemanticsWarning. Besides being another unnecessary change (trying to solve a non-existent problem), this isn't an improvement. The phrase RuntimeWarning is sufficiently generic to allow it to be used for a number of purposes. In costrast, SemanticsWarning is less flexible. Worse, it is not at all clear what a Semantics Warning would mean -- it suggests something much more ominous and complicated that it should. But the docs don't say that RuntimeWarning is meant as a generic warning but for dubious runtime behavior being changed. If it is truly meant to be generic (I think of UserWarning for that), then fine, I can let go of the name change. But it just took a friend of mine with no exposure to the warning system to understand what it meant. Another risk from gratuitous changes is the risk of unexpectedly introducing new problems. In this case, I find myself remembering the name as SemanticWarning instead of SemanticsWarning. These kind of changes suck -- they fail to take advantage of 15 years of field testing and risk introducing hard-to-change usability problems. OK, I can see the typos from that, but I still think RuntimeWarning and Error, for use as a generic exception, suck as names. Likewise, am a strong -1 on renaming RuntimeError to UserError. The latter name has some virtues but it is also misread as the User doing something wrong -- that is definitely not the intended meaning. While RuntimeError is a less than perfect name, it should not be changed unless we have both 1) demonstrated that real world problems have occurred with the current name and 2) that we have a clearly superior alternative name (a test which UserError fails). The only virtue to the name, UserError, is its symmetry with UserWarning. SimpleError? -0 on renaming ReferenceError to WeakReferenceError. The new name does better suggest the cause. OTOH, the context of the traceback would also make that perfectly clear. I'm not aware of a single user having had a problem with the current name. In general, we've avoided long names in favor of the short and pithy -- the theory was that the only a mnemonic is needed. Before adopting this one, there should be some discussion of 1) whether the current name is really that unclear, 2) whether shorter alternatives would serve (i.e. WeakrefError), and 3) whether the name suffers from capitalization ambiguity (WeakreferenceError vs WeakReferenceError). Will I didn't know what the exception was for until I read the docs. Granted this was just from looking at ``import exceptions; dir(exceptions)``, but why shouldn't the names be that obvious? And I don't see a capitalization ambiguity; if it was WeakrefError, sure. But not when the entire phrase is used. Summary: Most of the proposed name changes are unnecessary, the new names are not necessarily better, and there is a high risk of introducing new usability problems. I still think RuntimeError (and RuntimeWarning if that is what it is meant for) sucks as a name for a generic exception. I didn't know that was its use until I read the docs and Guido pointed out during the discussion of this thread. I am willing to compromise with a new exception that inherits RuntimeError named SimpleError (or the inheritance can be flipped). -Brett ___ 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
Re: [Python-Dev] PEP 348: Exception Reorganization for Python 3.0
On 8/5/05, Raymond Hettinger [EMAIL PROTECTED] wrote: When a user creates their own exception for exiting multiple levels of loops or frames, should they inherit from ControlFlowException on the theory that it no different in intent from StopIteration or should they inherit from UserError on the theory that it is a custom exception? I say ControlFlowException. UserError is meant for quick-and-dirty exception usage and not as a base for user error exceptions. If the name is confusing it can be changed to SimpleError. Gads. It sounds like you're just making this up on the fly. The process should be disciplined, grounded in use cases, and aimed at known, real problems with the current hierarchy. It is based on a real use case; my own. As I said in another email I just sent, I had no clue that RuntimeError was meant to be used as a generic exception until Guido pointed it out. -Brett ___ 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
Re: [Python-Dev] Exception Reorg PEP checked in
On 8/5/05, Guido van Rossum [EMAIL PROTECTED] wrote: On 8/5/05, Brett Cannon [EMAIL PROTECTED] wrote: On 8/4/05, Guido van Rossum [EMAIL PROTECTED] wrote: This does contradict my earlier claim that Python itself doesn't use RuntimeError; I think I'd be happier if it remained RuntimeError. (I think there are a few more uses of it inside Python itself; I don't think it's worth inventing new exceptions for all these.) I just realized that keeping RuntimeError still does not resolve the issue that the name kind of sucks for realizing intrinsically that it is for quick-and-dirty exceptions (or am I the only one who thinks this?). Should we toss in a subclass called SimpleError? I don't think so. People should feel free to use whatever pre-existing exception they like, even Exception. Fine, the idea is pulled. -Brett ___ 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
Re: [Python-Dev] Exception Reorg PEP checked in
On 8/5/05, Raymond Hettinger [EMAIL PROTECTED] wrote: On 8/4/05, James Y Knight [EMAIL PROTECTED] wrote: +-- NamespaceError (rename of NameError) +-- UnboundFreeError (new) +-- UnboundGlobalError (new) +-- UnboundLocalError What are these new exceptions for? Under what circumstances are they raised? Why is this necessary or an improvement? Exceptions relating to when a name is not found in a specific namespace (directly related to bytecode). So UnboundFreeError is raised when the interpreter cannot find a variable that is a free variable. UnboundLocalError already exists. UnboundGlobalError is to prevent NameError from being overloaded. UnboundFreeError is to prevent UnboundLocalError from being overloaded Do we have any use cases for making the distinctions. I have NEVER had a reason to write a different handler for the various types of NameError. Also, everyone knows what a Global is. Can the same be said for Free? I had thought that to be a implementation detail rather than part of the language spec. Perhaps then we should just ditch UnboundLocalError? If we just make sure we have good messages to go with the exceptions the reasons for the exception should be obvious. -Brett ___ 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
Re: [Python-Dev] PEP 8: exception style
On 8/6/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 8/6/05, A.M. Kuchling [EMAIL PROTECTED] wrote:
PEP 8 doesn't express any preference between the
two forms of raise statements:
raise ValueError, 'blah'
raise ValueError(blah)
I like the second form better, because if the exception arguments are
long or include string formatting, you don't need to use line
continuation characters because of the containing parens. Grepping
through the library code, the first form is in the majority, used
roughly 60% of the time.
Should PEP 8 take a position on this? If yes, which one?
Definitely ValueError('blah'). The other form will go away in Python
3000. Please update the PEP.
Done. rev. 1.18 .
-Brett
___
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
[Python-Dev] Major revision of PEP 348 committed
Version 1.5 of PEP 348 (http://www.python.org/peps/pep-0348.html) just got checked in. This one is a *big* change compared to the previous version: * Renamings removed * SystemExit are the KeyboardInterrupt are the only exceptions *not* inheriting from Exception + CriticalException has been renamed TerminalException so it is more inline with the idea that the exceptions are meant to terminate the interpreter, not that they are more critical than other exceptions * Removed ControlFlowException + StopIteration and GeneratorExit inherit from Exception directly * Added VMError which inherits Exception + SystemError and MemoryError subclass VMError * Removed UnboundG(Global|Free)Error * other stuff I don't remember This version addresses everyone's worries about backwards-compatibility or changes that were not substantive enough to break code. The things I did on my own without thorough discussion is remove ControlFlowException and introduce VMError. The former seemed reasonable since catching control flow exceptions as a group is probably rare and with StopIteration and GeneratorExit not falling outside of Exception, ControlFlowException lost its usefulness. VMError was introduced to allow the grouping of MemoryError and SystemError since they are both exceptions relating to the VM. The name can be changed to InterpreterError, but VMError is shorter while still getting the idea across. Plus I just like VMError more. =) OK, guys, have at it. -Brett ___ 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
Re: [Python-Dev] Major revision of PEP 348 committed
On 8/7/05, Raymond Hettinger [EMAIL PROTECTED] wrote: VMError -- This is a new intermediate grouping so it won't break anything and it does bring together two exceptions relating them by source. However, I recommend against introducing this new group. Besides added yet another thing to remember, it violates Flat-Is-Better-Than-Nested (see FIBTN below). Also, the new group is short on use cases with MemoryErrors sometimes being recoverable and SystemErrors generally not. In the library, only cookielib catches these and it does so along with KeyboardInterrupt in order to re-raise. In general, you don't want to introduce a new grouping unless there is some recurring need to catch that group. And Nick didn't like it either. Unless someone speaks up Monday, you can consider it removed. EOFError -- I recommend leaving this one alone. IOError is generally for real errors while EOF occurs in the normal course of reading a file or filelike source. The former is hard to recover and the latter is normal. The PEP's justification of Since an EOF comes from I/O it only makes sense that it be considered an I/O error is somewhat shallow and doesn't reflect thought about how those exceptions are actually used. That information is readily attainable by scanning the standard library with 57 instances of EOFError and 150 instances of IOError. There are a few cases of overlap where an except clause catches both; however, the two are mostly used independent from one another. The review of the library gives a good indication of how much code would be broken by this change. Also, see the FIBTN comment below. Basically you are arguing that EOFError is practically not an error and more of an exception signaling an event, like StopIteration for file reading. That makes sense, although it does suggest the name breaks the naming scheme Guido suggested. But I am not crazy enough to try to suggest a name change at this point. =) AnyDeprecationWarning -- This grouping makes some sense intuitively but do we have much real code that has had occasion to catch both at the same time? If not, then we don't need this. Well, PendingDeprecationWarning is barely used in Lib/ it seems. That would suggest the grouping isn't worth it just because the need to catch it will be miniscule. That also kills the argument that it would simplify warnings filters by cutting down on needing another registration since the chance of that happening seems to be microscopic. FIBTN (flat-is-better-than-nested) -- This bit of Zen carries extra significance for the exception hierarchy. The core issue is that exceptions are NOT inherently tree-structured. Each may ultimately carry its own set of meaningful attributes and those tend to not neatly roll-up into a parent/subclass relationships without Liskov violations. [SNIP] Vocabulary size -- At one time, python-dev exhibited a strong reluctance to introduce any new builtins. No matter how sensible the idea, there was typically an immediate effort to jam the proposed function into some other namespace. It should be remembered that each of PEP 348's proposed new exception groupings ARE new builtins. Therefore, the bar for admission should be relatively high (i.e. I would prefer Fredrik's join() proposal to any of the above new proposals). Every new word in the vocabulary makes the language a little more complex, a little less likely to fit in your brain, and a little harder to learn. Nestings make this more acute since learning the new word also entails remembering how it fits in the structure (yet another good reason for FIBTN). Now those are two arguments I can go with. OK, so your points make sense. I will wait until Monday evening after work to make any changes to give people a chance to argue against them, but VMError and AnyDeprecationWarning can be considered removed and EOFError will be moved to inherit from EnvironmentError again. Luckily you didn't say you hated TerminalException. =) -Brett ___ 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
Re: [Python-Dev] Major revision of PEP 348 committed
On 8/7/05, Nick Coghlan [EMAIL PROTECTED] wrote: Brett Cannon wrote: * SystemExit are the KeyboardInterrupt are the only exceptions *not* inheriting from Exception + CriticalException has been renamed TerminalException so it is more inline with the idea that the exceptions are meant to terminate the interpreter, not that they are more critical than other exceptions I like TerminalException, although TerminatingException may be less ambiguous. (There's nothing wrong with my terminal, you moronic machine!) Maybe. But the interpreter is not terminating quite yet; state is still fine since the exceptions have not reached the top of the stack if you caught it. But then terminal sounds destined to die, which is not true either since that only occurs if you catch the exceptions; terminating portrays that the plan is the termination but that it is not definite. OK, TerminatingException it is. This version addresses everyone's worries about backwards-compatibility or changes that were not substantive enough to break code. Well, I think you said from the start that the forces of backwards-compatibility would get you eventually ;) =) I should become a pundit for being able to tell what is going to happen. The things I did on my own without thorough discussion is remove ControlFlowException and introduce VMError. +1 on the former. -1 on the latter. Same reasons as Raymond, basically. These exceptions are builtins, so let's not add new ones without a strong use case. Anyway, this is starting to look pretty good (but then, I thought that a few days ago, too). Yeah, and so did everyone else basically. While Guido has his let's get all excited about a crazy idea, but then scale it back mentality, I guess I have the let's change everything for the better, but then realize other people actually use this language too. =) -Brett ___ 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
Re: [Python-Dev] PEP 347: Migration to Subversion
On 8/7/05, Martin v. Löwis [EMAIL PROTECTED] wrote: I have placed a new version of the PEP on http://www.python.org/peps/pep-0347.html Changes to the previous version include: - add more rationale for using svn (atomic changesets, fast tags and branches) - changed conversion procedure to a single repository, with some reorganization. See http://www.dcl.hpi.uni-potsdam.de/pysvn/ What is going in under python/ ? If it is what is currently /dist/src/, then great and the renaming of the repository works. But if that is what src/ is going to be used for, then what is python/ for and it would be nice to have a repository name that more directly reflects that it is the Python source tree. And I assume you are going to list the directory structure in the PEP at some point. -Brett ___ 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
Re: [Python-Dev] PEP 347: Migration to Subversion
On 8/7/05, Martin v. Löwis [EMAIL PROTECTED] wrote: Brett Cannon wrote: What is going in under python/ ? If it is what is currently /dist/src/, then great and the renaming of the repository works. Just have a look yourself :-) Yes, this is dist/src. Ah, OK. I didn't drill far enough down. Not enough experience with svn to realize that the directory was not just filled with default directories. But if that is what src/ is going to be used for This is nondist/src. Perhaps I should just move nondist/src/Compiler, and drop nondist/src. Wouldn't hurt. Since svn allows directory deletion there doesn't seem to be an huge need to worry about the projects/ directory getting to large. And I assume you are going to list the directory structure in the PEP at some point. Please take a look at the PEP. OK, now I see it. I scanned the PEP initially but I didn't see it; guess I was expecting a more literal directory list than a paragraph on it. -Brett ___ 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
Re: [Python-Dev] __traceback__ and reference cycles
On 8/8/05, Tim Peters [EMAIL PROTECTED] wrote: I can't think of a Python feature with a higher aggregate braincell_burned / benefit ratio than __del__ methods. If P3K retains them-- or maybe even before --we should consider taking the Java dodge on this one. That is, decree that henceforth a __del__ method will get invoked by magic at most once on any given object O, no matter how often O is resurrected. Wasn't there talk of getting rid of __del__ a little while ago and instead use weakrefs to functions to handle cleaning up? Is that still feasible? And if so, would this alleviate the problem? -Brett ___ 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
[Python-Dev] Exception Reorg PEP revised yet again
version 1.7 scales the proposal back once more (http://www.python.org/peps/pep-0348.html). At this point the only changes to the hierarchy are the addition of BaseException and TerminatingException, and the change of inheritnace for KeyboardInterrupt, SystemExit, and NotImplementedError. At this point I don't think MAL or Raymond will have any major complaints. =) Assuming no one throws a fit over this version, discussing transition is the next step. I think the transition plan is fine, but if anyone has any specific input that would be great. I could probably stand to do a more specific timeline in terms of 2.x, 2.x+1, 3.0-1, etc., but that will have to wait for another day this week. And once that is settled I guess it is either time for pronouncement or it just sits there until Python 3.0 actually starts to come upon us. -Brett ___ 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
Re: [Python-Dev] Exception Reorg PEP revised yet again
On 8/8/05, Raymond Hettinger [EMAIL PROTECTED] wrote: [Brett Cannon] At this point the only changes to the hierarchy are the addition of BaseException and TerminatingException, and the change of inheritnace for KeyboardInterrupt, SystemExit, and NotImplementedError. TerminatingException The rationale for adding TerminatingException needs to be developed or reconsidered. AFAICT, there hasn't been an exploration of existing code bases to determine that there is going to be even minimal use of except TerminatingException. Are KeyboardInterrupt and SystemExit often caught together on the same line and handled in the same way? The problem with existing code checking for this situation is that the situation itself is not the same as it will be if bare 'except's change:: try: ... except: ... except TerminatingException: ... has never really been possible before, but will be if the PEP goes forward. If so, isn't except TerminatingException less explicit, clear, and flexible than except (KeyboardInterrupt, SystemExit)? Do we need a second way to do it? But what if we add other exceptions that don't inherit from Exception that was want to typically propagate up? Having a catch-all for exceptions that a bare 'except' will skip that is more explicit than ``except BaseException`` seems reasonable to me. As Nick said in another email, it provides a more obvoius self-documentation point to catch TerminatingException than ``(KeyboardInterrupt, SystemExit)``, plus you get some future-proofing on top of it in case we add more exceptions that are not caught by a bare 'except'. Doesn't the new meaning of Exception already offer a better idiom: try: suite() except Exception: log_or_recover() except: handle_terminating_exceptions() else: Are there any benefits sufficient to warrant yet another new built-in? Does it also warrant violating FIBTN by introducing more structure? While I'm clear on why KeyboardInterrupt and SystemExit were moved from under Exception, it is not at all clear what problem is being solved by adding a new intermediate grouping. The PEP needs to address all of the above. Right now, it contains a definition rather than justification, research, and analysis. WindowsError This should be kept. Unlike module specific exceptions, this exception occurs in multiple places and diverse applications. It is appropriate to list as a builtin. Too O/S specific is not a reason for eliminating this. Looking at the codebase there does not appear to be a good substitute. Eliminating this one would break code, decrease clarity, and cause modules to grow competing variants. I unfortunately forgot to add that the exception would be moved under os, so it would be more of a renaming than a removal. The reason I pulled it was that Guido said UnixError and MacError didn't belong, so why should WindowsError stay? Obviously there are backwards-compatibility issues with removing it, but why should we have this platform-specific thing in the built-in namespace? Nothing else is platform-specific in the language until you go into the stdlib. The language itself is supposed to be platform-agnostic, and yet here is this exception that is not meant to be used by anyone but by a specific OS. Seems like a contradiction to me. After the change, nothing would be better and many things would be worse. NotImplementedError --- Moving this is fine. Removing unnecessary nesting is a step forward. The PEP should list that as a justification. Yay, something uncontraversial! =) Bare excepts defaulting to Exception After further thought, I'm not as sure about this one and whether it is workable. The code fragment above highlights the issue. In a series of except clauses, each line only matches what was not caught by a previous clause. This is a useful and basic part of the syntax. It leaves a bare except to have the role of a final catchall (much like a default in C's switch-case). If one line uses except Exception, then a subsequence bare except should probably catch KeyboardInterrupt and SystemExit. Otherwise, there is a risk of creating optical illusion errors (code that looks like it should work but is actually broken). I'm not certain on this one, but the PEP does need to fully explore the implications and think-out the consequent usability issues. This is Guido's thing. You will have to convince him of the change. I can flesh out the PEP to argue for which ever result he wants, but that part of the proposal is in there because Guido wanted it. I am just a PEP lackey in this case. =) And once that is settled I guess it is either time for pronouncement or it just sits there until Python 3.0 actually starts to come upon us. What happened to don't take this too seriously
Re: [Python-Dev] Exception Reorg PEP revised yet again
On 8/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote: WindowsError This should be kept. Unlike module specific exceptions, this exception occurs in multiple places and diverse applications. It is appropriate to list as a builtin. Too O/S specific is not a reason for eliminating this. Looking at the codebase there does not appear to be a good substitute. Eliminating this one would break code, decrease clarity, and cause modules to grow competing variants. [Brett] I unfortunately forgot to add that the exception would be moved under os, so it would be more of a renaming than a removal. Isn't OSError already used for another purpose (non-platform dependent exceptions raised by the os module)? Don't quite follow what that has to do with making WindowsError become os.WindowsError. Yes, OSError is meant for platform-agnostic OS errors by the os module, but how does that affect the proposed move of WindowsError? -Brett ___ 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
Re: [Python-Dev] Exception Reorg PEP revised yet again
On 8/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote: Then I don't follow what you mean by moved under os. In other words, to get the exception, do ``from os import WindowsError``. Unfortunately we don't have a generic win module to put it under. Maybe in the platform module instead? -1 on either. The WindowsError exception needs to in the main exception tree. It occurs in too many different modules and applications. That is a good reason for being in the main tree. Where is it used so much? In the stdlib, grepping for WindowsError recursively in Lib in 2.4 turns up only one module raising it (subprocess) and only two modules with a total of three places of catching it (ntpath once, urllib twice). In Module, there are no hits. If the name bugs you, I would support renaming it to PlatformError or somesuch. That would make it free for use with Mac errors and Linux errors. Also, it wouldn't tie a language feature to the name of an MS product. I can compromise to this if others prefer this alternative. Anybody else have an opinion? -Brett ___ 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
Re: [Python-Dev] Exception Reorg PEP revised yet again
On 8/10/05, Aahz [EMAIL PROTECTED] wrote: On Wed, Aug 10, 2005, Brett Cannon wrote: On 8/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote: If the name bugs you, I would support renaming it to PlatformError or somesuch. That would make it free for use with Mac errors and Linux errors. Also, it wouldn't tie a language feature to the name of an MS product. I can compromise to this if others prefer this alternative. Anybody else have an opinion? Googling for windowserror python produces 800 hits. So yes, it does seem to be widely used. I'm -0 on renaming; +1 on leaving things as-is. But Googling for attributeerror python turns up 94,700, a factor of over 118. OSError turns up 20,300 hits; a factor of 25. Even EnvironmentError turns up more at 5,610 and I would expect most people don't use this class directly that often. While 800 might seem large, it's puny compared to other exceptions. Plus, if you look at the first 10 hits, 4 are from PEP 348, one of which is the top hit. =) -Brett ___ 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
Re: [Python-Dev] Exception Reorg PEP revised yet again
On 8/11/05, James Y Knight [EMAIL PROTECTED] wrote: On Aug 11, 2005, at 2:41 PM, Josiah Carlson wrote: Remember, the Exception reorganization is for Python 3.0/3k/whatever, not for 2.5 . Huh, I could *swear* we were talking about fixing things for 2.5...but I see at least the current version of the PEP says it's talking about 3.0. If that's true, this is hardly worth discussing as 3.0 is never going to happen anyways. And why do you think it will never happen? Guido has already said publicly multiple times that the 2.x branch will not go past 2.9, so unless Python goes stale there will be a 3.0 release. Python 3.0 might not be around the corner, but will come eventually and this stuff needs to get done at some point. -Brett ___ 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
Re: [Python-Dev] Exception Reorg PEP revised yet again
On 8/12/05, Thomas Heller [EMAIL PROTECTED] wrote: Brett Cannon [EMAIL PROTECTED] writes: On 8/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote: Then I don't follow what you mean by moved under os. In other words, to get the exception, do ``from os import WindowsError``. Unfortunately we don't have a generic win module to put it under. Maybe in the platform module instead? -1 on either. The WindowsError exception needs to in the main exception tree. It occurs in too many different modules and applications. That is a good reason for being in the main tree. Where is it used so much? In the stdlib, grepping for WindowsError recursively in Lib in 2.4 turns up only one module raising it (subprocess) and only two modules with a total of three places of catching it (ntpath once, urllib twice). In Module, there are no hits. I don't know how you've been grepping, but the Python api functions to raise WindowsErrors are named like PyErr_SetFromWindowsErr() or so. Forgot to add that to the grep statement after I discovered that. Typically, WindowsErrors are raised when Win32 API functions fail. In the core extension modules, I find at least mmapmodule.c, posixmodule.c, _subprocess.c, and _winreg.c raising them. It may be a bit hidden, because the docs for _winreg mention only EnvironmentError, but they are wrong: C:\py Python 2.5a0 (#60, Jul 4 2005, 19:53:27) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import _winreg _winreg.OpenKey(_winreg.HKEY_CLASSES_ROOT, blah) Traceback (most recent call last): File stdin, line 1, in ? WindowsError: [Errno 2] Das System kann die angegebene Datei nicht finden If the name bugs you, I would support renaming it to PlatformError or somesuch. That would make it free for use with Mac errors and Linux errors. Also, it wouldn't tie a language feature to the name of an MS product. I can compromise to this if others prefer this alternative. Anybody else have an opinion? Win32 has the FormatError() api to convert error codes into descriptions - these descriptions are very useful, as are the error codes when you catch errors in client code. I would say as long as the Python core contains win32 specific modules like _winreg WindowsError should stay. For the name, I have no preference but I see no need to change it. OK, then it will just stay as-is. People can expect an updated PEP sometime this weekend. -Brett ___ 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
[Python-Dev] PEP 348 (exception reorg) revised again
I am sure people mainly care about the big changes inroduced by revision 1.8 of the PEP (http://www.python.org/peps/pep-0348.html). So, first is that WindowsError is staying. Enough people want it to stay and have a legitimate use that I removed the proposal to ditch it. Second, I changed the bare 'except' proposal again to recommend its removal. I had been feeling they should just go for about a week, but I solidified my thinking when I was talking with Alex and Anna Martelli and managed to convince them bare 'except's should go after Alex initially thought they should be changed to be ``except Exception``. This obviously goes against what Guido last said he wanted, but I hope I can convince him to get rid of bare 'except's. Minor stuff is fleshing out the arguments for TerminatingException (I am sure Raymond loves that I am leaving this part in =) and adding a Roadmap for the transition. -Brett ___ 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
Re: [Python-Dev] PEP 348 (exception reorg) revised again
OK, I will take this as BDFL pronouncement that ditching bare 'except's is just not going to happen. Had to try. =) And I will strip out the TerminatingException proposal. -Brett On 8/15/05, Guido van Rossum [EMAIL PROTECTED] wrote: I'm with Raymond here. On 8/15/05, Raymond Hettinger [EMAIL PROTECTED] wrote: [Brett] This obviously goes against what Guido last said he wanted, but I hope I can convince him to get rid of bare 'except's. -1 on eliminating bare excepts. This unnecessarily breaks tons of code without offering ANY compensating benefits. There are valid use cases for this construct. It is completely Pythonic to have bare keywords apply a useful default as an aid to readability and ease of coding. +1 on the new BaseException +1 on moving NotImplementedError, SystemExit, and KeyboardInterrupt. -1 on replacing except (KeyboardInterrupt, SystemExit) with except TerminatingException. 1) Grepping existing code bases shows that these two are almost never caught together so it is a bit silly to introduce a second way to do it. 2) Efforts to keep the builtin namespace compact argue against adding a new builtin that will almost never be used. 3) The change unnecessarily sacrifices flatness, making the language more difficult to learn. 4) The self-documenting rationale is weak -- if needed, a two-word comment would suffice. Existing code almost never has had to comment on catching multiple exceptions -- the exception tuple itself has been sufficiently obvious and explicit. This rationale assumes that code readers aren't smart enough to infer that SystemExit has something to do with termination. Raymond ___ 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/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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/brett%40python.org ___ 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
Re: [Python-Dev] PEP 348 (exception reorg) revised again
On 8/15/05, Toby Dickenson [EMAIL PROTECTED] wrote: On Monday 15 August 2005 14:16, Raymond Hettinger wrote: -1 on replacing except (KeyboardInterrupt, SystemExit) with except TerminatingException. The rationale for including TerminatingException in the PEP would also be satisfied by having a TerminatingExceptions tuple (in the exceptions module?). It makes sense to express the classification of exceptions that are intended to terminate the interpreter, but we dont need to express that classification as inheritence. While the idea is fine, I just know that the point is going to be brought up that the addition should not be done until experience with the new hierarchy is had. I will add a comment that tuples can be added to the module after enough experience is had, but I am not going to try pushing for this right now. Of course I could be surprised and everyone could support the idea. =) -Brett ___ 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
[Python-Dev] rev. 1.9 of PEP 348: Raymond tested, Guido approved
OK, TerminatingException and the removal of bare 'except' clauses are now out. I also stripped out the transition plan to basically just add BaseException in Python 2.5, tweak docs to recommend future-proof practices, and then change everything in Python 3.0 . This will prevent any nasty performance hit from what was being previously suggested to try to make it all backwards-compatible. -Brett ___ 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
Re: [Python-Dev] PEP 309: Partial method application
On 8/18/05, Guido van Rossum [EMAIL PROTECTED] wrote: On 8/18/05, Martin v. Löwis [EMAIL PROTECTED] wrote: As for the more general proposal: -1 on more places to pass strings to denote method/function/class names. These are ugly to type. Agreed. What I think you want is not a partial method, instead, you want to turn a method into a standard function, and in a 'virtual' way. So I would propose the syntax lst.sort(key=virtual.lower) # where virtual is functional.virtual I like this, but would hope for a different name -- the poor word 'virtual' has been abused enough by C++. Yeah, me too. Possible name are 'delayed', 'lazyattr', or just plain 'lazy' since it reminds me of Haskell. P.S. It's not even clear that this should be added to functional, as attrgetter and itemgetter are already in operator. But, perhaps, they should be in functional. They feel related to attrgetter more than to partial. True, but the idea of lazy evaluation, at least for me, reminds me more of functional languages and thus the functional module. Oh, when should we think of putting reduce into functional? I remember this was discussed when it was realized reduce was the only functional built-in that is not covered by itertools or listcomps. -Brett ___ 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
Re: [Python-Dev] PEP 309: Partial method application
On 8/18/05, Nick Coghlan [EMAIL PROTECTED] wrote: Brett Cannon wrote: Oh, when should we think of putting reduce into functional? I remember this was discussed when it was realized reduce was the only functional built-in that is not covered by itertools or listcomps. I expected functional.map, functional.filter and functional.reduce to all exist in 2.5. Itertools covers map, filter is covered by genexps. 'reduce' is the only one that does not have an equivalent anywhere. I guess we could cross-link itertools.map into functional.map, but I would rather just mention in the docs of one that it is located in the other module. And filter is just not worth it; that can definitely be covered in the docs of the module. -Brett ___ 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
Re: [Python-Dev] Bare except clauses in PEP 348
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, there is nothing you can change except: to in order not to get a deprecation warning and still have your code be correct in the face of documented features of python. I agree; isn't that already in ther PEP? This surely has been the thinking all along. Requiring inheritance of BaseException in order to pass it to 'raise' has been in the PEP since the beginning. -Brett ___ 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
Re: [Python-Dev] Remove str.find in 3.0?
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 to the PEP as well. -Brett ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/5/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Mon, 2005-09-05 at 20:52, Guido van Rossum wrote:
We could decide not to provide (b) directly, since it is easily
reduced to (c) using an appropriate format string (%s times the
number of arguments). But I expect that use case (b) is pretty
important, and not everyone likes having to use format strings. This
could be reduced to a special case of the Swiss Army Knife (...Not)
rule.
I'm not sure. I do agree with your design principles (though I might
call it Sometime's a Spoon's Just a Spoon ;) but thinking about my own
uses of print, I think we could easily get away with just (a) and (c).
I think someone else felt the same way in an earlier response to my
strawman, pointing out that the inline Separator instances wasn't really
any more usable than just degenerating to the format string version.
There's no doubt that the format string approach gives you direct
control over every character.
Eliminating the newline argument from print() would reduce the number of
reserved keyword arguments in my strawman by half. Maybe we could even
rename 'to' to '__to__' (!) to eliminate the other namespace wart. Is
this really too horrible:
print('$user forgot to frobnicate the $file!\n',
user=username, file=file.name, __to__=sys.stderr)
If I something stupid, I apologize; I have been swamped with
orientation stuff while this entire discussion has been going on and
so I am sure I have missed some of the finer details.
I like the way the above works, but ``print(username, forgot to
frobicate the, file.name)`` just seems nicer for simple output. I do
agree that there is a need for simple and formatted versions of print
and that controlled output of numbers is important. And I also like
the $ formatting so I wished there was a way to take what Barry did
above but be able to do formatting, like ``${num:0.6f}`` or something
and have that be the formatting version and just have the default be a
call on str() for the substitution.
BTW we could use from __future__ import printing to disable the
recognition of 'print' as a keyword in a particular module -- this
would provide adequate future-proofing.
+1
+1 from me as well.
-Brett
___
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
Re: [Python-Dev] Tools directory (Was RE: Replacement for print in Python 3.0)
On 9/8/05, Tony Meyer [EMAIL PROTECTED] wrote: [finding Tools/i18n/pygettext.py] You're right, I think Tools is probably a bad place for anything. If it's not part of the stdlib, I'll likely never find it. Agreed. Maybe with the introduction of -m in Python 2.4, some of the Tools/ scripts could be put in __main__ sections of appropriate modules? So that python -m gettext would be equivilant to python Tools/i18n/pygettext.py? (However, pyggettext.py is 22KB, which is a big addition to the module; not everything in Tools/Scripts might be used enough for this, or have an appopriate module to be put in either). Are there other ideas about how Tools/ could be improved? Either moving things, or making it more likely that people will look there for scripts? I assume that the Windows installer includes the Tools/ directory. If it doesn't that is one problem. =) Otherwise it is mostly a lack of advertisement and them not being installed by ``make install``. If you just download the soure and install you will never know the directory even exists. It needs to be made obvious to people that it is even there. Probably the only way is to document the directory. -Brett ___ 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
Re: [Python-Dev] python optimization
On 9/15/05, Neal Becker [EMAIL PROTECTED] wrote: I use cpython. I'm accustomed (from c++/gcc) to a style of coding that is highly readable, making the assumption that the compiler will do good things to optimize the code despite the style in which it's written. For example, I assume constants are removed from loops. In general, an entity is defined as close to the point of usage as possible. I don't know to what extent these kind of optimizations are available to cpython. For example, are constant calculations removed from loops? If you mean ``2+3``, then yes. If you mean ``2 + a`` where is a loop invariant, then no. How about functions? No optimization there. Is there a significant cost to putting a function def inside a loop rather than outside? If you put it in a loop then the function must be reconstructed every time through the loop. I have never benchmarked the cost of function construction but I doubt it's cheap. The problem with all of these optimizations that you can do in more static languages is you get to assume most things do not change from underneath you. In Python, thanks to threading, access to frames, global namespaces of modules, etc., most things cannot be naively optimized without a lot of checking up front to make sure the optimization is valid every time it is run. If you want some gruesome detail, you can read my thesis (http://www.drifty.org/thesis.pdf) and the section on problems with introducing type inference into Python. -Brett ___ 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
[Python-Dev] removing nested tuple function parameters
Is anyone truly attached to nested tuple function parameters; ``def fxn((a,b)): print a,b``? At one of the PyCon sprints Guido seemed okay with just having them removed when Jeremy asked about ditching them thanks to the pain they caused in the AST branch. I personally don't see them being overly useful thanks to assignment unpacking. Plus I don't think they are used very much (gut feeling, though, and not based on any grepping). Would anyone really throw a huge fit if they went away? I am willing to write a PEP for their removal in 2.6 with a deprecation in 2.5 if people are up for it. Otherwise I say they should definitely go in Python 3. -Brett ___ 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
Re: [Python-Dev] test__locale on Mac OS X
[forgot to CC python-dev] On 9/18/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: test__locale still fails for me on Mac OS X 10.3.9. This is on both the 2.4 branch and HEAD. Does it succeed for anyone on 10.4? If not, perhaps we should list that as an expected failure on that platform? It passes on 10.4 for me. -Brett ___ 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
Re: [Python-Dev] removing nested tuple function parameters
On 9/18/05, Greg Ewing [EMAIL PROTECTED] wrote: François Pinard wrote: The only practical reason to like this feature is sparing the need of finding an otherwise useless name for the formal argument. If the argument represents a coherent enough concept to be passed in as a tuple in the first place, it should be possible to find a meaningful name for it. Otherwise the elements should probably be passed in as separate arguments. Yet, if I was given the choice between nested tuple function arguments, and faster argument processing, the latter would win instantly. I believe that exactly the same bytecode results either way, so there's no speed advantage or penalty. Yep, the bytecode will be the same sans the compiler-created name for the tuple . -Brett ___ 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
Re: [Python-Dev] and and or operators in Py3.0
On 9/19/05, Barry Warsaw [EMAIL PROTECTED] wrote: On Mon, 2005-09-19 at 20:03, Guido van Rossum wrote: While you're at it, maybe we should switch to and || as well? That's another thing I always mistype when switching between languages... Please no! 'and' and 'or' is so readably beautiful. I completely agree. Also, this proposal needs to be considered together with the addition of a proper conditional operator, like x?y:z. Definitely. Yep. -Brett ___ 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
Re: [Python-Dev] and and or operators in Py3.0
On 9/20/05, Michael Hudson [EMAIL PROTECTED] wrote: [SNIP] I _like_ the explanation of 'and' and 'or' as they are now. They are basically control flow constructs -- and have to be to get short-circuiting to work -- and adding a coercion to bool at the end seems to add complexity, not reduce it (on some levels, anyway). If you change the definition of 'and' and 'or' to be boolean comparison operators (as Raymond is proposing) and not as control flow constructs then is it really that complicated? I think it would actually simplify things very slightly since you just say a boolean is returned instead of the last executed expression by the operator. P.S. Simplifying and and or may create a need to introduce a conditional operator but that is a discussion for another day. ... which was in the past, I thought. It was, but changing 'and' and 'or' does tweak the usefulness of a conditional operator. -Brett ___ 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
Re: [Python-Dev] Adding a conditional expression in Py3.0
On 9/20/05, Phillip J. Eby [EMAIL PROTECTED] wrote: At 12:17 PM 9/20/2005 -0700, Guido van Rossum wrote: I think I'd prefer (if expr then expr else expre) i.e. no colons. None of the other expression forms (list comprehensions and generator expressions) involving statement keywords use colons. +1, despite the fact that we seem on a slippery slope towards becoming a kind of infix Lisp. ;) Between (yield x), (x for x in y), and now (if x then y else z), it seems that parentheses are all the rage now. Will we get (try expr finally expr) next? 0.5 wink +1 from me as well. The use will be much more obvious to a newbie than ``expr ? expr : expr``. And I have used the syntactic-heavy listcomps in Haskell and I must say that Python's version is much nicer. I like the wordy version. =) *If* you want general community input, I would suggest a runoff ballot with those four choices (and a summary of pros and cons of each), or fewer if you see any as unacceptible. If there's one thing I've learned from the PEP 308 vote, it is that votes for language don't work. I prefer some discussion on Python-dev after which I pick one. Also +1. :) +1 from me, although I sure got lambasted by some people when I said I liked this style during the whole decorator debate. =) -Brett ___ 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
Re: [Python-Dev] GIL, Python 3, and MP vs. UP
On 9/20/05, John J Lee [EMAIL PROTECTED] wrote: On Mon, 19 Sep 2005, Florian Weimer wrote: The real problem is that you can ditch most extension modules. 8-( [...] *Is* that a showstopper for Python 3.0, though? Who knows. I bet Guido doesn't even know how much breakage he is going to want to push. Some people have rather strongly pointed out (usually after I have proposed something), breaking stuff without a good reason is not worth the added level of breakage for when people try to update code to Python 3.0. Completely changing how garbage collection works is not exactly a minor thing and there is the possibility it won't pan out. It would really suck for everyone to have to learn an entirely new way of handling garbage collection and have there not be a perk for doing so, especially since this kind of change will not be directly visible to the language itself. -Brett ___ 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
Re: [Python-Dev] and and or operators in Py3.0
On 9/21/05, Michael Hudson [EMAIL PROTECTED] wrote: Brett Cannon [EMAIL PROTECTED] writes: On 9/20/05, Michael Hudson [EMAIL PROTECTED] wrote: [SNIP] I _like_ the explanation of 'and' and 'or' as they are now. They are basically control flow constructs -- and have to be to get short-circuiting to work -- and adding a coercion to bool at the end seems to add complexity, not reduce it (on some levels, anyway). If you change the definition of 'and' and 'or' to be boolean comparison operators (as Raymond is proposing) and not as control flow constructs then is it really that complicated? If you eliminate the short circuiting behaviour of 'or' and 'and' the mobs will be after you with torches and pitchforks (and I'll be with them). I am not suggesting that at all. I would put myself on a pike first before the mob got there. =) I think it would actually simplify things very slightly since you just say a boolean is returned instead of the last executed expression by the operator. You might as well have 'and' be a builtin, then -- or do I misread you? I think you might be misreading me, but since Guido seems to have made the decision that 'and' and 'or' are not changing there is no need to try to clarify. P.S. Simplifying and and or may create a need to introduce a conditional operator but that is a discussion for another day. ... which was in the past, I thought. It was, but changing 'and' and 'or' does tweak the usefulness of a conditional operator. Another reason why it's a bad idea :) wink =) -Brett ___ 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
Re: [Python-Dev] Conditional Expression Resolution
On 9/29/05, Guido van Rossum [EMAIL PROTECTED] wrote: [SNIP] Flames, pleas to reconsider, etc., to /dev/null. Congratulations gracefully accepted. And gladly given! All proposals should be resolved this cleanly in the end. It's still my language! :-) Yes it is, thank goodness! -Brett ___ 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
Re: [Python-Dev] Python 2.5 and ast-branch
To answer Nick's email here, I didn't respond to that initial email because it seemed specifically directed at Guido and not me. On 10/5/05, Guido van Rossum [EMAIL PROTECTED] wrote: On 10/5/05, Nick Coghlan [EMAIL PROTECTED] wrote: Anyway, the question is: What do we want to do with ast-branch? Finish bringing it up to Python 2.4 equivalence, make it the HEAD, and only then implement the approved PEP's (308, 342, 343) that affect the compiler? Or implement the approved PEP's on the HEAD, and move the goalposts for ast-branch to include those features as well? I believe the latter is the safe option in terms of making sure 2.5 is a solid release, but doing it that way suggests to me that the ast compiler would need to be held over until 2.6, which would be somewhat unfortunate. Given that I don't particularly like that answer, I'd love for someone to convince me I'm wrong ;) Given the total lack of response, I have a different suggestion. Let's *abandon* the AST-branch. We're fooling ourselves believing that we can ever switch to that branch, no matter how theoretically better it is. Since the original people who have done the majority of the work (Jeremy, Tim, Neal, Nick, logistix, and myself) have fallen so far behind this probably is not a bad decision. Obviously I would like to see the work pan out, but since I personally just have not found the time to shuttle the branch the rest of the way I really am in no position to say much in terms of objecting to its demise. Maybe I can come up with a new design and get my dissertation out of it. =) -Brett ___ 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
Re: [Python-Dev] Python 2.5 and ast-branch
On 10/6/05, Guido van Rossum [EMAIL PROTECTED] wrote: [Kurt] Unless I'm missing something, we would need to merge HEAD to the AST branch once more to pick up the changes in MAIN since the last merge, and then make sure everything in the AST branch is passing the test suite. Otherwise we risk having MAIN broken for awhile following a merge. [Raymond] IMO, merging to the head is a somewhat dangerous strategy that doesn't have any benefits. Whether done on the head or in the branch, the same amount of work needs to be done. If the stability of the head is disrupted, it may impede other maintenance efforts because it is harder to test bug fixes when the test suites are not passing. Well, at some point it will HAVE to be merged into the head. The longer we wait the more painful it will be. If we suffer a week of instability now, I think that's acceptable, as long as all developers are suitably alerted, and as long as the AST team works towards resolving the issues ASAP. I happen to agree with Kurt that we should first merge the head into the branch; then the AST team can work on making sure the entire test suite passes; then they can merge back into the head. BUT this should only be done with a serious commitment from the AST team (I think Neil and Jeremy are offering this -- I just don't know how much time they will have available, realistically). My main point is, we should EITHER abandon the AST branch, OR force a quick resolution. I'm willing to suffer a week of instability in head now, or in a week or two -- but I'm not willing to wait again. Let's draw a line in the sand. The AST team (which includes whoever will help) has up to three weeks to het the AST branch into a position where it passes all the current unit tests merged in from the head. Then they merge it into the head after which we can accept at most a week of instability in the head. After that the AST team must remain available to resolve remaining issues quickly. So basically we have until November 1 to get all tests passing? For anyone who wants a snapshot of where things stand, http://www.python.org/sf/1191458 lists the tests that are currently failing (read the comments to get the current list; count is at 14). All AST-related tracker items are under the AST group so filtering to just AST stuff is easy. I am willing to guess a couple of those tests will start passing as soon as http://www.python.org/sf/1246473 is dealt with (this is just based on looking at some of the failure output seeming to be off by one). As of right now the lnotab is only has statement granularity when it really needs expression granularity. That requires tweaking all instances where an expression node is created to also take in the line number of where the expression exists. This fix is one of the main reasons I have not touched the AST branch; it is not difficult, but it is not exactly fun or small either. =) How does this sound to the non-AST-branch developers who have to suffer the inevitable post-merge instability? I think it's now or never -- waiting longer isn't going to make this thing easier (not with several more language changes approved: with-statement, extended import, what else...) What does the AST team think? Well, I have homework this weekend, a midterm two weeks from tomorrow (so the preceding weekend will be studying), and October 23 is my birthday so I will be busy that entire weekend visiting family. In other words Python time is a premium this month. But I will try to squeeze in what time I can. But I think the three week time frame is reasonable to light the fire under our asses to get this thing done (especially if it inspires people to jump in and help out; as always, people interested in joining in, check out the branch and read Python/compile.txt ). -Brett ___ 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
Re: [Python-Dev] PEP 3000 and exec
On 10/10/05, Christos Georgiou [EMAIL PROTECTED] wrote: This might be minor-- but I didn't see anyone mentioning it so far. If `exec` functionality is to be provided, then I think it still should be a keyword for the parser to know; currently bytecode generation is affected if `exec` is present. Even if that changes for Python 3k (we don't know yet), the paragraph for exec should be annotated with a note about this issue. But the PEP says that 'exec' will become a function and thus no longer become a built-in, so changing the grammar is not needed. -Brett ___ 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
Re: [Python-Dev] Fwd: defaultproperty
On 10/10/05, Barry Warsaw [EMAIL PROTECTED] wrote: On Mon, 2005-10-10 at 01:47, Calvin Spealman wrote: Never created for a reason? lumping things together for having the similar usage semantics, but unrelated purposes, might be something to avoid and maybe that's why it hasn't happened yet for decorators. If ever there was a makethreadsafe decorator, it should go in the thread module, etc. I mean, come on, its like making a module just to store a bunch of unrelated types just to lump them together because they're types. Who wants that? Like itertools? +1 for a decorators module. +1 from me as well. And placing defaultproperty in there makes sense if it is meant to be used as a decorator and not viewed as some spiffy descriptor. Should probably work in Michael's update_meta() function as well (albeit maybe with a different name since I think I remember Guido saying he didn't like the name). -Brett ___ 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
Re: [Python-Dev] PEP 3000 and exec
On 10/10/05, Greg Ewing [EMAIL PROTECTED] wrote: Brett Cannon wrote: But the better answer is we will just find a way. =) I think the best answer would be just to dump the idea of exec-in-local-namespace altogether. I don't think I've ever seen a use case for it that wasn't better done some other way. I agree that 'exec' could really stand to be tweaked. As it stands now it is nasty to deal with when it comes to program analysis. Anything that will make that easier gets my vote. -Brett ___ 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
Re: [Python-Dev] Migrating to subversion
On 10/18/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Martin If people want to test the installation before the switch Martin happens, this would be the time to do it. Martin, Can you let us know again the magic incantation to check out the source from the repository? And any other problems people come across or questions they have about Subversion and its use, please do ask. I will try to start a new section in the dev FAQ for svn-specific issues. -Brett ___ 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
Re: [Python-Dev] Conversion to Subversion is complete
On 10/27/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [SNIP] Most of you are probably interested in checking out one of these folders: svn+ssh://[EMAIL PROTECTED]/python/trunk svn+ssh://[EMAIL PROTECTED]/python/branches/release24-maint svn+ssh://[EMAIL PROTECTED]/peps Why the entire 'peps' directory and not just the trunk like with 'python'? It looks like no tags or branches have ever been created for the PEPs and thus are not really needed. I am also curious as to what you would have me check out for the sandbox; whole directory or just the trunk? -Brett ___ 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
Re: [Python-Dev] Conversion to Subversion is complete
I have started a svn section in the dev FAQ (http://www.python.org/dev/devfaq.html) pertaining to checking out a project from the repository and other stuff discussed so far. If something is not clear or people feel a step is missing, let me know. I will remove the CVS section once Martin has tossed the CVS repository on SF. -Brett On 10/27/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The Python source code repository is now converted to subversion; please feel free to start checking out new sandboxes. For a few days, this installation probably still needs to be considered in testing. If there are no serious problems found by next Monday, I would consider conversion of the data complete. The CVS repository will be kept available read-only for a while longer, so you can easily forward any patches you may have. Most of you are probably interested in checking out one of these folders: svn+ssh://[EMAIL PROTECTED]/python/trunk svn+ssh://[EMAIL PROTECTED]/python/branches/release24-maint svn+ssh://[EMAIL PROTECTED]/peps The anonymous read-only equivalents of these are http://svn.python.org/projects/python/trunk http://svn.python.org/projects/python/branches/release24-maint http://svn.python.org/projects/peps As mentioned before, in addition to plain http/WebDAV, viewcvs is available at http://svn.python.org/view/ There are some more things left to be done, such as updating the developer documentation. I'll start working on that soon, but contributions are welcome. Regards, Martin ___ 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/brett%40python.org ___ 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
Re: [Python-Dev] Conversion to Subversion is complete
On 10/27/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Brett I have started a svn section in the dev FAQ Brett (http://www.python.org/dev/devfaq.html) pertaining to checking Brett out a project from the repository and other stuff discussed so Brett far. If something is not clear or people feel a step is missing, Brett let me know. We're starting to look at how much information we can push over to the Wiki. Any pages where multiple people might contribute, especially if they are not the typical website maintainers, seems to me like good Wiki candidates to me. That goes double for anything FAQ-ish. I guess, but I just don't like wikis personally so I have no inclination to make the conversion. If someone wants to make the conversion over to the wiki and keep it up that's fine, but I have no problem keeping the dev FAQ updated like I have for CVS in the past. -Brett ___ 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
[Python-Dev] PEP 352: Required Superclass for Exceptions
Well, I am at it again, but this time Guido is a co-conspirator. We wrote a PEP that introduces BaseException and moves KeyboardInterrupt and SystemExit. Even if you followed the discussion for PEP 348 you should read the PEP since I am sure there will be something that someone doesn't like, such as the transition plan or how I didn't use British English throughout. =) Anyway, as soon as the cron job posts the PEP to the web site (already checked into the new svn repository) have a read and start expounding about how wonderful it is and that there is no qualms with it whatsoever. =) -Brett ___ 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
Re: [Python-Dev] Conversion to Subversion is complete
On 10/27/05, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote: On Thursday 27 October 2005 23:03, Brett Cannon wrote: I guess, but I just don't like wikis personally so I have no inclination to make the conversion. If someone wants to make the conversion over to the wiki and keep it up that's fine, but I have no problem keeping the dev FAQ updated like I have for CVS in the past. And I'm sure we all appreciate your efforts! I certainly do. Regarding using the wiki... I have mixed feelings. Wikis are really, really good for some things. Anything that's how-to based on technology (how to use SVN, CVS, etc.) seems like a reasonable candidate, because we get the advantages of peer review. For things that describe policy, I don't think that's so great. For policy (how to use SVN for Python development, because we have certain rules), I think we want to maintain strict editorial control. I like that explanation more than mine. =) So I am just going to keep the FAQ up then. If there is anything at http://www.python.org/dev/svn.html people feel should be moved over to the FAQ that has not occurred yet, let me know. Please have personal experience, though, with what you want added so as to make sure the information is relevant (e.g., Tim suffering through getting an SSH 2 key for Windows and what is exactly needed, complete with screenshots =) . -Brett ___ 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
Re: [Python-Dev] PEP 352: Required Superclass for Exceptions
On 10/28/05, Guido van Rossum [EMAIL PROTECTED] wrote: On 10/28/05, Nick Coghlan [EMAIL PROTECTED] wrote: Brett Cannon wrote: Anyway, as soon as the cron job posts the PEP to the web site (already checked into the new svn repository) have a read and start expounding about how wonderful it is and that there is no qualms with it whatsoever. =) You mean aside from the implementation of __getitem__ being broken in BaseException*? ;) Are you clairvoyant?! The cronjob wass broken due to the SVN transition and the file wasn't on the site yet. (Now fixed BTW.) Oh, and here's the URL just in case: http://www.python.org/peps/pep-0352.html Nick got the python-checkins email and then read the PEP from the repository (or at least that is what I assume since that is how Neal managed to catch the PEP literally in under 5 minutes after checkin). Aside from that, I actually do have one real problem and one observation. The problem: The value of ex.args The PEP as written significantly changes the semantics of ex.args - instead of being an empty tuple when no arguments are provided, it is instead a singleton tuple containing the empty string. A backwards compatible definition of BaseException.__init__ would be: def __init__(self, *args): self.args = args self.message = '' if not args else args[0] But does anyone care? As long as args exists and is a tuple, does it matter that it doesn't match the argument list when the latter was empty? IMO the protocol mostly says that ex.args exists and is a tuple -- the values in there can't be relied upon in pre-2.5-Python. Exceptions that have specific information should store it in a different place, not in ex.args. Looking at http://docs.python.org/lib/module-exceptions.html , it looks like Guido is right. All it ever says is that it is a tuple and that any passed-in arguments go into 'args'; nothing about its default value if no arguments are passed in. But I personally have no qualms changing it if people want it, so -0 from me on making it more backwards-compatible. The observation: The value of ex.message Under PEP 352 the concept of allowing return x to be used in a generator to mean raise StopIteration(x) would actually align quite well. A bare return, however, would need to be changed to translate to raise StopIteration(None) rather than its current raise StopIteration in order to get the correct value (None) into ex.message. Since ex.message is new, how can you say that it should have the value None? IMO the whole idea is that ex.message should always be a string going forward (although I'm not going to add a typecheck to enforce this). My feeling exactly on 'message'. -Brett ___ 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
Re: [Python-Dev] PEP 352 Transition Plan
On 10/28/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
Why would a
release allow catching something that cannot be raised? I must be
missing something here.
So conforming code can catch exceptions raised by not-yet conforming
code.
That makes sense.
What was the rationale for pushing the deprecation of __getitem__ and
args back to Py2.8? Is the there a disadvantage for doing it earlier?
On the flip side, is there any reason it has to be done at all prior to
Py3.0? That change seems orthogonal to the rest of the proposal and has
its own pluses and minuses (simplification on the plus-side and
code-breakage on the minus-side).
I thought that there was no exact rush on their removal. And I
suspect the later versions of the 2.x branch will be used to help ease
transition to Python 3, so I figured pushing it to 2.8 seemed like a
good idea. I could even push it all the way to 2.9 if people prefer.
FWIW, the args tuple does have a legitimate use case as one solution to
the problem of exception chaining (keeping the old info intact, but
adding new info as an extra field):
try:
raise TypeError('inner detail')
except TypeError, e:
args = e.args + ('outer context',)
raise TypeError(*args)
Interesting point, but I think that chaining should have more concrete
support ala PEP 344 or some other mechanism. I think most people
agree that exception chaining is important enough to have better
support than some implied way of a causing exception to be passed
along. Perhaps something more along the lines of:
try:
raise TypeError(inner detail)
except TypeError, e:
raise TypeError(outer detail, cause=e)
where BaseException then has a 'cause' attribute that is set to None
by default or some specific object that is passed in as the second
argument to the constructor.
-Brett
___
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
Re: [Python-Dev] PEP 352: Required Superclass for Exceptions
On 10/28/05, Nick Coghlan [EMAIL PROTECTED] wrote: Brett Cannon wrote: On 10/28/05, Guido van Rossum [EMAIL PROTECTED] wrote: Nick got the python-checkins email and then read the PEP from the repository (or at least that is what I assume since that is how Neal managed to catch the PEP literally in under 5 minutes after checkin). Actually, when you first check a PEP in, the diff includes the entire text of the PEP - so I just read the python-checkins email :) But does anyone care? As long as args exists and is a tuple, does it matter that it doesn't match the argument list when the latter was empty? IMO the protocol mostly says that ex.args exists and is a tuple -- the values in there can't be relied upon in pre-2.5-Python. Exceptions that have specific information should store it in a different place, not in ex.args. Looking at http://docs.python.org/lib/module-exceptions.html , it looks like Guido is right. All it ever says is that it is a tuple and that any passed-in arguments go into 'args'; nothing about its default value if no arguments are passed in. But I personally have no qualms changing it if people want it, so -0 from me on making it more backwards-compatible. I agree changing the behaviour is highly unlikely to cause any serious problems (mainly because anyone *caring* about the contents of args is rare), the current behaviour is relatively undocumented, and the PEP now proposes deprecating ex.args immediately, so Guido's well within his rights if he wants to change the behaviour. I was merely commenting from the 'its an unnecessary change to existing behaviour' angle, since the backwards compatible version gives the same behaviour of the new ex.message API as the version in the PEP, while leaving the now-deprecated ex.args API behaviour identical to that in Python 2.4. In other words, I'm looking for a *benefit* that comes from the behavioural change, rather than a 'but the current behaviour is undocumented anyway' response. If there's no actual benefit in breaking it, then why break it? :) The benefit for me was that the code kept the 'message' argument and thus, in my mind, made it much more obvious that 'mesage' and 'args' are different. But I think I have a much more reasonable solution that lets me keep the 'message' argument explicit. It also let me use the conditional operator to simplify the code more. So I went ahead and made it the more backwards-compatible. The observation: The value of ex.message Under PEP 352 the concept of allowing return x to be used in a generator to mean raise StopIteration(x) would actually align quite well. A bare return, however, would need to be changed to translate to raise StopIteration(None) rather than its current raise StopIteration in order to get the correct value (None) into ex.message. Since ex.message is new, how can you say that it should have the value None? IMO the whole idea is that ex.message should always be a string going forward (although I'm not going to add a typecheck to enforce this). My feeling exactly on 'message'. I'm talking about the specific context of the behaviour of 'return' in generators, not on the behaviour of ex.message in general. For normal exceptions, I agree '' is the correct default. For that specific case of allowing a return value from generators, and using it as the message on the raised StopIteration, *then* it makes sense for return to translate to raise StopIteration(None), so that generators have the same 'default return value' as normal functions. There's a reason I said it was just an observation - it has no effect on PEP 352 itself, only on a *different* syntax extension that hasn't even been officially suggested in a PEP (only mentioned in passing when discussing PEP 342). Ah, OK. So you just want to make sure that at the generator level that the bytecode (or the ceval loop, not sure where the change would need to be made) that the StopIteration be raised with an explicit 'message' argument of None. Which obviously does not directly affect PEP 352, but should be considered as a possible change. That makes sense to me and I have no trouble with that, but that is partially because I don't have to make that change. =) -Brett ___ 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
Re: [Python-Dev] PEP 352: Required Superclass for Exceptions
On 10/28/05, Guido van Rossum [EMAIL PROTECTED] wrote: [Trying to cut this short... We have too many threads for this topic. :-( ] On 10/28/05, Nick Coghlan [EMAIL PROTECTED] wrote: [on making args b/w compatible] I agree changing the behaviour is highly unlikely to cause any serious problems (mainly because anyone *caring* about the contents of args is rare), the current behaviour is relatively undocumented, and the PEP now proposes deprecating ex.args immediately, so Guido's well within his rights if he wants to change the behaviour. I take it back. Since the feature will disappear in Python 3.0 and is maintained only for b/w compatibility, we should keep it as b/w compatible as possible. That means it should default to () and always have as its value exactly the positional arguments that were passed. OTOH, I want message to default to , not to None (even though it will be set to None if you explicitly pass None as the first argument). So the constructor could be like this (until Python 3000): def __init__(self, *args): self.args = args if args: self.message = args[0] else: self.message = I think Nick proposed this before as well, so let's just do this. Yeah, but Nick used the conditional operator and I used that. All checked in. -Brett ___ 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
Re: [Python-Dev] PEP 352 Transition Plan
On 10/28/05, Nick Coghlan [EMAIL PROTECTED] wrote: Brett Cannon wrote: Interesting point, but I think that chaining should have more concrete support ala PEP 344 or some other mechanism. I think most people agree that exception chaining is important enough to have better support than some implied way of a causing exception to be passed along. Perhaps something more along the lines of: try: raise TypeError(inner detail) except TypeError, e: raise TypeError(outer detail, cause=e) where BaseException then has a 'cause' attribute that is set to None by default or some specific object that is passed in as the second argument to the constructor. Another point in PEP 352's favour, is that it makes it far more feasible to implement something like PEP 344 by providing __traceback__ and __prev_exc__ attributes on BaseException. The 'raise' statement could then take care of setting them appropriately if it was given an instance of BaseException to raise. Yep. This is why having a guaranteed API is so handy for exceptions. And actually PEP 3000 says that exceptions are supposed to gain a traceback attribute. But that can be another PEP if PEP 344 doesn't make it. Actually, that brings up another question - PEP 352 says it will require objects that inherit from BaseException. Does that mean that either subtypes or instances of BaseException will be acceptable? Or does it just mean instances? If the latter, how will that affect the multi-argument forms of 'raise'? I don't see how a multi-argument 'raise' changes the situation any. ``raise BaseException`` and ``raise BaseException()`` must both be supported which means isinstance() or issubtype() will be used (unless Python 3 bans raising a class or something). -Brett -Brett ___ 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
Re: [Python-Dev] cross-compiling
On 11/7/05, Neal Norwitz [EMAIL PROTECTED] wrote: We've been having some issues and discussions at work about cross compiling. There are various people that have tried (are) cross compiling python. Right now the support kinda sucks due to a couple of reasons. This might make a good sprint topic. Maybe your employer might be willing to get some people to come to hack on this? I know I wouldn't mind seeing the whole build process cleaned up. It works well enough, but I think some things could stand to be updated (speaking from experience of adding EXTRA_CFLAGS to the build process), such as setup.py being made more modular. -Brett ___ 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
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote: Maybe it makes more sense to deprecate .pyo altogether and instead have a post-load optimizer optimize .pyc files according to the current optimization settings? But I thought part of the point of .pyo files was that they left out docstrings and thus had a smaller footprint? Plus I wouldn't be surprised if we started to move away from bytecode optimization and instead tried to do more AST transformations which would remove possible post-load optimizations. I would have no issue with removing .pyo files and have .pyc files just be as optimized as they the current settings are and leave it at that. Could have some metadata listing what optimizations occurred, but do we really need to have a specific way to denote if bytecode has been optimized? Binary files compiled from C don't note what -O optimization they were compiled with. If someone distributes optimized .pyc files chances are they are going to have a specific compile step with py_compile and they will know what optimizations they are using. -Brett ___ 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
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote: On 11/9/05, Brett Cannon [EMAIL PROTECTED] wrote: Plus I wouldn't be surprised if we started to move away from bytecode optimization and instead tried to do more AST transformations which would remove possible post-load optimizations. I would have no issue with removing .pyo files and have .pyc files just be as optimized as they the current settings are and leave it at that. Could have some metadata listing what optimizations occurred, but do we really need to have a specific way to denote if bytecode has been optimized? Binary files compiled from C don't note what -O optimization they were compiled with. If someone distributes optimized .pyc files chances are they are going to have a specific compile step with py_compile and they will know what optimizations they are using. Currently, .pyo files have some important semantic differences with .pyc files; -O doesn't remove docstrings (that's -OO) but it does remove asserts. I wouldn't want to accidentally use a .pyc file without asserts compiled in unless the .py file wasn't around. For application distribution, the following probably would work: - instead of .pyo files, we use .pyc files - the .pyc file records whether optimizations were applied, whether asserts are compiled, and whether docstrings are retained - if the compiler finds a .pyc that is inconsistent with the current command line, it ignores it and rewrites it (if it is writable) just as if the .py file were newer However, this would be a major pain for the standard library and other shared code -- there it's really nice to have a cache for each of the optimization levels since usually regular users can't write the .py[co] files there, meaning very slow always-recompilation if the standard .pyc files aren't of the right level, causing unacceptable start-up times. What if PEP 304 came into being? Then people would have a place to have the shared code's recompiled version stored and thus avoid the overhead from repeated use. The only solutions I can think of that use a single file actually *increase* the file size by having unoptimized and optimized code side-by-side, or some way to quickly skip the assertions -- the -OO option is a special case that probably needs to be done differently anyway and only for final distribution. One option would be to introduce an ASSERTION bytecode that has an argument specifying the amount of bytecode for the assertion. The eval loop can then just igonore the bytecode if assertions are being evaluated and fall through to the bytecode for the assertions (and thus be the equivalent of NOP) or use the argument to jump forward that number of bytes in the bytecode and completely skip over the assertion (and thus be just like a JUMP_FORWARD). Either way assertions becomes slightly more costly but it should be very minimal. -Brett ___ 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
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote: [Guido] However, this would be a major pain for the standard library and other shared code -- there it's really nice to have a cache for each of the optimization levels since usually regular users can't write the .py[co] files there, meaning very slow always-recompilation if the standard .pyc files aren't of the right level, causing unacceptable start-up times. [Brett] What if PEP 304 came into being? Then people would have a place to have the shared code's recompiled version stored and thus avoid the overhead from repeated use. Still sounds suboptimal for the standard library; IMO it should just work. Fair enough. The only solutions I can think of that use a single file actually *increase* the file size by having unoptimized and optimized code side-by-side, or some way to quickly skip the assertions -- the -OO option is a special case that probably needs to be done differently anyway and only for final distribution. One option would be to introduce an ASSERTION bytecode that has an argument specifying the amount of bytecode for the assertion. The eval loop can then just igonore the bytecode if assertions are being evaluated and fall through to the bytecode for the assertions (and thus be the equivalent of NOP) or use the argument to jump forward that number of bytes in the bytecode and completely skip over the assertion (and thus be just like a JUMP_FORWARD). Either way assertions becomes slightly more costly but it should be very minimal. I like Phillip's suggestion -- no new opcode, just a conditional jump that can be easily optimized out. Huh? But Phillip is suggesting a new opcode that is essentially the same as my proposal but naming it differently and saying the bytecode should get changed directly instead of having the eval loop handle the semantic differences based on whether -O is being used. -Brett ___ 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
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote: I like Phillip's suggestion -- no new opcode, just a conditional jump that can be easily optimized out. Huh? But Phillip is suggesting a new opcode that is essentially the same as my proposal but naming it differently and saying the bytecode should get changed directly instead of having the eval loop handle the semantic differences based on whether -O is being used. Sorry. No problem. Figured you just misread mine. Looking back they look pretty much the same to me. Somehow I glanced over Phillip's code and thought he was proposing to use a regular JUMP_IF opcode with the special __debug__ variable (which would be a 3rd possibility, good if we had backwards compatibility requirements for bytecode -- which we don't, fortunately :-). Fortunately. =) So does this mean you like the idea? Should this all move forward somehow? -Brett ___ 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
[Python-Dev] dev FAQ updated with day-to-day svn questions
I just finished fleshing out the dev FAQ (http://www.python.org/dev/devfaq.html) with questions covering what someone might need to know for regular usage. If anyone thinks I didn't cover something I should have, let me know. -Brett ___ 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
Re: [Python-Dev] dev FAQ updated with day-to-day svn questions
On 11/10/05, Nick Coghlan [EMAIL PROTECTED] wrote: Brett Cannon wrote: I just finished fleshing out the dev FAQ (http://www.python.org/dev/devfaq.html) with questions covering what someone might need to know for regular usage. If anyone thinks I didn't cover something I should have, let me know. Should the section Developing on Windows disappear now? Well, the whole dev doc section needs cleaning up and that includes the dev FAQ. I was planning on doing this at some point; might as well start talking about it now. In my mind, the steps in each of the major things to do (bugs and patches) needs better docs. With that fleshed out, Intro to Development can act as an overview of the process. This should, together with the dev FAQ, cover what someone needs to do dev work. The question is how to structure the bug/patch guidelines. There are two options; dev FAQ entires much like the svn section or a more classic layout of the info. Both would have a bulleted list of the steps necessary for a bug/patch. The question is whether the information is presented in paragraphs of text following the bulleted list or as a list of questions. What do people prefer? -Brett ___ 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
Re: [Python-Dev] dev FAQ updated with day-to-day svn questions
On 11/10/05, Nick Coghlan [EMAIL PROTECTED] wrote: Brett Cannon wrote: I just finished fleshing out the dev FAQ (http://www.python.org/dev/devfaq.html) with questions covering what someone might need to know for regular usage. If anyone thinks I didn't cover something I should have, let me know. For question 1.2.10, I believe you also want: [miscellany] enable-auto-props = yes so that svn add works properly. Added. Missed that I had it in my personal config. =) Question 1.4.1 should cover the use of svn diff instead of cvs diff to make the patch. Changed. On that note, we need to update the patch submission guidelines to point to SVN instead of CVS (those guidelines also still say context diffs are preferred to unified diffs, which I believe is no longer true). Fixed and fixed. -Brett ___ 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
Re: [Python-Dev] Implementation of PEP 341
On 11/13/05, Nick Coghlan [EMAIL PROTECTED] wrote: Thomas Lee wrote: Implemented as you suggested and tested. I'll submit the patch to the tracker on sourceforge shortly. Are you guys still after contextual diffs as per the developer pages, or is an svn diff the preferred way to submit patches now? svn diff should be fine. Although I thought Brett had actually updated those pages after the move to svn. . . I did. But the docs just need to be revamped. But I can't start on that work until people tell me if they prefer FAQ-style (question listing all steps and then a question covering each step) or essay-style (bulleted list and then a definition/paragraph on each step) for bug/patch guidelines. Thanks very much for all your help, Nick. It was extremely informative. I think we can chalk up a respectable win for the AST-based compiler - the trick I suggested wouldn't really have been practical without the AST layer between the parser and the compiler. Yeah, this is a total win for the AST compiler. I would not have wanted to attempt this with the old CST compiler. -Brett ___ 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
Re: [Python-Dev] Memory management in the AST parser compiler
On 11/16/05, Fredrik Lundh [EMAIL PROTECTED] wrote: Thomas Lee wrote: Even if it meant we had just one function call - one, safe function call that deallocated all the memory allocated within a function - that we had to put before each and every return, that's better than what we have. alloca? (duck) But how widespread is its support (e.g., does Windows have it)? -Brett ___ 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
Re: [Python-Dev] Memory management in the AST parser compiler
On 11/16/05, Thomas Lee [EMAIL PROTECTED] wrote:
Just messing around with some ideas. I was trying to avoid the ugly
macros (note my earlier whinge about a learning curve) but they're the
cleanest way I could think of to get around the problem without
resorting to a mass deallocation right at the end of the AST run. Which
may not be all that bad given we're going to keep everything in-memory
anyway until an error occurs ... anyway, anyway, I'm getting sidetracked :)
The idea is to ensure that all allocations within a single function are
made using the pool so that a function finishes what it starts. This
way, if the function fails it alone is responsible for cleaning up its
own pool and that's all. No funkyness needed for sequences, because each
member of the sequence belongs to the pool too. Note that the stmt_ty
instances are also allocated using the pool.
This breaks interfaces all over the place though. Not exactly a pretty
change :) But yeah, maybe somebody smarter than I will come up with
something a bit cleaner.
--
/* snip! */
#define AST_SUCCESS(pool, result) return result
#define AST_FAILURE(pool, result) asdl_pool_free(pool); return result
This is actually exactly what I was thinking of; macros that handle
returns and specify whether the return signals a success or failure.
One tweak I would do is posibly lock down the the variable name with
AST_POOL_ALLOC() at the start of a function that creates _arena_pool.
That way you don't need to pass in the specific pool. I don't see why
we will need to have multiple pools within a function. This also
allows the VISIT_* macros to be easily modified and not suddenly
require another argument to specify the arena name.
And all of this is easy to police since you can grep for 'return' and
make sure that it is meant to be there and not in actuality be one of
the macros. Basically gives us the mini-language that Nick mentioned
way back at the beginning of this thread.
Oh, and tweak the macros to be within ``do { ... } while(0)`` (``if
(1) AST_FAILURE(pool, NULL);`` will not expand properly otherwise).
-Brett
___
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
