Re: [Python-Dev] Py3k: Except clause syntax
Greg Ewing wrote: > For Py3k, any thoughts on changing the syntax of > the except clause from > >except , : > > to > >except as : > > so that things like > >except TypeError, ValueError: > > will do what is expected? +1 here I actually had a go at figuring how to do this a long while back, but I have no idea what I ended up doing with the code (I think it died along with the old hard drive in my laptop). 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
[Python-Dev] towards a stricter definition of sys.executable
the definition of sys.executable is a bit unclear, something that has led to
incompatible use in deployed code.
the docstring for sys.executable says "pathname of this Python interpreter",
which can be interpreted as either
a) sys.executable points to the executable that was used to load the
Python interpreter library/dll.
this use is supported by the docstring and the implementation, and is quite
common in the wild. an application using this interpretation may
- call sys.executable to run another instance of itself
- extract data from resources embedded in (or attached to) sys.executable
- locate configuration data etc via os.path.dirname(sys.executable)
etc.
or
b) sys.executable points to a standard Python interpreter executable of
the same version, and having the same library, as the currently running
interpreter instance.
this use is supported by more strict interpretation of the word
"interpreter"
(as an executable, rather than an implementation DLL), and is quite common
in the wild. an application using this interpretation may
- call sys.executable to run a Python script in the same environment as
itself.
etc.
or
c) sys.executable points to the file containing the actual ("this")
interpreter. I
haven't seen any code that assumes this, probably because no implementation
uses this interpretation...
for programs that are invoked via the standard interpreter, case (a) and (b)
are of
course identical.
the problem is when the interpreter library is embedded in some other
application;
should sys.executable be set to the actual EXE used to start the program, or to
something else ? if it's set to something else, how can that application do
the things
that's described under (a) ?
to fix this, I propose adding another sys variable; for example, let
sys.executable
keep behaving like case (a) (which is how it's implemented today), and add a new
sys.python_executable for case (b). the latter can then be set to None if a
proper
interpreter cannot be located.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k: Except clause syntax
Greg Ewing wrote: > For Py3k, any thoughts on changing the syntax of > the except clause from > >except , : > > to > >except as : > > so that things like > >except TypeError, ValueError: > > will do what is expected? +1. Fits well with the current use of "as". Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Baptiste Carvello wrote: > [Baptiste] >> while manipulating binary data will happen mostly with bytes objects, >> some >> operations are better done with ints, like the bit manipulations with the >> &|~^ >> operators. [Greg] > Why not just support bitwise operations directly > on the bytes object? Well, what's the result of bytes([1,0,0])^ bytes([1,0]) ? Is it bytes([0,0,0]) (à la little-endian) or is it bytes([1,1,0]) (straight conversion to base-256)? Or perhaps throw a ValueError if the sizes differ? These details should be considered in the PEP. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch to MS VC++ 2005 ?!
"M.-A. Lemburg" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Microsoft has recently released their express version of the Visual C++. > Given that this version is free for everyone, wouldn't it make sense > to ship Python 2.5 compiled with this version ?! > >http://msdn.microsoft.com/vstudio/express/default.aspx Link to the middle of a previous thread about the same option: http://mail.python.org/pipermail/python-dev/2005-November/058052.html Link describes hands-on experience by Paul Moore. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k: Except clause syntax
On 3/16/06, Georg Brandl <[EMAIL PROTECTED]> wrote: > +1. Fits well with the current use of "as". I like it, but wonder about the false parallels below. My initial reaction is it's not worth worrying about as it's easy to learn as part of the import or except statements, and should do the right thing. Nobody would expect the second import to rename both items to q, and the first except clause would be a SyntaxError. from foo import bar as b, quux as q except TypeError as te, IndexError as ie from foo import bar, quux as q except TypeError, IndexError as e Michael -- Michael Urman http://www.tortall.net/mu/blog ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] towards a stricter definition of sys.executable
When I added this my intention was a mixture of (b) and (c) -- I
wasn't thinking of situations where there was a difference. (If you
remember Python's very early history, embedding wasn't something I had
anticipated -- hence the "Great Renaming".)
The use that I had in mind does things like os.system(sys.executable +
" foo.py") to run foo.py in a separate process. Any additional use
(e.g. digging data out of it or finding related files by parsing its
pathname) is a highly platform dependent activity; embedding can be
seen as a change in platform. For finding related files,
sys.exec_prefix and sys.prefix should be used. Digging data out of the
file itself never even occurred to me -- it assumes things like
executable format etc. that are typically beyond my understanding as a
portable language designer.
When Python is embedded in another app (e.g. mod_python), I would
expect sys.executable to be meaningless and its use to be undefined.
None would be a good value in that case. sys.prefix / exec_prefix may
or may not have a useful meaning in such an environment, depending on
how the standard library is made accessible.
Can you say more about the motivation for wanting this reinterpreted?
--Guido
On 3/16/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> the definition of sys.executable is a bit unclear, something that has led to
> incompatible use in deployed code.
>
> the docstring for sys.executable says "pathname of this Python interpreter",
> which can be interpreted as either
>
> a) sys.executable points to the executable that was used to load the
> Python interpreter library/dll.
>
> this use is supported by the docstring and the implementation, and is
> quite
> common in the wild. an application using this interpretation may
>
> - call sys.executable to run another instance of itself
> - extract data from resources embedded in (or attached to) sys.executable
> - locate configuration data etc via os.path.dirname(sys.executable)
>
> etc.
>
> or
>
> b) sys.executable points to a standard Python interpreter executable of
> the same version, and having the same library, as the currently running
> interpreter instance.
>
> this use is supported by more strict interpretation of the word
> "interpreter"
> (as an executable, rather than an implementation DLL), and is quite common
> in the wild. an application using this interpretation may
>
> - call sys.executable to run a Python script in the same environment as
> itself.
>
> etc.
>
> or
>
> c) sys.executable points to the file containing the actual ("this")
> interpreter. I
> haven't seen any code that assumes this, probably because no
> implementation
> uses this interpretation...
>
> for programs that are invoked via the standard interpreter, case (a) and (b)
> are of
> course identical.
>
> the problem is when the interpreter library is embedded in some other
> application;
> should sys.executable be set to the actual EXE used to start the program, or
> to
> something else ? if it's set to something else, how can that application do
> the things
> that's described under (a) ?
>
> to fix this, I propose adding another sys variable; for example, let
> sys.executable
> keep behaving like case (a) (which is how it's implemented today), and add a
> new
> sys.python_executable for case (b). the latter can then be set to None if a
> proper
> interpreter cannot be located.
>
>
>
>
>
> ___
> Python-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] towards a stricter definition of sys.executable
Guido van Rossum wrote: > For finding related files, sys.exec_prefix and sys.prefix should be used except that they're defined in terms of where the standard library is: prefix -- prefix used to find the Python library exec_prefix -- prefix used to find the machine-specific Python library there are scenarios (e.g. with exemaker) where several applications share a Python library / Python DLL, but there's no python.exe in sight. > When Python is embedded in another app (e.g. mod_python), I would > expect sys.executable to be meaningless and its use to be undefined. > None would be a good value in that case. sys.prefix / exec_prefix may > or may not have a useful meaning in such an environment, depending on > how the standard library is made accessible. > > Can you say more about the motivation for wanting this reinterpreted? well, I'm not asking for a reinterpretation as much as a clarification, and possibly some implementation tweaks (since the current code implements approach (a) by default). how about this alternative ? (extended (b)). d) If Python was started from a standard Python interpreter, sys.executable contains the full path to this interpreter. If not, or if the path could not be determined, sys.executable is set to None. If Python is embedded in another environment, that environment may set the executable to a corresponding interpreter, or leave it set to None. An embedding application may set sys.app_executable to point to the application executable. _PySys_Init should probably be modified to set sys.executable to None instead of Py_GetProgramFullPath(); the latter should be done in Py_Main (or in main() ?) when running under a standard interpreter, sys.app_executable could be left undefined, set to None, or set to the same thing as sys.executable. leaving it undefined is good enough for me. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] towards a stricter definition of sys.executable
Fredrik Lundh wrote:
> the definition of sys.executable is a bit unclear, something that has led to
> incompatible use in deployed code.
>
> the docstring for sys.executable says "pathname of this Python interpreter",
> which can be interpreted as either
>
> a) sys.executable points to the executable that was used to load the
> Python interpreter library/dll.
>
> this use is supported by the docstring and the implementation, and is
> quite
> common in the wild. an application using this interpretation may
>
> - call sys.executable to run another instance of itself
> - extract data from resources embedded in (or attached to) sys.executable
> - locate configuration data etc via os.path.dirname(sys.executable)
>
> etc.
>
> or
>
> b) sys.executable points to a standard Python interpreter executable of
> the same version, and having the same library, as the currently running
> interpreter instance.
>
> this use is supported by more strict interpretation of the word
> "interpreter"
> (as an executable, rather than an implementation DLL), and is quite common
> in the wild. an application using this interpretation may
>
> - call sys.executable to run a Python script in the same environment as
> itself.
>
> etc.
>
> or
>
> c) sys.executable points to the file containing the actual ("this")
> interpreter. I
> haven't seen any code that assumes this, probably because no
> implementation
> uses this interpretation...
>
> for programs that are invoked via the standard interpreter, case (a) and (b)
> are of
> course identical.
py2exe used the a) interpretation. It uses sys.executable to find the exe that
is currently
running, for registration of COM servers, and for finding resources in the exe:
the manifest
file that's needed for GUI applications on WindowsXP to give the native XP look
and feel,
icons, typelibs, and more.
> the problem is when the interpreter library is embedded in some other
> application;
> should sys.executable be set to the actual EXE used to start the program, or
> to
> something else ? if it's set to something else, how can that application do
> the things
> that's described under (a) ?
The use case for b) 'call sys.executable to run a Python script' makes no sense
for
a py2exe'd application.
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] towards a stricter definition of sys.executable
Guido van Rossum wrote: > Can you say more about the motivation for wanting this reinterpreted? Fredrik Lundh wrote: > d) If Python was started from a standard Python interpreter, My understanding matches Guido's description, so I'm not sure any changes are needed. Since an embedding application can provide an alternate API to the needed information, that seems sufficient. That said, option "d" seems like a reasonable approach as well, and I'd have no objection to the change. I suggest the sys.application instead of sys.app_executable for the new variable, but that's minor. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-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] Problem with module loading on multi-arch?
I just installed TwistedSumo-2006-02-12 on x86_64, and noticed a problem. It installs arch-dep stuff into /usr/lib64/python2.4/site-packages/twisted, and arch-indep into /usr/lib/python2.4/site-packages/twisted as it should. But: from twisted.web import html exceptions.ImportError: No module named web I'm guessing that what's happening is that since there is an /twisted, we never find the module /twisted/web. If my analysis (guess) is correct, I think we have a problem with the module search. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
"Christos Georgiou" <[EMAIL PROTECTED]> wrote: > Well, what's the result of > > bytes([1,0,0])^ bytes([1,0]) > > ? Is it bytes([0,0,0]) (à la little-endian) or is it bytes([1,1,0]) > (straight conversion to base-256)? Or perhaps throw a ValueError if the > sizes differ? It's a ValueError. If the sizes matched, it would be a per-element bitwise xor. > These details should be considered in the PEP. They aren't considered because they are *obvious* to most (if not all) sane people who use Python. Think of future bytes behavior to be similar to current array behavior, with a few bits and pieces added to make life easier (like all of the current string methods, etc.) - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
[Trent Mick wrote] > [Martin v. Loewis wrote] > > Tim Peters wrote: > > > I'd say instead that they should never be skipped: the real > > > difference on your box is the expected _outcome_ in the third > > > category. > > > > That is indeed more reasonable than what I proposed. > > I'll do this tonight or tomorrow. Done now (finally). Trent -- Trent Mick [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
[Python-Dev] Python Library Reference top page too long
The contents page for the Python Library Reference
("http://docs.python.org/dev/lib/lib.html";) has become much too long. I
suggest that it should be designed like the top page for portal web
sites. For example see "http://www.dmoz.org/";. I suggest that "lib.html"
be replaced by "lib_index.html" and "lib_contents.html". The latter is
the current "lib.html". "lib_index.html" should look something like:
Front Matter
Full Contents
1. Introduction
2. Built-in Objects
functions, types, exceptions, constants
3. File and Directory Access
open, file objects, os, os.path, ...
4. Generic Operating System Services
os, time, optparse, ...
5. Python Runtime Services
sys, __main__, __future__, ...
6. String Services
type str, string, re, ...
7. Numeric and Mathematical Modules
math, random, decimal, ...
...
Both "lib_index.html" and "lib_contents.html" should be accessible from
the top Python Documentation page.
Here are two principles I feel would be useful to follow. References are
to the Python 2.5 documentation at
"http://docs.python.org/dev/lib/lib.html";.
1. Important, commonly used, or confusing modules should be near the
top. The things I look up the most are os.path, os (files and
directories), and string attributes. "sys" should also be near the top
because of "sys.argv", "sys.stderr", and "sys.exit". Etc, etc.
2. Put cross-links everywhere. For example the documentation for built
in function "file" has a link to "File Objects". There should also be a
link to "open()" and to sections 13.1.2, 13.1.3, 13.1.4, and chapter 10.
(What became of the often proposed and long overdue reorganization of "os"?)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] towards a stricter definition of sys.executable
> Fredrik Lundh wrote: > > a) sys.executable points to the executable that was used to load the > > Python interpreter library/dll. > > > > this use is supported by the docstring and the implementation, and is > > quite > > common in the wild. an application using this interpretation may > > > > - call sys.executable to run another instance of itself > > - extract data from resources embedded in (or attached to) > > sys.executable > > - locate configuration data etc via os.path.dirname(sys.executable) > > > > etc. [Thomas Heller wrote] > py2exe used the a) interpretation. It uses sys.executable to find the exe > that is currently > running, for registration of COM servers, and for finding resources in the > exe: the manifest > file that's needed for GUI applications on WindowsXP to give the native XP > look and feel, > icons, typelibs, and more. > > The use case for b) 'call sys.executable to run a Python script' makes no > sense for > a py2exe'd application. Ditto on both counts for PyXPCOM (Python embedded in Mozilla). Trent -- Trent Mick [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] towards a stricter definition of sys.executable
> > > a) sys.executable points to the executable that was used to load the > > > Python interpreter library/dll. > > > > > > this use is supported by the docstring and the implementation, and is > > > quite > > > common in the wild. an application using this interpretation may Thomas: > > py2exe used the a) interpretation. /.../ > > The use case for b) 'call sys.executable to run a Python script' makes > > no sense for a py2exe'd application. Trent: > Ditto on both counts for PyXPCOM (Python embedded in Mozilla). Looks like I might have to withdraw my (d) proposal, and, once again, suggest that we stick to the "GetProgramFullPath" sense, as implemented, and add a new variable for the originally intended but not really implemented "GetInter- preterPath" sense... 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] Still looking for volunteer to run Windows buildbot
[Trent Mick, on changing test_winsound to expect RuntimeError on a box without a sound card] > Done now (finally). Cool -- thanks! I merged that to the 2.4 branch, and (of course) your buildbot slave passes the tests on that too now. Green is a lovely color :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] towards a stricter definition of sys.executable
At 07:40 PM 3/16/2006 +0100, Fredrik Lundh wrote: >Looks like I might have to withdraw my (d) proposal, and, once again, suggest >that we stick to the "GetProgramFullPath" sense, as implemented, and add a >new variable for the originally intended but not really implemented "GetInter- >preterPath" sense... Note that the stdlib and tools often use the (b) interpretation. For example, the distutils does byte-compilation of files by invoking sys.executable. So these would need to be changed. (This in fact is why I couldn't use exemaker to wrap easy_install on Windows and had to create my own wrapper that exec()'s Python rather than linking to it.) Basically, no matter how this is clarified, some code somewhere is going to have to change. (On the bright side, we could get rid of the distutils hack in 2.5 if compile() allowed you to set the optimization level.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] towards a stricter definition of sys.executable
Fredrik Lundh schrieb: >how about this alternative ? (extended (b)). > >d) If Python was started from a standard Python interpreter, >sys.executable contains the full path to this interpreter. If not, >or if the path could not be determined, sys.executable is set to >None. > > Our registration code for Windows services and COM servers and some other specific things rely on the fact, that sys.executable contains the name of the binary, that is actually running (either the full path of python[.exe] or the full path of the frozen application executable), so please don't touch sys.executable. Ulli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
Martin v. Löwis wrote: > Thomas Heller wrote: >> BTW: Is a "porting guide" to make extension modules compatible with 2.5 >> available somewhere? PEP 353 scratches only the surface... > > Wrt. ssize_t changes, PEP 353 is meant to be comprehensive. Which > particular aspect are you missing? I suggest to change this: #if PY_VERSION_HEX < 0x0205 typedef int Py_ssize_t; #endif with this: #if (PY_VERSION_HEX < 0x0205) typedef int Py_ssize_t; #define lenfunc inquiry #define readbufferproc getreadbufferproc #define writebufferproc getwritebufferproc #define segcountproc getsegcountproc #define charbufferproc getcharbufferproc #define ssizeargfunc intargfunc #define ssizessizeargfunc intintargfunc #define ssizeobjargproc intobjargproc #define ssizessizeobjargproc intintobjargproc ... more defines #endif Maybe a complete list of defines needed can be given? Then, from only reading the PEP without looking up the sources, it is not clear to me what the PY_SIZE_T_CLEAN definition does. Finally, the format codes to use for Py_ssize_t arguments passed to PyBuild_Value, PyString_FromFormat, PyObject_CallFunction (and other functions) are not mentioned at all. Thanks, 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] Problem with module loading on multi-arch?
Neal Becker wrote: > I'm guessing that what's happening is that since there is an > /twisted, we never find the module /twisted/web. If > my analysis (guess) is correct, I think we have a problem with the module > search. That is quite possible. I keep applying patches from people who claim to know how things on AMD64 linux work, much without questioning them. It is quite possible that one of these patches broke something. I'm happy to revert or augment them if needed. Somebody should define how things ought to work, implement a patch that both includes a documentation and an implementation of these decisions, and then keep an eye on patches that might break this design. 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] Py3k: Except clause syntax
Greg Ewing a écrit : >except as : > what about except with : a program dies "with" an error message, not "as" an error message. ciao, BC ___ Python-Dev mailing list Python-Dev@python.org 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 Library Reference top page too long
Edward C. Jones wrote:
> The contents page for the Python Library Reference
> ("http://docs.python.org/dev/lib/lib.html";) has become much too long.
I disagree. It serves my purposes very well: I usually search in the
page for a keywork I think should be there. If the page was broken
into multiple pages, that would break.
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] Py3k: Except clause syntax
In article <[EMAIL PROTECTED]>, Greg Ewing <[EMAIL PROTECTED]> wrote: > For Py3k, any thoughts on changing the syntax of > the except clause from > >except , : > > to > >except as : > > so that things like > >except TypeError, ValueError: > > will do what is expected? Brilliant. I may be showing my clumsiness, but I catch multiple exceptions so rarely that I often stumble over this. -- 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] towards a stricter definition of sys.executable
On Thu, 2006-03-16 at 12:02 +0100, Fredrik Lundh wrote: > a) sys.executable points to the executable that was used to load the > Python interpreter library/dll. > > this use is supported by the docstring and the implementation, and is > quite > common in the wild. an application using this interpretation may > > - call sys.executable to run another instance of itself > - extract data from resources embedded in (or attached to) sys.executable > - locate configuration data etc via os.path.dirname(sys.executable) Yep, that's how our embedded apps use sys.executable. > to fix this, I propose adding another sys variable; for example, let > sys.executable > keep behaving like case (a) (which is how it's implemented today), and add a > new > sys.python_executable for case (b). the latter can then be set to None if a > proper > interpreter cannot be located. As long as sys.executable behaving like a) doesn't change, that seems fine with me. ;) -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org 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 Library Reference top page too long
In article <[EMAIL PROTECTED]>,
"Edward C. Jones" <[EMAIL PROTECTED]> wrote:
> The contents page for the Python Library Reference
> ("http://docs.python.org/dev/lib/lib.html";) has become much too long. I
> suggest that it should be designed like the top page for portal web
> sites. For example see "http://www.dmoz.org/";. I suggest that "lib.html"
> be replaced by "lib_index.html" and "lib_contents.html". The latter is
> the current "lib.html". "lib_index.html" should look something like:
>
> Front Matter
> Full Contents
> 1. Introduction
> 2. Built-in Objects
> functions, types, exceptions, constants
> 3. File and Directory Access
> open, file objects, os, os.path, ...
> 4. Generic Operating System Services
> os, time, optparse, ...
> 5. Python Runtime Services
> sys, __main__, __future__, ...
> 6. String Services
> type str, string, re, ...
> 7. Numeric and Mathematical Modules
> math, random, decimal, ...
I agree it needs work and your suggestion sounds promising.
With the manual as it stands, I find it *very* difficult to find what I
want. Here are two typical queries I find painful:
1) Look up a string method.
- I usually think "OK, a string is a sequence type, so jump there".
- Jump to that link and you get a page that is completely irrelevant
*except* that at the *bottom* (if one gets down that far) is a nice list
of subtopics, one of which is the "right" link.
The real problem here is that if one jumps too deeply on the first go,
the page doesn't list sub-topics and related topics at the beginning.
Instead maybe there's a "subtopics" section at the end, but that's a
lousy place for it.
(Thus if I was less clever and just jumped to "Built-in Classes" I'd get
a nicely detailed TOC that has exactly the link I want.)
2) Look up the special methods for a sequence object (the __xxx___
methods that make one's own class look like a sequence). I've found them
before but every time I want them it's another @[EMAIL PROTECTED] wade
through the manual (I just tried to find them again--no luck). Thank god
for Python Essential Reference, dated as it is.
Fundamentally I think what's wanted is:
- Another level of sub-TOCs, e.g. one for "Sequence Types", "Mapping
Types", etc. Every page that has sub-topics or intimately related should
have a list of them at the beginning.
- The special methods for a given type of class would make a really good
"intimately related" topic for "Sequence Types" and "Mapping Types".
Another thing that would be *really* useful is to list the actual
built-in types with the category. For example:
Sequence Types (str, unicode, list, tuple, buffer, xrange)
Mapping Types (dict)
-- 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] Python Library Reference top page too long
Martin v. Löwis wrote:
> Edward C. Jones wrote:
>> The contents page for the Python Library Reference
>> ("http://docs.python.org/dev/lib/lib.html";) has become much too long.
>
> I disagree. It serves my purposes very well: I usually search in the
> page for a keywork I think should be there. If the page was broken
> into multiple pages, that would break.
Perhaps the lib page could have a portal-like index like the one Edward
Jones suggested at the top, followed the full list w/ descriptions?
That way, it would be easier to pick out a module with a fairly quick
glance, but searching the page would still work.
-Edward
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
Josiah Carlson a écrit : > They aren't considered because they are *obvious* to most (if not all) > sane people who use Python. They are not *that* obvious. Logical operations on ints have allowed users to forget about size (and shoot themselves in the foot from time to time). Or is 1^(~1) == -1 obvious ? Well, maybe that's not sane either :-) > Think of future bytes behavior to be > similar to current array behavior, with a few bits and pieces added to > make life easier (like all of the current string methods, etc.) > I didn't get before that the array behavior really *defined* the bytes behavior. OK, I'll keep that in mind. Cheers, BC ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making staticmethod objects callable?
Guido van Rossum wrote: > There's no need to change Python so that people coming from other > languages won't make silly mistakes, is there? Is that really a mistake... Yes, it's a mistake since staticmethod is a descriptor, but isn't it in a sense an implementation detail, particularly for a newbie? As Steven pointed, it is forcing to learn about descriptors. But I don't feel comfortable with that; I've always seen Python as a language that you can use with minimal knowledge. Again, I'm not thinking about anyone on this list. > BTW I question the claimed reflex -- assuming by "other languages" you > mean Java or C++ (the only languages I know that *have* static > methods) -- since those languages don't have the ability to call > methods (static or otherwise) at class definition time. Java, C++, C#. Yes, you're right, but the way I see it the first thing you learn in Python is that everything is dynamic. So I understand the reflex to quickly adapt the way you code to the new capabilities of Python. > So perhaps you need to dig deeper to find out *why* this is a recurring issue. I think I understand why this is a recurring issue, but maybe I'm not good at explaining why. In the end, on that specific issue I think there's something to improve for newbies. The error message "'staticmethod' object is not callable" could also be changed to something like "'staticmethod' object is a descriptor and is not callable". Personally, I prefer the "it just works to ease your life" compromise (it doesn't hurt much, no?). Note that it's not a big deal anyway and I hope it doesn't look like I want to argue; I just want to explain the issue. Regards, Nicolas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
Thomas Heller wrote: > Martin v. Löwis wrote: >> Thomas Heller wrote: >>> BTW: Is a "porting guide" to make extension modules compatible with 2.5 >>> available somewhere? PEP 353 scratches only the surface... >> Wrt. ssize_t changes, PEP 353 is meant to be comprehensive. Which >> particular aspect are you missing? > > I suggest to change this: > > #if PY_VERSION_HEX < 0x0205 > typedef int Py_ssize_t; > #endif > > with this: > > #if (PY_VERSION_HEX < 0x0205) > typedef int Py_ssize_t; > #define lenfunc inquiry > #define readbufferproc getreadbufferproc > #define writebufferproc getwritebufferproc > #define segcountproc getsegcountproc > #define charbufferproc getcharbufferproc > #define ssizeargfunc intargfunc > #define ssizessizeargfunc intintargfunc > #define ssizeobjargproc intobjargproc > #define ssizessizeobjargproc intintobjargproc > ... more defines > #endif > > Maybe a complete list of defines needed can be given? > > Then, from only reading the PEP without looking up the sources, > it is not clear to me what the PY_SIZE_T_CLEAN definition does. > > Finally, the format codes to use for Py_ssize_t arguments passed to > PyBuild_Value, > PyString_FromFormat, PyObject_CallFunction (and other functions) are not > mentioned at all. Since this change is going to affect a lot of 3rd party extensions, I'd also like to see a complete list of public APIs that changed and how they changed (including the type slots) Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 16 2006) >>> 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] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
M.-A. Lemburg wrote: > Since this change is going to affect a lot of 3rd party extensions, > I'd also like to see a complete list of public APIs that changed and > how they changed (including the type slots) You can construct this list easily by comparing the header files of the previous and the current release. Please contribute a patch that presents these changes in a form that you would consider acceptable. 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] bytes thoughts
Christos Georgiou wrote: > Well, what's the result of > > bytes([1,0,0])^ bytes([1,0]) > > ? Is it bytes([0,0,0]) (à la little-endian) or is it bytes([1,1,0]) > (straight conversion to base-256)? Or perhaps throw a ValueError if the > sizes differ? In the interests of refusing the temptation to guess, I'd go for the ValueError. Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
Baptiste Carvello <[EMAIL PROTECTED]> wrote: > Josiah Carlson a écrit : > > > They aren't considered because they are *obvious* to most (if not all) > > sane people who use Python. > > They are not *that* obvious. Logical operations on ints have allowed users to > forget about size (and shoot themselves in the foot from time to time). Or is > 1^(~1) == -1 obvious ? Well, maybe that's not sane either :-) I find most operations involving ~ to be insane (just a personal opinion), but in this case, if one assumes two's compliment arithmetic (which seems fairly reasonable considering current standard platforms), an integer, all of whose bits are 1, dictates that the value be -1. An insane use of ~, but a sane result. *shrug* - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem with module loading on multi-arch?
"Martin v. Löwis" wrote: > Neal Becker wrote: >> I'm guessing that what's happening is that since there is an >> /twisted, we never find the module /twisted/web. >> If my analysis (guess) is correct, I think we have a problem with the >> module search. > > That is quite possible. I keep applying patches from people who claim to > know how things on AMD64 linux work, much without questioning them. It > is quite possible that one of these patches broke something. I'm happy > to revert or augment them if needed. > > Somebody should define how things ought to work, implement a patch that > both includes a documentation and an implementation of these decisions, > and then keep an eye on patches that might break this design. > OK, let's talk about it. 1. Does it make sense to have both /app/subpackage and /app/subpackage ? My answer: definitely yes. We already agree that we should have both site-dep for binary code and site-indep for python code, so there is no way to avoid this. 2. What should the module search do? I don't know the details of the current algorithm, but clearly it's going to have to deal correctly with the above. One possibility (and maybe this is how it already works?) is that the module search doesn't know anything about site-dep/site-indep, it simply has a list of paths to search. If I did want to try to fix this myself, where would I find the code 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] bytes thoughts
Baptiste Carvello wrote: > They are not *that* obvious. Logical operations on ints have allowed users to > forget about size (and shoot themselves in the foot from time to time). Or is > 1^(~1) == -1 obvious ? Well, maybe that's not sane either :-) It's about as sane as you can get in a world where ints don't have any fixed size. Bytes objects will have a size, on the other hand, and it makes sense to take notice of it. BTW, is anyone else bothered that the term "bytes object" is a bit cumbersome? Also confusing as to whether it's singular or plural. Could we perhaps call it a bytevector or bytearray or something? Greg ___ Python-Dev mailing list Python-Dev@python.org 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 Library Reference top page too long
Russell E. Owen wrote: > Fundamentally I think what's wanted is: > - Another level of sub-TOCs, e.g. one for "Sequence Types", "Mapping > Types", etc. Every page that has sub-topics or intimately related should > have a list of them at the beginning. > - The special methods for a given type of class would make a really good > "intimately related" topic for "Sequence Types" and "Mapping Types". +1 to all that. > Another thing that would be *really* useful is to list the actual > built-in types with the category. For example: > Sequence Types (str, unicode, list, tuple, buffer, xrange) > Mapping Types (dict) +1 Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k: Except clause syntax
Baptiste Carvello wrote: > what about > > except with : > > a program dies "with" an error message, not "as" an error message. No. The exception object you're catching *is* the value, not something which *has* a value. I maintain that "as" is the correct word to use here. Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes thoughts
On 3/16/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > BTW, is anyone else bothered that the term "bytes object" > is a bit cumbersome? Also confusing as to whether it's > singular or plural. Could we perhaps call it a bytevector > or bytearray or something? Doesn't really bother me. You could call it a bytes array (especially since I expect it will start off as a subclass of the array.array class). I'd still like the built-in name to be 'bytes'. -- --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] Py3k: Except clause syntax
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Baptiste Carvello wrote: > >> what about >> >> except with : >> >> a program dies "with" an error message, not "as" an error message. > > No. The exception object you're catching *is* the value, > not something which *has* a value. I maintain that "as" > is the correct word to use here. Besides which, 'with' is a (new) main (compound statement) keyword while 'as' is always subordinate and denoting a name to be used in the sequel. And I also like using it to separate classes to be caught from name binding of instance. tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
> So PythonWin needs to be installed on a Windows buildbot slave, right? FWIW, we are having reasonable success with buildbot service packaged as a py2exe application - just unzip into a directory and go! This has the primary advantage (to me!) of not using the Python installed on the box, thereby avoiding inconvenient "file is in use" errors when you do need to update that Python or similar. As I've been chatting with Trent about recently, I intend updating my buildbot patch to use the win32 "Job" related functions to manage the build subtasks more effectively and potentially guard against the buildbot using too many resources. Sadly though, my buildbot patch has been languishing in their collector without comment, so my motivation is fairly low. Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k: Except clause syntax
Greg> except as : Baptiste> except with : Can I catch multiple exceptions with a single value in this case? Today, I write: try: foo() except (TypeError, KeyError), msg: print msg Either of the above seem like they'd require me to repeat the value, e.g: try: foo() except TypeError with msg, KeyError with msg: print msg Not very Pythonic methinks. 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] Py3k: Except clause syntax
On 3/16/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Baptiste Carvello wrote: > > > what about > > > > except with : > > > > a program dies "with" an error message, not "as" an error message. > > No. The exception object you're catching *is* the value, > not something which *has* a value. I maintain that "as" > is the correct word to use here. I agree. "as" is taking on the use of assignment in statements that are not ``=`` and I say we just keep on with that. Plus Greg's above explanation also makes sense to me; you are binding the exception to a name and treating as if it was called . -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] Py3k: Except clause syntax
Greg Ewing wrote: > Baptiste Carvello wrote: > >> what about >> >> except with : >> >> a program dies "with" an error message, not "as" an error message. > > No. The exception object you're catching *is* the value, > not something which *has* a value. I maintain that "as" > is the correct word to use here. > > Greg I think it reads well with "as" also. +1 To me it's a filter statement. So would catching multiple exceptions have the form: except (, ) as : The value is bound to the name if it's type is in the sequence. This would be an indirect assignment similar to. if value in list: name = value Which you can't do directly because you don't have access to the value yet. That's not too different than import which is also an indirect name binding operation of a value you don't have yet. Cheers, Ron ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k: Except clause syntax
On Mar 16, 2006, at 7:30 PM, Brett Cannon wrote: ... > I agree. "as" is taking on the use of assignment in statements that > are not ``=`` and I say we just keep on with that. Plus Greg's above Hmmm, if we allowed '( as )' for generic expr's we'd make a lot of people pining for 'assignment as an expression' very happy, wouldn't we...? 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
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 392 open ( +6) / 3094 closed ( +5) / 3486 total (+11) Bugs: 907 open (+18) / 5646 closed (+10) / 6553 total (+28) RFE : 213 open ( +1) / 202 closed ( +1) / 415 total ( +2) New / Reopened Patches __ new exit and quit objects (2006-03-09) CLOSED http://python.org/sf/1446372 opened by Georg Brandl zipfile: support for ZIP64 (2006-03-09) http://python.org/sf/1446489 opened by Ronald Oussoren patch for 1441408 compiler fails to spot extended slice (2006-03-09) http://python.org/sf/1446847 opened by Grant Olson Patch for bug 1441486: bad unary minus folding in compiler (2006-03-09) http://python.org/sf/1446922 opened by Grant Olson logging: findCaller() sometimes raises AttributeError (2006-03-10) CLOSED http://python.org/sf/1447410 opened by Kevin J Bluck ConnectRegistry blocks all threads (2006-03-12) http://python.org/sf/1448199 opened by Lars L decorator module (2006-03-12) http://python.org/sf/1448297 opened by Georg Brandl declspec for ssize_t (2006-03-12) http://python.org/sf/1448484 opened by Zooko O'Whielacronx const PyDict_Type ? (2006-03-12) http://python.org/sf/1448488 opened by Zooko O'Whielacronx email.message.py charset can be unicode instance (2006-03-13) http://python.org/sf/1449244 opened by Tokio Kikuchi Splitting CJK codecs from pythoncore dll (2006-03-14) http://python.org/sf/1449471 opened by Hye-Shik Chang Patches Closed __ new exit and quit objects (2006-03-09) http://python.org/sf/1446372 closed by gbrandl logging: findCaller() sometimes raises AttributeError (2006-03-10) http://python.org/sf/1447410 closed by vsajip Several minor fixes for NULL checks, etc. (2006-03-06) http://python.org/sf/1444030 closed by nnorwitz New with semantics (2006-03-08) http://python.org/sf/1445739 closed by nnorwitz Python memory allocator: Free memory (2005-02-15) http://python.org/sf/1123430 closed by tim_one New / Reopened Bugs ___ extended slice behavior inconsistent with docs (2006-03-09) http://python.org/sf/1446619 opened by Steven Bethard bug with xmlrpclib (2006-03-09) http://python.org/sf/1446690 opened by varun bhansaly whatsnew 2.5: pep 353, python -m (2006-03-09) http://python.org/sf/1447031 opened by Gene Tani tkinter Dialog fails when more than four buttons are used (2006-03-10) http://python.org/sf/1447222 opened by Hernan P. Dacharry tkinter Dialog fails when more than four buttons are used (2006-03-10) CLOSED http://python.org/sf/1447234 opened by Hernan P. Dacharry Mac Framework build fails on intel (2006-03-10) http://python.org/sf/1447587 opened by Michael Mondragon make frameworkinstall fails on Intel Macs (2006-03-10) http://python.org/sf/1447607 opened by Michael Mondragon "reindent.py" exposes bug in tokenize (2006-03-10) CLOSED http://python.org/sf/1447633 opened by Edward C. Jones traceback.format_exception_only() and SyntaxError (2006-03-11) http://python.org/sf/1447885 opened by Remy Blank Unable to stringify datetime with tzinfo (2006-03-11) http://python.org/sf/1447945 opened by Ilpo Nyyssönen Defining a class with __dict__ brakes attributes assignment (2006-03-11) http://python.org/sf/1448042 opened by Michal Kwiatkowski problems with too many sockets in FreeBSD (2006-03-12) http://python.org/sf/1448058 opened by aix-d gettext.py breaks on plural-forms header (2006-03-12) http://python.org/sf/1448060 opened by Danilo Segan re search infinite loop (2006-03-12) http://python.org/sf/1448325 opened by Don Allen Convertion error for latin1 characters with iso-2022-jp-2 (2006-03-12) CLOSED http://python.org/sf/1448490 opened by Francois Duranleau asyncore dispatcher.__getattr__() masks self._map (2006-03-12) http://python.org/sf/1448639 opened by Doug White datetime.__init__ cannot be overridden (2006-03-13) CLOSED http://python.org/sf/1448640 opened by Martin Blais Subscript operations generating incorrect code (2006-03-13) CLOSED http://python.org/sf/1448804 opened by Nick Coghlan urllib2+https+proxy not working (2006-03-13) http://python.org/sf/1448934 opened by Rui Martins urllib2+https+proxy not working (2006-03-14) CLOSED http://python.org/sf/1449397 opened by Rui Martins optparse: extending actions missing ALWAYS_TYPES_ACTIONS (2006-03-13) http://python.org/sf/1449311 opened by Christopher Build of readline fails (2006-03-14) CLOSED http://python.org/sf/1450019 opened by Sydney Weidman int() and isdigit() accept non-digit numbers when using unic (2006-03-15) CLOSED http://python.org/sf/1450212 opened by Pierre-Frédéric Caillaud windows python truncates files when reading them (2006-03-15) CLOSED http:
Re: [Python-Dev] Python Library Reference top page too long
Greg Ewing wrote: > Russell E. Owen wrote: > >> Fundamentally I think what's wanted is: >> - Another level of sub-TOCs, e.g. one for "Sequence Types", "Mapping >> Types", etc. Every page that has sub-topics or intimately related should >> have a list of them at the beginning. >> - The special methods for a given type of class would make a really good >> "intimately related" topic for "Sequence Types" and "Mapping Types". > > +1 to all that. I agree that the docs on __special__ methods really are hard to find if you don't know where to look. >> Another thing that would be *really* useful is to list the actual >> built-in types with the category. For example: >> Sequence Types (str, unicode, list, tuple, buffer, xrange) >> Mapping Types (dict) > > +1 If I understand correctly what you mean, that's already done. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
