Re: [Python-Dev] PEP 343 rewrite complete
http://www.python.org/peps/pep-0343.html I should add that IMO this obsoletes PEP 288 and PEP 325; I plan to reject those when PEP 343 is accepted. I've already withdrawn PEP 340. PEP 342 is separate (but I'll probably present it together with PEP 343). -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 rewrite complete
[Guido van Rossum] http://www.python.org/peps/pep-0343.html [Phillip J. Eby] Looks great. A few questions/comments: * What's the rationale for raising TypeError from close()? Wasn't RuntimeError discussed previously for that role? (and it's also used by the with_template example) OTOH, maybe that means we want a ControlFlowError or some such that can be used for both. I really don't want a new exception for this, since it's just a bug in the generator's code. I could go with RuntimeError here too, but I figured TypeError's meaning in a wider sense applies: the generator doesn't respond appropriately to the throw() call, which is similar to not handling a particular argument (list) correctly. * The opening example under Generator Decorator seems to be missing a try/finally block. Good catch. I've fixed this in the PEP. * The transaction handler could also be written as: @with_template def transactional(db): db.begin() try: yield db except: db.rollback() else: db.commit() at least, if I understand it correctly. Ah, of course. I've updated the PEP. -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 rewrite complete
[Arnold deVos, responding to himself] This template eats eats the exception, which will cause a RuntimeError in the proposed Wrapper, I think. A raise after rollback is needed. No, the generator returns after rolling back, which causes throw() to raise StopIteration, which is good enough for the wrapper as written. Actually, the Wrapper as written in the PEP does not raise RuntimeError if the generator catches a block's exception. Shouldn't the relevant clause in the Wrapper go like this: try: self.gen.throw(type, value, traceback) except type: return except StopIteration: raise RuntimeError(generator caught exception) else: raise RuntimeError(generator didn't stop) I considered that, but decided that it should be okay for the generator to respond to a throw() by returning (thus replacing the exception thrown by StopIteration) since the call to __exit__() is contained inside a finally-clause, so that when __exit__() returns normally, the finally-clause will re-raise the original exception anyway. Note that there are currently no other use cases for throw() except the with_template decorator and the close() method. Both allow the generator to respond either by letting the exception pass through it unchanged (after executing finally-clauses if present) or by simply returning (which will raise StopIteration in the caller of throw()). Erroneous behaviors are, in both cases, raising some other exception or *yielding* another value. There may be *other* use cases for yielding a value, for example, a future (looping) block-statement a la PEP 343. Raising another exception is always an indication of a bug in the generator. And the transaction template would go like this (re-raising the exception): @with_template def transactional(db): db.begin() try: yield None except: db.rollback() raise else: db.commit() At least this is what I gleaned from the earlier threads. It means that the template does not appear to supress an exception that it cannot actually supress. I disagree (at the -0 to -0.5 level); given that the with_template decorator allows StopIteration, I think that appearing to suppress an exception it doesn't actually suppress is a minor sin -- the key point is that the cleanup gets executed and doesn't raise a new exception or reaches a yield-statement. I'll summarize this discussion in the PEP. -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 rewrite complete
[me] I'll summarize this discussion in the PEP. I've added this section to the PEP. Is anyone dead set against the tentative resolutions here? Open Issues Discussion on python-dev has revealed some open issues. I list them here, with my preferred resolution and its motivation. The PEP as currently written reflects this preferred resolution. 1. What exception should be raised by close() when the generator yields another value as a response to the GeneratorExit exception? I originally chose TypeError because it represents gross misbehavior of the generator function, which should be fixed by changing the code. But the with_template decorator class uses RuntimeError for similar offenses. Arguably they should all use the same exception. I'd rather not introduce a new exception class just for this purpose, since it's not an exception that I want people to catch: I want it to turn into a traceback which is seen by the programmer who then fixes the code. So now I believe they should both raise RuntimeError. There are some precedents for that: it's raised by the core Python code in situations where endless recursion is detected, and for uninitialized objects (and for a variety of miscellaneous conditions). 2. Both the generator close() method and the __exit__() method of the with_template decorator class catch StopIteration and consider it equivalent to re-raising the exception passed to throw(). Is allowing StopIteration right here? This is so that a generator doing cleanup depending on the exception thrown (like the transactional() example below) can *catch* the exception thrown if it wants to and doesn't have to worry about re-raising it. I find this more convenient for the generator writer. Against this was brought in that the generator *appears* to suppress an exception that it cannot suppress: the transactional() example would be more clear according to this view if it re-raised the original exception after the call to db.rollback(). I personally would find the requirement to re-raise the exception an annoyance in a generator used as a with-template, since all the code after yield is used for is cleanup, and it is invoked from a finally-clause (the one implicit in the with-statement) which re-raises the original exception anyway. -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 rewrite complete
On 6/2/05, Phillip J. Eby [EMAIL PROTECTED] wrote: At 01:08 AM 6/3/2005 +1000, Nick Coghlan wrote: Also, I'm wondering if it would be useful to have a 'closing' template that looked like: @with_template def closing(obj): try: yield obj finally: obj.close() +1 if you make it 'if hasattr(obj,close): obj.close()' in the finally clause, so that it will still work if the type of the object changes. But then you'd get back the bug where it would silently do nothing when you pass it the wrong thing; wasn't that argument used against an earlier proposal to skip calling __exit__() when it doesn't exist? -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 rewrite complete
[Nick Coghlan] Also, I'm wondering if it would be useful to have a 'closing' template that looked like: @with_template def closing(obj): try: yield obj finally: obj.close() That can be used to deterministically close anything with a close method, be it file, generator, or something else: with closing(open(argument.txt)) as contradiction: for line in contradiction: print line with closing(some_gen()) as data: for datum in data: process(datum) I just realized this has a race condition. The bytecode for the expression closing(open(...)) must necessarily contain a bytecode that calls open() followed by another bytecode that calls closing(). If a ^C happens between these two byte codes, the stack contains an open file object that won't be closed explicitly. With the original opening() template, this race can be avoided (and I intend to do so) by implementing opening() in C (as a class with __enter__ and __exit__ methods), and by making sure that the interpreter does *not* check for interrupts between the call to __enter__ and the start of the try-finally-statement in the translation of the with-statement. The only way to avoid the race that I can see with the closing() template would be to disable signals for the duration of the evaluation of the expression in the with-statement, but I really don't like that solution at all -- system calls like that can be excruciatingly expensive compared to bytecode execution. Most applications don't catch ^C so they don't need this extra protection -- but the compiler doesn't know that so everybody pays for it. The solution for avoiding interrupts between the __enter__() call and the try start doesn't require disabling signals; there can be a single opcode that calls __enter__ and sets up the try-finally context. -- --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/archive%40mail-archive.com
Re: [Python-Dev] sys.path in interactive session
I've always liked it this way; using instead of . means that if you os.path.join() it with a script name you don't get a spurious ./ prepended. I think that the absolutizing of sys.path entries is relatively new (seems to have started in 2.3). Also note that it's not really the current directory but the directory containing the script; that is definitely intentional. On 6/2/05, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: While looking at bug #779191, I saw that sys.path's first element is '' in interactive sessions, but the current dir otherwise. Is this intentional? Reinhold -- Mail address is perfectly valid! ___ 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/archive%40mail-archive.com
[Python-Dev] For review: PEP 343: Anonymous Block Redux and Generator Enhancements
After many rounds of discussion on python-dev, I'm inviting public comments for PEP 343. Rather than posting the entire PEP text here, I'm inviting everyone to read it on line (http://www.python.org/peps/pep-0343.html) and then post comments on a Wiki page I've created for this purpose (http://wiki.python.org/moin/WithStatement). I think this is a good one; I hope people agree. Its acceptance will obsolete about 4 other PEPs! (A sign that it fulfills a need and that the proposed solution is powerful.) -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 rewrite complete
On 6/5/05, Martin v. Löwis [EMAIL PROTECTED] wrote: Guido van Rossum wrote: @with_template def closing(obj): try: yield obj finally: obj.close() I just realized this has a race condition. The bytecode for the expression closing(open(...)) must necessarily contain a bytecode that calls open() followed by another bytecode that calls closing(). This is not a convincing point. That race condition always existed, e.g. in the traditional f = open(filename) try: process(f) finally: f.close() as you could always get an async exception between open returns and f is assigned. This isn't much of an issue, since CPython would always release the file immediately as the stack frame is cleared due to the exception. I think would should explicitly weaken our guarantees for asynchronous exceptions (of which we currently only have KeyboardInterrupt). The PEP should point out that an async exception between the beginning of the with statement and the assignment to the variable may or may not cause __exit__ to be called (depending on how far you are into __enter__) That is pretty clear from the translation given in the PEP. What is not so clear is that the cace can be completely avoided *if* the call to __enter__ and the try-finally setup are combined in one opcode, *and* __enter__ is implemented in C, *and* the reversible actions are all done by __enter__. This is also why I don't like giving file objects __enter__ and __exit__ methods. I know all this doesn't matter in most situations, but sometimes it does, and it would be good if there was a solution -- today, there really isn't one except to rely on CPython's reference counting. -- --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/archive%40mail-archive.com
[Python-Dev] PEP 343 - next steps
While there's still some activity in the Wiki, nothing (to me) sounds like signs of serious disagreement or truly better alternatives. So I think I'd like to move forward towards acceptance soon (before EuroPython). Two issues brought up in the Wiki are worth considering: - throw() is a term taken from Java C++. We can't call the method raise() -- but perhaps we can call it next_raising() or next_raise(), which emphasizes the similarity with next(). Thoughts? I'm not strong on this; I think throw() is fine too, especially since I expect that it will be used explicitly extremely rarely -- the only customer is the with_template decorator. - Whether and how to keep a door open for a future extension to the syntax that allows multiple resources to be acquired in a single with-statement. Possible syntax could be (a)with EXPR1 [as VAR1], EXPR2 [as VAR2], EXPR3 [as VAR3], ...: or (b)with EXPR1, EXPR2, EXPR3, ... as VAR1, VAR2, VAR3, ...: Variant (a) seems better and is more analogous to the use of 'as' in import statements, and (b) has the disadvantage that if you want to acquire several resources and not all of them have an associated variable, you'll have to sprinkle dummy variables on the right of 'as'. So (a) would have my preference. But I would still like to start off without this extension. The issue is: if we allow VAR to be a comma-separated list of variables now, that cuts off the extension to (a) in the future; so the PEP would have to be amended to state that VAR must be a single variable or a list of variables IN PARENTHESES. Thoughts? -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - next steps
On 6/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote: - throw() is a term taken from Java C++. This was intended. There was much discussion about this for PEP 288 and this was more or less a concensus choice. The term is already associated with exceptions in other languages and it captures the concept of the raise occurring somewhere else (what is thrown at or into). It is simple, clear, and tends to suggest all the right things. I have no doubt that someone can point out differing semantics in other languages but I don't care. The verbal cue is what we are after. Cool. throw() it is. -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - next steps
[Nick] I also added a new question to the Wiki regarding what, if any, guarantees will be made regarding when (or if) asynchronous interrupts will be blocked. Given that the call to __enter__() can invoke arbitrary Python code, is pushing the with statement setup inside a single opcode actually sufficient? Not sufficient if __enter__ is written in Python; in that case, *nothing* can be done to make it sufficient. The single opcode makes it possible to implement __enter__ in C to solve the issue in specific cases. It also considers the possibility of using with statements in an RAII style by acquiring the resource in __init__ or __new__ rather than __enter__. Python isn't C++; you shouldn't do that. This is a topic that got a brief mention during early discussion here, but doesn't seem to be covered in the current version of PEP 343. I haven't been infected with the RAII meme, so I can't help you here. -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - next steps
I can't make time for this right now, but the more I think about it, the more I believe the worry about asynchronous exceptions is mostly irrational. Despite your proof that it *can* be implemented I really don't want to see anything like that implemented -- I doubt that you've covered all the cases and I don't like inserting new opcodes to handle a case that most programs don't care about. Declaring something atomic that could span an arbitrary amount of Python code execution (including calls) just doesn't seem right. Disregarding asynchronous exceptions, you can already use with-statements for your beloved RAII pattern, right? I'm still skeptical how important it is in Python -- its seems something invented very specifically for C++'s guarantee of local destructor execution, and I don't expect to see all that many applications for it in Python. The with-statement is about the reduction of boiler-plate code involving try-finally, and that is typically not used for resource release (unless you count locks, where RAII is inappropriate -- at least in Python). -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - next steps
[Nick] As I just added to the Wiki, dropping the issue completely works for me. I'm also far from convinced I'd covered all the corner cases (besides, blocking KeyboardInterrupt for an arbitrary amount of time made me uncomfortable). OK. You'd mostly convinced me that RAII was rare in Python, but two possible use cases remained - files, and call method X of object Y at the end of the block (e.g. closing() from the PEP). Both of those would require any async guarantee to cover evaluation of EXPR in order to be included in the guarantee. If with statements make no guarantees about async exceptions, then there is no problem (as there is officially no difference between the two styles). Any exception, async or otherwise, that happens before the 'try' of the translation is reached, does *not* cause __exit__ to be called. I just realized that the assignment to VAR (if present) also has to be represented by one or more opcodes, so a special guarantee that __enter__() called by the same opcode that sets up the try cannot work anyway. Forget I said anything about that. If we ever do resurrect the idea, I also realised a far simpler solution would involve moving evaluation of EXPR and the call to __enter__ inside the try/finally block, and having an internal flag to indicate whether or not __exit__ should be called as the block is exited. Far less screwing around with ceval.c, and far easier to get right. We considered this at some point during the PEP 340/343/346 discussion (in fact I had it this way in an early version of one of the PEPs), and in the end decided against it. I believe the argument was that any failure *before* __enter__() returns can be handled by try/except clauses inside __init__() or __enter__(). Changing to this style later would be a major backward incompatibility because the guarantees made to __exit__() are different. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Multiple expression eval in compound if statement?
On 6/12/05, Skip Montanaro [EMAIL PROTECTED] wrote: I'm horsing around with recognizing switch-like if statements like: if x == 1: print 1 elif x == 2: print 2 else: print unknown in the compiler and generating O(1) code. x can be any expression, but must be precisely the same in each elif clause, the comparison operator must be == and the RHS of the test must evaluate to a simple hashable constant (string, float, integer - still working on None, constant tuples may be allowed later). I can currently recognize such constructs and am working on code generation. Cool! This would represent a semantic change to the Python runtime, because x would only be evaluated once, whereas in existing usage it can potentially be evaluated many times. If evaluating x has side-effects, code like the above that currently works would break. In reading the language reference manual, it says: It selects exactly one of the suites by evaluating the expressions one by one until one is found to be true (see section 5.10 for the definition of true and false); then that suite is executed (and no other part of the if statement is executed or evaluated). If all expressions are false, the suite of the else clause, if present, is executed. It says nothing about possibly caching values, which is what I'm doing effectively, but it seems pretty clear that each full test expression will be evaluated until one evaluates to true. I can't imagine anyone relying on a side-effect when evaluating x in this context, and if someone did, their code would be truly fragile. Still, any thought as to whether or not such a semantic change to the language might be acceptable? I think it would be wiser if you only did this when x is a simple local variable. For locals, we *know* that no side effect of any expression can change the value. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Wishlist: dowhile
On 6/12/05, Nick Coghlan [EMAIL PROTECTED] wrote: Raymond Hettinger wrote: More than case-statement semantics or PEP343, I wish for a dowhile statement. The most straight-forward way is to put the conditional expression at the beginning of the block with the understanding that a dowhile keyword will evaluate the condition only after the block runs Out-of-order code execution rarely counts as 'straightforward' ;) Right. Millions of years of programming language design have shown us how to write a loop with the condition tested at the end -- the condition is written after the loop body. With PEP 315, a do-while loop would look like: do: body while cond: pass But then, I'm reasonably happy with the 'break out of an infinite loop' approach, so *shrug*. Amen. If we have to do this, PEP 315 has my +0. It is Pythonically minimal and the motivation rings true: I've often written code like this in the past: line = f.readline() while line: do something line = f.readline() But these days we do that using for line in f. I wonder if other similar use cases can't be rewritten using better iterators? Maybe Raymond can show us some motivating use cases. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Wishlist: dowhile
[BJörn Lindqvist] I would like to have do-while's like this: do: body until cond But I'm sure that has problems too. [Raymond Hettinger] That looks nice to me. [Nick Coghlan] And this could easily be extended to allow code both before and after the 'until', giving a fully general loop: do: body-1-or-more-times until cond body-0-or-more-times else: on-natural-loop-exit Which is exactly like PEP 315 except there 'until' must be spelled 'while not' and the while is properly indented. (I'm still not sure whether BJörn *meant* the 'until' to be indented or whether he simply made a mistake; his proposal resembles a Pythonic version of Pascal's repeat-until, which would have an unindented until-clause.) The 'until' is less hidden than the 'yield' that turns a function into a generator, and its presence is obviously signalled by the preceding 'do'. Its also less hidden than the 'if'/'break' construct in the infinite loop workaround, and about as hidden as the exit flag in the other style of workaround (although the 'until' can be more easily picked out by a syntax highlighter). Why are you so excited about having until indented? You didn't give any examples with multiple occurrences. A single occurrence works just fine unindented, as PEP 315 has already shown. The indented until sounds like unnecessary syntactic sugar for 'if X: break' -- not very Pythonic. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Wishlist: dowhile
On 6/13/05, BJörn Lindqvist [EMAIL PROTECTED] wrote: do: block until cond Written like this it is not very obvious that the 'unil' is part of the do-until suite. I also imagine it to be difficult to parse and it breaks the rule that suites end when there is a dedentation. So, IMHO using an indented 'until' is the least evil of a number of evils. Not difficult to parse at all, nor un-Pythonic. Multi-part blocks abound in Python: if / elif / else, try / finally, etc. Why are you so excited about having until indented? You didn't give any examples with multiple occurrences. A single occurrence works just fine unindented, as PEP 315 has already shown. The indented until sounds like unnecessary syntactic sugar for 'if X: break' -- not very Pythonic. Yes, but grepping the stdlib produces over 300 hits for while 1: and while True: combined. Some of those a if cond: break in the middle and some would be better written as generators, but lots of them would be rewritten as do-while's. So I think there is more than enough use cases for syntactic sugar for do-while loops. The PEP 315 solution looks much better than an until that isn't what it looks like. -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 342 - Enhanced Iterators
Good idea, done. On 6/13/05, Delaney, Timothy C (Timothy) [EMAIL PROTECTED] wrote: There's a thread on c.l.py at the moment (Controlling a generator the pythonic way) which is basically coming up with PEP 342. I've pointed them to PEP 342, but it's made me think that the name of the PEP could better indicate what it does. I propose Coroutines via Enhanced Iterators. Tim Delaney ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Dynamic class inheritance something else
On 6/14/05, Vero [EMAIL PROTECTED] wrote: Hi. My name is Veronica, I am a master student at UNAM. I am working on something related to Artificial Inteligence and I have been looking for the most appropriated programming language to implement my algorithms. I found python to be very close to what I need, but there are still a couple of details that I haven't been able to solve. First, (and most important) I would like to be able to dynamically modify the classes from which a class inherits. I haven't found any way to do it with the language as it is. If there is a way, any suggestion will be truly appreciated. If I had to modify the source code to achieve this, I hope that you could give me some hints; I have an idea of how something like this could be achieved but since I don't know deeply the python sourcode I could get lost. I wonder if assignment to __class__ (for instances) or to __bases__ (for classes) is what you are looking for? class C: def foo(self): print foo class D: def foo(self): print D.foo x = C() x.__class__ = D x.foo() D.foo x.__class__ = C x.foo() foo Second, since my program will be modifying classes during run time, I would like to have a way to write on a file the python code that would have defined the class with the functions and attributes as they were left, just as if it had been writen like that at the very begining. I need it to be python code because I will be using that latter. Maybe I will have to solve this second problem by myself but I just wrote in case anybody had a good idea. That one's not so easy; there's no standard solution for this problem. I recommend that you follow Aahz' suggestion of asking on c.l.py instead. -- --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/archive%40mail-archive.com
[Python-Dev] Compiling Python with Intel compiler?
Intel has a free (as in beer) C compiler for Linux. A friend of mine is involved in its production and marketing. He would like to see how his compiler does on Python -- does it work at all, and is there a speedup? I promised him I'd look into this, but between PEPs and my day job I don't seem to have the time, so now I'm making up on my promise by trying to delegate... The compiler is here: http://www.intel.com/software/products/compilers/clin/index.htm On the right is a link to a Free Non-Commercial Download. That's all I know. I think that if someone puts some time in this, they should get a free Intel T-shirt. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Withdrawn PEP 288 and thoughts on PEP 342
On 6/16/05, Raymond Hettinger [EMAIL PROTECTED] wrote: [Phillip] I could definitely go for dropping __next__ and the next() builtin from PEP 342, as they don't do anything extra. I also personally don't care about the new continue feature, so I could do without for-loop alteration too. I'd be perfectly happy passing arguments to next() explicitly; I just want yield expressions. That's progress! Please do what you can to get the non-essential changes out of 342. Here's my current position: instead of g.__next__(arg) I'd like to use g.next(arg). The next() builtin then isn't needed. I do like continue EXPR but I have to admit I haven't even tried to come up with examples -- it may be unnecessary. As Phillip says, yield expressions and g.next(EXPR) are the core -- and also incidentally look like they will cause the most implementation nightmares. (If someone wants to start implementing these two now, go right ahead!) Meanwhile, it hasn't promised any advantages over the dead PEP 288 proposals. Reading the comments in PEP 288's revision history, it sounds like the argument was to postpone implementation of next(arg) and yield expressions to a later version of Python, after more community experience with generators. We've had that experience now. 288 was brought out of retirement a few months ago. Guido hated every variation of argument passing and frequently quipped that data passing was trivially accomplished though mutable arguments to a generator, through class based iterators, or via a global variable. I believe all of those comments were made recently and they all apply equally to 342. That was all before I (re-)discovered yield-expressions (in Ruby!), and mostly in response to the most recent version of PEP 288, with its problem of accessing the generator instance. I now strongly feel that g.next(EXPR) and yield-expressions are the way to go. Making g.next(EXPR) an error when this is the *initial* resumption of the frame was also a (minor) breakthrough. Any data needed by the generator at this point can be passed in as an argument to the generator. Someone should really come up with some realistic coroutine examples written using PEP 342 (with or without continue EXPR). -- --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/archive%40mail-archive.com
Re: [Python-Dev] Propose to reject PEP 265 -- Sorting Dictionaries by Value
Agreed. I don't want to add sorting abilities (with all its infinite
variants) to every data structure -- or even one or two common data
structures. You want something sorted that's not already a list? Use
the sorted() method.
On 6/16/05, Steven Bethard [EMAIL PROTECTED] wrote:
Raymond Hettinger wrote:
May I suggest rejecting PEP 265.
As of Py2.4, its use case is easily solved with:
sorted(d.iteritems(), key=itemgetter(1), reverse=True)
[('b', 23), ('d', 17), ('c', 5), ('a', 2), ('e', 1)]
+1.
I find that usually when I want something like this, I use:
sorted(d, key=d.__getitem__, reverse=True)
because it doesn't require the operator module and most of the time I
just need the keys anyway.
py sorted(d, key=d.__getitem__, reverse=True)
['b', 'd', 'c', 'a', 'e']
Steve
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
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/archive%40mail-archive.com
Re: [Python-Dev] Propose to reject PEP 265 -- Sorting Dictionaries by Value
On 6/16/05, Guido van Rossum [EMAIL PROTECTED] wrote: Agreed. I don't want to add sorting abilities (with all its infinite variants) to every data structure -- or even one or two common data structures. You want something sorted that's not already a list? Use the sorted() method. I meant the sorted() function, of course. Java on my mind. :-) -- --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/archive%40mail-archive.com
Re: [Python-Dev] Propose to reject PEP 281 -- Loop Counter Iteration with range and xrange
On 6/16/05, Raymond Hettinger [EMAIL PROTECTED] wrote: The need for the indices() proposal was mostly met by PEP 279's enumerate() builtin. Commenting on 279 before it was accepted for Py2.3, PEP 281's author, Magnus Lie Hetland, wrote, I'm quite happy to have it make PEP 281 obsolete. Yes please. These examples are especially jarring: range(range(5), range(10), range(2)) [5, 7, 9] (etc.) -- --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/archive%40mail-archive.com
Re: [Python-Dev] Propose to reject PEP 276 -- Simple iterator for ints
I've never liked that idea. Down with it! On 6/16/05, Raymond Hettinger [EMAIL PROTECTED] wrote: The principal use case was largely met by enumerate(). From PEP 276's rationale section: A common programming idiom is to take a collection of objects and apply some operation to each item in the collection in some established sequential order. Python provides the for in looping control structure for handling this common idiom. Cases arise, however, where it is necessary (or more convenient) to access each item in an indexed collection by iterating through each index and accessing each item in the collection using the corresponding index. Also, while some nice examples are provided, the proposed syntax allows and encourages some horrid examples as well: for i in 3: print i 0 1 2 The backwards compatability section lists another problematic consequence; the following would stop being a syntax error and would become valid: x, = 1 The proposal adds iterability to all integers but silently does nothing for negative values. A minor additional concern is that floats are not given an equivalent capability (for obvious reasons) but this breaks symmetry with range/xrange which still accept float args. Raymond -- --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/archive%40mail-archive.com
Re: [Python-Dev] Withdrawn PEP 288 and thoughts on PEP 342
[Raymond]
Let me go on record as a strong -1 for continue EXPR. The for-loop is
our most basic construct and is easily understood in its present form.
The same can be said for continue and break which have the added
advantage of a near zero learning curve for people migrating from other
languages.
Any urge to complicate these basic statements should be seriously
scrutinized and held to high standards of clarity, explainability,
obviousness, usefulness, and necessity. IMO, it fails most of those
tests.
I would not look forward to explaining continue EXPR in the tutorial
and think it would stand out as an anti-feature.
You sometimes seem to compound a rational argument with too much rhetoric.
The correct argument against continue EXPR is that there are no use
cases yet; if there were a good use case, the explanation would follow
easily.
The original use case (though not presented in PEP 340) was to serve
as the equivalent to return EXPR in a Ruby block. In Ruby you have
something like this (I probably get the syntax wrong):
a.foreach() { |x| ...some code... }
This executes the block for each item in a, with x (a formal parameter
to the block) set to each consecutive item. In Python we would write
it like this of course:
for x in a:
...some code...
In Ruby, the block is an anonymous procedure (a thunk) and foreach() a
method that receives a margic (anonymous) parameter which is the
thunk. Inside foreach(), you write yield EXPR which calls the block
with x set to EXPR. When the block contains a return statement, the
return value is delivered to the foreach() method as the return value
of yield, which can be assigned like this:
VAR = yield EXPR
Note that Ruby's yield is just a magic call syntax that calls the thunk!
But this means that the thunks can be used for other purposes as well.
One common use is to have the block act as a Boolean function that
selects items from a list; this way you could write filter() with an
inline selection, for example (making this up):
a1 = a.filter() { |x| return x 0 }
might set a1 to the list of a's elements that are 0. (Not saying
that this is a built-in array method in Ruby, but I think you could
write one.)
This particular example doesn't translate well into Python because a
for-loop doesn't have a return value. Maybe that would be a future
possibility if yield-expressions become accepted (just kidding:-).
However, I can see other uses for looping over a sequence using a
generator and telling the generator something interesting about each
of the sequence's items, e.g. whether they are green, or should be
printed, or which dollar value they represent if any (to make up a
non-Boolean example).
Anyway, continue EXPR was born as I was thinking of a way to do this
kind of thing in Python, since I didn't want to give up return as a
way of breaking out of a loop (or several!) and returning from a
function.
But I'm the first to admit that the use case is still very much
hypothetical -- unlike that for g.next(EXPR) and VAR = yield.
--
--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/archive%40mail-archive.com
Re: [Python-Dev] Propose to reject PEP 313 -- Adding Roman Numeral Literals to Python
+M to reject. On 6/16/05, Raymond Hettinger [EMAIL PROTECTED] wrote: While the majority of Python users deem this to be a nice-to-have feature, the community has been unable to reach a consensus on the proper syntax after more than two years of intensive debate (the PEP was introduced in early April 2003). Most agree that there should be only-one-way-to-do-it; however, the proponents are evenly split into two camps, with the modernists preferring IX for nine and the classicists preferring V which was the most likely spelling in ancient Rome. The classicists not only rely on set-in-stone tradition, they point to pragmatic issues such as avoidance of subtraction, ease of coding, easier mental parsing (much less error prone), and ease of teaching to beginners. They assert that the modernists have introduced unnecessary algorithmic complexity just to save two keystrokes. The modernists point to compatible Java implementations and current grade school textbooks. They believe that users from other languages will expect the IX form. Note however, not all the modernists agree on whether MXM would be a well-formed spelling of 1990; most, but not all prefer MCMXC despite its likelihood of being mis-parsed on a first reading. There is also a small but vocal user group demanding that lowercase forms be allowed. Their use cases fall into four categories: (i) academia, (ii) the legal profession, (iii) research paper writing, and (iv) powerpoint slideshows. Reportedly, this is also a common convention among Perl programmers. Links: http://hrsbstaff.ednet.ns.ca/waymac/History%20A/A%20Term%201/1.%20Rome/R oman_Numerals.htm http://www.sizes.com/numbers/roman_numerals.htm 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/archive%40mail-archive.com
Re: [Python-Dev] Propose updating PEP 284 -- Integer for-loops
On 6/18/05, Michael Hudson [EMAIL PROTECTED] wrote: Raymond Hettinger [EMAIL PROTECTED] writes: I recommend that the proposed syntax be altered to be more parallel with the existing for-loop syntax to make it more parsable for both humans and for the compiler. Although all your suggestions are improvments, I'm still -1 on the PEP. Same here. The whole point (15 years ago) of range() was to *avoid* needing syntax to specify a loop over numbers. I think it's worked out well and there's nothing that needs to be fixed (except range() needs to become an interator, which it will in Python 3.0). -- --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/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
[Nick Coghlan] And here we see why I'm such a fan of the term 'deferred expression' instead of 'anonymous function'. Python's lambda expressions *are* the former, but they are emphatically *not* the latter. Let me emphatically disagree. Your POV is entirely syntactical, which IMO is a shallow perspective. Semantically, lambdas ARE anonymous functions, and that's what counts. Since deferred expression is not defined in Python, you can't reasonably argue about whether that's what lambdas are, but intuitively for me the term refers to something more lightweight than lambdas. Now, whether the use cases for lambdas are better served by anonymous functions or by something else that might be called deferred expression, I don't know yet. But as long as we are describing the present state we should call a spade a spade, etc. (Alas, no time to follow the rest of this thread -- vacationing with little connectivity until EuroPython starts next week.) -- --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/archive%40mail-archive.com
Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers
[Keith Dart] In SNMP, for example, a Counter32 is basically an unsigned int, defined as IMPLICIT INTEGER (0..4294967295). One cannot efficiently translate and use that type in native Python. Currently, I have defined an unsigned type as a subclass of long, but I don't think that would be speed or storage efficient. In my experience you can just use Python longs whenever a C API needs an unsigned long. There's no need to subtype, and your assumption that it would not be efficient enough is mistaken (unless you are manipulating arrays with millions of them, in which case you should be using Numeric, which has its own types for this purpose). (Want to argue about the efficiency? Write a typical use case and time it.) By far the easiest way to do arithmetic mod 2**32 is to just add 0x to the end of your expression. For example, simulating the effect of multiplying an unsigned long by 3 would be x = (x * 3) 0x. If there is a problem with ioctl() not taking long ints, that would be a bug in ioctl, not a lacking data type or a problem with long ints. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers
On 6/20/05, Keith Dart [EMAIL PROTECTED] wrote: On Mon, 20 Jun 2005, Guido van Rossum wrote: [...] By far the easiest way to do arithmetic mod 2**32 is to just add 0x to the end of your expression. For example, simulating the effect of multiplying an unsigned long by 3 would be x = (x * 3) 0x. But then I wouldn't know if it overflowed 32 bits. Huh? C unsigned ints don't flag overflow either -- they perform perfect arithmetic mod 2**32. In my usage, the integer will be translated to an unsigned (32 bit) integer in another system (SNMP). I want to know if it will fit, and I want to know early if there will be a problem, rather than later (at conversion time). So check if it is = 2**32 (or 0, of course). One of the selling points of Python in previous versions was that you would get an OverFlowError on overflow, where other languages did not (they overflowed silently). So I subclassed long in 2.3, to get the same overflow exception: ... Again, because I want to catch the error early, before conversion to the external type. This is a very specialized application. Your best approach is to check for overflow before passing into the external API -- ideally the wrappers for that API should do so. If there is a problem with ioctl() not taking long ints, that would be a bug in ioctl, not a lacking data type or a problem with long ints. That must be it, then. Shall I file a bug somewhere? SourceForge. (python.org/dev for more info) -- --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/archive%40mail-archive.com
Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers
On 6/20/05, Keith Dart [EMAIL PROTECTED] wrote: However, since it is sometimes necessary to interface to other systems with Python, I see no reason why Python should not have a full set of built in numeric types corresponding to the machine types and, in turn, other system types. Then it would be easier (and probaby a bit faster) to interface to them. Perhaps Python could have an integer type for long/int unified types, and just int type as normal integers? Strongly disagree. (a) Stop worrying about speed. The overhead of a single Python bytecode execution is probably more than the cost of an integer operation in most cases. (b) I don't know what you call a normal integer any more; to me, unified long/int is as normal as they come. Trust me, that's the case for most users. Worrying about 32 bits becomes less and less normal. (c) The right place to do the overflow checks is in the API wrappers, not in the integer types. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
On 6/27/05, Phillip J. Eby [EMAIL PROTECTED] wrote: I think the only questions remaining open are where to put it and what to call the class. Whoa! Do we really need a completely different mechanism for doing the same stuff we can already do? The path module seems mostly useful for folks coming from Java who are used to the Java Path class. With the massive duplication of functionality we should also consider what to recommend for the future: will the old os.path module be deprecated, or are we going to maintain both alternatives forever? (And what about all the duplication with the os module itself, like the cwd() constructor?) Remember TOOWTDI. I think we should put it in os.path, such that 'from os.path import path' gives you the path class for your platform, and using one of the path modules directly (e.g. 'from posixpath import path') gives you the specific platform's version. Aargh! Call it anything except path. Having two things nested inside each other with the same name is begging for confusion forever. We have a few of these in the stdlib now (StringIO, UserDict etc.) and they were MISTAKES. This is useful because sometimes you need to manipulate paths that are foreign to your current OS. For example, the distutils and other packages sometimes use POSIX paths for input and then convert them to local OS paths. Also, POSIX path objects would be useful for creating or parsing the path portion of many kinds of URLs, and I have often used functions from posixpath for that myself. Right. That's why posixpath etc. always exists, not only when os.name == posix. As for a PEP, I doubt a PEP is really required for something this simple; I have never seen anyone say, no, we shouldn't have this in the stdlib. I think it would be more important to write reference documentation and a complete test suite. No, we shouldn't have this in the stdlib. At least, not without more motivation than it gets high praise. By the way, it also occurs to me that for the sake of subclassability, the methods should not return 'path(somestr)' when creating new objects, but instead use self.__class__(somestr). Clearly it needs a PEP. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE forreview)
On 6/28/05, Anders J. Munch [EMAIL PROTECTED] wrote: Alas datetime objects do not unambiguously identify a point in time. datetime objects are not timestamps: They represent the related but different concept of _local time_, which can be good for presentation, but shouldn't be allowed anywhere near a persistent store. You misunderstand the datetime module! You can have a datetime object whose timezone is UTC; or you can have a convention in your API that datetime objects without timezone represent UTC. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE forreview)
[Anders J. Munch] Alas datetime objects do not unambiguously identify a point in time. datetime objects are not timestamps: They represent the related but different concept of _local time_, which can be good for presentation, but shouldn't be allowed anywhere near a persistent store. [GvR] You misunderstand the datetime module! You can have a datetime object whose timezone is UTC; or you can have a convention in your API that datetime objects without timezone represent UTC. [Anders] I can do a lot of things in my own code, and I'm sure the datetime module provides tools that I can build on to do so, but that doesn't help in interfacing with other people's code -- such as the standard library. Try saving a pickle of datetime.now() and reading it on a computer set to a different time zone. The repr will then show the local time on the _originating_ computer, and figuring out the absolute time this corresponds to requires knowledge of time zone and DST settings on the originating computer. How about datetime.utcnow(), then? Just use UTC for datetime timestamps? But that goes against the grain of the datetime module: Against the grain? There's just a bug in your example; stop assigning intentions to datetime that it doesn't have. Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import datetime, time datetime.datetime.fromtimestamp(time.time()) - datetime.datetime.now() datetime.timedelta(0) datetime.datetime.fromtimestamp(time.time()) - datetime.datetime.utcnow() datetime.timedelta(0, 7200) It seems when I subtract the present time from the present time, there's a two hour difference. No, you're mixing intentions. I can't tell if you're doing this intentionally to make the design look bad or if you don't understand the design; I'm going to assume the latter (if the former there's no point to this discussion at all) and explain what you should have done: datetime.datetime.utcfromtimestamp(time.time()) - datetime.datetime.utcnow() datetime.timedelta(0) Your bug is similar to comparing centimeters to inches, or speed to acceleration, or any number of similar mistakes. What I give you, however, is that a timezone object representing UTC should be part of the standard library, so that you wouldn't have an excuse for using tz-less datetime objects to represent UTC. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE forreview)
[Anders J. Munch] If ctime/mtime/atime were to return datetime objects, that would pretty much have to be UTC to not lose information in the DST transition. I doubt that's what Walter wanted though, as that would leave users with the job of converting from UTC datetime to local datetime; - unless perhaps I've overlooked a convenient UTC-local conversion method? To be honest, I'm not sure what the point would be of returning datetime objects for this use case. A time.time()-like value seems just fine to me. The quest for a single representation of time (as expressed by Walter's We should have one uniform way of representing time in Python) is IMO a mistake; there are too many different use cases. Note that datetime intentionally doesn't handle things like leap seconds and alternate calendars. Those things are very specialized applications and deserve to be handled by application-specific code. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
On 6/30/05, Neil Hodgson [EMAIL PROTECTED] wrote: One benefit I see for the path module is that it makes it easier to write code that behaves correctly with unicode paths on Windows. Currently, to implement code that may see unicode paths, you must first understand that unicode paths may be an issue, then write conditional code that uses either a string or unicode string to hold paths whenever a new path is created. Then maybe the code that handles Unicode paths in arguments should be fixed rather than adding a module that encapsulates a work-around... -- --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/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
Guido van Rossum: Then maybe the code that handles Unicode paths in arguments should be fixed rather than adding a module that encapsulates a work-around... On 7/3/05, Neil Hodgson [EMAIL PROTECTED] wrote: It isn't clear whether you are saying this should be fixed by the user or in the library. I meant the library. For a quick example, say someone wrote some code for counting lines in a directory: [deleted] Ah, sigh. I didn't know that os.listdir() behaves differently when the argument is Unicode. Does os.listdir(.) really behave differently than os.listdir(u.)? Bah! I don't think that's a very good design (although I see where it comes from). Promoting only those entries that need it seems the right solution -- user code that can't deal with the Unicode entries shouldn't be used around directories containing unicode -- if it needs to work around unicode it should be fixed to support that! Mapping Unicode names to ? seems the wrong behavior (and doesn't work very well once you try to do anything with those names except for printing). Face it. Unicode stinks (from the programmer's POV). But we'll have to live with it. In Python 3.0 I want str and unicode to be the same data type (like String in Java) and I want a separate data type to hold a byte array. -- --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/archive%40mail-archive.com
Re: [Python-Dev] floatobject.c 2.136
[Raymond Hettinger] I'm getting a compiler warning from your checkin: [Michael Hudson] your? Mine? Alas, a typical exchange. The checkins are mailed from the committer's Sf email address, but the mailing list has been set up to redirect all replies to python-dev -- if you don't catch this before sending, you may be embarrassed in public or confuse the addressee. Is this behavior of the checkins list really a good idea? -- --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/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
On 7/5/05, Andrew Durdin [EMAIL PROTECTED] wrote: I have written a patch that changes the way triple-quoted strings are scanned so that leading whitespace is ignored in much the same way that pep 257 handles it for docstrings. Largely this was for a learning experience in hacking the parser, but it would be very nice IMO if something of this sort could be implemented in a future version of Python. I don't think so. It smells too much of DWIM, which is very unpythonic. EIBTI. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Chaining try statements: eltry?
On 7/6/05, Thomas Lotze [EMAIL PROTECTED] wrote: I want to ask what you think about introducing a keyword 'eltry' which would be the counterpart of 'elif' for try statements. This had been suggested before on python-list a couple of years ago by Jonathan Gardner, but nothing (that I could find) seems to have come of it. I'm -1 on this. The use case doesn't occur often in my experience and IMO putting each try statement in the else clause of the previous one is a fine solution. I also notice that your only example is very repetitive, and would be better written as a loop, using Python's dynamic nature: for decoder in foo_decode, bar_decode, foobar_decode: try: data = decoder(data) break except ValueError: print data doesn't seem to be %s-encoded % decoder.__name__ -- --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/archive%40mail-archive.com
Re: [Python-Dev] Expanding max chunk size to 4GB.
Looks ok to me, but have you tested this with other software that reads/writes wave files? You seem to be speculating about the format where you should be reading the reference documentation for this file format (alas, I can't help you find it -- you can Google for it as well as I can :). Also, patches, are best submitted to SourceForge. Read python.org/dev/. On 7/6/05, Mark Rages [EMAIL PROTECTED] wrote: The RIFF chunk size (used by the Python wave library) is 2GB, because the length is read as a signed 32-bit integer. The attached patch to chunk.py raises the limit to 4GB by using a signed integer. Is this correct? Is there a more general solution to 32-bit addressing limitation in wave files? Multiple chunks? Set the length field to zero and let software assume we only have one chunk? Regards, Mark Rages [EMAIL PROTECTED] -- You think that it is a secret, but it never has been one. - fortune cookie ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Chaining try statements: eltry?
On 7/7/05, Thomas Lotze [EMAIL PROTECTED] wrote: Sure, that's true for the example given. Getting other stuff into a form which allows for looping may require additional code. Well, hypothetical illustrations don't carry much value when arguing for something as substantial as new syntax requiring a new keyword. You have to present an actual use case with an indication (even if only anecdotal) of how common the use case is, and an explanation why the existing ways of handling that use case are inadequate. Your illustration doesn't count as a use case because it is easily handled already. Thinking about it some more, I find that a symmetry between statements which have an 'else' part would be appealing from an aesthetic point of view, which includes introduction of 'elfor' and 'elwhile' - or allowing for syntax like 'else if ...:' and 'else try:'. (It seems some people favour that anyway. OTOH, I undestand that introducing two-token constructs doesn't necessarily simplify parsing.) But I haven't encountered any use cases for that, so it's probably just idle musing. The parsing would be easy enough (and in fact I sometimes think it was a mistake to introduce elif just to save typing else if. The problem with the elwhile/elfor/eltry idea (apart from the explosion of new keywords) is that you're just as likely to need e.g. a try in the else clause of a while-loop as another while, so you'd end up having all combinations in the syntax. Since, as you say, the use cases are rare, the syntactic complexity isn't worth it. I even wonder if else-clauses on for/while were a good idea. (The one on try is definitely a good idea since the use case is quite frequent and only clumsily handled otherwise; the use cases for else on for/while are less convincing IMO.) -- --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/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
+1 on @contextmanager +1. [__enter__, __exit__] These names should be changed to __beginwith__ and __endwith__. -1. The PEP has had an extensive review period and several alternatives were discussed and rejected. These names are clear, they *do* match, and as Fred says the __*__ namespace has lots of room. Also, the PEP was accepted with these names. Now, if it was accepted with a major flaw or some semantics left unspecified, I'd be happy to discuss repairs; but there's nothing broken about this part of the PEP, so I say enough is enough (and none of the proposals sound good to me anyway so I'd be -1 even if the PEP was still under discussion). -- --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/archive%40mail-archive.com
Re: [Python-Dev] Chaining try statements: eltry?
[Guido, on {for,while}/else]
...
The question remains whether Python would be easier to learn without
them. And if so, the question would remain whether that's offset by
their utility for experienced developers. All hard to assess
impartially!
[Tim saves the day]
That's what I'm here for. I like loop else clauses, but have to
admit that (a) I rarely use them; (b) most of the time I use them, my
control flow is on the way to becoming so convoluted that I'm going to
rewrite the whole function soon anyway; and, (c) I've often misread
code that uses them, mentally attaching the else to a nearby if
instead.
I also suspect that if they weren't in the language already, a PEP to
introduce them would fail, because
still_looking = True
some loop:
if found it:
still_looking = False
break
if still_looking:
# what would have been in the else clause
is clear and easy to write without it.
OTOH I don't particularly like code that requires flag variables; 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.
How would a PEP to *remove* this feature fare today?
Unhelpfully,
--
--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/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
On 7/7/05, Walter Dörwald [EMAIL PROTECTED] wrote: What is still unspecified (or at least not explicitely mentioned) in the PEP is the lifetime of VAR in: with EXPR as VAR: BLOCK It is specified well enough IMO -- you're supposed to take the translation into basic Python seriously. That translation specifies a simple assignment to VAR, and that's what I meant (and what I'm sure most folks understood). IOW VAR lives in the surrounding scope, overwrites a previous value, and survives past the with-statement (unless it is set inside of course). -- --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/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
On 7/9/05, Neil Hodgson [EMAIL PROTECTED] wrote: M.-A. Lemburg: I don't really buy this trick: what if you happen to have a home directory with Unicode characters in it ? Most people choose account names and thus home directory names that are compatible with their preferred locale settings: German users are unlikely to choose an account name that uses Japanese characters. Unicode is only necessary for file names that are outside your default locale. An administration utility may need to visit multiple user's home directories and so is more likely to encounter files with names that can not be represented in its default locale. I think it would be better if sys.path could include unicode entries but expect the code will rarely be exercised. Another problem is that if you can return 8-bit strings encoded in the local code page, and also Unicode, combining the two using string operations (e.g. a directory using the local code page containing a file using Unicode, and then combining the two using os.path.join()) will fail unless the local code page is also Python's global default encoding (which it usually isn't -- we really try hard to keep the default encoding 'ascii' at all times). In some sense the safest approach from this POV would be to return Unicode as soon as it can't be encoded using the global default encoding. IOW normally this would return Unicode for all names containing non-ASCII characters. The problem is of course that while the I/O functions will handle this fine, *printing* Unicode still doesn't work by default. :-( I can't wait until we switch everything to Unicode and have encoding on all streams... -- --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/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
On 7/10/05, Andrew Durdin [EMAIL PROTECTED] wrote: On 7/7/05, Guido van Rossum [EMAIL PROTECTED] wrote: I don't think so. It smells too much of DWIM, which is very unpythonic. EIBTI. In what way? The scheme described is explicit, and consistently applied to all triple-quoted strings[*] -- although the rules are different to the current behaviour. On the other hand, my written proposal may not be clear or explicit, something I will attempt to remedy over the next few days. The scheme may be explicitly spelled out in the language reference, but it is implicit to the human reader -- what you see is no longer what you get. [*] Whether it should apply also to normal strings with escaped newlines is not something I have yet considered. I recommend that you give it up. You ain't gonna convince me. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
I'm in full agreement with Marc-Andre below, except I don't like (1) at all -- having used other APIs that always return Unicode (like the Python XML parsers) it bothers me to get Unicode for no reason at all. OTOH I think Python 3.0 should be using a Unicode model closer to Java's. On 7/11/05, M.-A. Lemburg [EMAIL PROTECTED] wrote: Neil Hodgson wrote: On unicode versions of Windows, for attributes like os.listdir, os.getcwd, sys.argv, and os.environ, which can usefully return unicode strings, there are 4 options I see: 1) Always return unicode. This is the option I'd be happiest to use, myself, but expect this choice would change the behaviour of existing code too much and so produce much unhappiness. Would be nice, but will likely break too much code - if you let Unicode object enter non-Unicode aware code, it is likely that you'll end up getting stuck in tons of UnicodeErrors. If you want to get a feeling for this, try running Python with -U command line switch. 2) Return unicode when the text can not be represented in ASCII. This will cause a change of behaviour for existing code which deals with non-ASCII data. +1 on this one (s/ASCII/Python's default encoding). 3) Return unicode when the text can not be represented in the default code page. While this change can lead to breakage because of combining byte string and unicode strings, it is reasonably safe from the point of view of data integrity as current code is returning garbage strings that look like '?'. -1: code pages are evil and the reason why Unicode was invented in the first place. This would be a step back in history. 4) Provide two versions of the attribute, one with the current name returning byte strings and a second with a u suffix returning unicode. This is the least intrusive, requiring explicit changes to code to receive unicode data. For patch #1231336 I chose this approach producing sys.argvu and os.environu. -1 - this is what Microsoft did for many of their APIs. The result is two parallel universes with two sets of features, bugs, documentation, etc. For os.listdir the current behaviour of returning unicode when its argument is unicode can be retained but that is not extensible to, for example, sys.argv. I don't think that using the parameter type as parameter to function is a good idea. However, accepting both strings and Unicode will make it easier to maintain backwards compatibility. Since this issue may affect many attributes a common approach should be chosen. Indeed. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 11 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! -- --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/archive%40mail-archive.com
Re: [Python-Dev] Possible context managers in stdlib
On 7/8/05, James Y Knight [EMAIL PROTECTED] wrote: It is a really bad idea to codify the practice of modifying non- threadlocal global state like sys.std[in|out|err] and current directory with a context manager. A user can do it to themselves now, true, but by putting a context manager for it in the stdlib, you make it look like it'd be a local modification when it is not. I can only see confusion resulting from this. Users will inevitably try to use it like with sys.redirected_stderr(f): Which is of course a bug -- print doesn't go to stderr. Not sure if you meant this as an illustration of a typical bug or whether you meant sys.redirect_stdout(f). print hello print there instead of explicitly writing to f with print or write(). And that is just a terribly bad idea. It looks pretty, yes, but unless stdinouterr are made thread-local, it's just asking for trouble. Boy, do you have Java (or multi-threading) on your mind. A lot of Python programs are single-threaded, and this idiom has been promoted by examples for many years; I see nothing wrong with it in single-threaded code. I sure hope the world doesn't evolve to one where most programs have to be multi-threaded to be useful! Multi-threading is such a nightmare to program that we should really look for paradigms that hide it completely rather than trying to raise programmers who will write correct multi-threaded programs naturally; the latter just ain't gonna happen. A major use case for this, BTW, is to take *existing* Python code that was written using print statements and wrap it in something that captures its output. The f.write() or printf solutions won't work there... -- --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/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFEfor review)
QOTF candidate; should add that the default encoding is usually ASCII. On 7/12/05, Michael Chermside [EMAIL PROTECTED] wrote: M A Lemburg writes: we should use strings and Unicode like they are supposed to be used (in the context of text data): * strings are fine for text data that is encoded using the default encoding * Unicode should be used for all text data that is not or cannot be encoded in the default encoding Later on in Py3k, all text data should be stored in Unicode and all binary data in some new binary type. Wow. That is the most succinct and clear explanation of how to use unicode in Python that I think I've ever heard. It might even be simple enough for _me_ to understand it! I think I'm going to go frame this and have it posted in my cubical. -- Michael Chermside ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Linux Python linking with G++?
Nobody uses it. It should be ripped out. If someone disagrees, let them speak up. On 7/12/05, Michael Hudson [EMAIL PROTECTED] wrote: Tim Peters [EMAIL PROTECTED] writes: [Michael Hudson] --with-fpectl, for example. Does anyone lurking here actually use that, know what it does and require the functionality? Inquiring minds want to know. I know what it intends to do: Surprise! fpectlmodule.c intends to enable the HW FPU divide-by-0, overflow, and invalid operation traps; if any of those traps trigger, raise the C-level SIGFPE signal; and convert SIGFPE to a Python-level FloatingPointError exception. The comments in pyfpe.h explain this best. But do you use it? I know what it intends to do too, but I don't use it. The questions I asked were in the order they were for a reason. Cheers, mwh -- cube If you are anal, and you love to be right all the time, C++ gives you a multitude of mostly untimportant details to fret about so you can feel good about yourself for getting them right, while missing the big picture entirely -- from Twisted.Quotes ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Possible context managers in stdlib
FWIW, I've updated PEP 343 to use @contextmanager and class ContextWrapper. Please proofread. -- --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/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
On 7/15/05, Ron Adam [EMAIL PROTECTED] wrote: [several new syntax proposals] Please stop proposing new syntax. The PEP was accepted after quite enough back-and-forth; there's no point opening this up yet again. -- --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/archive%40mail-archive.com
Re: [Python-Dev] builtin filter function
On 7/19/05, Ruslan Spivak [EMAIL PROTECTED] wrote: I was reading source code for bltinmodule.c and found probably erroneus stuff in filter function. I'm newbie to python inners and don't know if attached code is worth for a patch submission. I would appreciate if someone could take a look at it and if it's ok then i'll make submission, otherwise just drop it. As was already said, thanks for your contribution! I noticed in your patch that you also did whitespace normalization of the file before diffing it. This is generally not a good idea -- it distracts the reader of the patch from the actual bug the patch is fixing. In your case, 4 out of 6 patch chunks were spurious. We do like to keep our whitespace normalized, but as a rule we only do this in patches that don't make otherwise significant changes, so that the semantic changes are separate from the cleanups. That's a minor nit, however -- thanks for finding the memory leak! -- --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/archive%40mail-archive.com
Re: [Python-Dev] python-dev summary for 2005-07-01 to 2005-07-15 [draft]
On 7/27/05, Steven Bethard [EMAIL PROTECTED] wrote: Here's the draft for the first half of July. Thanks! This is looking great! (Although I can't help you with the GCC/C++ thread -- I've been avoiding that one like the plague myself. :-) To all the contributors, great job guys! -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
On 7/28/05, Martin v. Löwis [EMAIL PROTECTED] wrote: I'd like to see the Python source be stored in Subversion instead of CVS, and on python.org instead of sf.net. To facilitate discussion, I have drafted a PEP describing the rationale for doing so, and the technical procedure to be performed. In principle I'm +1 on this (both aspects). I don't know enough to understand all the subtleties. I hope we're correctly estimating the effort required to manage the server and the users. Managing users is especially important -- if a user is compromised (as has happened in the past for python.org users) the whole repository is compromised. Now this could happen to SF users too, but I'm not sure that we know all the tricks in the book to prevent attacks; SF has been doing this for years and that's an aspect of SF that I trust (I think I've heard that they have even modified their SSH server to be stricter). -- --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/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/29/05, Brett Cannon [EMAIL PROTECTED] 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 . Thanks for getting this ball rolling! (I wonder what happened to Ping's PEP 344 -- he just dropped out, it seems.) Below is some feedback. 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. I appreciate the attempt to make bare except: less dangerous by not catching certain exceptions, but I worry that these changes might actually make bare except: *more* likely to be used, which is contrary to the intention. Maybe we should just get rid of it, and encourage people to write except Exception: or except Raisable: depending on what they want. MacError UnixError Do we really need these? Let's not add things that won't be used. NamespaceException To provide a common superclass for exceptions dealing with namespace issues, this exception is introduced. Both UnboundLocalError and UnboundGlobalError (the new name for NameError) inherit from this class. OTOH there's something to say to unify NameError and AttributeError, isn't there? EnvironmentError Originally meant as an exception for when an event outside of the interpreter needed to raise an exception, its use has been deemed unneeded. While both IOError and OSError inherited this class, the distinction between OS and I/O is significant enough to not warrant having a common subclass that one might base an ``except`` clause on. -1000. Depending on whether you use open() or os.open() you'll get one or the other for pretty much the same thing. Also, I think that socket.error and select.error should inherit from EnvironmentError (or maybe even from OSError). 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. -0.5. I use it all the time as the application exception in apps (scripts) that are too small to define their own exception hierarchy. StopIteration and GeneratorExit Inherit from ControlFlowException. Collecting all control flow-related exceptions under a common superclass continues with the theme of maintaining a hierarchy. Yes, but how useful it this? I don't expect to ever come across a situation where I'd want to catch both, so this is more for organization of the docs than for anything else. IMO a good principle for determining the ideal exception hierarchy is whether there's a use case for catching the common base class. IOError No longer subclasses EnvironmentError. -1000, see above. 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]_. Then we'll make it a word. Is Java's equivalent, Throwable, any more a word? In this case I like the parallel with Java. Should Bare ``except`` Clauses be Removed? Yes, see above. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
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/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
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. 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 of EIBTI? Seems a weak argument; we have defaults for lots of things. - 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. I may have missed the change. - Rename ControlFlowException to ControlFlowRaisable (anything except Error or Exception). No objection from me. I actually find it ugly; but it's not an error and it would be weird if there was an xxxException that didn't derive from Exception. - 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. What do you think? Of course the critical and control flow ones should *not* inherit from it. [...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. - 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. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Exception Reorg PEP checked in
In general the PEP looks really good now! On 8/4/05, Willem Broekema [EMAIL PROTECTED] wrote: On 8/4/05, Brett Cannon [EMAIL PROTECTED] wrote: 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. Currently, when the recursion limit is reached, a RuntimeError is raised. RuntimeError is in the PEP renamed to UserError. UserError is in the new hierarchy located below StandardError, below Exception. I think that in the new hierarchy this error should be in the same critical category as MemoryError. (MemoryError includes general stack overflow.) No. Usually, a recursion error is a simple bug in the code, no different from a TypeError or NameError etc. 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.) -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
One more thing. Is renaming NameError to NamespaceError really worth it? I'd say that NameError is just as clear. -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 348: Exception Reorganization for Python 3.0
On 8/5/05, Phillip J. Eby [EMAIL PROTECTED] wrote: While I agree with most of your -1's on gratuitous changes, this particular problem isn't gratuitous. A StopIteration that reaches a regular exception handler is a programming error; allowing StopIteration and other control-flow exceptions to be caught other than explicitly *masks* programming errors. And your point is? If that was the reasoning behind this PEP, it should move TypeError, NameError, AttributeError and a whole bunch of others (even LookupError) out of the StandardError hierarchy too! Those are all clear symptoms of programming errors and are frequently masked by bare 'except:'. The point is not to avoid bare 'except:' from hiding programming errors. There's no hope to obtain that goal. The point is to make *legitimate* uses of bare 'except:' easier -- the typical use case is an application that has some kind of main loop which uses bare 'except:' to catch gross programming errors in other parts of the app, or in code received from an imperfect source (like an end-user script) and recovers by logging the error and continuing. (I was going to say or clean up and exit, but that use case is handled by 'finally:'.) Those legitimate uses often need to make a special case of Keyboardinterrupt and SystemExit -- KeyboardInterrupt because it's not a bug in the code but a request from the user who is *running* the app (and the appropriate default response is to exit with a stack trace); SystemExit because it's not a bug but a deliberate attempt to exit the program -- logging an error would be a mistake. I think the use cases for moving other exceptions out of the way are weak; MemoryError and SystemError are exceedingly rare and I've never felt the need to exclude them; when GeneratorExit or StopIteration reach the outer level of an app, it's a bug like all the others that bare 'except:' WANTS to catch. -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 8: exception style
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.
--
--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/archive%40mail-archive.com
Re: [Python-Dev] Generalised String Coercion
[Removed python-list CC] On 8/6/05, Terry Reedy [EMAIL PROTECTED] wrote: PEP: 349 Title: Generalised String Coercion ... Rationale Python has had a Unicode string type for some time now but use of it is not yet widespread. There is a large amount of Python code that assumes that string data is represented as str instances. The long term plan for Python is to phase out the str type and use unicode for all string data. This PEP strikes me as premature, as putting the toy wagon before the horse, since it is premised on a major change to Python, possibly the most disruptive and controversial ever, being a done deal. However there is, as far as I could find no PEP on Making Strings be Unicode, let alone a discussed, debated, and finalized PEP on the subject. True. OTOH, Jython and IreonPython already have this, and it is my definite plan to make all strings Unicode in Python 3000. The rest (such as a bytes datatype) is details, as they say. :-) My first response to the PEP, however, is that instead of a new built-in function, I'd rather relax the requirement that str() return an 8-bit string -- after all, int() is allowed to return a long, so why couldn't str() be allowed to return a Unicode string? The main problem for a smooth Unicode transition remains I/O, in my opinion; I'd like to see a PEP describing a way to attach an encoding to text files, and a way to decide on a default encoding for stdin, stdout, stderr. -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 8: exception style
How do you then supply a traceback to the raise statement? raise ValueError, ValueError(blah), tb Maybe in Py3K this could become raise ValueError(bloop), tb -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 8: exception style
Maybe in Py3K this could become raise ValueError(bloop), tb The instantiation and bindings need to be done in one step without mixing two syntaxes. Treat this case the same as everything else: raise ValueError(blip, traceback=tb) That requires PEP 344. I have some vague feeling that the way we build up the traceback by linking backwards, this may not necessarily work right. I guess somebody has to try to implement PEP 344 in order to find out. (In fact, I think trying to implement PEP 344 would be an *excellent* way to validate it.) -- --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/archive%40mail-archive.com
Re: [Python-Dev] Generalised String Coercion
[me] a way to decide on a default encoding for stdin, stdout, stderr. [Martin] If stdin, stdout and stderr go to a terminal, there already is a default encoding (actually, there always is a default encoding on these, as it falls back to the system encoding if its not a terminal, or if the terminal's encoding is not supported or cannot be determined). So there is. Wow! I never kew this. How does it work? Can we use this for writing to files to? -- --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/archive%40mail-archive.com
Re: [Python-Dev] Generalised String Coercion
[Guido]
My first response to the PEP, however, is that instead of a new
built-in function, I'd rather relax the requirement that str() return
an 8-bit string -- after all, int() is allowed to return a long, so
why couldn't str() be allowed to return a Unicode string?
[MAL]
The problem here is that strings and Unicode are used in different
ways, whereas integers and longs are very similar. Strings are used
for both arbitrary data and text data, Unicode can only be used
for text data.
Yes, that is the case in Python 2.x. In Python 3.x, I'd like to use a
separate bytes array type for non-text and for encoded text data,
just like Java; strings should always be considered text data.
We might be able to get there halfway in Python 2.x: we could
introduce the bytes type now, and provide separate APIs to read and
write them. (In fact, the array module and the f.readinto() method
make this possible today, but it's too klunky so nobody uses it.
Perhaps a better API would be a new file-open mode (B?) to indicate
that a file's read* operations should return bytes instead of strings.
The bytes type could just be a very thin wrapper around array('b').
The new text() built-in would help make a clear distinction
between convert this object to a string of bytes and
please convert this to a text representation. We need to
start making the separation somewhere and I think this is
a good non-invasive start.
I agree with the latter, but I would prefer that any new APIs we use
use a 'bytes' data type to represent non-text data, rather than having
two different sets of APIs to differentiate between the use of 8-bit
strings as text vs. data -- while we *currently* use 8-bit strings for
both text and data, in Python 3.0 we won't, so then the interim APIs
would have to change again. I'd rather intrduce a new data type and
new APIs that work with it.
Furthermore, the text() built-in could be used to only
allow 8-bit strings with ASCII content to pass through
and require that all non-ASCII content be returned as
Unicode.
We wouldn't be able to enforce this in str().
I'm +1 on adding text().
I'm still -1.
I would also like to suggest a new formatting marker '%t'
to have the same semantics as text() - instead of changing
the semantics of %s as the Neil suggests in the PEP. Again,
the reason is to make the difference between text and
arbitrary data explicit and visible in the code.
Hm. What would be the use case for using %s with binary, non-text data?
The main problem for a smooth Unicode transition remains I/O, in my
opinion; I'd like to see a PEP describing a way to attach an encoding
to text files, and a way to decide on a default encoding for stdin,
stdout, stderr.
Hmm, not sure why you need PEPs for this:
I'd forgotten how far we've come. I'm still unsure how the default
encoding on stdin/stdout works.
But it still needs to be simpler; IMO the built-in open() function
should have an encoding keyword. (But it could return something whose
type is not 'file' -- once again making a distinction between open and
file.) Do these files support universal newlines? IMO they should.
--
--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/archive%40mail-archive.com
Re: [Python-Dev] PyTuple_Pack added references undocumented
On 8/7/05, Edward C. Jones [EMAIL PROTECTED] wrote: According to the source code, PyTuple_Pack returns a new reference (it calls PyTuple_New). It also Py_INCREF's all the objects in the new tuple. Is this unusual behavior? None of these added references are documented in the API Reference Manual. This seems the only sensible behavior given what it does. I think the INCREFs don't need to be documented because you don't have to worry about them -- they follow the normal pattern of reference counts: if you owned an object before passing it to PyTuple_Pack(), you still own it afterwards. The docs say that it returns a new object, so that's in order too. It's not listed in refcounts.dat; that seems an omission (or perhaps the function's varargs signature doesn't fit in the pattern?). -- --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/archive%40mail-archive.com
Re: [Python-Dev] Generalised String Coercion
Ouch. Too much discussion to respond to it all. Please remember that in Jythin and IronPython, str and unicode are already synonyms. That's how Python 3.0 will do it, except unicode will disappear as being redundant. I like the bytes/frozenbytes pair idea. Streams could grow a getpos()/setpos() API pair that can be used for stateful encodings (although it sounds like seek()/tell() would be okay to use in most cases as long as you read in units of whole lines). For sockets, send()/recv() would deal in bytes, and makefile() would get an encoding parameter. I'm not going to change my mind on text() unless someone explains what's so attractive about it. -- --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/archive%40mail-archive.com
Re: [Python-Dev] __traceback__ and reference cycles
On 8/8/05, Armin Rigo [EMAIL PROTECTED] wrote: Attaching a __traceback__ will only make this bug show up more often, as the 'except Exception, e' line in a __del__() method would be enough to trigger it. Hmm... We can blame this on __del__ as much as on __traceback__, of course... But it is definitely of concern. -- --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/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. I'm sympathetic to this one. Care to write a PEP? It could be really short and sweet as long as it provides enough information to implement the feature. -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
On 8/10/05, Fredrik Lundh [EMAIL PROTECTED] wrote: in contrast, Perforce just runs and runs and runs. the clients always do what you tell them. and server maintenance is trivial; just make sure that the server starts when the host computer boots, and if you have enough disk, just leave it running. if you're tight on disk space, trim away some log files now and then. that's it. We've used P4 at Elemental for two years now; I mostly agree with this assessment, although occasionally the server becomes unbearably slow and a sysadmin does some painful magic to rescue it. Maybe that's just because the box is underpowered. More troublesome is that I've seen a few client repositories getting out of sync; one developer spent a lot of time tracking down mysterious compilation errors that went away after forced resync'ing. We never figured out the cause, but (since he swears he didn't touch the affected files) most likely hitting ^C during a previous sync could've broken some things. Another problem with P4 is that local operation is lousy -- if you can't reach the server, you can't do *anything* -- while svn always lets you edit and diff. Also, P4 has *no* command to tell you which files you've created without adding them to the repository yet -- so the most frequent build breakage is caused by missing new files. Finally, while I hear that P4's branching support is superior over SVN's, I find it has a steep learning curve -- almost every developer needs some serious hand-holding before they understand P4 branches correctly. I'm intrigued by Linus Torvald's preference for extremely distributed source control, but I have no experience and it seems a bit, um, experimental. Someone should contact Steve Alexander, who I believe is excited about Bazaar-NG. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Exception Reorg PEP revised yet again
On 8/11/05, James Y Knight [EMAIL PROTECTED] wrote: If that's true, this is hardly worth discussing as 3.0 is never going to happen anyways. You are wrong. So wrong. -- --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/archive%40mail-archive.com
Re: [Python-Dev] xml.parsers.expat no userdata in callback functions
Kristian Benoit wrote: This means one cant parse multiple files at the same time using the same handlers. You cant pass the context current context to the handler, you must base your code on global variables which is not so nice. Martin v. Löwis replied: This is not true. You can create multiple parsers, and then can make the callback functions bound methods, using self to store parse-specific data. There is no need to have extra callback data. What he said. Kristian's complaint is probably a common misconception about Python -- not too many languages have unified the concepts of bound methods and callables so completely as Python. Every callable is in a sense a closure (or can be). Nested functions are other examples. -- --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/archive%40mail-archive.com
[Python-Dev] Fwd: Distributed RCS
With permission, I'm forwarding an email from Mark Shuttleworth about Bazaar-2 (aka Bazaar-NG), a distributed source control system (not entirely unlike bitkeeper, I presume) written in Python and in use by the Ubuntu system. What do people think of using this for Python? Is it the right model? Do we want to encourage widespread experimentation with the Python source code? --Guido van Rossum (home page: http://www.python.org/~guido/) -- Forwarded message -- From: Mark Shuttleworth [EMAIL PROTECTED] Date: Aug 11, 2005 12:13 PM Subject: Distributed RCS To: Guido van Rossum [EMAIL PROTECTED] Cc: Steve Alexander [EMAIL PROTECTED], Martin Pool [EMAIL PROTECTED], Fredrik Lundh [EMAIL PROTECTED] Hi Guido Steve forwarded your mail to me regarding distributed revision control, so I thought I'd follow up with some thoughts on why I agree with Frederick Lundh that it's important, and where we are going with the Bazaar project. First, distributed RCS systems reduce the barrier to participation. Anybody can create their own branches, and begin work on features, with full revision control support, without having to coordinate with the core RCS server sysadmin. So, for example, if someone gets an idea to work on PEP X, they can simply create a branch, and start hacking on it locally, with full RCS functionality like commit and undo, and logs of their changes over time. They can easily merge continually from the trunk, to keep their branch up to date. And they can publish their branch using only a web server. With Bazaar, these branches can be personal or shared group branches. The net effect of this is to make branching a core part of the development process. Each feature gets developed on a branch, and then merged when its ready. Instead of passing patches around in email, you find yourself passing out branch references, which are much easier to deal with since they are always up to date. In Launchpad, we have evolved to work around this branch-per-feature approach, and built a review process so that each branch gets a review before the code is merged to the trunk. It also has a positive social impact, because groups that are interested in a feautre can begin to collaborate on it immediately rather than waiting to get consensus from everybody else, they just start their branch and get more testing when it is reaching a reasonable state of maturity - then the project decides whether or not it lands. That results in less argument about whether or not a feature is a good idea before anybody really knows what it's going to look like. Those who are interested, participate, and those who aren't reserve judgement till it's done. As for Bazaar, we have just wrapped up our latest sprint, where we decided that bazaar-ng (bzr), which is being written in Python by Martin Pool, will become Bazaar 2.x, in the first quarter of 2006. The current 1.x line of development has served us well, but the ideas we developed and which have been implemented as a working bazaar-ng reference by Martin are now proven enough that I'm committing the project (Ubuntu, and all of Launchpad) to it. Martin will continue to work on it full time, and will be joined by the current Bazaar 1.x team, Robert Collins, David Allouche and James Blackwell. That makes for a substantial chunk of resources but I think it's worth it because we need a truly superb free revision control system when dealing with something as large and complex as an entire distribution. The whole of Ubuntu will be in Bazaar in due course. Currently, we have about 500 upstreams published in the Bazaar 1.x format (see http://bazaar.ubuntu.com/ for the list), all of those will be converted to Bazaar 2.x and in addition we will continue to publish more and more upstreams in the 2.x archive format. We actively convert CVS and SVN upstreams and publish them in the Bazaar format to allow us to use a single, distributed revision control system across all of those packages. So there's a lot of real-world data and real-world coding going on with Bazaar as the RCS holding it all together. Perhaps more importantly, we are integrating Bazaar tightly with the other Launchpad applications, Rosetta and Malone. This means that bug tracking and translation will be branch aware. You will be able to close a bug by noting that a commit in one of your branches fixes the bug, then merging it into the relevant mainline branch, and have the launchpad bug tracker automatically mark the bug as closed, if you wish. Similarly you will be able to get the latest translations just by merging from the branch published by Rosetta that has the latest translations in it for your application. The combination of distributed revision control, and ultimately integrated bug tracking and translations, will I think be a very efficient platform for collaborative development. Bazaar is free, and the use of Launchpad is free though we have not yet released the code to the web services for bug tracking
[Python-Dev] Fwd: Distributed RCS
Another fwd, describing how Steve Alexander's group user bazaar. --Guido van Rossum (home page: http://www.python.org/~guido/) -- Forwarded message -- From: Steve Alexander [EMAIL PROTECTED] Date: Aug 12, 2005 4:00 PM Subject: Re: Distributed RCS To: Guido van Rossum [EMAIL PROTECTED] Cc: Mark Shuttleworth [EMAIL PROTECTED], Martin Pool [EMAIL PROTECTED], Fredrik Lundh [EMAIL PROTECTED] Hi Guido, I'm not going to post to python-dev just now, because I'm leaving on 1.5 weeks vacation tomorrow, and I'd rather be absent than unable to answer questions promptly. Martin Pool will be around next week, and will be able to take part in discussions on the list. Feel free to post all or part of Mark's or my emails to the python lists. Mark wrote: I hope that puts bazaar into perspective for you. Give it a spin - the development 2.x codebase is robust enough now to handle a line of development and do basic merging, we are switching our own development to the pre-release 2.x line in October, and we will switch over all the public archives we maintain in around March next year. A large part of the internal development at Canonical is the Launchpad system. This is about 30-40 kloc of Python code, including various Twisted services, cron scripts, a Zope 3 web application, database tools, ... It's being worked on by 20 software developers. Everyone uses bazaar 1.4 or 1.5, and around October, we'll be switching to use bazaar 2.x. I'll describe how we work on Launchpad using Bazaar. This is all from the Bazaar 1.x perspective, and some things will become simpler when we change to using Bazaar 2.x. I've left the description quite long, as I hope it will give you some of the flavour of working with a distributed RCS. == Two modes of working: shared branches and PQM == Bazaar supports two different modes of working for a group like the Launchpad team. 1. There's a shared read/write place that all the developers have access to. This is contains the branches we release from, and represents the trunk of the codebase. 2. A virtual person called the patch queue manager (PQM) has exclusive write access to a collection of branches. PQM takes instructions as GPG signed emails from launchpad developers, to merge their code into PQM's branches. We use the latter mode because we have PQM configured not only to accept requests to merge code into PQM's codebase, but to run all the tests first and refuse to merge if any test fails. == The typical flow of work on Launchpad == Say I want to work on some new feature for Launchpad. What do I do? 1. I use 'baz switch' to change my working tree from whatever I was working on last, and make it become PQM's latest code. baz switch [EMAIL PROTECTED]/launchpad--devel--0 rocketfuel is the code-name for the branches we release our code from. PQM manages the rocketfuel branches. In Bazaar 1.x, collections of branches are called archives and are identified by an email address plus some other optional information. So, [EMAIL PROTECTED] is PQM's email address. launchpad--devel--0 is simply the name of the main launchpad branch. The format of branch names is very strict in Bazaar 1.x. It is much more open in Bazaar 2.x. 2. I use 'baz branch' to create my own branch of this code that I can commit changes to. baz branch [EMAIL PROTECTED]/launchpad--ImproveLogins--0 My archive is called [EMAIL PROTECTED]. The branch will be used to work on the login functionality of Launchpad, so I have named the branch launchpad--ImproveLogins--0. 3. I hack on the code, and from time to time commit my changes. I need to 'baz add' new files and directories, and 'baz rm' to remove files, and 'baz mv' to move files around. # hack hack hack baz commit -s Refactored the whatever.py module. # hack hack hack baz del whatever_deprecated.py baz commit -s Removed deprecated whatevers. # hack hack hack 4. Let's say I hacked on some stuff, but I didn't commit it. I don't like what I did, and I want to start again. # hack hack hack baz undo 'baz undo' puts the source code back into the state it was in after the last commit, and puts the changes somewhere. If I change my mind again, I can say 'baz redo', and get my changes back. 5. All this hacking and committing has been happening on my own workstation, without a connection to the internet. Perhaps I've been on a plane or at a cafe. When I have a connection again, I can make my work available for others to see by mirroring my code to a central location. Each Launchpad developer has a mirror of the archive they use for Launchpad work on a central machine at the Canonical data centre. In our case, the mirror command uses sftp to copy the latest changes I have made into the mirror on this central server. baz archive-mirror 6. Because we have a strict code review proccess for Launchpad development, I can't (or rather, shouldn't) submit my changes to PQM yet. I should get
Re: [Python-Dev] Fwd: Distributed RCS
On 8/14/05, Neil Schemenauer [EMAIL PROTECTED] wrote: It looks like the process of converting a CVS repository to Bazaar-NG does not yet work well (to be kind). The path CVS-SVN-bzr would probably work better. I suspect cvs2svn has been used on quite a few CVS repositories already. I don't think going to SVN first would lose any information. My vote is to continue with the migration to SVN. We can re-evaluate Bazaar-NG at a later time. That's looks like a fair assessment -- although it means twice the conversion pain for developers. It sounds as if bazaar-NG can use a bit of its own medicine -- I hope everybody who found a bug in their tools submitted a patch! :-) -- --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/archive%40mail-archive.com
Re: [Python-Dev] Exception Reorg PEP checked in
On 8/14/05, Michael Hudson [EMAIL PROTECTED] wrote: Wilfredo Sánchez Vega [EMAIL PROTECTED] writes: I'm curious about why Python lacks FileNotFoundError, PermissionError and the like as subclasses of IOError. Good question. Lack of effort/inertia? Well, I wonder how often it's needed. My typical use is this: try: f = open(filename) except IOError, err: print Can't open %s: %s % (filename, err) return and the error printed contains all the necessary details (in fact it even repeats the filename, so I could probably just say print err). Why do you need to know the exact reason for the failure? If you simply want to know whether the file exists, I'd use os.path.exists() or isfile(). (Never mind that this is the sometimes-frowned-upon look-before-you-leap; I think it's often fine.) Also note that providing the right detail can be very OS specific. Python doesn't just run on Unix and Windows. -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 348 (exception reorg) revised again
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/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
(1) Please use the SF patch manager. (2) Please don't propose adding more bare except: clauses to the standard library. (3) I think a better patch is to use str(word)[:n] instead of word[:n]. On 8/14/05, Michael Krasnyk [EMAIL PROTECTED] wrote: Hello all, Recently I've found that rlcompleter does not work correctly with SWIG generated classes. In some cases dir(object) containes not only strings, but also type of the object, smth like class 'mywrapper.IClassPtr'. And condition word[:n] == attr throws an exception. Is it possible to solve this problem with following path? --- cut --- --- rlcompleter.py.org 2005-08-14 13:02:02.0 +0200 +++ rlcompleter.py 2005-08-14 13:18:59.0 +0200 @@ -136,8 +136,11 @@ matches = [] n = len(attr) for word in words: -if word[:n] == attr and word != __builtins__: -matches.append(%s.%s % (expr, word)) +try: +if word[:n] == attr and word != __builtins__: +matches.append(%s.%s % (expr, word)) +except: +pass return matches def get_class_members(klass): --- cut --- Thanks in advance, Michael Krasnyk ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 348 (exception reorg) revised again
On 8/15/05, Scott David Daniels [EMAIL PROTECTED] wrote: An argument _for_ TerminatingException as a class is that I can define my own subclasses of TerminatingException without forcing it to being a subclass of KeyboardInterrupt or SystemExit. And how would that help you? Would your own exceptions be more like SystemExit or more like KeyboardInterrupt, or neither? If you mean them to be excluded by base except:, you can always subclass BaseException, which exists for this purpose. -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
Nor this Guido, FWIW (I think we shouldn't rule it out as an option, but I don't have any preferences). On 8/16/05, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote: Tim Peters wrote: [Martin v. Löwis] I would agree. However, there still is the debate of hosting the repository elsehwere. Some people (Anthony, Guido, Tim) would prefer to pay for it, instead of hosting it on svn.python.org. Not this Tim. Not this one either. I haven't actually used any of the various systems that much (work is ClearCase) so I have no opinions whatsoever. It's interesting reading though. Tim Delaney ___ 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/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
On 8/17/05, Timothy Fitz [EMAIL PROTECTED] wrote: On 8/16/05, Raymond Hettinger [EMAIL PROTECTED] wrote: -0 The behavior of dir() already a bit magical. Python is much simpler to comprehend if we have direct relationships like dir() and vars() corresponding as closely as possible to the object's dictionary. If someone injects non-strings into an attribute dictionary, why should dir() hide that fact? Indeed, there seem to be two camps, those who want dir to reflect __dict__ and those who want dir to reflect attributes of an object. It seems to me that those who want dir to reflect __dict__ should just use __dict__ in the first place. Right. However, in the case of dir handling non-strings, should dir handle non-valid identifiers as well, that is to say that while foo.__dict__[2] = ... is an obvious case what about foo.__dict__[1] ? See below. Right now the documentation says that it returns attributes, and I would not consider non-strings to be attributes, so either the documentation or the implementation should rectify this disagreement. I think that dir() should hide non-strings; these aren't attributes if you believe the definition that an attribute name is something acceptable to getattr() or setattr(). Following this definition, the string 1 is a valid attribute name (even though it's not a valid identifier), but the number 1 is not. Try it. :-) -- --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/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
[Timothy Fitz] It seems to me that those who want dir to reflect __dict__ should just use __dict__ in the first place. [Raymond] The dir() builtin does quite a bit more than obj.__dict__.keys(). Well that's the whole point, right? We shouldn't conflate the two. I don't see this as an argument why it would be bad to delete non-string-keys found in __dict__ from dir()'s return value. I don't think that the equation set(x.__dict__) = set(dir(x)) provides enough value to try and keep it. A more useful relationship is name in dir(x) == getattr(x, name) is valid -- --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/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
[me] A more useful relationship is name in dir(x) == getattr(x, name) is valid [Raymond] That would be a useful invariant. Well, the == part can't really be guaranteed due to the existence of __getattr__ overriding (and all bets are off if __getattribute__ is overridden!), but apart from those, stripping non-strings in dir() would be a big help towards making the invariant true. So I'm +1 on that. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Deprecating builtin id (and moving it to sys())
On 8/17/05, Anthony Baxter [EMAIL PROTECTED] wrote: If you _really_ want to call a local variable 'id' you can (but shouldn't). Disagreed. The built-in namespace is searched last for a reason -- the design is such that if you don't care for a particular built-in you don't need to know about it. You also can't/shouldn't call a variable 'class', 'def', or 'len' -- but I don't see any movement to allow these... Please don't propagate the confusion between reserved keywords and built-in names! -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 309: Partial method application
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++. 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. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Deprecating builtin id (and moving it to sys())
On 8/19/05, Jeremy Hylton [EMAIL PROTECTED] wrote: On 8/18/05, Guido van Rossum [EMAIL PROTECTED] wrote: On 8/17/05, Anthony Baxter [EMAIL PROTECTED] wrote: If you _really_ want to call a local variable 'id' you can (but shouldn't). Disagreed. The built-in namespace is searched last for a reason -- the design is such that if you don't care for a particular built-in you don't need to know about it. In practice, it causes much confusion if you ever use a local variable that has the same name as the built-in namespace. If you intend to use id as a variable, it leads to confusing messages when a typo or editing error accidentally removes the definition, because the name will still be defined for you. It also leads to confusion when you later want to use the builtin in the same module or function (or in the debugger). If Python defines the name, I don't want to provide a redefinition. This has startled me a few times, but never for more than 30 seconds. In correct code there sure isn't any confusion. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Deprecating builtin id (and moving it to sys())
On 8/20/05, Anthony Baxter [EMAIL PROTECTED] wrote: On Friday 19 August 2005 02:22, Guido van Rossum wrote: On 8/17/05, Anthony Baxter [EMAIL PROTECTED] wrote: If you _really_ want to call a local variable 'id' you can (but shouldn't). Disagreed. The built-in namespace is searched last for a reason -- the design is such that if you don't care for a particular built-in you don't need to know about it. I'm not sure what you're disagreeing with. Are you saying you _can't_ call a variable 'id', or that it's OK to do this? That it's OK. You also can't/shouldn't call a variable 'class', 'def', or 'len' -- but I don't see any movement to allow these... Please don't propagate the confusion between reserved keywords and built-in names! It's not a matter of 'confusion', more that there are some names you can't or shouldn't use in Python. When coding twisted, often the most obvious 'short' name for a Deferred is 'def', but of course that doesn't work. My point is that there are two reasons for not using such a name. With 'def', you *can't*. With 'len', you *could* (but it would be unwise). With 'id', IMO it's okay. -- --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/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
I'm ready to accept te general idea of moving to subversion and away from SourceForge. On the hosting issue, I'm still neutral -- I expect we'll be able to support the current developer crowd easily on svn.python.org, but if we ever find ther are resource problems (either people or bandwidth etc.) I just received a recommendation for wush.net which specializes in svn hosting. $90/month for 5 Gb of disk space sounds like a good deal and easily within the PSF budget. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Bare except clauses in PEP 348
On 8/23/05, Raymond Hettinger [EMAIL PROTECTED] wrote: The latest version of PEP 348 still proposes that a bare except clause will default to Exception instead of BaseException. Initially, I had thought that might be a good idea but now think it is doomed and needs to be removed from the PEP. If we syntactically enforce that the bare except, if present, must be last, would that remove your objection? I agree that a bare except in the middle is an anomaly, but that doesn't mean we can't keep bare except: as a shorthand for except Exception:. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Bare except clauses in PEP 348
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. -- --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/archive%40mail-archive.com
Re: [Python-Dev] FW: Bare except clauses in PEP 348
On 8/24/05, Raymond Hettinger [EMAIL PROTECTED] wrote: Hey guys, don't give up your bare except clauses so easily. They are an attractive nuisance by being so much shorter to type than the right thing to do. Especially if they default to something whose use cases are rather esoteric (i.e. BaseException). -- --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/archive%40mail-archive.com
Re: [Python-Dev] Bare except clauses in PEP 348
On 8/24/05, Brett Cannon [EMAIL PROTECTED] wrote: Is there any desire for a __future__ statement that makes it a syntax error? How about making 'raise' statements only work with objects that inherit from BaseException? I doubt it. Few people are going to put a __future__ statement in to make sure that *don't* use a particular feature: it's just as easy to grep your source code for except:. __future__ is in general only used to enable new syntax that previously has a different meaning. Anyway, you can make it an error globally by using the -W option creatively. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Bare except clauses in PEP 348
On 8/24/05, James Y Knight [EMAIL PROTECTED] wrote: On Aug 24, 2005, at 9:39 PM, Brett Cannon wrote: On 8/24/05, Guido van Rossum [EMAIL PROTECTED] wrote: On 8/24/05, James Y Knight [EMAIL PROTECTED] wrote: I think it must be the case that raising an object which does not 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. Yes, it talks about that as a change that will happen in Python 3.0. I was responding to OK, I'm convinced. Let's drop bare except for Python 3.0, and deprecate them until then, without changing the meaning. which is talking about deprecating bare excepts in Python 2.5. Now maybe it's the idea that everything that's slated for removal in Python 3.0 by PEP 348 is supposed to be getting a deprecation warning in Python 2.5, but that certainly isn't stated. The transition plan section says that all that will happen in Python 2.5 is the addition of BaseException. Then maybe the PEP isn't perfect just yet. :-) It's never too early to start deprecating a feature we know will disappear in 3.0. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Bare except clauses in PEP 348
On 8/25/05, Raymond Hettinger [EMAIL PROTECTED] wrote: It's only an overstatement if Guido didn't mean what he said. If bare except clauses are deprecated in 2.x, it WILL affect tons of existing code and invalidate a portion of almost all Python books. Deprecation means your code will still work I hope every book that documents except: also adds but don't use this except under very special circumstances. I think you're overreacting (again), Raymond. 3.0 will be much more successful if we can introduce many of its features into 2.x. Many of those features are in fact improvements of the language even if they break old code. We're trying to balance between breaking old code and introducing new features; deprecation is the accepted way to do this. Regarding the complaint that Python is changing too fast, that really sounds like FUD to me. With a new release every 18 months Python is about as stable as it gets barring dead languages. The PHP is in the throws of the 4-5 conversion which breaks worse than Python 2-3 will (Rasmus ia changing object assignment semantics from copying to sharing). Maybe they should be warned not to learn Perl because Larry is deconstructing it all for Perl 6? :-) -- --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/archive%40mail-archive.com
Re: [Python-Dev] Style for raising exceptions (python-dev Summary for 2005-08-01 through 2005-08-15 [draft])
On 8/25/05, M.-A. Lemburg [EMAIL PROTECTED] wrote: I must have missed this one: Style for raising exceptions Guido explained that these days exceptions should always be raised as:: raise SomeException(some argument) instead of:: raise SomeException, some argument The second will go away in Python 3.0, and is only present now for backwards compatibility. (It was necessary when strings could be exceptions, in order to pass both the exception type and message.) PEPs 8_ and 3000_ were accordingly updated. AFAIR, the second form was also meant to be able to defer the instantiation of the exception class until really needed in order to reduce the overhead related to raising exceptions in Python. However, that optimization never made it into the implementation, I guess. Something equivalent is used internally in the C code, but that doesn't mean we'll need it in Python code. The optimization only works if the exception is also *caught* in C code, BTW (it is instantiated as soon as it is handled by a Python except clause). Originally, the second syntax was the only available syntax, because all we had were string exceptions. Now that string exceptions are dead (although not yet buried :) I really don't see why we need to keep both versions of the syntax; Python 3.0 will only have one version. (We're still debating what to do with the traceback argument; wanna revive PEP 344?) If you need to raise exceptions fast, pre-instantiate an instance. -- --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/archive%40mail-archive.com
