[issue1766304] improve xrange.__contains__

Changes by Benjamin Peterson : -- resolution: -> accepted status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailin

[issue1766304] improve xrange.__contains__

Benjamin Peterson added the comment: 2010/6/3 Tal Einat : > > Tal Einat 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

[issue1766304] improve xrange.__contains__

Tal Einat 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 users. Finally, conditions such

[issue1766304] improve xrange.__contains__

Antoine Pitrou 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 from 2.x and

[issue1766304] improve xrange.__contains__

Alexander Belopolsky 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 __

[issue1766304] improve xrange.__contains__

Benjamin Peterson 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 _

[issue1766304] improve xrange.__contains__

Antoine Pitrou added the comment: Rescheduling to 3.2, if applicable (otherwise I suggest closing). -- versions: +Python 3.2 -Python 2.7 ___ Python tracker ___ ___

[issue1766304] improve xrange.__contains__

Antoine Pitrou 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 2.7? > Y

[issue1766304] improve xrange.__contains__

Changes by Alexander Belopolsky : -- assignee: -> belopolsky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1766304] improve xrange.__contains__

Alexander Belopolsky added the comment: On Wed, Jun 2, 2010 at 11:17 AM, Tal Einat 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 I'll take my time with this. I'll review your patch, b

[issue1766304] improve xrange.__contains__

Mark Dickinson 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 __

[issue1766304] improve xrange.__contains__

Tal Einat 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 I guess I'll take my time wit

[issue1766304] improve xrange.__contains__

Mark Dickinson 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, since this is pure opt

[issue1766304] improve xrange.__contains__

Tal Einat 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. Currently I'm thinking of: 1. starting

[issue1766304] improve xrange.__contains__

Raymond Hettinger 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 _

[issue1766304] improve xrange.__contains__

Changes by Mark Dickinson : -- versions: -Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue1766304] improve xrange.__contains__

Mark Dickinson 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 ___ _

[issue1766304] improve xrange.__contains__

Changes by Eugene Kapun : -- nosy: +abacabadabacaba ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue1766304] improve xrange.__contains__

Changes by Mark Dickinson : -- assignee: mark.dickinson -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue1766304] improve xrange.__contains__

Mark Dickinson 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 __

[issue1766304] improve xrange.__contains__

Mark Dickinson 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 subclass of int:

[issue1766304] improve xrange.__contains__

Mark Dickinson 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. -- ___ Python tracker

[issue1766304] improve xrange.__contains__

Mark Dickinson 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

[issue1766304] improve xrange.__contains__

Robert Lehmann 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 ___

[issue1766304] improve xrange.__contains__

Benjamin Peterson 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: +benjamin.peterson __

[issue1766304] improve xrange.__contains__

Mark Dickinson 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, other): return oth

[issue1766304] improve xrange.__contains__

Mark Dickinson 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 within/without/at endpo

[issue1766304] improve xrange.__contains__

Robert Lehmann 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: http://bugs.python.org/file14939/range.patch

[issue1766304] improve xrange.__contains__

Mark Dickinson 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'. (Though tha

[issue1766304] improve xrange.__contains__

Mark Dickinson 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 overflow, leading to

[issue1766304] improve xrange.__contains__

Mark Dickinson added the comment: The py3k patch no longer works: it makes use of PyObject_Cmp, which no longer exists. -- ___ Python tracker ___

[issue1766304] improve xrange.__contains__

Raymond Hettinger added the comment: +1 for an O(1) contains-test. -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list

[issue1766304] improve xrange.__contains__

Joseph Thomson 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 said in my closed duplica

[issue1766304] improve xrange.__contains__

Changes by Mark Dickinson : -- nosy: +hpesoj ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue1766304] improve xrange.__contains__

Changes by Mark Dickinson : -- stage: -> needs patch type: -> feature request versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.0 ___ Python tracker ___ ___

[issue1766304] improve xrange.__contains__

Mark Dickinson added the comment: Closed issue 6826 as a duplicate of this issue. -- nosy: +marketdickinson ___ Python tracker ___

[issue1766304] improve xrange.__contains__

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 be

[issue1766304] improve xrange.__contains__

Stargaming added the comment: Later on, when Greg mentions the current for/if performance asymmetry, Guido states: > Fair enough. So maybe *you* can contribute a patch? I don't read this as a rejection, but of course you're right -- this patch is purely an optimization. As already written in m

[issue1766304] improve xrange.__contains__

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. -

[issue1766304] improve xrange.__contains__

Antoine Pitrou added the comment: The 2.6 patch should probably use long instead of int. -- nosy: +pitrou _ Tracker <[EMAIL PROTECTED]> _ ___

[issue1766304] improve xrange.__contains__

Changes by Guido van Rossum: -- versions: +Python 3.0 _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bugs-list mailing list Unsubscribe:

[issue1766304] improve xrange.__contains__

Changes by Georg Brandl: -- keywords: +py3k _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bugs-list mailing list Unsubscribe: http://m