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 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] 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 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] 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 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] 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 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] 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 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] 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
---BeginMessage---
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
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] 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 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] 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 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] 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 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] 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 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] 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 ---BeginMessage--- 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 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] 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 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] 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 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] 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 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] 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 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
