Re: [Python-Dev] Replacement for print in Python 3.0
Greg == Greg Ewing [EMAIL PROTECTED] writes: Greg Stephen J. Turnbull wrote: IMO strings that are being printf'd can probably be assumed to be human readable, and therefore candidates for translation. This Greg That's a dangerous assumption to make, I think. Could be. For me, the name print is associated with a long history of magical behavior that only a human could possibly feel comfortable with. One of the great sins of Pascal was tarring the name write with the same brush! Greg I'd be uncomfortable with having some strings in my program Greg translated automatically and others not. EIBTI here, I Greg feel. If printf is going to be part of a magical family of print* functions that do things like insert interword spacing and EOLs, I have no problem with documenting that among the other magical things that printf does, it translates strings. This is no less explicit than any other function that bundles several more primitive functions. If instead, we come up with a sufficiently excellent set of formatting and interpolation notations that printf isn't magic at all, simply a function that interprets a precisely defined set of explicit notations, then i18n should have its own notation, too. On reviewing the thread, the latter seems to be the direction things are going. Although several people have defended print's magical behaviors, most of them (and several others) seem at least as excited about a printf with a more economical yet powerful set of operators. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can do free software business; ask what your business can do for free software. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Greg Ewing wrote: Maybe backquotes could be repurposed in Py3k for interpolated string literals? backquotes are a PITA to type on many non-US keyboards. /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] Replacement for print in Python 3.0
Fredrik Lundh [EMAIL PROTECTED] writes: Greg Ewing wrote: Maybe backquotes could be repurposed in Py3k for interpolated string literals? backquotes are a PITA to type on many non-US keyboards. Even more since they are especially broken in Windows XEmacs. Thomas ___ Python-Dev mailing list Python-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] international python
This does make me think of the interesting prospect of an internationalised string literal, though (e.g., _This an il8n string). I'm not sure it would be enough of a win over the status quo though, I don't think so either. i18n doesn't require its specific string notation (in addition, dropping _() may make it harder to interface with standard gettext tools). On the hand, international support in Python apps will benefit from: - seamless unicode support: how about making the default Python charset utf-8 instead of ascii ? right now, someone (say an American or English) who does not design his app with non-ascii characters in mind may have a surprise when users enter those characters in customizable fields: for example, debug print statements which end up crashing the app with an UnicodeException on the user's machine, without even a way to diagnose this when the app is a GUI app and stdout is not shown ;)) - simple formatting syntax (the current % operator is quite fine in that regard) As for seamless unicode support, there are also problems sometimes with filenames and filepaths: see e.g. https://sourceforge.net/tracker/?func=detailaid=1283895group_id=5470atid=105470 Regards Antoine. ___ Python-Dev mailing list Python-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] international python
Antoine Pitrou wrote: - seamless unicode support: how about making the default Python charset utf-8 instead of ascii ? right now, someone (say an American or English) who does not design his app with non-ascii characters in mind may have a surprise when users enter those characters in customizable fields: for example, debug print statements which end up crashing the app with an UnicodeException on the user's machine, without even a way to diagnose this when the app is a GUI app and stdout is not shown ;)) using a variable-width default encoding will break stuff that expect string lengths to be constant, or just prefer their character and slice indices to stay where they are. defaulting to replace (or better, an escaping UnicodeEncodeError handler) on the standard output channels would be a better idea. /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] Tools directory (Was RE: Replacement for print in Python 3.0)
On Thu, Sep 08, 2005 at 06:52:59PM -0700, Brett Cannon wrote: Otherwise it is mostly a lack of advertisement and them not being installed by ``make install``. If you just download the soure and Agreed. I've often wished that reindent.py was installed somewhere. Probably the only way is to document the directory. How should we document it? Writing man pages for the scripts and installing them is probably the minimum. Would there also need to be a LaTeX document for all the scripts, or is that overkill? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools directory (Was RE: Replacement for print in Python 3.0)
[Brett Cannon] I assume that the Windows installer includes the Tools/ directory. It installs part of it, not all: C:\Python24\Toolsdir/b i18n pynche Scripts versioncheck webchecker So it's missing these Tools directories: audiopy bgen compiler faqwiz framer freeze modulator msi unicode world Historically, a Tools directory got into the Windows installer iff somone asked for 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] international python
Le vendredi 09 septembre 2005 à 23:09 +1000, Neil Hodgson a écrit : Antoine Pitrou: As for seamless unicode support, there are also problems sometimes with filenames and filepaths: see e.g. https://sourceforge.net/tracker/?func=detailaid=1283895group_id=5470atid=105470 This bug report is using byte string arguments causing byte string processing rather than unicode calls with unicode processing. Windows code that may encounter file paths outside the default locale should stick to unicode for paths. Try converting os.curdir to unicode before calling other functions: os.path.abspath(unicode(os.curdir)) I don't have a Windows machine at hand right now to test it, but, even if this solution works, it breaks the principle of least astonishment: os.path.abspath() should do the Right Thing regardless of what the current locale is. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/8/05, Stephen J. Turnbull [EMAIL PROTECTED] wrote: Could be. For me, the name print is associated with a long history of magical behavior that only a human could possibly feel comfortable with. One of the great sins of Pascal was tarring the name write with the same brush! Well, apart from your personal history, and in the light of future developments, for most people who aren't programmers using dinosaur languages, print will probably mean convert a document to bits of ink on paper or perhaps by extension into the third dimension produce a physical object from a virtual one. (I've seen some amazing demos of the latter at foocamp, even though the equipment is still a bit big to fit in a typical kitchen. :) While I laugh at the naive view of people who write things like Interface equality and neutrality would be a good thing in the language and seriously (? I didn't see a smiley) use this argument to plead for not making print() a built-in, I do think that avoiding the 'print' name would be a good thing if it could be done without ticking off the old-timers. On the third hand, I notice that Java uses read()/write() and class names ending in Stream for a byte-oriented API, and print()/println() with class names ending in Reader/Writer for a text/character-based API. (Some classes provide both print() and write() methods and there the distinction is clearest.) Since Python 3000 is heading in the same direction, I wouldn't mind having some API distinction so it's clearer to the reader whether we are writing binary or or text data. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Fredrik backquotes are a PITA to type on many non-US keyboards. Interesting. On US keyboards they are often easier to type than parens... 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
[Python-Dev] Tools directory (Was RE: Replacement for print in Python 3.0)
How should we document [the tools directory] At the interactive prompt, help() lets me get a list of topics (not including tools), keywords, or modules -- but no mention of tools. I didn't find any references at http://python.org/doc/ The tutorial does mention the standard library (and the library reference documents it), but I didn't find any suggestion in either that there was another library out there under a Tools or Scripts directory. -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] PEP 3000 and new style classes
In article [EMAIL PROTECTED], Tristan Seligmann [EMAIL PROTECTED] wrote: * Lisandro Dalcin [EMAIL PROTECTED] [2005-09-08 13:56:07 -0300]: Yes, you are right. But this way, you are making explicit a behavior that will be implicit in the future. For example, we could also do: two = float(4)/float(2) instead of from future import division two = 4/2 Why does it matter if the single statement you insert is spelled metaclass = type instead of from future import whatever? Remember, unlike the division example, you would only have to insert one statement, as opposed to changing every use of integer division. It matters because metaclass = type is completely obscure. How would any non-expert have a clue what it means? -- Russell ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and new style classes
On Fri, Sep 09, 2005 at 11:31 -0700, Russell E. Owen wrote: In article [EMAIL PROTECTED], Tristan Seligmann [EMAIL PROTECTED] wrote: Why does it matter if the single statement you insert is spelled metaclass = type instead of from future import whatever? Remember, unlike the division example, you would only have to insert one statement, as opposed to changing every use of integer division. It matters because metaclass = type is completely obscure. How would any non-expert have a clue what it means? How would this non-expert have a clue what from __future__ import new_style_classes means? holger ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/8/05, Antoine Pitrou [EMAIL PROTECTED] wrote: Hi, Le jeudi 08 septembre 2005 à 19:12 +0900, Stephen J. Turnbull a écrit : It would be nice to be able to lose the _() calls to gettext(). The function would look to see if a message catalog was available for the current output stream, and if not, do no translation. That doesn't sound right to me. 1. You still need to do automatic extraction of these strings (gettext has tools for that, which rely on the use of the _() function - or any other dedicated function (*)). 2. You can't assume that all strings must be i18n'ed. For example if I'm interfacing with the user via a text-based network protocol which has a field named Length, I don't want that Length field to be replaced with the Japanese translation of the word Length. For i18n, explicit is better than implicit ;) The beauty of _() is that it's at the same time explicit, easily recognizable, and very short to type and read (it doesn't clutter the source code). If I dare say, the % operator has the same qualities. (*) of course more automatization of what gettext does could be a nice improvement too! Here goes something: for applications targeted to the web, where newlines don't matter, the line breaks in _()'ed strings are superfluous. In order to avoid the problem of not being able to fix my strings when reindenting the source, and to avoid the need in general to have newlines in the po files, I added an option to pygettext that allows it to flatten the strings in a single line. This does not break the old functionality, just allows you more flexbility in the input source (you can break strings on multiple lines) and the strings in the catalogs are nicer too (no newlines clutter). I submitted a patch on 2005-01-08, nobody has had time to review/integrate it yet. If you're interested, see [ 1098749 ] Single-line option to pygettext.py http://sourceforge.net/tracker/index.php?func=detailaid=1098749group_id=5470atid=305470 cheers, ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and new style classes
Lisandro Dalcín proposes: Any possibility to add something like from __future__ import new_style_classes Tristan Seligmann writes: Why does it matter if the single statement you insert is spelled metaclass = type instead of from future import whatever? Russell Owen responds: It matters because metaclass = type is completely obscure. How would any non-expert have a clue what it means? Holger asks: How would this non-expert have a clue what from __future__ import new_style_classes means? Mon-expert users can safely assume that any from __future__ import statements are there to future-proof a program or make use of advanced features early. Non-expert users cannot safely assume anything about assignments to __metaclass__ and, in fact, may well break into a cold sweat any time they hear the word metaclass. I'm not saying that it's necessary, but if it were my call (and it isn't) I'd probably not bother to code from __future__ import new_style_classes but I'd probably accept a patch if someone wrote one. I think it would provide a REALLY nice migration path if it were possible to write Python 3.0 code in Python 2.x (for large values of x) so long as you included an appropriate preamble of from __future__ import statements. I don't believe we'll ever get it perfect because there would be a few minor incompatibilities no matter how hard we try, but just imagine how the Perl5 users today would feel if they were told that they could use Perl6 code in the Perl5 interpreter by using the @ .fture. command. I love making Perl users jealous, so I certainly wouldn't vote less than -0 (I don't care so why bother) on a proposal like this one. -- Michael Chermside ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 3000 and iterators
PEP 3000 says (http://www.python.org/peps/pep-3000.html) : Core language - Return iterators instead of lists where appropriate for atomic type methods (e.g. dict.keys(), dict.values(), dict.items(), etc.) Built-in Namespace - Make built-ins return an iterator where appropriate (e.g. range(), zip(), etc.) - Relevant functions should consume iterators (e.g. min(), max()) To be removed: - xrange(): use range() instead [1] Any possibility to add one (or more) __future__ statement to implicitly get this behavior? Any suggestion about naming? -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Python-Dev mailing list Python-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] SIGPIPE = SIG_IGN?
Greetings,
I was wondering, why are we setting SIGPIPE to SIG_IGN
in initsigs():
static void
initsigs(void)
{
#ifdef SIGPIPE
PyOS_setsig(SIGPIPE, SIG_IGN);
#endif
[...]
}
One of the side effects is:
os.system(yes | read any)
yes: standard output: Broken pipe
yes: write error
0
os.system(yes | head -1)
y
yes: standard output: Broken pipe
yes: write error
0
That stops when setting to SIG_DFL:
signal.signal(signal.SIGPIPE, signal.SIG_DFL)
1
os.system(yes | head -1)
y
0
os.system(yes | read any)
0
Out of curiosity, many of the google results for
yes: standard output: Broken pipe are from
Python programs. :-)
Regards,
--
Gustavo Niemeyer
http://niemeyer.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and new style classes
Can you all just stop discussing this? In the last 4 contributions nothing has been added that hasn't been said yet. It's not going to change. Get used to it.There are more important issues. On 9/9/05, Russell E. Owen [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (holger krekel) wrote: On Fri, Sep 09, 2005 at 11:31 -0700, Russell E. Owen wrote: In article [EMAIL PROTECTED], Tristan Seligmann [EMAIL PROTECTED] wrote: Why does it matter if the single statement you insert is spelled metaclass = type instead of from future import whatever? Remember, unlike the division example, you would only have to insert one statement, as opposed to changing every use of integer division. It matters because metaclass = type is completely obscure. How would any non-expert have a clue what it means? How would this non-expert have a clue what from __future__ import new_style_classes means? Because it's plain english. Also because it's easy to look up. For example: google for: - python from __future__ import; the third link is useful, though a bit technical; presumably it's is in the manual somewhere as well - python new style classes python; the first link is useful If and when the __future__ directive under discussion is added, I would try googling for the whole line and probably hit it on the first go. Now try that with metaclass = type. Good luck. I tried all sorts of variants and came up with nothing except a tutorial on metaclasses, which was interesting, but NOT a ready explanation of what metaclass = type does. -- Russell ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and iterators
On 9/9/05, Lisandro Dalcin [EMAIL PROTECTED] wrote: PEP 3000 says (http://www.python.org/peps/pep-3000.html) : Core language - Return iterators instead of lists where appropriate for atomic type methods (e.g. dict.keys(), dict.values(), dict.items(), etc.) Built-in Namespace - Make built-ins return an iterator where appropriate (e.g. range(), zip(), etc.) - Relevant functions should consume iterators (e.g. min(), max()) To be removed: - xrange(): use range() instead [1] Any possibility to add one (or more) __future__ statement to implicitly get this behavior? Any suggestion about naming? For the builtins, it would actually be possible to do this by simply importing an alternate builtins module. Something like from future_builtins import min, max, zip, range For methods on standard objects like dicts it's not really possible either way; the type of a dict is determined by the module containing the code creating it, not the module containing the code using it. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SIGPIPE = SIG_IGN?
I was wondering, why are we setting SIGPIPE to SIG_IGN in initsigs(): Because you can get a SIGPIPE from writing to a socket whose other side has shut down, and we want to turn that into an error. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools directory (Was RE: Replacement for print in Python 3.0)
Jim Jewett wrote: How should we document [the tools directory] At the interactive prompt, help() lets me get a list of topics (not including tools), keywords, or modules -- but no mention of tools. I didn't find any references at http://python.org/doc/ The tutorial does mention the standard library (and the library reference documents it), but I didn't find any suggestion in either that there was another library out there under a Tools or Scripts directory. Even adding something (e.g., Tools/README) to the undocumented modules section of the standard library would be an improvement on the status quo. I also noticed that the Windows installer does *not* install Tools/README.txt, so there isn't even a synopsis of the tools which _are_ included with the Windows installer. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.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] international python
Antoine Pitrou: I don't have a Windows machine at hand right now to test it, but, even if this solution works, it breaks the principle of least astonishment: Astonishment is subjective and so a poor tool to measure by. At one stage Ruby tried to follow the more common formulation principle of least surprise (POLS) but this produced arguments of the following form: I am surprised by X. Therefore, X contradicts POLS. Therefore, X must be fixed. POLS was then abandoned. os.path.abspath() should do the Right Thing regardless of what the current locale is. This was discussed recently and the consensus position was for functions that can not return a value in the default encoding to instead return a unicode value. Correct implementation of this would require not only changing the behaviour of functions returning strings but also those receiving strings (which should treat byte strings as being in the default encoding). This would require a large amount of work, and is unlikely to be performed in the near future. Neil ___ Python-Dev mailing list Python-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] [draft] python-dev Summary for 2005-08-16 through 2005-08-31
If anyone would like to take a break from all this Py3k discussion, please
feel free to read through the following draft for the second August summary.
Checking over the O(N**2) behaviour in StreamReader.readline summary would
be particularly appreciated. As always, any corrections/suggestions should
be sent to me or Steve (steven.bethard at gmail.com). Thanks!
=
Announcements
=
--
PyPy release 0.7.0
--
PyPy_ has a new release, 0.7.0, which is now a fully self-contained Python
implementation. It includes whole-program type inference and translation to
both C and LLVM, a choice of refcounting or Boehm garbage collectors,
language-level compliancy with CPython 2.4.1 and much more. If you haven't
already, now's the time to check it out!
.. _PyPy: http://codespeak.net/pypy/
Contributing thread:
- `PyPy release 0.7.0
http://mail.python.org/pipermail/python-dev/2005-August/055773.html`__
[SJB]
--
New mailbox module
--
Gregory K. Johnson, who's been working with A.M. Kuchling for Google's
Summer of Code, has completed a new version of the mailbox module that
allows the adding and removing of messages. It will be double-checked for
code quality, complete documentation, and full backwards-compatibility and
then hopefully checked in.
Contributing thread:
- `New mailbox module
http://mail.python.org/pipermail/python-dev/2005-August/055652.html`__
[SJB]
=
Summaries
=
str.find
Terry Reedy suggested that str.find() be removed in Python 3.0, in favour of
str.index(); the main issue with str.find() is that it returns -1 on
failure, leading to the common if s.find(sub): bug (which should be if
sub in s:); -1 is also a valid index into a string. Guido agreed that
removal would be a good idea, however Tim Peters pointed out that the
requirement to use a try/except clause can lead to another kind of sloppy
code.
Raymond Hettinger suggested that the ideal solution would be to replace
str.find() with new methods, str.partition() and str.rpartition(), which
work like::
s = ' http://www.python.org'
s.partition('://')
('http', '://', 'www.python.org')
s.rpartition('.')
(' http://www.python', '.', 'org')
s.partition('?')
('' http://www.python.org', '', '')
Replacing str.find() with str.partition() in the standard library generally
resulted in much cleaner and clearer code, without requiring the addition of
try/except blocks. Comments were overwhelmingly in favour of this new
method.
part and cut were suggested as alternative names to partition,
although Raymond is very attached to the partition name.
Contributing threads:
- `Remove str.find in 3.0?
http://mail.python.org/pipermail/python-dev/2005-August/055704.html`__
- `partition() (was: Remove str.find in 3.0?)
http://mail.python.org/pipermail/python-dev/2005-August/055786.html`__
- `Proof of the pudding: str.partition()
http://mail.python.org/pipermail/python-dev/2005-August/055781.html`__
- `partition()
http://mail.python.org/pipermail/python-dev/2005-August/055792.html`__
- `Alternative name for str.partition()
http://mail.python.org/pipermail/python-dev/2005-August/055788.html`__
[TAM]
PEP 348: Exception Reorganization for Python 3.0
This fortnight saw the final demise of `PEP 348`_. This began with `Guido's
agreement`_ to remove bare except: from Python 3.0 entirely. Introducing a
transition plan for this change in Python 3.0 proved problematic, however.
To quote Michael Chermside, no syntax will work in BOTH 2.5 and 3.0. For
example, the proposed Python 3.0 code::
try:
my_result = call_some_library(my_data)
except Exception: # doesn't catch KeyboardInterrupt or SystemExit
report_nonterminal_error()
would need to be written in Python 2.5 as::
try:
my_result = call_some_library(my_data)
except (KeyboardInterrupt, SystemExit):
raise
except:
report_nonterminal_error()
Note that the final ``except:`` in the 2.5 code can't be written as ``except
Exception:`` - Python 2.5 will still allow exceptions that do not derive
from Exception (e.g. string exceptions). Thus deprecating bare ``except:``
would mean that some code would produce warnings, and yet not have any way
to be rewritten that would be upwards-compatible.
As a result, Guido rejected the entire PEP.
.. _PEP 348: http://www.python.org/peps/pep-0348.html
.. _Guido's agreement:
http://mail.python.org/pipermail/python-dev/2005-August/055620.html
Contributing threads:
- `Bare except clauses in PEP 348
http://mail.python.org/pipermail/python-dev/2005-August/055603.html`__
- `FW: Bare except clauses in PEP 348
http://mail.python.org/pipermail/python-dev/2005-August/055622.html`__
- `rev. 1.9 of PEP 348: Raymond tested, Guido approved
