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 style
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
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,
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 just being
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
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)]
How would this
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
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 conventions instead
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 start and/or stop
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
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
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 release
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
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 value and
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] mailto:
[EMAIL PROTECTED] wrote: On Thu, Aug 24, 2006 at 12:21:06PM -0700, Brett Cannon wrote: Start a new bugBefore starting a new bug please try
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 make its
-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, it
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
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,
[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
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
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 current
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, but of
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 ... as a
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 +s
To get
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
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
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:
28 matches
Mail list logo
