Tal Einat talei...@users.sourceforge.net added the comment:
In my mind, the reason for this patch is that xrange/range can be thought of as
a lazy list of integers. However without this patch, membership checking was
done trivially instead of in a smart/lazy manner, which is unexpected for
Benjamin Peterson benja...@python.org added the comment:
2010/6/3 Tal Einat rep...@bugs.python.org:
Tal Einat talei...@users.sourceforge.net added the comment:
In my mind, the reason for this patch is that xrange/range can be thought of
as a lazy list of integers. However without this
Changes by Benjamin Peterson benja...@python.org:
--
resolution: - accepted
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1766304
___
Tal Einat talei...@users.sourceforge.net added the comment:
I'd like to implement this for 2.x, if there's any chance of this being
accepted. Is there still a chance of getting this into 2.7?
This will be my first patch for the Python core, so please tell me if I'm
missing something.
Mark Dickinson dicki...@gmail.com added the comment:
A rapidly diminishing chance for 2.7, IMO. I wouldn't want to try to add this
after the first release candidate, which is scheduled for June 5 (and I'm not
sure I'll have time to review a patch between now and then).
On the other hand,
Tal Einat talei...@users.sourceforge.net added the comment:
I'd really like to have this in 2.7. Is there no chance of getting it into 2.7
after rc1 is released?
If so, I can have the patch ready by Friday 14:00 GMT, but if nobody will have
time to review (and possibly commit) in time for RC1
Mark Dickinson dicki...@gmail.com added the comment:
Benjamin?
I'd really like to have this in 2.7. Is there no chance of getting it
into 2.7 after rc1 is released?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1766304
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Wed, Jun 2, 2010 at 11:17 AM, Tal Einat rep...@bugs.python.org wrote:
..
If so, I can have the patch ready by Friday 14:00 GMT, but if nobody will
have time to review
(and possibly commit) in time for RC1 I guess
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
assignee: - belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1766304
___
Antoine Pitrou pit...@free.fr added the comment:
If so, I can have the patch ready by Friday 14:00 GMT, but if nobody will
have time to review
(and possibly commit) in time for RC1 I guess I'll take my time with this.
I'll review your patch, but why are you so eager to get this into
Antoine Pitrou pit...@free.fr added the comment:
Rescheduling to 3.2, if applicable (otherwise I suggest closing).
--
versions: +Python 3.2 -Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1766304
Benjamin Peterson benja...@python.org added the comment:
I don't really see the point. I would be more inclined towards it if there was
a patch already, but patching this doesn't strike me as a key feature.
--
___
Python tracker
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
This is already in 3.x. The only reason I can think of to get this in
2.7 is to have fewer performance surprises between 2.x and 3.x.
--
___
Python tracker
Antoine Pitrou pit...@free.fr added the comment:
Le mercredi 02 juin 2010 à 18:10 +, Alexander Belopolsky a écrit :
This is already in 3.x. The only reason I can think of to get this in
2.7 is to have fewer performance surprises between 2.x and 3.x.
Since you are supposed to forward-port
Changes by Eugene Kapun abacabadabac...@gmail.com:
--
nosy: +abacabadabacaba
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1766304
___
___
Mark Dickinson dicki...@gmail.com added the comment:
I suggest closing this: it's been implemented (for range) in Python 3.x, and I
think it's too late for 2.x now.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1766304
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
As an implementation detail, it isn't too late to put this into 2.x if it is
something we care about.
--
priority: normal - low
___
Python tracker rep...@bugs.python.org
Mark Dickinson dicki...@gmail.com added the comment:
Just to be on the safe side, I changed the PyLong_Check(ob) check to
PyLong_CheckExact(ob) || PyBool_Check(ob), in r75051. Without this, one
can get different results for 'x in range(10)' and 'x in list(range(10))'
if x is an instance of a
Mark Dickinson dicki...@gmail.com added the comment:
Unassigning myself since I don't intend to do anything myself about
xrange.__contains__ in 2.x. (But I'll happily review patches.)
--
___
Python tracker rep...@bugs.python.org
Changes by Mark Dickinson dicki...@gmail.com:
--
assignee: mark.dickinson -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1766304
___
___
Mark Dickinson dicki...@gmail.com added the comment:
Great---thanks!
Would it be worth using PyObject_IsTrue instead of comparing with zero
using PyObject_RichCompareBool? (Sorry; should have spotted this last
time around.)
--
___
Python tracker
Mark Dickinson dicki...@gmail.com added the comment:
Answering myself: probably not worth it: I failed to notice that you
already need zero for the 'step 0' comparison.
Applied in r75028.
Leaving open for consideration of 2.x xrange.
--
___
Mark Dickinson dicki...@gmail.com added the comment:
Robert,
The patch looks good: thank you.
Please use C89-style comments (/* ... */).
I'd like to see a few more tests covering the various combinations of
start less-than/equal-to/greater-than stop, step positive/negative, tested
value
Mark Dickinson dicki...@gmail.com added the comment:
Also, it would be good to add a test or two for non-integers, e.g. to make
explicit that the following behaviour hasn't changed:
class C:
... def __int__(self): return 3
... def __index__(self): return 5
... def __eq__(self,
Benjamin Peterson benja...@python.org added the comment:
As a small style note, I would prefer if the patch assigned in
conditionals less and split them out to the line before. I see that
rangeobject.c has a mixed style with regards to this, so the clearer one
should win! :)
--
nosy:
Robert Lehmann lehman...@gmail.com added the comment:
Thanks for your feedback. I added a few tests and changed the bits you
criticized.
--
Added file: http://bugs.python.org/file14945/range.patch
___
Python tracker rep...@bugs.python.org
Robert Lehmann lehman...@gmail.com added the comment:
I revised the patch for Python 3.1 and added notices to Misc/NEWS and
the range documentation.
(Changing Type to resource usage.)
--
nosy: +lehmannro
type: feature request - resource usage
Added file:
Mark Dickinson dicki...@gmail.com added the comment:
The py3k patch no longer works: it makes use of PyObject_Cmp, which no
longer exists.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1766304
Mark Dickinson dicki...@gmail.com added the comment:
The trunk patch is also unacceptable in its current form:
1. there are no docs or tests
2. keyval, start, step and end should have type long, not type int
(as Antoine already mentioned)
3. the expression ((keyval - start) % step) can
Mark Dickinson dicki...@gmail.com added the comment:
[Joseph Thomson]
Also, as I said in my closed duplicate issue, 'if value in range(lower,
upper)' to me looks far more Pythonic than 'if value = lower and value
upper'.
Note that the Pythonic spelling would be: 'if lower = value upper'.
Mark Dickinson dicki...@gmail.com added the comment:
Closed issue 6826 as a duplicate of this issue.
--
nosy: +marketdickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1766304
___
Changes by Mark Dickinson dicki...@gmail.com:
--
stage: - needs patch
type: - feature request
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.0
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1766304
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +hpesoj
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1766304
___
___
Python-bugs-list
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
+1 for an O(1) contains-test.
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1766304
___
Joseph Thomson joseph.thom...@gmail.com added the comment:
Seeing as the range type has most likely stabalised by now, I would like
to renew this issue. The current behaviour of range/xrange could
introduce unforeseen performance issues if users are not aware of its
inner workings.
Also, as I
Alexander Belopolsky added the comment:
Here are my comments on the py3k patch:
1. Sign of a PyLong object o is the same as the sign of Py_SIZE(o). I
would think it is safe to use this fact within python core. (User code
that may need to work across multiple versions of python may need to
Alexander Belopolsky added the comment:
Do we really need another way to spell a = x b? Have you got a
real-world use case in mind for the version with step 1?
I'm at most lukewarm; I'd be willing to look at a patch to the C code
in the py3k-struni branch, plus unit tests though.
-- GvR
Antoine Pitrou added the comment:
The 2.6 patch should probably use long instead of int.
--
nosy: +pitrou
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1766304
_
Changes by Guido van Rossum:
--
versions: +Python 3.0
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1766304
_
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Georg Brandl:
--
keywords: +py3k
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1766304
_
___
Python-bugs-list mailing list
Unsubscribe:
40 matches
Mail list logo
