Re: [Python-Dev] Py3k: Except clause syntax
Greg Ewing wrote: For Py3k, any thoughts on changing the syntax of the except clause from except type, value: to except type as value: 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
Re: [Python-Dev] Py3k: Except clause syntax
Greg Ewing wrote: For Py3k, any thoughts on changing the syntax of the except clause from except type, value: to except type as value: 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. /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/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. /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] 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. 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
[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 arch-dep/twisted, we never find the module arch-indep/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 ? /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] 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] [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 arch-dep/twisted, we never find the module arch-indep/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 type as value: what about except type with value: 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 type, value: to except type as value: 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
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 arch-dep/twisted, we never find the module arch-indep/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 site-dep/app/subpackage and site-indep/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 type with value: 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 type with value: 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 type as value: Baptiste except type with value: 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 type with value: 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 value. -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
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 '(expr as var)' 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
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
