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
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)?
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
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
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
[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
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
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
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
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__
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
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
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
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:
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
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'),
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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.
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
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
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
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:
47 matches
Mail list logo
