[Python-Dev] a quit that actually quits
sourceforge just went off the air, so I'm posting this patch here, in order to distract you all from Christian's deque thread. this silly little patch changes the behaviour of the interpreter so that quit and exit actually exits the interpreter. it does this by installing a custom excepthook that looks for NameErrors at the top level, in interactive mode only. whaddya think? /F Index: Lib/site.py === --- Lib/site.py (revision 41831) +++ Lib/site.py (working copy) @@ -60,6 +60,7 @@ import sys import os import __builtin__ +import traceback def makepath(*paths): @@ -222,19 +223,20 @@ def setquit(): -Define new built-ins 'quit' and 'exit'. -These are simply strings that display a hint on how to exit. +Set default exception handler for the interactive mode. +def defaultexcepthook(exc_type, exc_value, exc_info): +if hasattr(sys, ps1): +# interactive mode +if isinstance(exc_value, NameError) and not exc_info.tb_next: +text = exc_value[0] +if (text == name 'exit' is not defined or +text == name 'quit' is not defined): +# XXX: print helpful Use control-D etc message here? +raise SystemExit +# XXX: add if text == help ? +traceback.print_exception(exc_type, exc_value, exc_info) +sys.excepthook = defaultexcepthook - -if os.sep == ':': -exit = 'Use Cmd-Q to quit.' -elif os.sep == '\\': -exit = 'Use Ctrl-Z plus Return to exit.' -else: -exit = 'Use Ctrl-D (i.e. EOF) to exit.' -__builtin__.quit = __builtin__.exit = exit - - class _Printer(object): interactive prompt objects for printing the license text, a list of contributors and the copyright notice. ___ 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] file() vs open(), round 7
Aahz wrote: class file(object) | file(name[, mode[, buffering]]) - file object | | Open a file. The mode can be 'r', 'w' or 'a' for reading (default), [...] | Note: open() is an alias for file(). This is confusing. I suggest that we make ``open()`` a factory function right now. (I'll submit a bug report (and possibly a patch) after I get agreement.) +1. can we add a opentext factory for file/codecs.open while we're at it ? /F ___ 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] a quit that actually quits
Fredrik whaddya think? We're going to wind up with the same problem that spawned the atexit module: multiple code sources wanting to fiddle with sys.excepthook step on one another's toes. For example, I already use an excepthook in interactive mode to try to resolve NameErrors: % python Python 2.5a0 (#2, Dec 10 2005, 14:05:27) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type help, copyright, credits or license for more information. sys.excepthook function _autoload_exc at 0x3d6830 sin(12) found sin in math module -0.53657291800043505 Other than that, seems fine to me. Skip ___ 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] status of development documentation
Neal Norwitz wrote: And hopefully of interest to many here: http://docs.python.org/dev/results/ These are the results of svn update, configure, build, test, install and the doc run. the trunk link on http://www.python.org/dev/doc/ still points to the old http://www.python.org/dev/doc/devel/ rather than the new http://docs.python.org/dev/ /F ___ 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] file() vs open(), round 7
Fredrik Lundh wrote: Aahz wrote: class file(object) | file(name[, mode[, buffering]]) - file object | | Open a file. The mode can be 'r', 'w' or 'a' for reading (default), [...] | Note: open() is an alias for file(). This is confusing. I suggest that we make ``open()`` a factory function right now. (I'll submit a bug report (and possibly a patch) after I get agreement.) +1. can we add a opentext factory for file/codecs.open while we're at it ? Why a new factory function ? Can't we just redirect to codecs.open() in case an encoding keyword argument is passed to open() ?! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 27 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list 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] file() vs open(), round 7
M.-A. Lemburg wrote: can we add a opentext factory for file/codecs.open while we're at it ? Why a new factory function ? Can't we just redirect to codecs.open() in case an encoding keyword argument is passed to open() ?! I think open is overloaded enough as it is. Using separate functions for distinct use cases is also a lot better than keyword trickery. Here's a rough draft: def textopen(name, mode=r, encoding=None): if U not in mode: mode += U if encoding: return codecs.open(name, mode, encoding) return file(name, mode) /F ___ 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] a quit that actually quits
Fredrik Lundh wrote: sourceforge just went off the air, so I'm posting this patch here, in order to distract you all from Christian's deque thread. this silly little patch changes the behaviour of the interpreter so that quit and exit actually exits the interpreter. it does this by installing a custom excepthook that looks for NameErrors at the top level, in interactive mode only. What is wrong with something like this: class Quitter: ... def __repr__(self): raise SystemExit ... exit = quit = Quitter() It could optionally check for top level too, of course. 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/archive%40mail-archive.com
Re: [Python-Dev] a quit that actually quits
Reinhold Birkenfeld wrote: What is wrong with something like this: class Quitter: ... def __repr__(self): raise SystemExit ... exit = quit = Quitter() vars() # oops! /F ___ 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] a quit that actually quits
On 12/28/05, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: Fredrik Lundh wrote: sourceforge just went off the air, so I'm posting this patch here, in order to distract you all from Christian's deque thread. this silly little patch changes the behaviour of the interpreter so that quit and exit actually exits the interpreter. it does this by installing a custom excepthook that looks for NameErrors at the top level, in interactive mode only. What is wrong with something like this: class Quitter: ... def __repr__(self): raise SystemExit ... exit = quit = Quitter() It could optionally check for top level too, of course. Not sure if this is what you mean by check for top level too, but the obvious problem is that calling vars(__builtins__) (or similar) will cause your interpreter to exit. :) -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ 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] file() vs open(), round 7
Fredrik Lundh wrote: M.-A. Lemburg wrote: can we add a opentext factory for file/codecs.open while we're at it ? Why a new factory function ? Can't we just redirect to codecs.open() in case an encoding keyword argument is passed to open() ?! I think open is overloaded enough as it is. Using separate functions for distinct use cases is also a lot better than keyword trickery. Fair enough. Here's a rough draft: def textopen(name, mode=r, encoding=None): if U not in mode: mode += U The U is not needed when opening files using codecs - these always break lines using .splitlines() which breaks lines according to the Unicode rules and also knows about the various line break variants on different platforms. if encoding: return codecs.open(name, mode, encoding) return file(name, mode) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 27 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list 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] a quit that actually quits
Fredrik Lundh wrote: Reinhold Birkenfeld wrote: What is wrong with something like this: class Quitter: ... def __repr__(self): raise SystemExit ... exit = quit = Quitter() vars() # oops! You're right. class Quitter: ... def __repr__(self): ... n = sys._getframe(1).f_code.co_names ... if n == (exit,) or n == (quit,): ...raise SystemExit better? ;) 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/archive%40mail-archive.com
Re: [Python-Dev] a quit that actually quits
On 27-dec-2005, at 14:55, Christopher Armstrong wrote: On 12/28/05, Reinhold Birkenfeld reinhold-birkenfeld- [EMAIL PROTECTED] wrote: Fredrik Lundh wrote: sourceforge just went off the air, so I'm posting this patch here, in order to distract you all from Christian's deque thread. this silly little patch changes the behaviour of the interpreter so that quit and exit actually exits the interpreter. it does this by installing a custom excepthook that looks for NameErrors at the top level, in interactive mode only. What is wrong with something like this: class Quitter: ... def __repr__(self): raise SystemExit ... exit = quit = Quitter() It could optionally check for top level too, of course. Not sure if this is what you mean by check for top level too, but the obvious problem is that calling vars(__builtins__) (or similar) will cause your interpreter to exit. :) Why must quit and exit be so special in the first place? They could be plain functions, or even something like:: class _QuitOrExit: def __init__(self, name): self.name = name def __repr__(self): return Use %(name)s() to exit.%(self.__dict__) def __call__(self): raise SystemExit quit = _QuitOrExit(quit) exit = _QuitOrExit(exit) Ronald ___ 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] file() vs open(), round 7
At 02:35 PM 12/27/2005 +0100, Fredrik Lundh wrote: M.-A. Lemburg wrote: can we add a opentext factory for file/codecs.open while we're at it ? Why a new factory function ? Can't we just redirect to codecs.open() in case an encoding keyword argument is passed to open() ?! I think open is overloaded enough as it is. Using separate functions for distinct use cases is also a lot better than keyword trickery. Here's a rough draft: def textopen(name, mode=r, encoding=None): if U not in mode: mode += U if encoding: return codecs.open(name, mode, encoding) return file(name, mode) Nice. It should probably also check whether there's a 'b' or 't' in 'mode' and raise an error if so. I'd also prefer to call it 'textfile', as that reads more nicely with for line in textfile(...): use cases, and it does return a file object. ___ 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] deque alternative
Hi Christian, On Mon, Dec 26, 2005 at 01:38:37PM +0100, Christian Tismer wrote: I don't think your code has to decide about this. The power lies in the fact that you don't specify that, but just use the list in a different way. We do this in the PyPy implementation; right now it is true that we have a static analysis, but a JIT is to come, and I'm pretty sure it will try to use an array until something gets used like a list. You are mentioning confusingly many levels of PyPy for this argument. This is not directly related to static analysis nor to the JIT. The point is just that while a Python program runs, the implementation can decide to start using a deque-like structure instead of a zero-based array for a given user list. This can be done in any implementation of Python; both in PyPy and in CPython it would be done by adding checks and cases in the code that implements list objects. As much as I like this approach I fear that it will be rejected for CPython, as e.g. lazily concatenated string objects were, on grounds of code obfuscation and unpredictability of performance. But it's PyPy's goal to experiment here :-) A bientot, Armin ___ 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] file() vs open(), round 7
Phillip J. Eby wrote: At 02:35 PM 12/27/2005 +0100, Fredrik Lundh wrote: M.-A. Lemburg wrote: can we add a opentext factory for file/codecs.open while we're at it ? Why a new factory function ? Can't we just redirect to codecs.open() in case an encoding keyword argument is passed to open() ?! I think open is overloaded enough as it is. Using separate functions for distinct use cases is also a lot better than keyword trickery. Here's a rough draft: def textopen(name, mode=r, encoding=None): if U not in mode: mode += U if encoding: return codecs.open(name, mode, encoding) return file(name, mode) Nice. It should probably also check whether there's a 'b' or 't' in 'mode' and raise an error if so. Why should it do that ? FYI: codecs.open() explicitly adds the 'b' to the mode since we don't want the platform text mode interfere with the Unicode line breaking. I'd also prefer to call it 'textfile', as that reads more nicely with for line in textfile(...): use cases, and it does return a file object. Nope: open() is only guaranteed to return a file-like object, e.g. codecs.open() will return a wrapped version of a file object. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 27 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list 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] file() vs open(), round 7
At 04:20 PM 12/27/2005 +0100, M.-A. Lemburg wrote: Phillip J. Eby wrote: At 02:35 PM 12/27/2005 +0100, Fredrik Lundh wrote: M.-A. Lemburg wrote: can we add a opentext factory for file/codecs.open while we're at it ? Why a new factory function ? Can't we just redirect to codecs.open() in case an encoding keyword argument is passed to open() ?! I think open is overloaded enough as it is. Using separate functions for distinct use cases is also a lot better than keyword trickery. Here's a rough draft: def textopen(name, mode=r, encoding=None): if U not in mode: mode += U if encoding: return codecs.open(name, mode, encoding) return file(name, mode) Nice. It should probably also check whether there's a 'b' or 't' in 'mode' and raise an error if so. Why should it do that ? It's not necessary if both codecs.open() and file() raise an error when there's both a 'U' and a 't' or 'b' in the mode string, I suppose. FYI: codecs.open() explicitly adds the 'b' to the mode since we don't want the platform text mode interfere with the Unicode line breaking. I think maybe you're confusing the wrapped file's mode with the passed-in mode, here. The passed-in mode should contain at most one of 'b', 't', or 'U', IIUC. The mode used for the wrapped file should of course always be 'b', but that's not visible to the user of the routine. I'd also prefer to call it 'textfile', as that reads more nicely with for line in textfile(...): use cases, and it does return a file object. Nope: open() is only guaranteed to return a file-like object, e.g. codecs.open() will return a wrapped version of a file object. I meant it's a file object in use case terms, not that isinstance(ob,file). ___ 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] file() vs open(), round 7
Phillip J. Eby wrote: Here's a rough draft: def textopen(name, mode=r, encoding=None): if U not in mode: mode += U if encoding: return codecs.open(name, mode, encoding) return file(name, mode) Nice. It should probably also check whether there's a 'b' or 't' in 'mode' and raise an error if so. I'd also prefer to call it 'textfile', as that reads more nicely with for line in textfile(...): use cases, and it does return a file object. textfile was my original proposal: http://mail.python.org/pipermail/python-dev/2002-March/021115.html but that was made at a time when it wasn't clear if open or file would be the preferred way to open a file. now that we've settled on the verb form, I think textopen or opentext would be slightly more consistent. but I agree that textfile looks a bit better. how about opentextfile ? ;-) /F ___ 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] file() vs open(), round 7
At 04:37 PM 12/27/2005 +0100, Fredrik Lundh wrote: but that was made at a time when it wasn't clear if open or file would be the preferred way to open a file. now that we've settled on the verb form, I think textopen or opentext would be slightly more consistent. Sorry, I'm confused. Who settled on the verb form? Are you saying Guido's 2002 post supports open() instead of file(), or is there some more recent reference to this? ___ 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] a quit that actually quits
Ronald Oussoren wrote: Why must quit and exit be so special in the first place? They could be plain functions, or even something like:: class _QuitOrExit: def __init__(self, name): self.name = name def __repr__(self): return Use %(name)s() to exit.%(self.__dict__) def __call__(self): raise SystemExit quit = _QuitOrExit(quit) exit = _QuitOrExit(exit) but now we're back to today's situation: quit 'Use Ctrl-Z plus Return to exit.' which violates the basic if you know what I mean, why the /!/!//%¤ don't you do what I say usability rule. /F ___ 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] status of development documentation
On Tuesday 27 December 2005 08:06, Fredrik Lundh wrote: the trunk link on http://www.python.org/dev/doc/ Fixed now; thanks for the reminder. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file() vs open(), round 7
Phillip J. Eby wrote: but that was made at a time when it wasn't clear if open or file would be the preferred way to open a file. now that we've settled on the verb form, I think textopen or opentext would be slightly more consistent. Sorry, I'm confused. Who settled on the verb form? Are you saying Guido's 2002 post supports open() instead of file(), or is there some more recent reference to this? see: http://mail.python.org/pipermail/python-dev/2004-July/045921.html I recently saw a checkin that changed a call to open() into a call to file(), suggesting that using file() is more politically correct than open(). I'm not sure I agree with this. http://mail.python.org/pipermail/python-dev/2004-July/045967.html Anyway, here's my future-proof distinction: use open() as the factory function, and file for type-testing. /F ___ 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] NotImplemented reaching top-level
Hi Facundo, On Mon, Dec 26, 2005 at 02:31:10PM -0300, Facundo Batista wrote: nb_add and nb_multiply should be tried. I don't think that this would break existing C or Python code, but it should probably only go in 2.5, together with the patch #1390657 that relies on it. It'd be good to know if this will be applied for the next version 2.4.x or will wait until 2.4.5, for me to search a workaround in Decimal or not (really don't know if I can find a solution here). I completed the patch on the SF tracker, and now I believe that it could safely be checked in the HEAD and in the 2.4 branch (after the appropriate review). A bientot, Armin ___ 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] a quit that actually quits
On 27-dec-2005, at 16:39, Fredrik Lundh wrote: Ronald Oussoren wrote: Why must quit and exit be so special in the first place? They could be plain functions, or even something like:: class _QuitOrExit: def __init__(self, name): self.name = name def __repr__(self): return Use %(name)s() to exit.%(self.__dict__) def __call__(self): raise SystemExit quit = _QuitOrExit(quit) exit = _QuitOrExit(exit) but now we're back to today's situation: quit 'Use Ctrl-Z plus Return to exit.' which violates the basic if you know what I mean, why the /!/!//%¤ don't you do what I say usability rule. I'd prefer 'def quit(): raise SystemExit', the class above just adds a message for someone that accidently got stuck in a python shell. I don't like the idea of making quit or exit special enough to cause side effects without parentheses, no other function does that. Anyone that knows how to program in Python should be able to guess that you have to use 'quit()' instead of 'quit'. BTW. I do agree that the current situation is stupid. Ronald /F ___ 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/ ronaldoussoren%40mac.com ___ 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] a quit that actually quits
Ronald Oussoren wrote: I'd prefer 'def quit(): raise SystemExit', the class above just adds a message for someone that accidently got stuck in a python shell. I don't like the idea of making quit or exit special enough to cause side effects without parentheses, no other function does that. Anyone that knows how to program in Python should be able to guess that you have to use 'quit()' instead of 'quit'. The thing is there primarily for people who *don't* know how to program in Python. If they knew, they knew how to get out of it; they wouldn't type quit() but simply Ctrl-D. So if they do quit function quit at 0xb7d96294 they are just as confused as if they got a name error. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file() vs open(), round 7
Phillip J. Eby wrote: At 04:20 PM 12/27/2005 +0100, M.-A. Lemburg wrote: Phillip J. Eby wrote: At 02:35 PM 12/27/2005 +0100, Fredrik Lundh wrote: M.-A. Lemburg wrote: can we add a opentext factory for file/codecs.open while we're at it ? Why a new factory function ? Can't we just redirect to codecs.open() in case an encoding keyword argument is passed to open() ?! I think open is overloaded enough as it is. Using separate functions for distinct use cases is also a lot better than keyword trickery. Here's a rough draft: def textopen(name, mode=r, encoding=None): if U not in mode: mode += U if encoding: return codecs.open(name, mode, encoding) return file(name, mode) Nice. It should probably also check whether there's a 'b' or 't' in 'mode' and raise an error if so. Why should it do that ? It's not necessary if both codecs.open() and file() raise an error when there's both a 'U' and a 't' or 'b' in the mode string, I suppose. I see what you mean. codecs.open() doesn't work with 'U'. FYI: codecs.open() explicitly adds the 'b' to the mode since we don't want the platform text mode interfere with the Unicode line breaking. I think maybe you're confusing the wrapped file's mode with the passed-in mode, here. The passed-in mode should contain at most one of 'b', 't', or 'U', IIUC. The mode used for the wrapped file should of course always be 'b', but that's not visible to the user of the routine. Thinking about this some more, I think it's better to make encoding mandatory and to not use file() at all in the API. When we move to all text is Unicode in Py3k, we'll have to require this anyway, so why not start with it now. That said, I think that a name textfile would be more appropriate for the factory function, like you suggested. Valid values for mode would then be 'r', 'w' and 'a'. 'U' is not needed. 'b' and 't' neither. The '+' modes don't work well with codecs. I'd also prefer to call it 'textfile', as that reads more nicely with for line in textfile(...): use cases, and it does return a file object. Nope: open() is only guaranteed to return a file-like object, e.g. codecs.open() will return a wrapped version of a file object. I meant it's a file object in use case terms, not that isinstance(ob,file). We usually call this an xyz-like object (meaning that the object provides a certain kind of interface). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 27 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list 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] (back to): Linked lists -- (was: deque alternative)
On 12/26/05, Josiah Carlson [EMAIL PROTECTED] wrote: A flat list or tuple would certainly be more space-efficient up to this point. But when the graph branches, the 2-tuple representation allows *sharing* the common path suffix (which may be very long!): ... If there's an N-way branch, using 2-tuples allows recording the N new paths back to the root with incremental memory burden N * some_constant. You can't do this kind of sharing with a flat list or tuple, and the incremental memory burden at an N-way branch zooms to (N + some_other_constant) * (the amount of memory needed to record the path from the branch point back to the root), due to duplicating the back-to-the-root info N times. The potential memory saving from using 2-tuples instead is unbounded. But one doesn't _need_ to use flat lists. If one were to combine cons cells with Python lists, you can get the space efficiency of lists with the reusability of the desired cons cells (or tuples as the case may be). How? (i, l), where i is the prefix of list l which is the desired portion of whatever l represents. You toss one of those anywhere in your 'flat list', and you have your stored/saved path with a couple dozen bytes. If you are not careful, you end up storing/saving paths which would be stored more efficiently by copying the contents, but at that point we are talking about a constant factor blowup, not the (potentially) exponential blowup of storing all paths as copies, and we can always copy to be more efficient if necessary. I have personally used this trick to construct a union-find data structure in which all unions are reversable regardless of find operation. [1] Hmm using a single simple data type seems more elegant and less error-prone in this case than what you suggest. I would argue that such solutions come about exactly because lists aren't available. Sure your solution works, but IMO it's a case of raising the hammer with your arm, noticing that it's a screw and not a nail, and then using the hammer sideways to try to turn the screw. I want a screwdriver. So, the list will generally be 1/8th of its size overallocated, or 112 elements plus 9 words overhead is 121 words. Better than any cons- linked list could be, and *insanely better* than a cons-linked list would be in python. You seem to be ignoring possiblities for sharing across lists, and such sharing is natural in many graph algorithms. Not necessarily so as I have pointed out above. You said yourself; practicality beats purity. While using cons cells are pure, as us using only flat lists are pure, flat lists are practically smaller than cons cells in certain cases (by a factor of ~4), and non-flat lists can be smaller than cons cells in the rest of the cases. I don't know about practicality beats purity type of arguments. Such general principles don't always apply. Building lists and trees/graphs with cons cells seem very, very practical to me. Now, it's not all about storage space. What about front-insertion? Everytime I have to type L.insert(0, bli), somewhere that I know runs often I cringe. If I had lists I would be able to express my thoughts more clearly in the computer program. Right now, I cringe, and then I just shrug. ___ 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] file() vs open(), round 7
M.-A. Lemburg wrote: Here's a rough draft: def textopen(name, mode=r, encoding=None): if U not in mode: mode += U The U is not needed when opening files using codecs - these always break lines using .splitlines() which breaks lines according to the Unicode rules and also knows about the various line break variants on different platforms. Still, codecs typically don't implement universal newlines correctly. If you specify 'U', then do .read(), you deserve to get \n (U+0010) as the line separator; with most codecs, you get whatever line breaks where in the file. Passing 'U' to the underlying stream is wrong, as well: if the stream is double-byte oriented (e.g. UTF-16), the 'U' filtering will rarely do anything, but if it does something, it will be wrong. I agree that it would be desirable to have textopen always default to universal newlines, however, this is difficult to implement. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (back to): Linked lists -- (was: deque alternative)
On Tue, Dec 27, 2005, Martin Blais wrote: Now, it's not all about storage space. What about front-insertion? Everytime I have to type L.insert(0, bli), somewhere that I know runs often I cringe. If I had lists I would be able to express my thoughts more clearly in the computer program. Right now, I cringe, and then I just shrug. Why don't you just write your own list type? Why does this need to go into Python? Why should it be one of the builtin types instead of a library? Please answer these questions on comp.lang.python, NOT python-dev. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Don't listen to schmucks on USENET when making legal decisions. Hire yourself a competent schmuck. --USENET schmuck (aka Robert Kern) ___ 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 + Visual C++ 8.0?
Python uses LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH flag which means that DLLs used by the extension will be searched IN THE EXTENSION FOLDER and not on PATH. Try putting msvcp80.dll right next to your extension DLL. It is a little strange that it is not loaded directly from the Windows side by side folder (%WINDIR%\WinSxS). You should check if the manifest is embedded correctly inside the DLL. And like Martin said, mixing Python and extensions compiled with different compilers is a bad idea. ___ 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] file() vs open(), round 7
Martin v. Löwis wrote: M.-A. Lemburg wrote: Here's a rough draft: def textopen(name, mode=r, encoding=None): if U not in mode: mode += U The U is not needed when opening files using codecs - these always break lines using .splitlines() which breaks lines according to the Unicode rules and also knows about the various line break variants on different platforms. Still, codecs typically don't implement universal newlines correctly. If you specify 'U', then do .read(), you deserve to get \n (U+0010) as the line separator; with most codecs, you get whatever line breaks where in the file. Passing 'U' to the underlying stream is wrong, as well: if the stream is double-byte oriented (e.g. UTF-16), the 'U' filtering will rarely do anything, but if it does something, it will be wrong. I agree that it would be desirable to have textopen always default to universal newlines, however, this is difficult to implement. I think that codecs solve the problem in a better way. If you want to read lines from a stream, you'd use .readline() or .readlines() to read the lines, and not expect .read() to magically apply some conversion to the original data. Both line methods have a parameter keepends (which defaults to True). This parameter specifies whether you will get the original line end markers or not, which makes it possible to let the application implement whatever logic it finds appropriate. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 27 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list 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] a quit that actually quits
Martin So if they do quit function quit at 0xb7d96294 Martin they are just as confused as if they got a name error. Probably more so... wink Skip ___ 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] a quit that actually quits
[EMAIL PROTECTED] wrote: Fredrik whaddya think? We're going to wind up with the same problem that spawned the atexit module: multiple code sources wanting to fiddle with sys.excepthook step on one another's toes. in this case, I'm not sure it matters that much. if you add your own except- hook, you take responsibility. (it would be nice if it was possible to detect interactive mode when the site code runs, though. does anyone know if that's possible ?) /F ___ 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] a quit that actually quits
Martin v. Löwis wrote: The thing is there primarily for people who *don't* know how to program in Python. If they knew, they knew how to get out of it; they wouldn't type quit() but simply Ctrl-D. Except that on Windows, it's Ctrl-Z. This can be quite confusing when you regularly use Python on both Windows and Unix, and use the wrong key combination. Ctrl-D on Windows does not have the desired result, and Ctrl-Z on Unix suspends the process. (And if you use a GUI version, they often have their own rules... on IDLE for Windows, Ctrl-D works but Ctrl-Z doesn't; on PyCrust, neither one works.) Granted, it's not a big problem, but it *is* annoying. IMHO, it would be more useful if you could just type 'exit' or 'quit' (like in many other interpreters) and be done with it, rather than having to remember the correct key combination. (A key combination which has nothing to do with the Python language per se.) -- Hans Nowak http://zephyrfalcon.org/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Small any/all enhancement
I see that Python 2.5 will include a simple implementation of any/all.
What I would like to ask, before it's too late, is if it's possible to add an
optional test argument.
any(iterable, test=bool) and all(iterable, test=bool)
These would be the new proposed APIs. The usecase is to be able to extract
attributes from objects or simply to have arbitrary checks like:
import operator
any(some_objects, test=operator.attrgetter('some_attribute'))
or
def zerop(x):
return x==0
all(some_objects, zerop)
instead of preprocessing the generator with a generator expression before
passing it to any/all.
Thanks.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
pgpm3YZZLyclq.pgp
Description: PGP signature
___
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] a quit that actually quits
Hans Nowak wrote: Granted, it's not a big problem, but it *is* annoying. IMHO, it would be more useful if you could just type 'exit' or 'quit' (like in many other interpreters) and be done with it, rather than having to remember the correct key combination. (A key combination which has nothing to do with the Python language per se.) If you want to type something consistently across platforms, you can currently do raise SystemExit Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a quit that actually quits
Fredrik Lundh wrote: (it would be nice if it was possible to detect interactive mode when the site code runs, though. does anyone know if that's possible ?) I believe checking sys.argv==[''] is a nearly reliable test (the only other case where I could make it happen is when the script is read from stdin). Introducing a flag into InteractiveLoop would be an option, too. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a quit that actually quits
Martin v. Löwis wrote: If you want to type something consistently across platforms, you can currently do raise SystemExit I'm not sure what to say to that. Do you really want to type raise SystemExit every time you want to exit the interpreter? (Your answer would probably be something like No -- that's why I use Ctrl-D. But that wouldn't really get us anywhere, would it?) My point is that there is currently no acceptable, universal way to exit the interpreter. Again, it's not that big of a deal... but it seems silly that something apparently trivial like that cannot be done right. -- Hans Nowak http://zephyrfalcon.org/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python + Visual C++ 8.0?
--- Martin v. Löwis [EMAIL PROTECTED] wrote: Ralf W. Grosse-Kunstleve wrote: I am using a Visual Studio 2005 Professional installation. I also ran vcredist_x86.exe. Moving msvc[mpr]80.dll to a directory on PATH didn't help. However, standalone executables work OK without any gymnastics. Does anyone know what the problem could be with the extensions? Can't check right now - but could it be that the standalone executables get an extra copy of this library in their binary directory, as part of the build process? No. A quick attempt to compile Python from scratch using Visual C++ 8.0 produced a python.exe, but it doesn't run (the debug / send report / don't send report box pops up). Has someone tried this before? Yes; a patch to fix this problem has been checked into the trunk (but I have no plans for backporting it to the 2.4 branch, as 2.4 will be compiled with VC7.1 forever - i.e. until its final release). OK. Regards, Martin P.S. I currently also plan to build Python 2.5 with VC 7.1. P.P.S. You do know that this configuration (extension compiled with VS2005, Python compiled wit VS.NET2003) is not supported, right? I wasn't sure about that. In the transition from VC 6 to VC 7.x we didn't have compatibility problems. I was hoping this trend continues ... If that's not the case we will need two Python 2.5 installers, one compiled with VC 7.1, one with VC 8.0. I'll try to build SVN Python with VC 8.0. If that succeeds, is there an equivalent of make install that will give me a directory structure resembling what I get from the binary installer? Thanks! Cheers, Ralf __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ 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] Small any/all enhancement
Valentino Volonghi aka Dialtone wrote:
What I would like to ask, before it's too late, is if it's possible to add an
optional test argument.
I don't see why: you can easily synthesize that with map/imap.
These would be the new proposed APIs. The usecase is to be able to extract
attributes from objects or simply to have arbitrary checks like:
import operator
any(some_objects, test=operator.attrgetter('some_attribute'))
So write
any(map(operator.attrgetter('some_attribute'), some_objects))
# same number of characters to type
any(o.some_attribute for o in some_objects)
# fewer number of characters
def zerop(x):
return x==0
all(some_objects, zerop)
So write
all(map(some_objects, zerop))
or
all(o==0 for o in some_objects)
# avoids defining zerop
instead of preprocessing the generator with a generator expression before
passing it to any/all.
What is the disadvantage of such preprocessing?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small any/all enhancement
On Dec 27, 2005, at 12:45 PM, Valentino Volonghi aka Dialtone wrote:
...
any(iterable, test=bool) and all(iterable, test=bool)
...
any(some_objects, test=operator.attrgetter('some_attribute'))
Why would that be better than
any(o.some_attribute for o in some_objects)
?
def zerop(x):
return x==0
all(some_objects, zerop)
and why would that be better than
all(o==0 for o in some_objects)
?
instead of preprocessing the generator with a generator expression
before
passing it to any/all.
I guess I just don't see the advantage, along any plane, since the
genexp fits so snugly right there inside the any/all's parentheses.
What am I missing?
Alex
___
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 + Visual C++ 8.0?
--- Adal Chiriliuc [EMAIL PROTECTED] wrote: Python uses LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH flag which means that DLLs used by the extension will be searched IN THE EXTENSION FOLDER and not on PATH. Try putting msvcp80.dll right next to your extension DLL. I tried that first since that's the way we use VC 7.1 extensions with older Python versions (compiled with VC 6). It is a little strange that it is not loaded directly from the Windows side by side folder (%WINDIR%\WinSxS). You should check if the manifest is embedded correctly inside the DLL. Sorry, the manifests are new to me. How can I check if the manifest is correctly embedded? FWIW: I already tried copying the manifest into the directory with the extensions. In case it matters, here are the compiler and liker switches I am using (commands issued by scons): cl /nologo /D_CRT_SECURE_NO_DEPRECATE /wd4996 /Zm800 /MD /GR /EHsc /DBOOST_DISABLE_THREADS /DNDEBUG /Ox -DBOOST_PYTHON_MAX_BASES=2 -DBOOST_PYTHON_SOURCE link /nologo /incremental:no /dll /out:lib\cctbx_math_ext.pyd /implib:lib\cctbx_math_ext.lib /LIBPATH:lib Am I missing some magic new switch? And like Martin said, mixing Python and extensions compiled with different compilers is a bad idea. If that's really the case it will mean a lot of work. Mixing VC6 Python and VC7.x extensions never gave us any trouble. Thanks! Cheers, Ralf __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ ___ 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] a quit that actually quits
[Martin v. Löwis] If you want to type something consistently across platforms, you can currently do raise SystemExit [Hans Nowak] I'm not sure what to say to that. Do you really want to type raise SystemExit every time you want to exit the interpreter? (Your answer would probably be something like No -- that's why I use Ctrl-D. But that wouldn't really get us anywhere, would it?) My point is that there is currently no acceptable, universal way to exit the interpreter. ... I haven't used Python on a PDA yet, but on everything from PCs to mainframes I get out of the interpreter just by pulling the power plug. Why on Earth would you want to exit Python while your machine was running? Aha! The light dawns. resolve-to-keep-python-running-24/7-in-2006-ly y'rs - tim ___ 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] a quit that actually quits
Hans Nowak wrote: My point is that there is currently no acceptable, universal way to exit the interpreter. Again, it's not that big of a deal... but it seems silly that something apparently trivial like that cannot be done right. it's the usual problem: getting enough developers to agree that this really is a problem is a lot more work than implementing it... oh, well. looks like SF is back up again. I'll post the patch over there when I find the time... /F ___ 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 + Visual C++ 8.0?
Adal Chiriliuc wrote: Python uses LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH flag which means that DLLs used by the extension will be searched IN THE EXTENSION FOLDER and not on PATH. Can you please refer to the part of the documentation that documents that PATH is not searched? In http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic-link_library_search_order.asp the documentation says that the PATH is searched in step 6. It is a little strange that it is not loaded directly from the Windows side by side folder (%WINDIR%\WinSxS). You should check if the manifest is embedded correctly inside the DLL. How do you get VS to do that? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python + Visual C++ 8.0?
Ralf W. Grosse-Kunstleve wrote: I wasn't sure about that. In the transition from VC 6 to VC 7.x we didn't have compatibility problems. I was hoping this trend continues ... That was by pure luck only. Other people did have problems. If that's not the case we will need two Python 2.5 installers, one compiled with VC 7.1, one with VC 8.0. I'll try to build SVN Python with VC 8.0. If that succeeds, is there an equivalent of make install that will give me a directory structure resembling what I get from the binary installer? You can create an installer yourself, through Tools/msi/msi.py. There is no make install procedure. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a quit that actually quits
Hans Nowak wrote: I'm not sure what to say to that. Do you really want to type raise SystemExit every time you want to exit the interpreter? (Your answer would probably be something like No -- that's why I use Ctrl-D. But that wouldn't really get us anywhere, would it?) Well... I understand that you want exit to quit the interpreter, and I can understand why you want that. Fredrik's proposed change started that entire thread. My point is that there is currently no acceptable, universal way to exit the interpreter. That clearly depends on the definition of acceptable. If acceptable means using a four-letter keyword, then you are right, yes. Again, it's not that big of a deal... but it seems silly that something apparently trivial like that cannot be done right. It's silly only if you understand the background that leads to this state of affairs. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a quit that actually quits
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. exit 'Use Ctrl-Z plus Return to exit.' I've just tried Ctrl+Z (plus Return) and some variations on Win XP and it doesn't work! Ctrl+D does. Beside, it should be spelled Ctrl+Z and not Ctrl-Z (at least this is the Windows way). I think it's intuitive for exit/quit to exit the interactive interpreter. That's what I did the first time I've tried Python. In another one (I think CLISP, but I'm not sure) I couldn't figure out how to exit. And definatly in CLISP when trying simple things I always got stuck in some kind or different error mode (with a different prompt). That's why I gave up playing with it. ___ 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] Small any/all enhancement
On Tue, Dec 27, 2005 at 01:50:37PM -0800, Alex Martelli wrote: I'll answer here for all the people who kindly answered. Why would that be better than any(o.some_attribute for o in some_objects) ? I think it's because lately I've been using common lisp a lot and the approach with the test function is pretty common there. Of course I already knew all the alternatives using map and the generator expression, but I felt like mine was clearer for a reader, this is probably true but not enough to justify the change. One reason was to hide the iteration from the user and let python handle it, but I can see that this is both not enough and probably not even so necessary since the iteration protocol is already 'hidden' when using for..in. What am I missing? Nothing, it's just me and the bad influence that lisp has on my mind :). Sorry to bother the list then. Thanks for the kind replies. -- Valentino Volonghi aka Dialtone Now Running MacOSX 10.4 Blog: http://vvolonghi.blogspot.com http://weever.berlios.de pgpeKPBtN4P2s.pgp Description: PGP signature ___ 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] Small any/all enhancement
On Dec 27, 2005, at 5:48 PM, Valentino Volonghi aka Dialtone wrote: On Tue, Dec 27, 2005 at 01:50:37PM -0800, Alex Martelli wrote: I'll answer here for all the people who kindly answered. Why would that be better than any(o.some_attribute for o in some_objects) ? I think it's because lately I've been using common lisp a lot and the approach with the test function is pretty common there. Of course I already knew all the alternatives using map and the generator expression, but I felt like mine was clearer for a reader, this is probably true but not enough to justify the change. I think that generator/list expressions are more common practice than attrgetter/itemgetter, so I'm not even sure it's clearer. I don't see the harm in a key argument like sorted has, but without a key argument it could be extended to take more arguments like max/ min do for convenience. e.g. any(a, b, c) instead of any((a, b, c)). -bob ___ 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] a quit that actually quits
Adal Chiriliuc wrote: Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. exit 'Use Ctrl-Z plus Return to exit.' I've just tried Ctrl+Z (plus Return) and some variations on Win XP and it doesn't work! Ctrl+D does. WinXP or WinXP+Cygwin ? here's what I get: python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. ^Z python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. ^D File stdin, line 1 ? ^ SyntaxError: invalid syntax /F ___ 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] a quit that actually quits
It sounds to me like what is being proposed amounts to essentially promote sys.exit to a builtin. So why not do that? I see two options. Either: (a) Simply let __builtins__.exit = sys.exit. Then we get: exit built-in function exit which may be enough of a clue that you type exit() to exit. (b) If more handholding seems like a good idea, then: class ExitHatch: def __call__(self): sys.exit() def __repr__(self): return 'Type exit() to exit Python.' __builtins__.exit = __builtins__.quit = ExitHatch() -- ?!ng ___ 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] a quit that actually quits
On Wednesday, December 28, 2005 Fredrik Lundh wrote: WinXP or WinXP+Cygwin ? here's what I get: Normal WinXP, without Cygwin. python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. ^Z python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. ^D File stdin, line 1 ? ^ SyntaxError: invalid syntax I tracked this down to having IPython installed. I was able to get the exact behaviour you've got by disabling the readline package from site-packages. I have a solution proposal (I have no idea if it's feasible): why not intercept exit and quit in the interpreter command line parser? A simple regexp should do. Is the interactive interpreter implemented in Python or on the C side? ___ 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] a quit that actually quits
Adal Chiriliuc wrote: I have a solution proposal (I have no idea if it's feasible): why not intercept exit and quit in the interpreter command line parser? A simple regexp should do. Is the interactive interpreter implemented in Python or on the C side? In short: it's not feasible. Please don't propose such things on python-dev without an implementation strategy in mind. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python + Visual C++ 8.0?
On Tuesday, December 27, 2005 Ralf W. Grosse-Kunstleve wrote: Sorry, the manifests are new to me. How can I check if the manifest is correctly embedded? FWIW: I already tried copying the manifest into the directory with the extensions. To check if you have a manifest you need to use a tool like Resource Hacker or XN Resource Editor. http://www.wilsonc.demon.co.uk/d10resourceeditor.htm Where did you get that manifest? You need one listing the MSVC runtime (not one which enables the XP look). Of course, it must be named exactly like you dll/pyd, with an additional .manifest extension. ?xml version='1.0' encoding='UTF-8' standalone='yes'? assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0' dependency dependentAssembly assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' / /dependentAssembly /dependency /assembly In case it matters, here are the compiler and liker switches I am using (commands issued by scons): cl /nologo /D_CRT_SECURE_NO_DEPRECATE /wd4996 /Zm800 /MD /GR /EHsc /DBOOST_DISABLE_THREADS /DNDEBUG /Ox -DBOOST_PYTHON_MAX_BASES=2 -DBOOST_PYTHON_SOURCE link /nologo /incremental:no /dll /out:lib\cctbx_math_ext.pyd /implib:lib\cctbx_math_ext.lib /LIBPATH:lib Am I missing some magic new switch? Add /manifest to the linker options. This will generate cctbx_math_ext.pyd.manifest either in the output folder or in the intermediate one. Then you need to run mt.exe to embedd the manifest: mt.exe /outputresource:cctbx_math_ext.pyd;#2 /manifest cctbx_math_ext.pyd.manifest ___ 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] a quit that actually quits
On 12/27/05, Ka-Ping Yee [EMAIL PROTECTED] wrote: It sounds to me like what is being proposed amounts to essentially promote sys.exit to a builtin. So why not do that? I see two options. Either: (a) Simply let __builtins__.exit = sys.exit. Then we get: exit built-in function exit which may be enough of a clue that you type exit() to exit. (b) If more handholding seems like a good idea, then: class ExitHatch: def __call__(self): sys.exit() def __repr__(self): return 'Type exit() to exit Python.' __builtins__.exit = __builtins__.quit = ExitHatch() I prefer (b) since this does need to be newbie-friendly and thus self explaining. I would prefer the name ExitInterpreter for the class and including the keyboard shortcut in the message as well. And Tim had a good point about PDAs and such; how are they supposed to exit? What if someone picked up Python for their Nokia S60 phone and tried to exit from the interpreter? Unless Nokia has tweaked something I don't know how they would know to exit without knowing about sys.exit() or raising SystemExit since I wouldn't know how to do the equivalent Ctrl-D on a cell phone. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a quit that actually quits
Ka-Ping Yee wrote It sounds to me like what is being proposed amounts to essentially promote sys.exit to a builtin. no, what's being proposed is what the subject says: a quit/exit command that actually quits, instead of printing a you didn't say please! message. /F ___ 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] a quit that actually quits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ka-Ping Yee wrote: [...] (b) If more handholding seems like a good idea, then: class ExitHatch: def __call__(self): sys.exit() def __repr__(self): return 'Type exit() to exit Python.' __builtins__.exit = __builtins__.quit = ExitHatch() That looks like a good compromise to me. - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDsdPWdIO4ozGCH14RAsTyAKCW5mwCJ/cN+UbKICufXwmDIX9/tgCfQLJa LaEL4a4pV7Jhnh3ry/b+CrU= =/FQl -END PGP SIGNATURE- ___ 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] a quit that actually quits
Brett Cannon wrote: And Tim had a good point about PDAs and such; how are they supposed to exit? What if someone picked up Python for their Nokia S60 phone and tried to exit from the interpreter? Unless Nokia has tweaked something I don't know how they would know to exit without knowing about sys.exit() or raising SystemExit since I wouldn't know how to do the equivalent Ctrl-D on a cell phone. The version of Python on my phone (2.2.2) doesn't recognize quit or exit, but there is a soft key conveniently labeled Exit which drops out of the interactive console. ___ 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] Keep default comparisons - or add a second set?
Today, x y will return a consistent result, even if the two objects are not comparable in any meaningful manner.[*] The current plan for Python 3 is to instead raise TypeError. If this really needs to be changed (and I don't think it does), then there should still be a standard way to get a canonical ordering. Jim Fulton asked how this canonical ordering should be defined. The obvious answer is Just like the __lt__ operator today. But it doesn't actually *need* to be that sensible, if there are strong reasons to prefer a simpler ordering. The more I think about it, though, __eq__ really does need to be honored; I don't want an Are these two containers equivalent? test to depend on how well the memory subsystem happened to be working. Given that, also honoring an explicit __lt__ isn't much of an extra burden, and will make the ordering much more useful for debugging and output. The only real question left is what to do when the two objects' classes do not define a comparison between them. Current CPython eventually falls back to the objects' locations in memory. Unfortunately, this isn't stable across different sessions, and can mask some wrong-type bugs. There is no general answer to the lack of stability; if objects from multiple sessions might be compared (Jim Fulton's BTree example), then whatever communication channel mixes the objects will have to provide its own wrapper for fallback comparisons. Taking away the default fallback will (at best) change where bugs are caught, and it won't always be earlier. There is some value in saying unlike objects should not be compared by accident, so I would understand a decision to create two types of sorting. Comparison would raise a TypeError if the pair of objects were not comparable; Ordering would continue on to something consistent, just like sorts do today. The catch is that both operations are needed, and the obvious syntax () should go with the operation whose semantics are not backwards- compatible. Given that, I don't think the separation of operations would clarify code in practice. [*] Paul Moore pointed out that comparing Numeric arrays to other objects does raise a TypeError. But this was an explicit choice, and the Numeric authors had to jump through enough hoops to get this behavior that it isn't likely to be a common problem. -jJ ___ 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] Small any/all enhancement
Of course I already knew all the alternatives using map and the generator expression, but I felt like mine was clearer for a reader, this is probably true but not enough to justify the change. If there is to be any enhancement, I think I would prefer it to be an enhancement to map, so that map's second and subsequent arguments can be sequences or iterables, and its result is an iterable if any of its arguments is an iterable. Unfortunately, that would be an incompatible change :-( ___ 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] deque alternative
Dear Armin, You are mentioning confusingly many levels of PyPy for this argument. This is true, I didn't want to care. This is not directly related to static analysis nor to the JIT. The point is just that while a Python program runs, the implementation can decide to start using a deque-like structure instead of a zero-based array for a given user list. This can be done in any implementation of Python; both in PyPy and in CPython it would be done by adding checks and cases in the code that implements list objects. Correct. It is neither directly related to static analysis nor to JIT, I just drew some line of analogy between how we decide whether to implement a list or a straight array. Mentioning many levels of PyPy might be confusing, but these levels are more related to each other for me than you might expect, or you might just not expect the kind of picture I think to have. I'm of course not confused, but tend to put different levels into relation. PyPy has several levels to attack/approach certain problems. It thinks to insulate them. Actually, it is less insulating but more structuring, trying to attach valid levels of approaches to a problem. This crystallizes as certain ways to implement some ideas in RPython, while it comes up in a different flavor when JIT approaches for one level up are discussed. But all these different approaches have one similar mindset in common, which is always seeking for the best balance between feasibility, simplicity, comprehensibility and elegance, in conjunction with the confidence that we can do better if we do it right. And there are similar patterns to be observed, at every level. PyPy gives me the advantage that I can emit a more or less wild idea and check if it is doable, makes sense, or leads to more problems than it solves. I cannot discuss this on the Python list, because this is always bearing lots of other considerations, where the hardest ones are can we implement it, do people like it, and is it worth it, where the latter was the point why I brought the issue up, at all, trying to ride on Guido's arguments. As much as I like this approach I fear that it will be rejected for CPython, as e.g. lazily concatenated string objects were, on grounds of code obfuscation and unpredictability of performance. But it's PyPy's goal to experiment here :-) No fears needed, I'm not putting my person into it, again. Guido asked me to shut up, a while ago. I did! If I'm showing up from time to time, this is not meant to make him happy, just to remind him on contradictions to himself. You know CPython and its community almost as good as I know, and that I left it to some extent quite a while ago. One reason was the ambiguous decision of what is considerable and what not. This is too much of personality going into it for me. PyPy gives me the chance to discuss things, try things, go wrong, correct myself, and in case of disagreement, nobody would object to create a branch for a new idea until it is approved or I'm healed. This is what I'm missing in CPython, and why I'm feeling well being with PyPy. Stackless is a good example. In PyPy, everybody can decide to go for Stackless and set a compiler option. There is no question asked, everybody agrees that it can be a good thing if you need it, so use it or not. A new feature may be a good thing as well, so let's see if it makes sense, and categorize it if it is of general use, or a special case, which should be treated differently, maybe even by a real branch. The big advantage that we have is that we are not bound to a single, hand-written implementation which has to be maintained by hand. We can try and let the code generator get astray, automatically. We'll fix it and don't worry. Don't worry, I'm not expecting anything positive from python-dev, and the only thing that makes me still unhappy is unreflected abuses of my changed topic, but that's a minor matter of taste :-)) all the best -- chris -- Christian Tismer :^) mailto:[EMAIL PROTECTED] tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/ 14109 Berlin : PGP key - http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ ___ 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] (back to): Linked lists -- (was: deque alternative)
[Martin Blais] Now, it's not all about storage space. What about front-insertion? Everytime I have to type L.insert(0, bli), somewhere that I know runs often I cringe. If I had lists I would be able to express my thoughts more clearly in the computer program. Right now, I cringe, and then I just shrug. Doesn't collections.deque() meet your front-insertion needs? 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/archive%40mail-archive.com
Re: [Python-Dev] Small any/all enhancement
Bob Ippolito wrote: I don't see the harm in a key argument like sorted has, but without a key argument it could be extended to take more arguments like max/ min do for convenience. e.g. any(a, b, c) instead of any((a, b, c)). Hmm, I think you just found the use case for fixing the current lack of support for keyword-only arguments - it allows conveniences like this, while still allowing keyword arguments to tailor function behaviour. For example, min max could grow a key argument analogous to sorted's (e.g. to find the person with the highest score in a list of players). (Guido's already approved the concept of permitting keyword arguments to be supplied after a * entry in a function call. I don't remember if he expressed an opinion on allowing the same syntax in a function definition to define keyword only arguments). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a quit that actually quits
Fredrik a quit/exit command that actually quits, instead of printing a Fredrik you didn't say please! message. I like Fredrik's idea more and more. Without my Unix bifocals it wouldn't occur to me that Ctrl-D is the way to exit. Knowing Ctrl-Z is EOF on Windows, it wouldn't occur to me that I'd also have to hit Return. Without my Python shades I'd never guess to exit via raise SystemExit. While the raise command is one true way, it certainly won't occur to newbies. I have no idea how I'd exit from Pippy or from the interpreter prompt on a Nokia phone without it. In short, I think it makes a lot of sense to support a bare exit and/or quit as a completely intuitive platform-independent newbie-friendly way to exit the interpreter. Skip ___ 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] a quit that actually quits
On Wed, 28 Dec 2005, Fredrik Lundh wrote:
Ka-Ping Yee wrote
It sounds to me like what is being proposed amounts to essentially
promote sys.exit to a builtin.
no, what's being proposed is what the subject says: a quit/exit command
that actually quits, instead of printing a you didn't say please! message.
Okay, that would be fine. It's just that the solutions so far that
work without parentheses are a bit too magical for me.
Fredrik's NameError-based proposal (exit when there's an exception
with no tb_next that says name 'exit' is not defined) causes the
interpreter to quit when you enter any expression involving 'exit'.
print exit # seems surprising
[3, 4, 5, exit] # seems surprising
'a' in 'xyz' or exit# desirable or undesirable?
del exit# actually happened to me
x = exit# seems surprising
Reinhold's proposal (exit when sys._getframe(1).f_code.co_names
is (exit,)) causes the interpreter to quit whenever any function
attempts to print out or represent 'exit', as long as it doesn't
mention any other variables.
print exit # seems surprising
[3, 4, 5, exit] # seems surprising
'a' in 'xyz' or exit# desirable or undesirable?
def foo():
print exit
foo() # seems surprising
I'd be happy with having Python exit when the user types just plain
'exit' without parentheses, but only in that case, not others.
However, i'm starting to think that may be impossible to implement.
I can't think of any way to make 'print exit' not exit, for example.
('exit' is a shorthand for 'exit' or 'quit' above.)
-- ?!ng
___
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 + Visual C++ 8.0?
--- Adal Chiriliuc [EMAIL PROTECTED] wrote: Then you need to run mt.exe to embedd the manifest: mt.exe /outputresource:cctbx_math_ext.pyd;#2 /manifest cctbx_math_ext.pyd.manifest That is the magic trick! After applying the mt command to all our extensions most of our unit tests work even with the VC7.1 compiled Python. I am very optimistic I can get all our tests to work with a few C++ adjustments (related to the new way STL iterators are implemented). Thanks a lot! I could not have figured this out myself in a million years. Cheers, Ralf __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ ___ 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] Keep default comparisons - or add a second set?
Jim Jewett wrote: Jim Fulton asked how this canonical ordering should be defined. The obvious answer is Just like the __lt__ operator today. But it doesn't actually *need* to be that sensible, if there are strong reasons to prefer a simpler ordering. The more I think about it, though, __eq__ really does need to be honored; I don't want an Are these two containers equivalent? test to depend on how well the memory subsystem happened to be working. Given that, also honoring an explicit __lt__ isn't much of an extra burden, and will make the ordering much more useful for debugging and output. Tell me: a = [0] * 3 b = [0] * 3 a[0] = b b[0] = a What order should a and b have? --Scott David Daniels [EMAIL PROTECTED] ___ 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] Small any/all enhancement
Alex Martelli wrote:
On Dec 27, 2005, at 12:45 PM, Valentino Volonghi aka Dialtone wrote:
...
any(iterable, test=bool) and all(iterable, test=bool)
...
any(some_objects, test=operator.attrgetter('some_attribute'))
Why would that be better than
any(o.some_attribute for o in some_objects)
?
def zerop(x):
return x==0
all(some_objects, zerop)
and why would that be better than
all(o==0 for o in some_objects)
?
all() can be terminated at the first false element. For very long
sequences this has important performance benefits. Besides, it makes
all(seq,pred) the equivalent of pred(seq[0]) and pred(seq[1]) and
pred(seq[2]) and ...
___
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] a quit that actually quits
Ka-Ping Yee wrote: Fredrik's NameError-based proposal (exit when there's an exception with no tb_next that says name 'exit' is not defined) causes the interpreter to quit when you enter any expression involving 'exit'. print exit # seems surprising [3, 4, 5, exit] # seems surprising 'a' in 'xyz' or exit# desirable or undesirable? del exit# actually happened to me x = exit# seems surprising the easiest way to solve this that I can think of right now is to add a new sys variable that contains a copy of the most recent line read by the interactive prompt. if sys.commandline.strip() in (exit, quit): sys.exit() /F ___ 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
