Re: [Python-Dev] Extended Buffer Protocol - simple use examples
On 09/04/07, Travis Oliphant <[EMAIL PROTECTED]> wrote: > > I have skimmed (briefly, I'll admit!) the pre-PEP, but I've found it > > extremely difficult to find a simple example of the basic (in my view) > > use case of an undifferentiated block of bytes. > > > > This is a great suggestion and it was on my to-do list. I've included > some examples of this use-case in the new PEP. Nice - those look clear to me. One question - if a producer is generating a more complex data format (for example, the RGBA example in the PEP) then would the "simple consumer" code (Ex. 3) still get a pointer (or would the RGBA code need to go through extra effort to allow this)? Sorry, again this is probably clear from reading the PEP details, but my eyes glaze over when I read about strides, shapes, etc... My motivation here is that it would be a shame if "old-style" code that was prepared to guess the format of a memory block stopped working when the producer of the memory added shape information (that the consumer didn't care about, except to validate its guess). Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Checking PEP autobuild results
The PEP I checked in for Travis hasn't turned up on the website, despite building without warnings when I run pep2html.py. The changes I made to PEP 0 haven't turned up either. I thought the subversion commit hook for the PEPs folder caused the website to update automatically. Have I forgotten a step in the process somewhere, or is something broken? Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3118: Extended buffer protocol (new version)
Carl Banks wrote: > Another little mistake I made: looking at the Python source, it seems > that most C defines do not use the Py_ prefix, so probably we shouldn't > here. Sorry. Most of the #define's aren't exposed via Python.h and aren't part of the public C API. The public ones are meant to use the prefix. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Checking PEP autobuild results
On Tue, Apr 10, 2007 at 07:58:02PM +1000, Nick Coghlan wrote: > Have I forgotten a step in the process somewhere, or is something broken? Something's broken; I'm looking into it. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] HTTP responses and errors
Facundo Batista wrote: > Martin v. Löwis wrote: > ... > >> think it should treat all 2xx responses as success. Callers can >> then still check the response code themselves if they need to. > > The same I think. If nobody has a conflic with this decission, I'll fix > this. Nobody raised any objection, I'll fix this these days. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Changes to decimal.py
Now that the checkin is done, I don't think it needs to be reverted. But, in
general, we should probably abstain from making wholesale revisions that add
zero value for the users.
The stylistic change from:
ValueError, 'foo'
ValueError('foo')
is fine.
Changing MockThreading to subclass from object though borders on being a
semantic change and should be done with care. In this particular case, I see
no harm in it, but then I haven't tested it on a Py2.3 build with threading
disabled.
As promised in the decimal.py header, the spec updates should all be considered
as bugs and backported at some point after they are fully tested and we're
happy with them all around. Also, as promised, the module should continue to
run on Py2.3.
For the most part, many of the new operations can be implemented in terms of
the existing ops or in terms of the support functions that we already use
internally. Ideally, you can refactor common code while leaving almost all of
the exisiting algorithm implementation code untouched.
The spec's choice of new method names is unfortunate. You'll have to come-up
with something better than copy() and class().
FWIW, I think the new decimal development should probably be done in a branch
off of the current head. That way, you can check-in at will and get feedback
from everyone without risking the integrity of the head.
If you want to discuss anything during development, I'm usually available on
AOL instant messaging with the screename: raymondewt
Likewise, consider soliciting Tim's input on how to implement the ln()
operation. That one will be tricky to get done efficiently and correctly.
Raymond
--- Begin Message ---
2007/4/10, Raymond Hettinger <[EMAIL PROTECTED]>:
I don't think patches like this are a good idea. For almost
zero benefit, we've lost the clean info in "svn ann" and lost
having the code in Py2.6 exactly match Py2.5 and Py2.4
(so it will now be more difficult to backport and validate
real bug fixes).
Well. This is the first step in "me started working on decimal again".
The Decimal spec changed: it has new operations, but also changed the
behaviour of some already-present operations (right now I'm pulling my
hair because of a corner case of rounding that must behave different
in quantize).
What I don't know is: these changes will be considered as "bugs" and
backported to <2.6, or it will be considered as little changes that
will join the bigger changes in 2.6?
If the former, I agree with you that this change should be reversed
(note that I didn't realize these losses at its moment, but everybody
learns, ;).
What do you think?
When the exceptions were changed to new-style, I hope there
was a speed-up, that there is no change in semantics, and
that the code still runs under Py2.3 as promised in the header.
It changed from "ValueError, 'foo'" to "ValueError('foo')". Don't
remember when this was introduced in the language, though (didn't find
it overlooking the "What's new" docs...).
Thank you!
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
--- End Message ---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Checking PEP autobuild results
On 4/10/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: The PEP I checked in for Travis hasn't turned up on the website, despite building without warnings when I run pep2html.py. The changes I made to PEP 0 haven't turned up either. I thought the subversion commit hook for the PEPs folder caused the website to update automatically. Have I forgotten a step in the process somewhere, or is something broken? Had this happen to me. Usually means that another PEP is invalid and is breaking things. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Py2.5.1 release candidate
It looks like the release candidate has been held-up for a bit. If it is going to stay held-up for a few days, can we unfreeze it so some bugfixes can go in (fixing the +0/-0 problem, eliminating some segfaults, and fixing some exception code)? Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] USE_FAST code in stringobject.c
Do any of the Iceland sprinters (Fredrik or Andrew perhaps) know why the USE_FAST section is segregated and whether it is supposed to be on or off by default? Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5.1 release candidate
Raymond Hettinger schrieb: > It looks like the release candidate has been held-up for a bit. If > it is going to stay held-up for a few days, can we unfreeze it so > some bugfixes can go in (fixing the +0/-0 problem, eliminating some > segfaults, and fixing some exception code)? No, the release binaries are all produced, and just await upload. If it's an urgent issue, we need another RC. If it isn't urgent (e.g. not a regression relative to 2.5.0), I think it should wait for 2.5.2. (IMHO all, of course) Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: Re: Py2.5.1 release candidate
> No, the release binaries are all produced, and just await upload. Woohoo! > If it's an urgent issue, we need another RC. > If it isn't urgent (e.g. not a regression relative to 2.5.0), > I think it should wait for 2.5.2. (IMHO all, of course) These bug fixes will have to wait. Raymond --- Begin Message --- Raymond Hettinger schrieb: > It looks like the release candidate has been held-up for a bit. If > it is going to stay held-up for a few days, can we unfreeze it so > some bugfixes can go in (fixing the +0/-0 problem, eliminating some > segfaults, and fixing some exception code)? No, the release binaries are all produced, and just await upload. If it's an urgent issue, we need another RC. If it isn't urgent (e.g. not a regression relative to 2.5.0), I think it should wait for 2.5.2. (IMHO all, of course) Regards, Martin --- End Message --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Checking PEP autobuild results
On Tue, Apr 10, 2007 at 07:30:13AM -0400, A.M. Kuchling wrote: > Something's broken; I'm looking into it. David Goodger found the problem and repaired it. It was nothing to do with the PEPs; another directory was causing the build process to stop with an error. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changes to decimal.py
Raymond Hettinger wrote:
> As promised in the decimal.py header, the spec
> updates should all be considered as bugs and backported at some point
> after they are fully tested and we're happy with them all around.
> Also, as promised, the module should continue to run on Py2.3.
Ok. So far, I'm dealing just with this. decimal.py passes, for example,
the old quantize.decTest, but not the new one.
My first step in this journey is to get the new test cases pass ok.
> For the most part, many of the new operations can be implemented in terms
> of the existing ops or in terms of the support functions that we
> already use internally. Ideally, you can refactor common code while
> leaving almost all of the exisiting algorithm implementation code
> untouched.
Yes. Some of the existing code will be touched, but mostly for bug
fixing.
> The spec's choice of new method names is unfortunate. You'll have to
> come-up with something better than copy() and class().
The names, as the new functions will be discussed here in the second
step. For example, I'm not absolute sure that something like...
>>> Decimal("1100").xor(Decimal("0110")
Decimal("1010")
...is actually needed.
> FWIW, I think the new decimal development should probably be done in a
> branch off of the current head. That way, you can check-in at will
> and get feedback from everyone without risking the integrity of the head.
This is a very good idea.
> If you want to discuss anything during development, I'm usually available on
> AOL instant messaging with the screename: raymondewt
>
> Likewise, consider soliciting Tim's input on how to implement the ln()
> operation.
> That one will be tricky to get done efficiently and correctly.
Great, thank you!!
--
. Facundo
.
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: Re: Changes to decimal.py
[Facundo Batista]
>The names, as the new functions will be discussed here in the second
>step. For example, I'm not absolute sure that something like...
>
Decimal("1100").xor(Decimal("0110")
>Decimal("1010")
>
>...is actually needed.
>
It doesn't matter. We promise to offer a full impleme
Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5.1 release candidate
On Wednesday 11 April 2007 07:07, Martin v. Löwis wrote: > Raymond Hettinger schrieb: > > It looks like the release candidate has been held-up for a bit. > > If it is going to stay held-up for a few days, can we unfreeze > > it so some bugfixes can go in (fixing the +0/-0 problem, > > eliminating some segfaults, and fixing some exception code)? > > No, the release binaries are all produced, and just await upload. Apologies for the delay in the uploading - some stuff came up over the Easter break, and then the website wouldn't rebuild (David and Andrew fixed the latter, yay!) Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 2.5.1, release candidate 1
On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.5.1 (release candidate 1). This is the first bugfix release of Python 2.5. Python 2.5 is now in bugfix-only mode; no new features are being added. According to the release notes, over 150 bugs and patches have been addressed since Python 2.5, including a fair number in the new AST compiler (an internal implementation detail of the Python interpreter). For more information on Python 2.5.1, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.5.1/ Highlights of this new release include: Bug fixes. According to the release notes, at least 150 have been fixed. Highlights of the previous major Python release (2.5) are available from the Python 2.5 page, at http://www.python.org/2.5/highlights.html Enjoy this release, Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
