At 05:57 PM 8/29/2006 -0700, Raymond Hettinger wrote:
>Phillip J. Eby wrote:
>
>>At 05:20 PM 8/29/2006 -0700, Raymond Hettinger wrote:
>>
>>>* The implementation's doc string examples were not tested and don't
>>>work (this is a deep error). One reads:
>>>
>>> with decimal.getcontext() as ctx:
On Wednesday 30 August 2006 08:57, Tim Peters wrote:
> Speaking of which, I saw no feedback on the proposed patch in
>
> http://mail.python.org/pipermail/python-dev/2006-August/068502.html
>
> so I'll just check that in tomorrow.
This should also be backported to release24-maint and release23-
On Wednesday 30 August 2006 08:57, Tim Peters wrote:
> Speaking of which, I saw no feedback on the proposed patch in
>
> http://mail.python.org/pipermail/python-dev/2006-August/068502.html
>
> so I'll just check that in tomorrow.
Fine with me!
thanks,
Anthony
--
Anthony Baxter <[EMAIL P
Phillip J. Eby wrote:
> At 05:20 PM 8/29/2006 -0700, Raymond Hettinger wrote:
>
>> * The implementation's doc string examples were not tested and don't
>> work (this is a deep error). One reads:
>>
>> with decimal.getcontext() as ctx:
>> ctx.prec += 2
>> s = ...
>> return
Raymond Hettinger wrote:
>I would like to see the changes to the decimal module reverted for the
>Py2.5 release.
>
>Currently, the code in the decimal module implements the context manager
>as a separate class instead of incorporating it directly in
>decimal.Context.
>
>
That should read ".
On Tue, 2006-08-29 at 19:07 -0400, Tim Peters wrote:
> > I work in the team that delivers python on Solaris. Recently we've
> > been getting requests for delivering python in 64-bit as well
> > as in 32-bit. As you probably know, Solaris can run 64-bit and
> > 32-bit binaries on the same system,
At 05:20 PM 8/29/2006 -0700, Raymond Hettinger wrote:
>* The implementation's doc string examples were not tested and don't
>work (this is a deep error). One reads:
>
> with decimal.getcontext() as ctx:
> ctx.prec += 2
> s = ...
> return +s
>
>
>To get this to work with the
I would like to see the changes to the decimal module reverted for the
Py2.5 release.
Currently, the code in the decimal module implements the context manager
as a separate class instead of incorporating it directly in
decimal.Context. This makes the API unnecessarily complex and is not
prett
[Laszlo (Laca) Peter]
> I work in the team that delivers python on Solaris. Recently we've
> been getting requests for delivering python in 64-bit as well
> as in 32-bit. As you probably know, Solaris can run 64-bit and
> 32-bit binaries on the same system, but of course you can't mix and
> match
[Thomas Wouters]
>>> Why not just "... && x == LONG_MIN"?
[Tim Peters]
>> it's better (when possible) not to tie the code to that `x` was
>> specifically declared as type "long" (e.g., just more stuff that will
>> break if Python decides to make its short int of type PY_LONG_LONG
>> instead).
[Ar
Is anyone familiar enough with modulefinder.py to fix its breakage in
Py3k? It chokes in a nasty way (exceeding the recursion limit) on the
relative import syntax. I suspect this is also a problem for 2.5, when
people use that syntax; hence the cross-post. There's no unittest for
modulefinder.py, b
Hi,
I work in the team that delivers python on Solaris. Recently we've
been getting requests for delivering python in 64-bit as well
as in 32-bit. As you probably know, Solaris can run 64-bit and
32-bit binaries on the same system, but of course you can't mix and
match shared objects with differ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 29, 2006, at 11:29 AM, Georg Brandl wrote:
> There's one problem: it was thought for a long time that there
> wouldn't be
> any more 2.3 releases, so bug fixes were applied only in the head
> and 2.4
> branch.
>
> If there will be a 2.3.6,
Hi Tim,
On Sat, Aug 26, 2006 at 08:37:46PM -0400, Tim Peters wrote:
> [Thomas Wouters]
> > Why not just "... && x == LONG_MIN"?
> it's better (when possible) not to tie the code to that `x` was
> specifically declared as type "long" (e.g., just more stuff that will
> break if Python decides to ma
On 8/28/06, Steve Holden <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> Made it the first step. =)>> -Brett>> On 8/24/06, *Oleg Broytmann* <[EMAIL PROTECTED]>
[EMAIL PROTECTED]>> wrote:>> On Thu, Aug 24, 2006 at 12:21:06PM -0700, Brett Cannon wrote:> > Start a new bug>>"Before s
On Tue, 29 Aug 2006 17:44:40 +0100, David Hopwood <[EMAIL PROTECTED]> wrote:
>Nick Coghlan wrote:
>> A discussion on the py3k list reminded me that translating a forward slice
>> into a reversed slice is significantly less than obvious to many people. Not
>> only do you have to negate the step valu
Nick Coghlan wrote:
> A discussion on the py3k list reminded me that translating a forward slice
> into a reversed slice is significantly less than obvious to many people. Not
> only do you have to negate the step value and swap the start and stop values,
> but you also need to subtract one from
Barry Warsaw <[EMAIL PROTECTED]> wrote:
> I am considering producing a Python 2.3.6 release, which would of
> course only be a bug fix maintenance release. The primary reason is
> that not all OS distributions have upgraded to Python 2.4 and I think
> it's worthwhile for us to bless a relea
Barry Warsaw wrote:
> I am considering producing a Python 2.3.6 release, which would of
> course only be a bug fix maintenance release. The primary reason is
> that not all OS distributions have upgraded to Python 2.4 and I think
> it's worthwhile for us to bless a release that fixes known cr
I am considering producing a Python 2.3.6 release, which would of course only be a bug fix maintenance release. The primary reason is that not all OS distributions have upgraded to Python 2.4 and I think it's worthwhile for us to bless a release that fixes known critical bugs. I'm willing to be
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>>reversed(seq[start:stop:step]) becomes
>> seq[(stop-1)%abs(step):start-1:-step]
>>
>> An rslice builtin would make the latter version significantly easier
>> to read:
>>
>>seq[rslice(start, stop, step)]
>
> How would this deal with omitted sta
On Tue, Aug 29, 2006, Greg Ewing wrote:
> Fredrik Lundh wrote:
>>
>> ET was written years before the "certain modules should use camelcase" stuff
>> was removed from PEP 8.
>
> Maybe so, but I was hoping that additions to the stdlib in this day
> and age might be adapted to follow modern conventi
That discussion on py3k is far from finished.
We've also had a similar discussion in the past and ended up with
reversed(), which solves the problem on the other end (using a forward
slice but iterating backwards).
Also, when I saw your subject I thought rslice() was related to
rfind(), so the na
On 8/29/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
>
> >reversed(seq[start:stop:step]) becomes
> > seq[(stop-1)%abs(step):start-1:-step]
> >
> > An rslice builtin would make the latter version significantly easier to
> > read:
> >
> >seq[rslice(start, stop, step)]
>
>
Nick Coghlan wrote:
>reversed(seq[start:stop:step]) becomes
> seq[(stop-1)%abs(step):start-1:-step]
>
> An rslice builtin would make the latter version significantly easier to read:
>
>seq[rslice(start, stop, step)]
How would this deal with omitted start and/or stop values?
--
Greg
__
Greg Ewing wrote:
> Fredrik Lundh wrote:
>
>
>>ET was written years before the "certain modules should use camelcase" stuff
>>was removed from PEP 8.
>
>
> Maybe so, but I was hoping that additions to the
> stdlib in this day and age might be adapted to follow
> modern conventions instead of ju
A discussion on the py3k list reminded me that translating a forward slice
into a reversed slice is significantly less than obvious to many people. Not
only do you have to negate the step value and swap the start and stop values,
but you also need to subtract one from each of the step values, an
Fredrik Lundh wrote:
> ET was written years before the "certain modules should use camelcase" stuff
> was removed from PEP 8.
Maybe so, but I was hoping that additions to the
stdlib in this day and age might be adapted to follow
modern conventions instead of just being plonked in
as-is.
--
Greg
Steve Holden wrote:
> Standards, apparently, are for *other* people :-)
ET was written years before the "certain modules should use camelcase" stuff
was removed from PEP 8. as a refresher for those of you who have trouble
remembering how things were back in early 2004, here's GvR's original styl
29 matches
Mail list logo
