Re: [Python-Dev] PEP 3003 - Python Language Moratorium
On Sun, Nov 8, 2009 at 1:16 AM, Steven D'Aprano st...@pearwood.info wrote: Willem, the rationale for this PEP is to give alternative implementations the chance to catch up with CPython. Given your statement that CLPython is quite complete on the language level, but missing standard library features, how do you think the moratorium will help CLPython? It would be great to have a pause in Python-the-language, so that CLPython might at the end of the moratorium finally be up to date with the latest 2.x and 3.x features. Supporting standard libraries is a bigger challenge, as the ones written in C need rewriting. Whether or not there is a pause on that front does not matter too much to that situation. - Willem ___ 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 3003 - Python Language Moratorium
On Fri, Nov 6, 2009 at 6:18 AM, Steven D'Aprano st...@pearwood.info wrote: I don't know how mature or active it is, so it may not count as either major or complete, but there's also CLPython: http://common-lisp.net/project/clpython/ CLPython is in steady development, quite complete and stable on the language level (somewhere between 2.5 and 2.6), but missing most built-in library functionality. (It reuses the pure-Python parts of the stdlib.) As its developer, I don't care much about being mentioned in discussions or presentations, as CLPython is not as widely used as IronPython and Jython. But in a PEP like this, which is directly about alternative implementations, it deserves to be mentioned, IMHO. - Willem ___ 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 about sys.implementation and implementation specific user site directory
On Sat, Oct 10, 2009 at 1:29 AM, Christian Heimes li...@cheimes.de wrote: I'm proposing two new attributes in the sys module: sys.implementation and sys.userdirsuffix. This seems like a good idea. I'm not sure this idea will easily be accepted, but I'd like to see the sys module eventually split up in two parts, so it is very obvious to both implementers and users which system-specific features are portable and which are not: a) implementation details of the C implementation (subversion, _*, dllhandle, dont_write_bytecode, settscdump, ..) in one module, b) portable functionality (interpreter name and version etc, builtin_module_names, copyright, excepthook, settrace, ..) in the other - Willem (CLPython) ___ 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] operator precedence of __eq__, __ne__, etc, if both object have implementations
On Tue, Sep 22, 2009 at 5:12 PM, Mark Dickinson dicki...@gmail.com wrote: - Exception to the previous item: if the left operand is an instance of a built-in type or a new-style class, and the right operand is an instance of a proper subclass of that type or class AND overrides the base’s __rop__() method, the right operand’s __rop__() method is tried before the left operand’s __op__() method. The AND above (which I uppercased) is subtle but important. In the x op y case with y being of a subclass of the class of x, if there is no class in between x and y (excluding x, including y) that overrides the __rop__ method, then y,__rop__(x) is *not* tried before x.__op__(y). It's easy for other implementations to get this wrong. :) - Willem ___ 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] Avoiding file descriptors leakage in subprocess.Popen()
On Tue, Jun 16, 2009 at 1:21 PM, Michael Foordfuzzy...@voidspace.org.uk wrote: Steven D'Aprano wrote: On Tue, 16 Jun 2009 01:20:53 pm Cameron Simpson wrote: I don't think all pythons do immediate ref-counted GC. Jython and IronPython don't. I don't know about PyPy, CLPython, Unladen Swallow, etc. PyPy doesn't, Unladen Swallow won't. Also most Lisp implementations, thus CLPython, use a tracing GC. - Willem ___ 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] yield * (Re: Missing operator.call)
On Sat, Feb 7, 2009 at 10:04 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: def f(): v = yield *g() print v def g(): yield 42 return spam Function g violates the current limitation that generators can't return with a value. So can g only be used using yield * then, or would that limitation be removed? - Willem ___ 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] effect of exec on local scope
The issue came up while trying to get some Sympy code running on CLPython.
class C:
exec a = 3
print locals()
1. Is it guaranteed that class C gets an attribute a, i.e. that the
locals printed include {'a': 3}?
2. It it (also) guaranteed if it were in a function scope?
The complete syntax of exec is:
exec CODE in Y, Z
where Y, Z are optional.
The documentation of exec says if the optional parts are
omitted,the code is executed in the current scope. There are at least
two different interpretations:
a. The code is executed in the current class scope, so the assignment
must have an effect on the class scope.
b. The scope defaults to the local scope, by which is meant the
mapping returned by locals(), and of locals() the documentation says
that changes made to it may not influence the interpreter. (The
documentation of exec suggests using globals() and locals() as
arguments to exec, which seems hint at this interpretation.)
The relevant documentation:
exec:
http://docs.python.org/reference/simple_stmts.html#grammar-token-exec_stmt
locals: http://docs.python.org/library/functions.html#locals
- Willem
___
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] bug or a feature?
On Thu, Jun 12, 2008 at 2:56 PM, Carl Friedrich Bolz [EMAIL PROTECTED] wrote: Of course attribute name lookups are affected, because you can have a non-string key that has a __hash__ and __eq__ method to make it look sufficiently like a string to the dict. Then the attribute lookup needs to take these into account. This makes a method cache implementation much more complex, because suddenly arbitrary user code can run during the lookup and your classes (and thus your method caches) can change under your feed during the lookup. In this situation getting the corner cases right is very hard. I fully agree with this assessment: the theoretical possibilities make attribute handling very hairy. Note that besides non-strings, also user-defined subclasses of string can have their own hash/eq logic. If namespace keys and attributes could be locked down to only be regular strings, not of another type and not a string subclass instance, then implementing attributes becomes a lot less hairy, and optimizations much more straightforward. - Willem (CLPython) ___ 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] bug or a feature?
On Thu, Jun 12, 2008 at 9:46 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
The intention was for these dicts to be used as namespaces. I think of
it as follows:
(a) Using non-string keys is a no-no, but the implementation isn't
required to go out of its way to forbid it.
That will allow easier and more efficient implementation, good!
(b) Using non-empty string keys that aren't well-formed identifiers
should be allowed.
ok.
Is it allowed to normalize subclasses of strings to regular string,
e.g. after:
class mystring(str): pass
class C: pass
x = C()
setattr(x, mystring('foo'), 42)
is it allowed that the dict of x contains a regular string 'foo'
instead of the mystring instance?
- Willem
___
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] Problem with super() usage
On 7/18/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: C++ originally specified multiple inheritance, but it wasn't cooperative in the sense that super is. In Lisp, though, where cooperative method dispatch originated, call-next-method does basically the same thing in the case where there's no next method: it calls no-next-method which signals a generic error. Don't forget Lisp's next-method-p, which tests (-p for predicate) if there is any next method to call. Highly elegant, I'd say. http://www.lisp.org/HyperSpec/Body/locfun_call-next-method.html http://www.lisp.org/HyperSpec/Body/locfun_next-method-p.html - Willem ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception Reorg PEP checked in
On 8/4/05, 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.) - Willem ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 8/2/05, Stephen J. Turnbull [EMAIL PROTECTED] wrote: I don't see it that way. Rather, Raisable is the closest equivalent to serious-condition, and CriticalException is an intermediate class that has no counterpart in Lisp usage. That would imply that all raisables are 'serious' in the Lisp sense, which is defined as all conditions serious enough to require interactive intervention if not handled. Yet Python warnings are raisable (as raisable is the root), but are certainly not serious in the Lisp sense. (This is complicated by that warnings are raised using 'signal'. More below.) Willem: I'd prefer the 'condition' and 'error' terminology, and to label a keyboard interrupt a condition, not any kind of exception or error. To clarify myself: a 'serious-condition' in CL stands for all conditions serious enough to require interactive intervention if not handled; I meant to label KI a 'serious-condition'. Stephen: Now, that does bother me.wink Anything we will not permit a program to ignore with a bare except: pass if it so chooses had better be more serious than merely a condition. Also, to me a condition is something that I poll for, it does not interrupt me. To me, a condition (even a serious one) is precisely the kind of thing that I should be able to ignore with a bare except! If I understand your position correctly, it is probably not changed yet by the above clarification. wink Maybe it will surprise you, that in Lisp a bare except (ignore-errors) does not catch non-serious things like warnings. And if left uncatched, a warning leaks out to the top level, gets printed and subsequently ignored. That's because non-serious conditions are (usually) raised using 'signal', not 'error'. The default top-level warnings handler just prints it, but does not influence the program control flow, so the execution resumes just after the (warn ..) form. This probably marks a very important difference between Python and CL. I think one could say that where in Python one would use a bare except to catch both non-serious and serious exceptions, in CL one normally doesn't bother with catching the non-serious ones because they will not create havoc at an outer level anyway. So in Python a warning must be catched by a bare except, while in Lisp it would not. And from this follow different contraints on the hierarchy. By the way, this is the condition hierarchy in Allegro CL (most of which is prescribed by the ANSI standard): http://www.franz.com/support/documentation/7.0/doc/errors.htm - Willem ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/31/05, Brett Cannon [EMAIL PROTECTED] wrote: On 7/31/05, Willem Broekema [EMAIL PROTECTED] wrote: I does not seem right to me to think of KeyboardInterrupt as a means to cause program halting. An interpreter could in principle recover from it and resume execution of the program. Same goes for MemoryError as well, but you probably don't want to catch that exception either. Well, an possible scenario is that if allocation of memory fails, then the interpreter (not the Python program in it) can detect that it is not caught explicitly and print possible ways of execution, like try the allocation again or abort the program, letting the user determine how to proceed. Although in this case immediately retrying the allocation will fail again, so the user has to have a way to free some objects in the meantime. I realize it's major work to add recovery features to the CPython interpreter, so I don't think CPython will have anything like it soon and therefore also Python-the-language will not. Instead, my reason for mentioning this is to get the _concept_ of recoveries across. I think including (hypothetical, for now) recovery features in a discussion about exceptions is valuable, because that influences whether one thinks a label like critical for an exception is appropriate. I'm working on an implementation of Python in Common Lisp. The CL condition system offers recovery features, so this implementation could, too. Instead of the interpreter handling the interrupt in an application-specific way, as Fred said, the interpreter could handle the interrupt by leaving the choice to the user. Concretely, this is how KeyboardInterrupt is handled by a CL interpreter, and thus also how a Python interpreter could handle it: (defun foo () (loop for i from 0 do (format t ~A i))) (foo) = 0 1 2 3 CTRL-C Error: Received signal number 2 (Keyboard interrupt) [condition type: INTERRUPT-SIGNAL] Restart actions (select using :continue): 0: continue computation 1: Return to Top Level (an abort restart). 2: Abort entirely from this process. :continue 0 = 4 5 6 ... But it doesn't sound like you are arguing against putting KeyboardInterrupt under CriticalException, but just the explanation I gave, right? I hope the above makes the way I'm thinking more clear. Like Phillip J. Eby, I think that labeling KeyboardInterrupt a CriticalException seems wrong; it is not an error and not critical. - Willem ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 8/1/05, Stephen J. Turnbull [EMAIL PROTECTED] wrote:
Uh, according to your example in Common LISP it is indeed an error,
I think you are referring to the first word of this line:
Error: Received signal number 2 (Keyboard interrupt) [condition type:
INTERRUPT-SIGNAL]
Well, that refers to the fact that it was raised with (error ...). It
says nothing about the type of a Keyboad interrupt condition. (The
function 'error' vs 'signal' mark the distinction between raising
conditions that must be handled otherwise you'll end up in the
debugger, and conditions that when not handled are silently ignored.)
The CL ANSI standard does not define what kind of condition a Keyboard
interrupt is, so the implementations have to make that decision.
Although this implementation (Allegro CL) has currently defined it as
a subclass of 'error', I'm told it should have been a
'serious-condition' instead ('error' is a subclass of
'serious-condition', which is a subclass of 'condition'), precisely
because forms like ignore-errors, like a bare except in Python, will
catch it right now when they shouldn't. I assume most of the other
Lisp implementations have already defined it as serious-condition.
So, in short, Keyboard interrupts in Lisp are a serious-condition, not an error.
(And what is labeled CriticalException in this discussion, has in
serious-condition Lisp's counterpart.)
and if an unhandled signal whose intended interpretation is drop the
gun and put your hands on your head! isn't critical, what is?wink
Eh, are you serious? wink
I didn't miss your point, but I don't see a good reason to oppose that
label based on the usual definitions of the words or Common LISP
usage, either.
Well, I'm not opposed to KeyboardInterrupt being in a class that's not
a subclass of 'Exception', when the latter is the class used in a bare
'except'. But when CriticalException, despite its name, is not a
subclass of Exception, that is a bit strange. I'd prefer the
'condition' and 'error' terminology, and to label a keyboard interrupt
a condition, not any kind of exception or error.
It seems to me the relevant question is is it likely that catching
KeyboardInterrupt with 'except Exception:' will get sane behavior from
a generic user-defined handler?
I agree with you that it should not be caught in a bare 'except' (or
an 'except Exception', when that is equivalent).
- Willem
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/31/05, Brett Cannon [EMAIL PROTECTED] wrote: While we do tend to use KeyboardInterrupt as a way to kill a program, is that really control flow, or a critical exception that the program needs to stop because an serious event occurred? I does not seem right to me to think of KeyboardInterrupt as a means to cause program halting. An interpreter could in principle recover from it and resume execution of the program. The behaviour of the current Python interpreters is that upon encountering an uncaught KeyboardInterrupt (as with any uncaught exception), computation is aborted and a backtrace printed. But that is not how it /must be/ as there might be alternative interpreters that upon encountering an uncaught KeyboardInterrupt will pause execution of the program, but then allow the user to either continue or abort execution, effectively not stopping but pausing the program. Because of this possible recovery, thinking of KeyboardInterrupt as in order to abort the program, the user has caused a keyboard interrupt is wrong; it should be more like just the user has interrupted the computation and whether or not the program is consequently aborted is not predefined. - Willem ___ 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
