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
(wh
"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
Neal Becker wrote:
> 1. Does it make sense to have both
>
> /app/subpackage
> and
> /app/subpackage
> ?
>
> My answer: definitely yes. We already agree that we should have both
> site-dep for binary code and site-indep for python code, so there is no way
> to avoid this.
I'm not sure I unders
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 s
[EMAIL PROTECTED] writes:
> Greg> except as :
>
> Baptiste> except with :
>
> Can I catch multiple exceptions with a single value in this case? Today, I
> write:
>
> try:
> foo()
> except (TypeError, KeyError), msg:
> print msg
>
> Either of the above seem like t
Michael Hudson wrote:
[EMAIL PROTECTED] writes:
Greg> except as :
Baptiste> except with :
Can I catch multiple exceptions with a single value in this case? Today, I
write:
try:
foo()
except (TypeError, KeyError), msg:
print msg
Either of the
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
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_ty
On 3/17/06, Neal Becker <[EMAIL PROTECTED]> wrote:
OK, let's talk about it.1. Does it make sense to have both/app/subpackage and/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 th
"Martin v. Löwis" wrote:
> Neal Becker wrote:
>> 1. Does it make sense to have both
>>
>> /app/subpackage
>> and
>> /app/subpackage
>> ?
>>
>> My answer: definitely yes. We already agree that we should have both
>> site-dep for binary code and site-indep for python code, so there is no
>> way
Hello,
today I got my first real python bug. Problem is described in:
Bug with ID: 1184112
http://sourceforge.net/tracker/index.php?func=detail&aid=1184112&group_id=5470&atid=105470
I use python 2.3.5 in an embedded C++ Application which uses function:
PyRun_SimpleString.
Is this bug still pre
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=detail&aid=1184112&group_id=5470&atid=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 back
Wolfgang Langner wrote:
> today I got my first real python bug. Problem is described in:
>
> Bug with ID: 1184112
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1184112&group_id=5470&atid=105470
>
> I use python 2.3.5 in an embedded C++ Application which uses function:
> PyRun_Simple
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> http://sourceforge.net/tracker/index.php?func=detail&aid=1184112&group_id=5470&atid=105470
>"When compiling multi-line statements, two caveats apply: line
>endings must be represented by a single newline charac
Terry Reedy wrote:
> "Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>>> http://sourceforge.net/tracker/index.php?func=detail&aid=1184112&group_id=5470&atid=105470
>>"When compiling multi-line statements, two caveats apply: line
>>endings must be represented b
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 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 p
"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
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 t
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
"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 lea
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
>
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 '( as )' 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 as|with .
Fuzzyman is right.
> In your formulation the comma bi
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 excepti
Travis E. Oliphant wrote:
> 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 incar
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:
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 t
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
__
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 "
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 e
Thomas Heller wrote:
> 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
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 i
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.
>> >
>> > Per
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 s
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,
On 3/17/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Considering your quote, I have thusfar not seen any opinion dissenting
> from what I stated as 'obvious' behavior.
FWIW, I have no objections to the behaviour you state as "obvious",
but I didn't find it immediately obvious (although admitted
On 3/17/06, Thomas Heller <[EMAIL PROTECTED]> 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?
>
> I'm very much for that.
>
> > Is someone on this list willing to help make it happen?
>
>
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
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 o
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/
A.M. Kuchling wrote:
> Good idea? Dumb idea?
I have no idea about urllib, but httplib certainly should stay,
and its bugs should get fixed (and will get fixed, over time).
It is very easy to write a httplib application, since you can
follow its source code. It would be much more complicated to
u
On 3/17/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> 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
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
"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.blogsp
"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
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 lo
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
>>>
"Travis E. Oliphant" 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 i
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
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
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
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
> weeken
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
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
Can't think of a more Pythonic way to celebrate St Patrick's day!-)
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
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:
On 17-mrt-2006, at 22:14, 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
I posted a message to c.l.p about the upcoming alpha 1.
Just in case anybody here's been snoozing, 2.5 alpha 1 is coming up
real quick, hopefully within a couple of weeks. If you have any
*major* features (particularly implemented in C) that you want to see
in 2.5, bring it up now. I want to str
Thomas Heller wrote:
> #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 ss
64 matches
Mail list logo
