Re: [Python-Dev] towards a stricter definition of sys.executable
Fred L. Drake, Jr. wrote: 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. the problem with that is that your understanding doesn't match the implementation (which implements (a), as the GetProgramFullPath name indicates). as we've seen, lots of people (mainly application builders on windows) relies on the implemented behaviour, while some people (mostly toolmakers, from what I can tell) use guido's original interpretation. I don't think many people embed setup.py scripts, so alternative (e) would pro- bably cause the least problems: e) sys.executable contains the full path to the program used to invoke this interpreter instance, or None if this could not be determined. A new variable, sys.python_executable, is set to the name of the python executable used to invoke this interpreter instance. If this instance is embedded, this variable may be set to a corresponding interpreter, or to None if no such interpreter is available. If Python is started from a standard Python interpreter, both variables are set to the same value. any application that uses sys.executable to start another application will still work, as long as the application is started via a standard interpreter. embedded apps on windows will still work as today. /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] bytes thoughts
Josiah Carlson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Christos Georgiou [EMAIL PROTECTED] wrote: [Christos] 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? [Josiah] It's a ValueError. If the sizes matched, it would be a per-element bitwise xor. I agree (in the face of ambiguity...), although I understand that it wasn't obvious that I do from the way I asked the question, which I was expecting Greg to answer :) [Christos] These details should be considered in the PEP. [Josiah] They aren't considered because they are *obvious* to most (if not all) sane people who use Python. I beg to disagree. I don't know whether you are Dutch or not, but most of the Python users aren't; one of the reason PEPs exist is to explain what *should* be obvious at first when one is Dutch ;-) Apart from joking, PEPs should be a record of beating/thinking the PEP subject to its death: The PEP author is responsible for building consensus within the community and documenting dissenting opinions. ___ 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: 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. I'm not sure I understand what you are talking about. What is site-dep and site-indep? Where do we have that for binary code and for python code? I know what prefix and exec_prefix are. 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. It's very simple. Importing traverses sys.path. 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. Well, I don't know about site-dep/site-indep, so I wouldn't be surprised if module search didn't, either. If I did want to try to fix this myself, where would I find the code for it? The code for importing is in Modules/import.c. sys.path is defined in Modules/getpath.c 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
[Python-Dev] Expose the array interface in Python 2.5?
Last year, during development of NumPy, the concept of the array interface was developed as a means to share array_like data. It was realized that it is this concept that needs to be explored further and pushed into Python itself, rather than a particular incarnation of an array. It is very important for many people to get access to memory with some description of how that memory should be interpreted as an array. Several Python packages could benefit if Python had some notion of an array interface that was at least supported in a duck-typing fashion. The description of what we've come up with so far and is implemented in NumPy (and Numarray and last released Numeric) is at http://numeric.scipy.org/#array_interface Quite a few of us would love to see this get into Python proper, but have very little free-time to spare to make sure it happens. Would it be possible to add at least the C-struct array interface to the Python arrayobject in time for Python 2.5? Is someone on this list willing to help make it happen? In NumPy, there is also a reasonably good way to describe the data-type of arbitrary data, that fell out of the discussions over the array interface. I think something like this could eventually find its way into Python as well. We would love any feedback from the Python community on the array interface. Especially because we'd like to see it in Python itself and supported and used by every relevant Python package sooner rather than later. Thanks, -Travis Oliphant ___ 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: I don't think many people embed setup.py scripts, so alternative (e) would pro- bably cause the least problems: e) sys.executable contains the full path to the program used to invoke this interpreter instance, or None if this could not be determined. It seems that you indeed are trying to solve a problem you encountered. Can you please explain what the problem is? ISTM that the current definition doesn't really cause problems, despite potentially being fuzzy. People that start sys.executable typically *do* get a Python interpreter - in an embedded interpreter, they just don't want to start a new interpreter, as that couldn't work, anyway. 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
[EMAIL PROTECTED] writes: 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. except TypeError or KeyError as msg: ! not-serious-ly y'rs, mwh -- That's why the smartest companies use Common Lisp, but lie about it so all their competitors think Lisp is slow and C++ is fast. (This rumor has, however, gotten a little out of hand. :) -- Erik Naggum, comp.lang.lisp ___ 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
Michael Hudson wrote: [EMAIL PROTECTED] writes: 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. Wasn't the proposal : try: something except NameError, OtherError as e: something... ? With e being bound for any of the exceptions... Michael Foord except TypeError or KeyError as msg: ! not-serious-ly y'rs, mwh ___ 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] Expose the array interface in Python 2.5?
Travis E. Oliphant wrote: Would it be possible to add at least the C-struct array interface to the Python arrayobject in time for Python 2.5? Do you mean simply adding an __array_shape__ attribute that consists of a tuple with the array length, and an __array_type__ attribute set to 'O'? Or trying to expose the array object's data? The former seems fairly pointless, and the latter difficult (since it has implications for moving the data store when the array gets resized). We would love any feedback from the Python community on the array interface. Especially because we'd like to see it in Python itself and supported and used by every relevant Python package sooner rather than later. I've spent a fair bit of time looking at this interface, and while I'm a big fan of the basic idea, I'm not convinced that it makes sense to include the interface in the core without *also* adopting a common convention for multi-dimensional fixed shape indexing (e.g. by introducing a simple dimensioned array type as something like array.dimarray). The fact that array.array is a mutable sequence rather than a fixed shape array means that it doesn't mesh particularly well with the ideas behind the array interface. numpy arrays can have their shape changed via reshape, but they impose the rule that the total number of elements can't change so that the allocated memory doesn't need to be moved - the standard library's array type has no such limitation. Aside from the obvious (the use of Ellipsis and permitting multiple dimensions), there are a number of ways in which the semantics of numpy array subscripts differ from normal sequence subcripts, and which of these should be part of the common multi-dimensional indexing conventions needs to be thrashed out in a PEP: - numpy array slices are views that permit mutation of the original object (slicing a sequence creates a copy of the sliced section) - assignment to slices is not allowed to change the shape of a numpy array (assigning to a slice of a normal sequence may change the total length) - deletion of slices is not permitted by numpy arrays (deleting a slice of a sequence changes the total length) - NewAxis is a novel use of subscript notation - there are sophisticated rules to try to align numpy array shapes - assignment of a sequence to a numpy array section is rather disconcerting, as the checks to determine what should and should not be repeated to fit into the available space are type based For something in the standard library, much of the complexity should be stripped out, with the clever bits of programmer convenience left for numpy to provide. However, decided which bits to remove and which to keep is a non-trivial task. Given that even the bytes type has been deferred to 2.6 to allow further consideration of the appropriate API, my vote is to do the same for an array.dimarray type and allow more time to figure out the appropriate *Python* interface. Regards, 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] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
Martin v. Löwis wrote: 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. Sorry, but I'd rather spend that time on getting my extensions working again for both Python 2.4 and 2.5. I think it's only fair that I ask the patch authors to complete the PEP, since the ssize_t patch is causing extension authors enough trouble already. If you want quick adoption of the changes, you have to make it as easy as possible for the authors to port their extensions to the new API. Otherwise, we'll end up having quite a large number of users who can't switch to Python 2.5 simply because their favorite extensions don't work with it. The argument that it only affects 64-bit platforms simply ignores reality. Most new machines are 64-bit machines, so by the time Python 2.5 goes public, 64-bit will have a large enough market share to make a difference. It's also not good enough to simply suggest to ignore compiler warnings - this falls back on the extension authors and the quality of their code without them really having done anything wrong. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 17 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] Expose the array interface in Python 2.5?
Nick Coghlan wrote: Travis E. Oliphant wrote: Would it be possible to add at least the C-struct array interface to the Python arrayobject in time for Python 2.5? Do you mean simply adding an __array_shape__ attribute that consists of a tuple with the array length, and an __array_type__ attribute set to 'O'? Or trying to expose the array object's data? I was thinking more the __array_struct__ (in particular the C-structure that defines it). The former seems fairly pointless, and the latter difficult (since it has implications for moving the data store when the array gets resized). Sure, it's the same problem as exposing through the buffer protocol. Since, we already have that problem, why try to pretend we don't? I've spent a fair bit of time looking at this interface, and while I'm a big fan of the basic idea, I'm not convinced that it makes sense to include the interface in the core without *also* adopting a common convention for multi-dimensional fixed shape indexing (e.g. by introducing a simple dimensioned array type as something like array.dimarray). True, such a thing would be great, but it could also be written in Python fairly quickly building on top of the array and serve as a simple example. My big quest is to get PIL, PyVox, WxPython, PyOpenGL, and so forth to be able to use the same interface. Blessing the interface by including it in the Python core would help. I'm also just wanting people in py-dev to get the concept of an array interface on their radar, as discussions of new bytes types emerges. Sometimes, there is not enough cross-talk between numpy-discussions and pydev. This is our fault, of course, but we're often swamped (I know I am...), and it can take some effort for us array people to figure out what's going on in the depths of Python sufficiently to comprehend some of the discussions here. The fact that array.array is a mutable sequence rather than a fixed shape array means that it doesn't mesh particularly well with the ideas behind the array interface. numpy arrays can have their shape changed via reshape, but they impose the rule that the total number of elements can't change so that the allocated memory doesn't need to be moved - the standard library's array type has no such limitation. This is not really a limitation of numpy arrays either. Check the resize method... But, I understand your point that array.array's are more-like lists. Of course, when they behave that way, their buffer interface is presently broken. So, maybe the array.array is sufficiently broken to not be worth fixing, but what else should be done? I'm kind of tired of this problem dragging on and on. The Numeric header (essentially what the __array_struct__ exposes) is now basically unchanged for over 10 years and yet it's direct support by Python is still not their. The Python community has been very helpful over the years, but we need more direct discussion with Python developers to help things along. I'm grateful Nick has responded. If anyone else has any interest in these ideas, please sound off. Aside from the obvious (the use of Ellipsis and permitting multiple dimensions), there are a number of ways in which the semantics of numpy array subscripts differ from normal sequence subcripts, and which of these should be part of the common multi-dimensional indexing conventions needs to be thrashed out in a PEP: While these are interesting academic issues. The problem with most of these comments is that you will get load voices of disapproval if any of these conventions changes significantly from what has become standard via Numeric's use over 10 years. I think no one is up to the task of trying to re-concile Numeric behavior with Python-dev opinions of what 'ought' to be, unless the basic usage does not change too much. - numpy array slices are views that permit mutation of the original object (slicing a sequence creates a copy of the sliced section) Not really open for discussion among Numeric Python users as it's been debated for years always coming to the same (keep the current behavior) conclusion. - assignment to slices is not allowed to change the shape of a numpy array (assigning to a slice of a normal sequence may change the total length) People might be open to this idea, as it adds a new feature and doesn't signficantly change other usages. - deletion of slices is not permitted by numpy arrays (deleting a slice of a sequence changes the total length) Also something people might accept. - NewAxis is a novel use of subscript notation True, but not something we can really change. - there are sophisticated rules to try to align numpy array shapes You are speaking of broadcasting. These could of course be discussed, but current behavior is entrenched - assignment of a sequence to a numpy array section is rather disconcerting, as the
Re: [Python-Dev] Problem with module loading on multi-arch?
On 3/17/06, Neal Becker [EMAIL PROTECTED] wrote: OK, let's talk about it.1. Does it make sense to have bothsite-dep/app/subpackage andsite-indep/app/subpackage?My answer: definitely yes. Nope. It would make sense to have .py files in site-indep and .pyc, .pyo and .so files in site-dep, but Python doesn't allow that (in 2.x, anyway; 3.x feature?) I believe it should all be in site-dep.-- Thomas Wouters [EMAIL PROTECTED]Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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:
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.
I'm not sure I understand what you are talking about. What is site-dep
and site-indep? Where do we have that for binary code and for python
code? I know what prefix and exec_prefix are.
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.
It's very simple. Importing traverses sys.path.
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.
Well, I don't know about site-dep/site-indep, so I wouldn't be surprised
if module search didn't, either.
Sorry, maybe I used confusing terminology.
A reference is here: http://fedoraproject.org/wiki/Packaging/Python
This is the current setup. For example, this is a standard macro used by
Redhat in RPM SPEC files for python:
%define python_sitearch %(%{__python} -c from distutils.sysconfig import
get_python_lib; print get_python_lib(1))}
%define python_sitelib %(%{__python} -c from distutils.sysconfig import
get_python_lib; print get_python_lib())}
Clearly this practice is widespread. It would seem that module search needs
some modification to fully support 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
[Python-Dev] Bug 1184112 still valid
Hello, today I got my first real python bug. Problem is described in: Bug with ID: 1184112 http://sourceforge.net/tracker/index.php?func=detailaid=1184112group_id=5470atid=105470 I use python 2.3.5 in an embedded C++ Application which uses function: PyRun_SimpleString. Is this bug still present in current python or the 2.4 line ? I found nothing about it. -- bye by Wolfgang ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug 1184112 still valid
Wolfgang Langner wrote: Hello, today I got my first real python bug. Problem is described in: Bug with ID: 1184112 http://sourceforge.net/tracker/index.php?func=detailaid=1184112group_id=5470atid=105470 I use python 2.3.5 in an embedded C++ Application which uses function: PyRun_SimpleString. Is this bug still present in current python or the 2.4 line ? I found nothing about it. Confirmed on SVN trunk. I don't know enough about the tokenizer to determine if the proposed fix is the best solution, though. 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] Merging email 4.0 to Python 2.5 svn trunk
Last night I merged email 4.0 from the sandbox into my working copy of
the Python svn trunk and ran make testall. I hit one failure, in
test_pyclbr.py. The test was importing email.Parser and expecting a
real module, however in email 4.0 email.Parser is a placeholder object
which exposes a backward compatible API for email.parser.
The fix is simple, change 'P' to 'p' in the test, but I want to make
sure that nobody cares that __import__('email.Parser') now returns an
object that isn't a module, but acts enough like the original module for
all intents and purposes.
-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] Bug 1184112 still valid
Fredrik Lundh [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
http://sourceforge.net/tracker/index.php?func=detailaid=1184112group_id=5470atid=105470
When compiling multi-line statements, two caveats apply: line
endings must be represented by a single newline character ('\n'),
and the input must be terminated by at least one newline character.
Relevant part of quote added to bug report.
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] Bug 1184112 still valid
Terry Reedy wrote:
Fredrik Lundh [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
http://sourceforge.net/tracker/index.php?func=detailaid=1184112group_id=5470atid=105470
When compiling multi-line statements, two caveats apply: line
endings must be represented by a single newline character ('\n'),
and the input must be terminated by at least one newline character.
Relevant part of quote added to bug report.
One quirk though, is that omitting the newline actually works for some other
statements (e.g. exec if 1:\n print 'Hello world!' works just fine)
However, I don't think the quote is as relevant as one might think, because in
the code that fails the multi-line statement is not only terminated by a
newline, it's actually followed by a blank line as well. The line missing the
newline is only a single-line statement (specifically, a line with only a
comment).
Compare:
Py exec
... if 1:
... print 'This works!'
...
... pass # Do nothing at all
This works!
With:
Py exec
... if 1:
... print 'This breaks!'
...
... # Do nothing at all
Traceback (most recent call last):
File stdin, line 1, in ?
File string, line 5
# Do nothing at all
^
SyntaxError: invalid syntax
There's an easy workaround (adding the missing newline), but I think there's
definitely something going wrong in the tokenizer.
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
Skip try: Skip foo() Skip except TypeError with msg, KeyError with msg: Skip print msg fuzz Wasn't the proposal : fuzz try: fuzz something fuzz except NameError, OtherError as e: fuzz something... I'm not sure. I only saw SomeError as|with SomeValue. In your formulation the comma binds more tightly than the as keyword. In import statements it's the other way around. That seems like it might be a source of confusion. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Making runpy.run_module *not* thread-safe
While it may seem like going backwards, I actually have a legitimate reason for getting rid of the current thread safety mechanism in runpy.run_module. It appears Guido's doubts about the approach I used are entirely justified. When the alter_sys flag is set, runpy.run_module pokes around a bit in the sys module. Because one of the things it modifies is sys.modules (putting a partially initialised module there), it currently uses the import lock to make this tinkering thread-safe. However, if you try using -m test.regrtest you'll notice that test_threaded_import gets skipped because the import lock is held in the main application script. This is *not* the case when invoking regrtest directly via the filesystem - in that case, the runtime simply puts the partially initialised __main__ module into sys.modules, and leaves it to the application to decide whether or not that module is safe to import. That's all well and good for regrtest.py, but any program that actually spawned additional threads that attempted to import modules would likely see deadlocks in very short order. Removing the locking from run_module() makes it more like the PyRun C APIs - it puts the extra module in sys.modules, but leaves it up to the invoking code to decide whether or not to grab the import lock (or some other synchronisation object) during execution. The import lock will still be held while trying to *find* the requested module and the various optimisation caches in sys are updated. If I don't hear any objections, I'll switch SVN (along with PEP 338 and the docs patch) to the new (non-thread-safe) semantics sometime this weekend. Regards, 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] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
M.-A. Lemburg wrote: I think it's only fair that I ask the patch authors to complete the PEP, since the ssize_t patch is causing extension authors enough trouble already. Well, the PEP is complete as it stands. It's possible to provide more guidelines, but the specification part of it says precisely what I intend it to say. Also, the API documentation ought to be in the Python documentation, and, for these changes, it is. If you want quick adoption of the changes, you have to make it as easy as possible for the authors to port their extensions to the new API. Otherwise, we'll end up having quite a large number of users who can't switch to Python 2.5 simply because their favorite extensions don't work with it. I don't see how giving a complete list of all changed functions helps in any way. It's also not good enough to simply suggest to ignore compiler warnings - this falls back on the extension authors and the quality of their code without them really having done anything wrong. Sure. Compiler warnings should be corrected. That's why the compiler emits them. However, I don't see how this is related to the text of the PEP. 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 [EMAIL PROTECTED] wrote: [Christos] These details should be considered in the PEP. [Josiah] They aren't considered because they are *obvious* to most (if not all) sane people who use Python. I beg to disagree. I don't know whether you are Dutch or not, but most of There's probably a bit of dutch in me, but likely not sufficient to alter my language intuitions. the Python users aren't; one of the reason PEPs exist is to explain what *should* be obvious at first when one is Dutch ;-) Apart from joking, PEPs should be a record of beating/thinking the PEP subject to its death: The PEP author is responsible for building consensus within the community and documenting dissenting opinions. Considering your quote, I have thusfar not seen any opinion dissenting from what I stated as 'obvious' behavior. As I told Michael Chermside off-list: Sure, great, clarify it. I wasn't saying anything in regards to whether it should or shouldn't [be clarified], just why it probably wasn't already. Also considering that I lack SVN commit permission, it's not within my power to clarify the PEP. - 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] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
Martin v. Löwis wrote: M.-A. Lemburg wrote: I think it's only fair that I ask the patch authors to complete the PEP, since the ssize_t patch is causing extension authors enough trouble already. Well, the PEP is complete as it stands. It's possible to provide more guidelines, but the specification part of it says precisely what I intend it to say. Also, the API documentation ought to be in the Python documentation, and, for these changes, it is. If you want quick adoption of the changes, you have to make it as easy as possible for the authors to port their extensions to the new API. Otherwise, we'll end up having quite a large number of users who can't switch to Python 2.5 simply because their favorite extensions don't work with it. I don't see how giving a complete list of all changed functions helps in any way. I'm not sure if this is what Marc-Andre means, but maybe these definitions could go into a new include file: #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 ___ 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], Georg Brandl [EMAIL PROTECTED] wrote: 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. You're right! I was using a local copy of 2.4.0 documentation and it did not have this feature. -- 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] Expose the array interface in Python 2.5?
Travis E. Oliphant [EMAIL PROTECTED] wrote: It is very important for many people to get access to memory with some description of how that memory should be interpreted as an array. Several Python packages could benefit if Python had some notion of an array interface that was at least supported in a duck-typing fashion. Which packages? Which people? Which constituencies? Travis E. Oliphant [EMAIL PROTECTED] also wrote: My big quest is to get PIL, PyVox, WxPython, PyOpenGL, and so forth to be able to use the same interface. Blessing the interface by including it in the Python core would help. I'm also just wanting people in py-dev to get the concept of an array interface on their radar, as discussions of new bytes types emerges. I use PIL and numarray a lot. It would be nice if they used a common array format so I would not need to convert back and forth. But I survive quite well with the current arrangement. Many other packages besides PIL and Numeric / numarray / Numpy are involved here: byte, struct, ctypes, SWIG, PyTables, Psyco, PyPy, Pyrex, etc. There are some major issues that need to be dealt with which I will state concisely in an abstract way. A data structure without an API and thorough documentation is useless. Any proposal needs to include them from the very start. How should Python interact with low level data? By low level data I mean data as seen by C, C++, and FORTRAN as well as linear arrays of bytes. What changes in Python would make the packages listed above easier to write and use? Easier enough to write that the package owners would be willing to give up control of part of their packages. Does anyone know of any academic-type papers that have been written in the last few years on these matters? ___ 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] Expose the array interface in Python 2.5?
Edward C. Jones wrote: Travis E. Oliphant [EMAIL PROTECTED] wrote: It is very important for many people to get access to memory with some description of how that memory should be interpreted as an array. Several Python packages could benefit if Python had some notion of an array interface that was at least supported in a duck-typing fashion. Which packages? Which people? Which constituencies? I think I spell it out later. Do you really need to argue about whether or not an array interface is a useful thing? I thought we were beyond that and to the point of trying to figure out how to get the many groups to agree at least on a common interface. Travis E. Oliphant [EMAIL PROTECTED] also wrote: My big quest is to get PIL, PyVox, WxPython, PyOpenGL, and so forth to be able to use the same interface. Blessing the interface by including it in the Python core would help. I'm also just wanting people in py-dev to get the concept of an array interface on their radar, as discussions of new bytes types emerges. I use PIL and numarray a lot. It would be nice if they used a common array format so I would not need to convert back and forth. But I survive quite well with the current arrangement. We all survive, but saying it is quite well is a bit optimistic as it means many very useful applications are harder to write than they really need to be. Many other packages besides PIL and Numeric / numarray / Numpy are involved here: byte, struct, ctypes, SWIG, PyTables, Psyco, PyPy, Pyrex, etc. There are some major issues that need to be dealt with which I will Sure they are involved, but I would argue the other ones you list care less about the multidimensional aspect of the array interface. (Actually PyTables just uses NumPy and so it should not be discussed as a separate package --- i.e. PyTables already tries to get along with NumPy as do many other packages...) A data structure without an API and thorough documentation is useless. Any proposal needs to include them from the very start. Again, I restate. The Numeric structure has been documented and has been around for a *long* time. I'm just trying to get this basic interface into Python as a very simple object. Let's not try to make it so complicated that no body can agree on what it should do. To be specific, I want to see a type object with almost none of the Type structure filled in with specific behavior. I'm mainly interested in an array structure that other packages can rely on (and inherit from if they so choose). Because the C-structure of the Numeric PyArrayObject (which NumPy also uses) is so widely known and used and documented for over 10 years, I argue it ought to form the foundation for this simple Python object. We can argue about explicit multidimensional indexing behavior, but to hold hostage the introduction of a simple inheritable object to disagreements about those more complicated issues seems to be missing the mark. How should Python interact with low level data? By low level data I mean data as seen by C, C++, and FORTRAN as well as linear arrays of bytes. This is already known about in Numeric. That's what I'm saying. Numeric handles this well, let's just bring over this basic memory model for an array over to Python itself and not worry about the other TypeObject function-pointer tables until later. Everybody I talked to at SciPy was very enthused about this concept. There is a large number of people who don't read Python-dev that I'm speaking for here. What changes in Python would make the packages listed above easier to write and use? Easier enough to write that the package owners would be willing to give up control of part of their packages. They don't have to give up control if we just introduce a simple memory model for an array. Thanks for your comments, -Travis ___ 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, Alex Martelli [EMAIL PROTECTED] wrote: 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...? Yes, but I don't want them to be happy. =) -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 Fri, 17 Mar 2006, [EMAIL PROTECTED] wrote: [...] fuzz Wasn't the proposal : fuzz try: fuzz something fuzz except NameError, OtherError as e: fuzz something... I'm not sure. I only saw SomeError as|with SomeValue. Fuzzyman is right. In your formulation the comma binds more tightly than the as keyword. In import statements it's the other way around. That seems like it might be a source of confusion. Perhaps parentheses around the exception list should be mandatory for the 2-or-more exceptions case? except NameError as e: -- fine except (NameError) as e:-- fine except (NameError,) as e: -- fine except NameError, OtherError as e: -- SyntaxError except (NameError, OtherError) as e:-- fine John ___ 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: M.-A. Lemburg wrote: I think it's only fair that I ask the patch authors to complete the PEP, since the ssize_t patch is causing extension authors enough trouble already. Well, the PEP is complete as it stands. It's possible to provide more guidelines, but the specification part of it says precisely what I intend it to say. Also, the API documentation ought to be in the Python documentation, and, for these changes, it is. Changes to the public API must be documented somewhere, either in Misc/NEWS or in the PEP. How else do you expect users to find out about these changes ??? If you want quick adoption of the changes, you have to make it as easy as possible for the authors to port their extensions to the new API. Otherwise, we'll end up having quite a large number of users who can't switch to Python 2.5 simply because their favorite extensions don't work with it. I don't see how giving a complete list of all changed functions helps in any way. It documents those changes, allows extension authors and extension users to check their extensions for possible problems and is (or at least should be) standard procedure. The list of changes is also necessary in order to be able to write code which allows a module to work in both Python 2.4 and 2.5. The code snippet that Thomas suggested should be part of the conversion guidelines. Again, if you don't make it easy for the developers, they are going to have a hard time upgrading their modules and getting them stable again after the changes. Telling them to read the header files or API docs and suggesting that they should compare 2.4 and 2.5 versions of these should not be the attitude with which such changes are approached. It's also not good enough to simply suggest to ignore compiler warnings - this falls back on the extension authors and the quality of their code without them really having done anything wrong. Sure. Compiler warnings should be corrected. That's why the compiler emits them. However, I don't see how this is related to the text of the PEP. Module authors have the choice whether they support this PEP in their code or not; if they support it, they have the choice of different levels of compatibility. If a module is not converted to support this PEP, it will continue to work unmodified on a 32-bit system. On a 64-bit system, compile-time errors and warnings might be issued, and the module might crash the interpreter if the warnings are ignored. Do you really think module authors do have a choice given that last sentence ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 17 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
Thomas Heller wrote: I'm not sure if this is what Marc-Andre means, but maybe these definitions could go into a new include file: How would that include file be used? You would have to copy it into your own source base, and include it, right? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
Martin v. Löwis wrote: Thomas Heller wrote: I'm not sure if this is what Marc-Andre means, but maybe these definitions could go into a new include file: How would that include file be used? You would have to copy it into your own source base, and include it, right? We could put it into a b/w compatibility header file, e.g. #include pycompat.h -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 17 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] Py3k: Except clause syntax
Brett Cannon wrote: On 3/17/06, Georg Brandl [EMAIL PROTECTED] wrote: John J Lee wrote: In your formulation the comma binds more tightly than the as keyword. In import statements it's the other way around. That seems like it might be a source of confusion. Perhaps parentheses around the exception list should be mandatory for the 2-or-more exceptions case? except NameError as e: -- fine except (NameError) as e:-- fine except (NameError,) as e: -- fine except NameError, OtherError as e: -- SyntaxError except (NameError, OtherError) as e:-- fine I don't like that particularly, but I guess that for consistency's sake it would have to be done this way. I don't like it period. What consistency problem is there? This is Python 3 we are talking about, so if something makes good sense such as not having parentheses, I say leave them off. There are multiple places where parens could be required but are not, like multiple assignment. I only think of consistency with the usage of as in the import statement. I know how it works, but I predict people will come and write except NameError as e, OtherError as f: 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] Py3k: Except clause syntax
On 3/17/06, Georg Brandl [EMAIL PROTECTED] wrote: Brett Cannon wrote: On 3/17/06, Georg Brandl [EMAIL PROTECTED] wrote: John J Lee wrote: In your formulation the comma binds more tightly than the as keyword. In import statements it's the other way around. That seems like it might be a source of confusion. Perhaps parentheses around the exception list should be mandatory for the 2-or-more exceptions case? except NameError as e: -- fine except (NameError) as e:-- fine except (NameError,) as e: -- fine except NameError, OtherError as e: -- SyntaxError except (NameError, OtherError) as e:-- fine I don't like that particularly, but I guess that for consistency's sake it would have to be done this way. I don't like it period. What consistency problem is there? This is Python 3 we are talking about, so if something makes good sense such as not having parentheses, I say leave them off. There are multiple places where parens could be required but are not, like multiple assignment. I only think of consistency with the usage of as in the import statement. I know how it works, but I predict people will come and write except NameError as e, OtherError as f: Really? I don't. 'while' statement doesn't work that way either. I don't personally associate 'as' with any specific statement that uses it. Plus the above is bad since those should be separate 'except' clauses if people need to differentiate between what exceptions they caught. Otherwise it should be ambiguous and assigned to a single variable name. -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] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
M.-A. Lemburg wrote: Martin v. Löwis wrote: Thomas Heller wrote: I'm not sure if this is what Marc-Andre means, but maybe these definitions could go into a new include file: How would that include file be used? You would have to copy it into your own source base, and include it, right? We could put it into a b/w compatibility header file, e.g. #include pycompat.h #include pep353.h ___ 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 Mar 17, 2006, at 12:40 AM, Martin v. Löwis wrote: Fredrik Lundh wrote: I don't think many people embed setup.py scripts, so alternative (e) would pro- bably cause the least problems: e) sys.executable contains the full path to the program used to invoke this interpreter instance, or None if this could not be determined. It seems that you indeed are trying to solve a problem you encountered. Can you please explain what the problem is? ISTM that the current definition doesn't really cause problems, despite potentially being fuzzy. People that start sys.executable typically *do* get a Python interpreter - in an embedded interpreter, they just don't want to start a new interpreter, as that couldn't work, anyway. I've seen cases where people want to start worker processes from bundled apps (as in py2app/py2exe). The bootstrap executable (sys.executable) is not suitable for this purpose, as it runs a specific script. Forking doesn't quite do the right thing either because it's not safe to fork without exec'ing in all cases due to state that persists that shouldn't across processes with certain platform libraries (in Mac OS X especially). For py2app, we can bundle a Python interpreter that links to the same Python framework and has the same set of modules and extensions that the bundled application does, so we can support this use case. I'd definitely like to see something like sys.python_executable become standard, and I think I'll go ahead and support it in the next release of py2app. It's possible to degrade gracefully with this approach too: def get_python_executable(): python_executable = getattr(sys, 'python_executable', None) if python_executable is not None: return python_executable if not sys.frozen and sys.executable: # launched from a standard interpreter return sys.executable # frozen without python_executable support raise RuntimeError -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
M.-A. Lemburg wrote: Changes to the public API must be documented somewhere, either in Misc/NEWS or in the PEP. Sure. They are documented in the PEP, which says # All occurrences of index and length parameters and results are changed # to use Py_ssize_t, including the sequence slots in type objects, and # the buffer interface. The relevant Misc/NEWS entry is - PEP 353: Using ssize_t as the index type. It documents those changes, allows extension authors and extension users to check their extensions for possible problems and is (or at least should be) standard procedure. The changes are documented in the PEP. The current API is documented in the API docs. The list of changes is also necessary in order to be able to write code which allows a module to work in both Python 2.4 and 2.5. The code snippet that Thomas suggested should be part of the conversion guidelines. It is (atleast some form of it). Module authors have the choice whether they support this PEP in their code or not; if they support it, they have the choice of different levels of compatibility. If a module is not converted to support this PEP, it will continue to work unmodified on a 32-bit system. On a 64-bit system, compile-time errors and warnings might be issued, and the module might crash the interpreter if the warnings are ignored. Do you really think module authors do have a choice given that last sentence ? I really do. Most developers will not be confronted with 64-bit systems for several years to come. That current hardware supports a 64-bit mode is only one aspect: Most operating system installations on such hardware will continue to operate in 32-bit mode for quite some time. Of course, developers of widely-used extension modules will need to support the PEP in some way. They should follow the guidelines in the PEP. 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
[Python-Dev] Py3K thought: use external library for client-side HTTP
Thought: We should drop all of httplib, urllib, urllib2, and ftplib, and instead adopt some third-party library for HTTP/FTP/whatever, write a Python wrapper, and use it instead. (The only such library I know of is libcurl, but doubtless there are other candidates; see http://curl.haxx.se/libcurl/competitors.html for a list.) Rationale: * HTTP client-side support is pretty complicated. HTTP itself has many corners (httplib.py alone is 1420 lines long, and urllib2 is 1300 lines). * There are many possible permutations of proxying, SSL on/off, and authentication. We probably haven't tested every permutation, and probably lack the volunteer effort to test them all. If you search for 'http' in the bug tracker, you find about 16 or so bugs submitted for httplib/urllib/urllib2, most of them for one permutation or another. With a third-party library, the work of maintaining RFC compliance falls to someone else. * A third-party library might support more features than we have time to implement. A downside: these libraries would be in C, and might be the source of security bugs. Python code may be buggy, but probably won't fall prey to buffer overflow. We'd also have to keep in sync with the library. Similar arguments could be made for a server-side solution, but here I have no idea what we might choose. A server-side HTTP implementation + a WSGI gateway might be all that Python 3000 needs. Good idea? Dumb idea? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] dealing with decorators hiding metadata of decorated functions
With the discussion of a possible @decorator to help set the metadata of the decorator to that of what the wrapped function has, I had an idea that I wanted to toss out there (this dicussion stems from a blog post I made: http://sayspy.blogspot.com/2006/03/how-to-handle-object-identity-issues.html). The problem I have with the current practice of setting __name__ and __doc__ (updating __dict__ I have no problem with) is that is destroys metadata on the decorator. This seems kind of bad to destroy metadata for introspection purposes. So how about a __decorates__ attribute that points to what something is decorating? Then help() along with 'inspect' can be changed to look for that attribute, and if it is there, use that for introspection. This way advanced users can still poke at the decorator for information while more common introspection will still point to the decorated function instead of the decorator itself, all without data loss! And on top of it all, it's simple to add support for (obviously the actual code in 'inspect' would be different than what is below =) !:: _help = help def help(obj): while hasattr(obj, __decorates__): obj = obj.__decorates__ _help(obj) Worst case is advanced users at the command line will be put out by not being able to directly look at obj.__doc__ for the docstring they care about and such. But this should be a minor issue. But if people don't like that, I do have another proposal to add a __signature__ attribute that would hold an object representing the call signature of a function. This could then be put on a decorator so that introspection on the calling requirements of a decorated function are correct instead of the typical ``*args, **kwargs``. Anyway, what do people think of a __decorates__ attribute? -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] Problem with module loading on multi-arch?
On 3/18/06, Neal Becker [EMAIL PROTECTED] wrote: x86_64 is multiarch.That means, we allow both i386 and x86_64 binaries tocoexits.Is the proposal that python should not support this?That wouldbe unfortunate.Not within a single interpreter, I'd say. Extensions compiled for x86_64 will not load into an interpreter compiled for x86, and vice-versa, so that's out of the question. What else should python support? You can, of course, have different interpreters live next to each other -- python already supports that just fine. Python shouldn't care about architectures, though, and just use 'prefix' and 'exec_prefix' as they were given at compiletime; they contain the properly compiled extensions for that interpreter. For the purpose of multi-archedness, python and all its modules and extensions are a single application. Perhaps Py3K should differentiate more between .so files and .py files (and .pyc/.pyo files), but I'm not entirely convinced of the value of installing a module once for multiple interpreters.-- Thomas Wouters [EMAIL PROTECTED]Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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?
On Mar 17, 2006, at 4:38 PM, Neal Becker wrote:
Martin v. Löwis wrote:
Neal Becker wrote:
Sorry, maybe I used confusing terminology.
A reference is here: http://fedoraproject.org/wiki/Packaging/Python
This is the current setup. For example, this is a standard macro
used by
Redhat in RPM SPEC files for python:
%define python_sitearch %(%{__python} -c from
distutils.sysconfig import
get_python_lib; print get_python_lib(1))}
%define python_sitelib %(%{__python} -c from distutils.sysconfig
import
get_python_lib; print get_python_lib())}
Clearly this practice is widespread. It would seem that module
search
needs some modification to fully support it.
Ah. That isn't supported at all, at the moment. Redhat should not be
using it. Instead, there shouldn't be a difference between
sitearch and
sitelib.
x86_64 is multiarch. That means, we allow both i386 and x86_64
binaries to
coexits. Is the proposal that python should not support this?
That would
be unfortunate.
I suspect is would not be that difficult to correctly support
multiarch
platforms. As it is, this usually works - but the example I gave
above
shows where it seems to break.
All the difficult issues supporting multi-arch are going to be with
distutils, not Python itself.
On OS X it isn't all that hard to support (beyond backwards
compatibility issues) because you run gcc once with the right options
and get a single universal binary as output. It would be a lot more
invasive if GCC had to be run multiple times and the products had to
be put in different places.
-bob
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expose the array interface in Python 2.5?
Travis E. Oliphant oliphant.travis at ieee.org wrote: It is very important for many people to get access to memory with some description of how that memory should be interpreted as an array. Several Python packages could benefit if Python had some notion of an array interface that was at least supported in a duck-typing fashion. I have just submited a patch to SF that implements __array_shape__ and __array_typestr__ attributes for the array.array class. These are the only two attributes that are marked required in the N-D array interface document. I think it makes sense to discuss these two first. Note that these methods do not add any new functionality. Shape is just (len(a),) and typestr just packs endiness information together with a.typecode and a.itemsize. The only benefit of adding these two methods is to create one true way to access this information. I am fairly happy with __array_shape__, but __array_typestr__ feels somewhat archaic. I would rather see ctypes style data description instead of this struct style. I believe unifying the way different python modules describe binary data is a worthwhile first step in bringing array interface to the core. ___ 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] All green!
After backporting a patch from Neal (to make test_timeout less likely to fail on the Mac buildbot slave living at python.org), all 14 columns in http://www.python.org/dev/buildbot/all/ are green. Yippee! Let's keep 'em that way. You can all take the weekend off ;-) I believe it's possible to fiddle the buildbot master to send email when a test run fails, and maybe it's time to start doing that. BTW, there's still one compiler warning on Windows, on the trunk: Compiling... _ctypes_test.c \buildbot_py25\trunk.mcintyre-windows\build\Modules\_ctypes\_ctypes_test.c(102) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data ___ 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
Oleg Broytmann wrote: On Fri, Mar 17, 2006 at 07:44:51PM +, John J Lee wrote: Perhaps parentheses around the exception list should be mandatory for the 2-or-more exceptions case? except NameError as e: -- fine except (NameError) as e:-- fine except (NameError,) as e: -- fine except NameError, OtherError as e: -- SyntaxError except (NameError, OtherError) as e:-- fine If parens are mandatory what is the difference from the current syntax? Why do we need as here? Why not stay with except (NameError, OtherError), e: Currently the comma is used for two very different purposes within the same clause, so it's far too easy to make the mistake: except NameError, OtherError: and then have to deal with the fact that OtherError isn't caught (and given how often unit tests fail to cover all error cases, it wouldn't be unusual for this bug to escape a unit testing regime, too). If this code is made to do the right thing, then there needs to be some other syntax to indicate the name that should be used for the value of the caught exception. as is already used as an embedded naming syntax in two places: - import statements use it for locate an object or module using one name, but bind it to a different name in this module In this case, the binding is restricted to a single name and is applied individually to each element of a comma separated list: import foo as a, bar as b, baz as c - with statements use it for retrieve the context manager for this context and bind the result of the manager's __enter__ method to this name In this case, the binding may be either a single name or a tuple of names, and the expression itself is limited to a single term - parentheses are required around both comma separated lists and unpacking to separate names is optional: with (foo, bar, baz) as (a, b, c): pass with (foo, bar, baz) as x: pass The proposal to use it for except clauses encounters a subtle difference - in the except clause, even if multiple exception types are listed in the clause, there is still only a single exception value to be bound to the name. The list of exception names merely limits the possible types for that exception, rather than their names. So, as a somewhat novel approach, what about putting the as *before* the list of exceptions types? After all, the thing being bound is the exception caught, not the possible list of types: except NameError, OtherError: # Exception value not bound except as ex, NameError, OtherError: # Exception value bound to ex I don't actually have a problem with simply tacking the clause on the end (with or without mandatory parentheses) but figured I'd throw this idea out as an option. I'm not sure whether the parallel with print and print stream, is a positive or a negative, though. . . 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] Expose the array interface in Python 2.5?
Travis E. Oliphant wrote: Given that even the bytes type has been deferred to 2.6 to allow further consideration of the appropriate API, my vote is to do the same for an array.dimarray type and allow more time to figure out the appropriate *Python* interface. I was afraid of that. But, unless people in pydev actually care to discuss these matters, I fear that yet again nothing will be done. The problem is that for most of us array users, it's only community outreach and a desire to get people using Python talking the same array language that makes us really care about these things. The NumPy library works fine for what we really need it to do, and it's hard to get motivated to convince people that haven't used an array-language like IDL or MATLAB in the past to understand the reasons for NumPy's behavior. Hmm, we could have the builtin type support only access to individual elements (raising an IndexError or ValueError for any slice operations, or failures to specify all dimensions). It wouldn't be that easy to *manipulate* data in that format, but it would meet the needs of a common memory format for the various array implementions that *do* make the data easy to manipulate. Doing that would allow us to get a basic type while ducking most (all?) of the potentially controversial behaviour. Such a type would definitely belong in the array module rather than being a builtin, though. As the bytes type is developed please keep in mind it's uses as the memory for an N-dimensional array. Perhaps the bytes object could be a default way (or built on a default way) to allocate memory. A simple reference-counted memory object would certainly belay the problems of the buffer interface that the array object currently has problems with. Even if array.dimarray was implemented as a fairly dumb implementation of the multi-dimensional array interface, then other types could either inherit from it or contain it and manipulate the memory directly. In other words, the array object should not malloc it's own memory but create a memory object which is nothing more than a reference-counted pointer to memory. Surely this has been talked about. Is there a reason it has not been implemented? It would not be that hard. A simple implementation of array.dimarray could certainly serve as such an object. Note that we don't have to do everything at once. It would be possible to put a transition plan in a PEP whereby array.dimarray was added in Python 2.5 (allowing external modules to start relying on it), while converting things like ctypes and array.array to use it could be deferred until 2.6. If we defer the whole lot, then even if the standard library used a common bulk data format in 2.6, extension modules probably wouldn't be using it until 2.7. Of course, there's a whole 'nother question of where Jython, IronPython and PyPy would fit into this. . . Regards, 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] All green!
Tim Peters wrote: After backporting a patch from Neal (to make test_timeout less likely to fail on the Mac buildbot slave living at python.org), all 14 columns in http://www.python.org/dev/buildbot/all/ are green. Yippee! Let's keep 'em that way. You can all take the weekend off ;-) I believe it's possible to fiddle the buildbot master to send email when a test run fails, and maybe it's time to start doing that. Neal's already set it up to email the Python checkins list when something breaks. It already told me about a bug in the PEP 338 tests that meant they wouldn't work on Windows. The combination of -uall and rerunning with -v when a test fails is really quite effective. 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
Georg Brandl wrote: I predict people will come and write except NameError as e, OtherError as f: Then they'll learn very fast not to write that, because they'll get a SyntaxError. 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] Expose the array interface in Python 2.5?
Nick Coghlan wrote: The former seems fairly pointless, and the latter difficult (since it has implications for moving the data store when the array gets resized). I don't see why that should be a serious problem, as long as it's understood that the address reported by the array interface is only for temporary use. I also don't see what relevance the semantics of Python indexing or mutation has. The array interface should just report the location and shape of the data as it happens to be when the call is made. What happens to it in between times is entirely up to the object. 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] dealing with decorators hiding metadata of decorated functions
Josiah Carlson wrote: Brett Cannon [EMAIL PROTECTED] wrote: With the discussion of a possible @decorator to help set the metadata of the decorator to that of what the wrapped function has, I had an idea that I wanted to toss out there (this dicussion stems from a blog post I made: http://sayspy.blogspot.com/2006/03/how-to-handle-object-identity-issues.html). [snip] Edward Loper suggested this way back on September 5, 2004. http://mail.python.org/pipermail/python-dev/2004-September/048626.html I was and continue to be +1 on this, +1 here, too. Unlike Brett, though, I have no problem with overwriting __name__ and updating __dict__ unconditionally, and overwriting __doc__ if it hasn't already been set. The first two are needed if we expect print f and f.a to work properly. The function's name is set on the 'def' line, and I'd be much happier seeing that at all levels of the decorator chain, rather than seeing something like wrapper, wrapper, ... wrapper, f. Annotating decorators will modify the functions' attributes, and this needs to be visible in the final function's dictionary. If a wrapper doesn't set a docstring explicitly, it makes a lot more sense to me to re-uses the original function's docstring rather than leave it at None. My real interest is that it should be possible to get at all the details of the original function (such as its code object), and the obvious way to do that is with a standard attribute that links to the original. though I would go farther and state, like I did at the time, that one shouldn't copy any of the function attributes, they should come 'free', similar to the way that class attributes are 'free' on subclasses. Well, that's the idea behind the decorator decorator - simply put @decorator on your decorator function and it will automatically do the right thing. http://mail.python.org/pipermail/python-dev/2004-September/048631.html What would make this _really_ nice is if one didn't need to do anything manually; that the attribute that pointed to the decorated function/object would be automatically applied - though I realize that this may not be generally possible. A slight problem is that not all decorators will wrap the function they decorate - some will only annotate it. However, here's an idea for the @decorator decorator that would make it pretty much automatic, leaves the docstring alone if the decorator has already set it on the wrapper, and builds up a record of the decorators that are wrapping the the original function: def _link_decorated(decorated, orig, decorator): Link a decorated function with the original decorated.__name__ = orig.__name__ decorated.__dict__.update(orig.__dict__) if decorated.__doc__ is None: decorated.__doc__ = orig.__doc__ decorated.__decorates__ = orig decorated.__decorator__ = decorator def decorator(orig_decorator): Decorator to create a well-behaved decorator # Wrapper function that links a decorated function # to the original function if necessary def wrapper(f): decorated = orig_decorator(f) if decorated is not f: # Link wrapper function to the original _link_decorated(decorated, f, wrapper) return decorated _link_decorated(wrapper, orig_decorator, decorator) return wrapper Decorators that only do annotations aren't recorded because there isn't anywhere to record them. Wrapping decorators, on the other hand, allow the references to both the decorated function and the applied decorator to be stored on the new function object. Cheers, Nick. P.S. Example usage: Py @decorator ... def annotated(f): ... f.note = 1 ... return f ... Py @decorator ... def wrapped(f): ... def wrapper(*args, **kwds): ... return f(*args, **kwds) ... return wrapper ... Py @wrapped ... @annotated ... @wrapped ... @wrapped ... def show(*args, **kwds): ... print args, kwds ... Py while hasattr(obj, __decorates__): ... print obj ... print Decorates:\t%s % obj.__decorates__ ... print Using:\t%s % obj.__decorator__ ... print Annotated?:\t%s % hasattr(obj, note) ... print ... obj = obj.__decorates__ ... function show at 0x00AE9D30 Decorates:function show at 0x00AE9AB0 Using:function wrapped at 0x00AE9CF0 Annotated?: True function show at 0x00AE9AB0 Decorates:function show at 0x00AE9B30 Using:function wrapped at 0x00AE9CF0 Annotated?: True function show at 0x00AE9B30 Decorates:function show at 0x00AE99F0 Using:function wrapped at 0x00AE9CF0 Annotated?: False -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list
