Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Guido van Rossum wrote: On 2/10/06, Mark Russell [EMAIL PROTECTED] wrote: On 10 Feb 2006, at 12:45, Nick Coghlan wrote: An alternative would be to call it __discrete__, as that is the key characteristic of an indexing type - it consists of a sequence of discrete values that can be isomorphically mapped to the integers. Another alternative: __as_ordinal__. Wikipedia describes ordinals as numbers used to denote the position in an ordered sequence which seems a pretty precise description of the intended result. The as_ prefix also captures the idea that this should be a lossless conversion. Aren't ordinals generally assumed to be non-negative? The numbers used as slice or sequence indices can be negative! The other problem with 'ordinal' as a name is that the term already has a meaning in Python (what else would 'ord' be short for?). I liked index from the start, but I thought we should put at least a bit of effort into seeing if we could come up with anything better. I don't really see any way that either 'discrete' or 'ordinal' can be said to qualify as better :) 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/10/06, Mark Russell [EMAIL PROTECTED] wrote: On 10 Feb 2006, at 12:45, Nick Coghlan wrote: An alternative would be to call it __discrete__, as that is the key characteristic of an indexing type - it consists of a sequence of discrete values that can be isomorphically mapped to the integers. Another alternative: __as_ordinal__. Wikipedia describes ordinals as numbers used to denote the position in an ordered sequence which seems a pretty precise description of the intended result. The as_ prefix also captures the idea that this should be a lossless conversion. Aren't ordinals generally assumed to be non-negative? The numbers used as slice or sequence indices can be negative! Also, I don't buy the reason for 'as'l I don't see how this word would require the conversion to be losless. The PEP continues to use __index__ and I'm happy with that. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Guido: I don't like __true_int__ very much. Personally, I'm fine with calling it __index__ index is OK, but is there a reason __integer__ would be rejected? __int__ roughly follows the low-level C implementation, and may do odd things on unusual input. __integer__ properly creates a conceptual integer, so it won't lose or corrupt information (unless the class writer does this intentionally). -jJ ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Is there a reason __integer__ would be rejected? Guido van Rossum answered: Given the number of folks who misappreciate the difference between __getattr__ and __getattribute__, I'm not sure I'd want to encourage using abbreviated and full forms of the same term in the same context. When confronted with the existence of __int__ and __integer__ I can see plenty of confusion ahead. I see this case as slightly different. getattr and getattribute are both things you might reasonably want to do. __int__ is something you probably shouldn't be doing very often anymore; it is being kept for backwards compatibility. Switching getattr and getattribute will cause bugs, which may be hard to diagnose, even for people who might reasonably be using the hooks. Switching __int__ and (newname) won't matter, unless __int__ was already doing something unexpected. Since backwards compatibility means we can't prevent __int__ from doing the unexpected, a similar name might be *good* -- at least it would tip people off that __int__ might not be what they want. I can't think of any way to associate getattr vs getattribute with timing or precedence. I already associate int with a specific C datatype and integer with something more abstract. (I'm not sure the new method is a better match for my integer concept, and it probably isn't a better match for java.lang.Integer, but ... the separation is there.) -jJ ___ 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] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Travis wrote: The patch adds a new API function int PyObject_AsIndex(obj) How did you decide between int and long? Why not ssize_t? Also, if index is being added as a builtin, should the failure result be changed? I'm thinking that this may become a replacement for isinstance(val, (int, long)). If so, it might be nice not to raise errors, or at least to raise a more specific subclass. (Catching a TypeError and then checking the message string ... does not seem clean.) -jJ ___ 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] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Travis wrote: The patch adds a new API function int PyObject_AsIndex(obj) How did you decide between int and long? Why not ssize_t? ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/13/06, Jim Jewett [EMAIL PROTECTED] wrote: Travis wrote: The patch adds a new API function int PyObject_AsIndex(obj) How did you decide between int and long? Why not ssize_t? It should be the same type used everywhere for indexing. In the svn HEAD that's int. Once PEP 353 lands it should be ssize_t. I've made Travis aware of this issue already. Also, if index is being added as a builtin, should the failure result be changed? I don't like to add a built-in index() at this point; mostly because of Occam's razor (we haven't found a need). I'm thinking that this may become a replacement for isinstance(val, (int, long)). But only if it's okay if values sys.maxint (or some other constant indicating the limit of ssize_t) are not required to be supported. If so, it might be nice not to raise errors, or at least to raise a more specific subclass. (Catching a TypeError and then checking the message string ... does not seem clean.) I'm not sure what you mean. How could index(x) ever replace isinstance(x, (int, long)) without raising an exception? Surely index(abc) *should* raise an exception. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On Mon, Feb 13, 2006, Jim Jewett wrote: getattr and getattribute are both things you might reasonably want to do. __int__ is something you probably shouldn't be doing very often anymore; it is being kept for backwards compatibility. And how do you convert a float to an int? __int__ is NOT going away; the sole purpose of __index__ is to enable sequence index functionality and similar use-cases for int-like objects that do not subclass from int. (For example, one might want to allow an enumeration type to index into a list.) -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/13/06, Guido van Rossum [EMAIL PROTECTED] wrote: ... I don't like to add a built-in index() at this point; mostly because of Occam's razor (we haven't found a need). I thought you had agreed, back when I had said that __index__ should also be made easily available to implementors of Python-coded classes implementing sequences, more elegantly than by demanding that they code x.__index__() [I can't think offhand of any other special-named method that you HAVE to call directly -- there's always some syntax or functionality in the standard library to call it more elegantly on your behalf]. This doesn't neessarily argue that index should be in the built-ins module, of course, but I thought there was a sentiment towards having it in either the operator or math modules. Alex ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Sorry, you're right. operator.index() sounds fine. --Guido On 2/13/06, Alex Martelli [EMAIL PROTECTED] wrote: On 2/13/06, Guido van Rossum [EMAIL PROTECTED] wrote: ... I don't like to add a built-in index() at this point; mostly because of Occam's razor (we haven't found a need). I thought you had agreed, back when I had said that __index__ should also be made easily available to implementors of Python-coded classes implementing sequences, more elegantly than by demanding that they code x.__index__() [I can't think offhand of any other special-named method that you HAVE to call directly -- there's always some syntax or functionality in the standard library to call it more elegantly on your behalf]. This doesn't neessarily argue that index should be in the built-ins module, of course, but I thought there was a sentiment towards having it in either the operator or math modules. Alex -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 10 Feb 2006, at 12:45, Nick Coghlan wrote:An alternative would be to call it "__discrete__", as that is the key characteristic of an indexing type - it consists of a sequence of discrete values that can be isomorphically mapped to the integers. Another alternative: __as_ordinal__. Wikipedia describes ordinals as "numbers used to denote the position in an ordered sequence" which seems a pretty precise description of the intended result. The "as_" prefix also captures the idea that this should be a lossless conversion.Mark Russell___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Guido van Rossum wrote: But, then it *should* be renamed to i.e. __true_int__. One such place is in abstract.c sequence_repeat function. I don't like __true_int__ very much. Personally, I'm fine with calling it __index__ after the most common operation. (Well, I would be since I think I came up with the name in the first place. :-) Since naming is always so subjective *and* important, I'll wait a few days, but if nobody suggests something better then we should just go with __index__. An alternative would be to call it __discrete__, as that is the key characteristic of an indexing type - it consists of a sequence of discrete values that can be isomorphically mapped to the integers. Numbers conceptually representing continuously variable quantities (such as floats and decimals) are the ones that really shouldn't define this method. I wouldn't mind __index__ though, as even though some of the use cases won't be strictly using the result as an index, the shared characteristic of being isomorphic to the integers should be sufficient to allow the term to make some sort of sense. This would hardly be the first case where names of operators are overloaded using imprecise terminology, after all. 'or', 'and', 'sub' and 'xor' aren't the right terms for set union, intersection, difference and disjunction, but they're close enough conceptually that the names still have meaning. Ditto for 'mul' and 'add' meaning repetition and concatenation for sequences (no comment on 'mod' and string formatting though. . .) 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
[Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Guido seemed accepting to this idea about 9 months ago when I spoke to him. I finally got around to writing up the PEP. I'd really like to get this into Python 2.5 if possible. -Travis PEP: ### Title: Allowing any object to be used for slicing Version: $Revision 1.1$ Last Modified: $Date: 2006/02/09 $ Author: Travis Oliphant oliphant at ee.byu.edu Status: Draft Type: Standards Track Created: 09-Feb-2006 Python-Version: 2.5 Abstract This PEP proposes adding an sq_index slot in PySequenceMethods and an __index__ special method so that arbitrary objects can be used in slice syntax. Rationale Currently integers and long integers play a special role in slice notation in that they are the only objects allowed in slice syntax. In other words, if X is an object implementing the sequence protocol, then X[obj1:obj2] is only valid if obj1 and obj2 are both integers or long integers. There is no way for obj1 and obj2 to tell Python that they could be reasonably used as indexes into a sequence. This is an unnecessary limitation. In NumPy, for example, there are 8 different integer scalars corresponding to unsigned and signed integers of 8, 16, 32, and 64 bits. These type-objects could reasonably be used as indexes into a sequence if there were some way for their typeobjects to tell Python what integer value to use. Proposal Add a sq_index slot to PySequenceMethods, and a corresponding __index__ special method. Objects could define a function to place in the sq_index slot that returns an C-integer for use in PySequence_GetSlice, PySequence_SetSlice, and PySequence_DelSlice. Implementation Plan 1) Add the slots 2) Change the ISINT macro in ceval.c to accomodate objects with the index slot defined. 3) Change the _PyEval_SliceIndex function to accomodate objects with the index slot defined. Possible Concerns Speed: Implementation should not slow down Python because integers and long integers used as indexes will complete in the same number of instructions. The only change will be that what used to generate an error will now be acceptable. Why not use nb_int which is already there? The nb_int, nb_oct, and nb_hex methods are used for coercion. Floats have these methods defined and floats should not be used in slice notation. Reference Implementation Available on PEP acceptance. Copyright This document is placed in the public domain ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Travis Oliphant wrote:
PEP: ###
Title: Allowing any object to be used for slicing
[...]
Rationale
Currently integers and long integers play a special role in slice
notation in that they are the only objects allowed in slice
syntax. In other words, if X is an object implementing the sequence
protocol, then X[obj1:obj2] is only valid if obj1 and obj2 are both
integers or long integers. There is no way for obj1 and obj2 to
tell Python that they could be reasonably used as indexes into a
sequence. This is an unnecessary limitation.
[...]
I like the general idea from an academic point of view.
Just one question: could you explain what I should expect from x[
slicer('spam') : slicer('eggs') ] when slicer implements this
protocol?
Specifically, I'd like to known how you want to define the interval
between two objects. Or is that for the sliced/indexed object to
decide?
--eric
___
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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Eric Nieuwland wrote:
Travis Oliphant wrote:
PEP: ###
Title: Allowing any object to be used for slicing
[...]
Rationale
Currently integers and long integers play a special role in slice
notation in that they are the only objects allowed in slice
syntax. In other words, if X is an object implementing the sequence
protocol, then X[obj1:obj2] is only valid if obj1 and obj2 are both
integers or long integers. There is no way for obj1 and obj2 to
tell Python that they could be reasonably used as indexes into a
sequence. This is an unnecessary limitation.
[...]
I like the general idea from an academic point of view.
Just one question: could you explain what I should expect from x[
slicer('spam') : slicer('eggs') ] when slicer implements this
protocol?
Specifically, I'd like to known how you want to define the interval
between two objects. Or is that for the sliced/indexed object to
decide?
As I understand it:
The sliced object will only see integers. The PEP wants to give arbitrary
objects the possibility of pretending to be an integer that can be used
for indexing.
Georg
___
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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Eric Nieuwland wrote:
Travis Oliphant wrote:
PEP: ###
Title: Allowing any object to be used for slicing
[...]
Rationale
Currently integers and long integers play a special role in slice
notation in that they are the only objects allowed in slice
syntax. In other words, if X is an object implementing the sequence
protocol, then X[obj1:obj2] is only valid if obj1 and obj2 are both
integers or long integers. There is no way for obj1 and obj2 to
tell Python that they could be reasonably used as indexes into a
sequence. This is an unnecessary limitation.
[...]
I like the general idea from an academic point of view.
Just one question: could you explain what I should expect from x[
slicer('spam') : slicer('eggs') ] when slicer implements this protocol?
Specifically, I'd like to known how you want to define the interval
between two objects. Or is that for the sliced/indexed object to decide?
I'm not proposing to define that. The sequence protocol already
provides to the object only a c-integer (currently it's int but there's
a PEP to change it to ssize_t). Right now, only Python integer and
Python Long integers are allowed to be converted to this c-integer
passed to the object that is implementing the slicing protocol. It's up
to the object to deal with those integers as it sees fit.
One possible complaint that is easily addressed is that the slot should
really go into the PyNumber_Methods as nb_index because a number-like
object is what would typically be easily convertible to a c-integer.
Having to implement the sequence protocol (on the C-level) just to
enable sq_index seems in-appropriate.
So, I would change the PEP to implement nb_index instead...
-Travis
___
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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Travis Oliphant [EMAIL PROTECTED] wrote: Guido seemed accepting to this idea about 9 months ago when I spoke to him. I finally got around to writing up the PEP. I'd really like to get this into Python 2.5 if possible. -1 I've detailed my reasons here: http://mail.python.org/pipermail/python-dev/2006-January/059851.html In short, there are purely math usages that want to convert to int while raising exceptions from inexact results. The name __index__ seems inappropriate for this, and I feel it would be cleaner to fix float.__int__ to raise exceptions from inexact results (after a suitable warning period and with a trunc() function added to math.) -- Adam Olsen, aka Rhamphoryncus ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Adam Olsen wrote: On 2/9/06, Travis Oliphant [EMAIL PROTECTED] wrote: Guido seemed accepting to this idea about 9 months ago when I spoke to him. I finally got around to writing up the PEP. I'd really like to get this into Python 2.5 if possible. -1 I've detailed my reasons here: http://mail.python.org/pipermail/python-dev/2006-January/059851.html In short, there are purely math usages that want to convert to int while raising exceptions from inexact results. The name __index__ seems inappropriate for this, and I feel it would be cleaner to fix float.__int__ to raise exceptions from inexact results (after a suitable warning period and with a trunc() function added to math.) I'm a little confused. Is your opposition solely due to the fact that you think float's __int__ method ought to raise exceptions and the apply_slice code should therefore use the __int__ slot? In theory I can understand this reasoning. In practice, however, the __int__ slot has been used for coercion and changing the semantics of int(3.2) at this stage seems like a recipe for lots of code breakage. I don't think something like that is possible until Python 3k. If that is not your opposition, please be more clear. Regardless of how it is done, it seems rather unPythonic to only allow 2 special types to be used in apply_slice and assign_slice. -Travis ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Travis Oliphant [EMAIL PROTECTED] wrote: Guido seemed accepting to this idea about 9 months ago when I spoke to him. I finally got around to writing up the PEP. I'd really like to get this into Python 2.5 if possible. -Travis PEP: ### Title: Allowing any object to be used for slicing Overally I am fine with the idea. Being used as an index is different than coercion into an int so adding this extra method seems reasonable. Implementation Plan 1) Add the slots 2) Change the ISINT macro in ceval.c to accomodate objects with the index slot defined. Maybe the macro should also be renamed? Not exactly testing if something is an int anymore if it checks for __index__. 3) Change the _PyEval_SliceIndex function to accomodate objects with the index slot defined. -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
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Travis Oliphant [EMAIL PROTECTED] wrote: Guido seemed accepting to this idea about 9 months ago when I spoke to him. I finally got around to writing up the PEP. I'd really like to get this into Python 2.5 if possible. Excellent! I was just going over the 2.5 schedule with Neal Norwitz last night, and looking back in my slides for OSCON 2005 I noticed this idea, and was wondering if you still wanted it. I'm glad the answer is yes! BTW do you also still want to turn ZeroDivisionError into a warning (that is changed into an error by default)? That idea shared a slide and I believe it was discussed in the same meeting you I and some others had in San Mateo last summer. I'll comment on the PEP in-line. I've assigned it number 357 and checked it in. meta-remark In the past, the protocol for aqcuiring a PEP number has been to ask the PEP coordinators (Barry Warsaw and David Goodger) to assign one. I believe that we could simplify this protocol to avoid necessary involvement of the PEP coordinators; all that is needed is someone with checkin privileges. I propose the following protocol: 1. In the peps directory, do a svn sync. 2. Look at the files that are there and the contents of pep-.txt. This should provide you with the last PEP number in sequence, ignoring the out-of-sequence PEPs (666, 754, and 3000). The reason to look in PEP 0 is that it is conceivable that a PEP number has been reserved in the index but not yet committed, so you should use the largest number. 3. Add 1 to the last PEP number. This gives your new PEP number, . 4. Using svn add and svn commit, check in the file pep-.txt (use %04d to format the number); the contents can be a minimal summary or even just headers. If this succeeds, you have successfully assigned yourself PEP number . Exit. 5. If you get an error from svn about the commit, someone else was carrying out the same protocol at the same time, and they won the race. Start over from step 1. I suspect the PEP coordinators have informally been using this protocol amongst themseles -- and amongst the occasional developer who bypassed the official protocol, like I've done in the past and like Neal Norwitz did last night with the Python 2.5 release schedule, PEP 356. I'm simply extending the protocol to all developers with checkin permissions. For PEP authors without checkin permissions, nothing changes, except that optionally if they don't get a timely response from the PEP coordinators, they can ask someone else with checkin permissions. /meta-remark PEP: ### Title: Allowing any object to be used for slicing Version: $Revision 1.1$ Last Modified: $Date: 2006/02/09 $ Author: Travis Oliphant oliphant at ee.byu.edu Status: Draft Type: Standards Track Created: 09-Feb-2006 Python-Version: 2.5 Abstract This PEP proposes adding an sq_index slot in PySequenceMethods and an __index__ special method so that arbitrary objects can be used in slice syntax. Rationale Currently integers and long integers play a special role in slice notation in that they are the only objects allowed in slice syntax. In other words, if X is an object implementing the sequence protocol, then X[obj1:obj2] is only valid if obj1 and obj2 are both integers or long integers. There is no way for obj1 and obj2 to tell Python that they could be reasonably used as indexes into a sequence. This is an unnecessary limitation. In NumPy, for example, there are 8 different integer scalars corresponding to unsigned and signed integers of 8, 16, 32, and 64 bits. These type-objects could reasonably be used as indexes into a sequence if there were some way for their typeobjects to tell Python what integer value to use. Proposal Add a sq_index slot to PySequenceMethods, and a corresponding __index__ special method. Objects could define a function to place in the sq_index slot that returns an C-integer for use in PySequence_GetSlice, PySequence_SetSlice, and PySequence_DelSlice. Shouldn't this slot be in the PyNumberMethods extension? It feels more like a property of numbers than of a property of sequences. Also, the slot name should then probably be nb_index. There's also an ambiguity when using simple indexing. When writing x[i] where x is a sequence and i an object that isn't int or long but implements __index__, I think i.__index__() should be used rather than bailing out. I suspect that you didn't think of this because you've already special-cased this in your code -- when a non-integer is passed, the mapping API is used (mp_subscript). This is done to suppose extended slicing. The built-in sequences (list, str, unicode, tuple for sure, probably more) that implement mp_subscript should probe for nb_index before giving up. The generic code in PyObject_GetItem should also check for nb_index before giving up. Implementation Plan 1) Add the slots 2) Change the ISINT macro in
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Brett Cannon [EMAIL PROTECTED] wrote: 2) Change the ISINT macro in ceval.c to accomodate objects with the index slot defined. Maybe the macro should also be renamed? Not exactly testing if something is an int anymore if it checks for __index__. Have you looked at the code? ceval.c uses this macro only in the slice processing code. I don't particularly care what it's called... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 2/9/06, Brett Cannon [EMAIL PROTECTED] wrote: 2) Change the ISINT macro in ceval.c to accomodate objects with the index slot defined. Maybe the macro should also be renamed? Not exactly testing if something is an int anymore if it checks for __index__. Have you looked at the code? ceval.c uses this macro only in the slice processing code. I don't particularly care what it's called... Yeah, I looked. I just don't want a misnamed macro to start being abused for some odd reason. Might as well rename it while we are thinking about it then let it have a bad name. -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
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Travis E. Oliphant [EMAIL PROTECTED] wrote: I'm a little confused. Is your opposition solely due to the fact that you think float's __int__ method ought to raise exceptions and the apply_slice code should therefore use the __int__ slot? In theory I can understand this reasoning. In practice, however, the __int__ slot has been used for coercion and changing the semantics of int(3.2) at this stage seems like a recipe for lots of code breakage. I don't think something like that is possible until Python 3k. If that is not your opposition, please be more clear. Regardless of how it is done, it seems rather unPythonic to only allow 2 special types to be used in apply_slice and assign_slice. Yes, that is the basis of my opposition, and I do understand it would take a long time to change __int__. What is the recommended practice for python? I can think of three distinct categories of behavior: - float to str. Some types converted to str might by lossy, but in general it's a very drastic conversion and unrelated to the others - float to Decimal. Raises an exception because it's usually lossy. - Decimal to int. Truncates, quite happily losing precision.. I guess my confusion revolves around float to Decimal. Is lossless conversion a good thing in python, or is prohibiting float to Decimal conversion just a fudge to prevent people from initializing a Decimal from a float when they really want a str? -- Adam Olsen, aka Rhamphoryncus ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On Thu, 09 Feb 2006 01:00:22 -0700, Travis Oliphant [EMAIL PROTECTED] wrote: Abstract This PEP proposes adding an sq_index slot in PySequenceMethods and an __index__ special method so that arbitrary objects can be used in slice syntax. Rationale Currently integers and long integers play a special role in slice notation in that they are the only objects allowed in slice syntax. In other words, if X is an object implementing the sequence protocol, then X[obj1:obj2] is only valid if obj1 and obj2 are both integers or long integers. There is no way for obj1 and obj2 to tell Python that they could be reasonably used as indexes into a sequence. This is an unnecessary limitation. In NumPy, for example, there are 8 different integer scalars corresponding to unsigned and signed integers of 8, 16, 32, and 64 bits. These type-objects could reasonably be used as indexes into a sequence if there were some way for their typeobjects to tell Python what integer value to use. Proposal Add a sq_index slot to PySequenceMethods, and a corresponding __index__ special method. Objects could define a function to place in the sq_index slot that returns an C-integer for use in PySequence_GetSlice, PySequence_SetSlice, and PySequence_DelSlice. How about if SLICE byte code interpretation would try to call obj.__int__() if passed a non-(int,long) obj ? Would that cover your use case? BTW the slice type happily accepts anything for start:stop:step I believe, and something[slice(whatever)] will call something.__getitem__ with the slice instance, though this is neither a fast nor nicely spelled way to customize. Regards, Bengt Richter ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On Thu, 2006-02-09 at 11:30 -0800, Guido van Rossum wrote: In the past, the protocol for aqcuiring a PEP number has been to ask the PEP coordinators (Barry Warsaw and David Goodger) to assign one. I believe that we could simplify this protocol to avoid necessary involvement of the PEP coordinators; all that is needed is someone with checkin privileges. I propose the following protocol: [omitted] In general, this is probably fine. Occasionally we reserve a PEP number for something special, or for a pre-request, but I think both are pretty rare. And because of svn and the commit messages we can at least catch those fairly quickly and fix them. Maybe we can add known reserved numbers to PEP 0 so they aren't taken accidentally. What I'm actually more concerned about is that we (really David) often review PEPs and reject first submissions on several grounds. I must say that David's done such a good job at keeping the quality of PEPs high that I'm leery of interfering with that. OTOH, perhaps those with commit privileges should be expected to produce high quality PEPs on the first draft. Maybe we can amend your rules to those people who both have commit privileges and have successfully submitted a PEP before. PEP virgins should go through the normal process. -Barry signature.asc Description: This is a digitally signed message part ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Bengt Richter wrote: How about if SLICE byte code interpretation would try to call obj.__int__() if passed a non-(int,long) obj ? Would that cover your use case? I believe that this is pretty much exactly what I'm proposing. The apply_slice and assign_slice functions in ceval.c are called for the SLICE and STORE_SLICE and DELETE_SLICE opcodes. BTW the slice type happily accepts anything for start:stop:step I believe, and something[slice(whatever)] will call something.__getitem__ with the slice instance, though this is neither a fast nor nicely spelled way to customize. Yes, the slice object itself takes whatever you want. However, Python special-cases what happens for X[a:b] *if* X as the sequence-protocol defined. This is the code-path I'm trying to enhance. -Travis ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Bengt Richter wrote: How about if SLICE byte code interpretation would try to call obj.__int__() if passed a non-(int,long) obj ? Would that cover your use case? I believe that this is pretty much what I'm proposing (except I'm not proposing to use the __int__ method because it is already used as coercion and doing this would allow floats to be used in slices which is a bad thing). The apply_slice and assign_slice functions in ceval.c are called for the SLICE and STORE_SLICE and DELETE_SLICE opcodes. BTW the slice type happily accepts anything for start:stop:step I believe, and something[slice(whatever)] will call something.__getitem__ with the slice instance, though this is neither a fast nor nicely spelled way to customize. Yes, the slice object itself takes whatever you want. However, Python special-cases what happens for X[a:b] *if* X as the sequence-protocol defined. This is the code-path I'm trying to enhance. -Travis ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Barry Warsaw [EMAIL PROTECTED] wrote: On Thu, 2006-02-09 at 11:30 -0800, Guido van Rossum wrote: In the past, the protocol for aqcuiring a PEP number has been to ask the PEP coordinators (Barry Warsaw and David Goodger) to assign one. I believe that we could simplify this protocol to avoid necessary involvement of the PEP coordinators; all that is needed is someone with checkin privileges. I propose the following protocol: [omitted] In general, this is probably fine. Occasionally we reserve a PEP number for something special, or for a pre-request, but I think both are pretty rare. And because of svn and the commit messages we can at least catch those fairly quickly and fix them. Maybe we can add known reserved numbers to PEP 0 so they aren't taken accidentally. What I'm actually more concerned about is that we (really David) often review PEPs and reject first submissions on several grounds. I must say that David's done such a good job at keeping the quality of PEPs high that I'm leery of interfering with that. OTOH, perhaps those with commit privileges should be expected to produce high quality PEPs on the first draft. Maybe we can amend your rules to those people who both have commit privileges and have successfully submitted a PEP before. PEP virgins should go through the normal process. Sounds reasonable to me. Then again I don't think I would ever attempt to get a PEP accepted without at least a single pass over by python-dev or c.l.py . But making it simpler definitely would be nice when you can already check in yourself. -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
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Attached is an updated PEP for 357. I think the index concept is better situated in the PyNumberMethods structure. That way an object doesn't have to define the Sequence protocol just to be treated like an index. -Travis PEP: 357357357 Title: Allowing any object to be used for slicing Version: Revision 1.2 Last Modified: 02/09/2006 Author: Travis Oliphant oliphant at ee.byu.edu Status: Draft Type: Standards Track Created: 09-Feb-2006 Python-Version: 2.5 Abstract This PEP proposes adding an nb_as_index slot in PyNumberMethods and an __index__ special method so that arbitrary objects can be used in slice syntax. Rationale Currently integers and long integers play a special role in slice notation in that they are the only objects allowed in slice syntax. In other words, if X is an object implementing the sequence protocol, then X[obj1:obj2] is only valid if obj1 and obj2 are both integers or long integers. There is no way for obj1 and obj2 to tell Python that they could be reasonably used as indexes into a sequence. This is an unnecessary limitation. In NumPy, for example, there are 8 different integer scalars corresponding to unsigned and signed integers of 8, 16, 32, and 64 bits. These type-objects could reasonably be used as indexes into a sequence if there were some way for their typeobjects to tell Python what integer value to use. Proposal Add a nb_index slot to PyNumberMethods, and a corresponding __index__ special method. Objects could define a function to place in the sq_index slot that returns an appropriate C-integer for use as ilow or ihigh in PySequence_GetSlice, PySequence_SetSlice, and PySequence_DelSlice. Implementation Plan 1) Add the slots 2) Change the ISINT macro in ceval.c to ISINDEX and alter it to accomodate objects with the index slot defined. 3) Change the _PyEval_SliceIndex function to accomodate objects with the index slot defined. Possible Concerns Speed: Implementation should not slow down Python because integers and long integers used as indexes will complete in the same number of instructions. The only change will be that what used to generate an error will now be acceptable. Why not use nb_int which is already there? The nb_int, nb_oct, and nb_hex methods are used for coercion. Floats have these methods defined and floats should not be used in slice notation. Reference Implementation Available on PEP acceptance. Copyright This document is placed in the public domain ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Looks good to me. Only change I might make is mention why __int__ doesn't work sooner (such as in the rationale). Otherwise +1 from me. -Brett On 2/9/06, Travis E. Oliphant [EMAIL PROTECTED] wrote: Attached is an updated PEP for 357. I think the index concept is better situated in the PyNumberMethods structure. That way an object doesn't have to define the Sequence protocol just to be treated like an index. -Travis PEP: 357357357 Title: Allowing any object to be used for slicing Version: Revision 1.2 Last Modified: 02/09/2006 Author: Travis Oliphant oliphant at ee.byu.edu Status: Draft Type: Standards Track Created: 09-Feb-2006 Python-Version: 2.5 Abstract This PEP proposes adding an nb_as_index slot in PyNumberMethods and an __index__ special method so that arbitrary objects can be used in slice syntax. Rationale Currently integers and long integers play a special role in slice notation in that they are the only objects allowed in slice syntax. In other words, if X is an object implementing the sequence protocol, then X[obj1:obj2] is only valid if obj1 and obj2 are both integers or long integers. There is no way for obj1 and obj2 to tell Python that they could be reasonably used as indexes into a sequence. This is an unnecessary limitation. In NumPy, for example, there are 8 different integer scalars corresponding to unsigned and signed integers of 8, 16, 32, and 64 bits. These type-objects could reasonably be used as indexes into a sequence if there were some way for their typeobjects to tell Python what integer value to use. Proposal Add a nb_index slot to PyNumberMethods, and a corresponding __index__ special method. Objects could define a function to place in the sq_index slot that returns an appropriate C-integer for use as ilow or ihigh in PySequence_GetSlice, PySequence_SetSlice, and PySequence_DelSlice. Implementation Plan 1) Add the slots 2) Change the ISINT macro in ceval.c to ISINDEX and alter it to accomodate objects with the index slot defined. 3) Change the _PyEval_SliceIndex function to accomodate objects with the index slot defined. Possible Concerns Speed: Implementation should not slow down Python because integers and long integers used as indexes will complete in the same number of instructions. The only change will be that what used to generate an error will now be acceptable. Why not use nb_int which is already there? The nb_int, nb_oct, and nb_hex methods are used for coercion. Floats have these methods defined and floats should not be used in slice notation. Reference Implementation Available on PEP acceptance. Copyright This document is placed in the public domain ___ 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/brett%40python.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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Guido van Rossum wrote: On 2/9/06, Travis Oliphant [EMAIL PROTECTED] wrote: BTW do you also still want to turn ZeroDivisionError into a warning (that is changed into an error by default)? That idea shared a slide and I believe it was discussed in the same meeting you I and some others had in San Mateo last summer. I think that idea has some support, but I haven't been thinking about it for awhile. Shouldn't this slot be in the PyNumberMethods extension? It feels more like a property of numbers than of a property of sequences. Also, the slot name should then probably be nb_index. Yes, definitely!!! There's also an ambiguity when using simple indexing. When writing x[i] where x is a sequence and i an object that isn't int or long but implements __index__, I think i.__index__() should be used rather than bailing out. I suspect that you didn't think of this because you've already special-cased this in your code -- when a non-integer is passed, the mapping API is used (mp_subscript). This is done to suppose extended slicing. The built-in sequences (list, str, unicode, tuple for sure, probably more) that implement mp_subscript should probe for nb_index before giving up. The generic code in PyObject_GetItem should also check for nb_index before giving up. I agree. These should also be changed. I'll change the PEP, too. I think all sequence objects that implement mp_subscript should probably be modified according to the lines I sketched above. True. This is very close to acceptance. I think I'd like to see the patch developed and submitted to SF (and assigned to me) prior to acceptance. O.K. I'll work on it. -Travis ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Adam Olsen [EMAIL PROTECTED] wrote: On 2/9/06, Travis Oliphant [EMAIL PROTECTED] wrote: Guido seemed accepting to this idea about 9 months ago when I spoke to him. I finally got around to writing up the PEP. I'd really like to get this into Python 2.5 if possible. -1 I've detailed my reasons here: http://mail.python.org/pipermail/python-dev/2006-January/059851.html I don't actually see anything relevant to this discussion in that post. In short, there are purely math usages that want to convert to int while raising exceptions from inexact results. The name __index__ seems inappropriate for this, and I feel it would be cleaner to fix float.__int__ to raise exceptions from inexact results (after a suitable warning period and with a trunc() function added to math.) Maybe cleaner, but a thousand time harder given the status quo. Travis has a need for this *today* and __index__ can be added without any incompatibilities. I'm not even sure that it's worth changing __int__ for Python 3.0. Even if float.__int__ raised an exception if the float isn't exactly an integer, I still think it's wrong to use it here. Suppose I naively write some floating point code that usually (or with sufficiently lucky inputs) produces exact results, but which can produce inaccurate (or at least approximate) results in general. If I use such a result as an index, your proposal would allow that -- but the program would suddenly crash with an ImpreciseConversionError exception if the inputs produced an approximated result. I'd rather be made aware of this problem on the first run. Then I can decide whether to use int() or int(round()) or whatever other appropriate conversion. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On Thu, Feb 09, 2006 at 02:32:47PM -0800, Brett Cannon wrote: Looks good to me. Only change I might make is mention why __int__ doesn't work sooner (such as in the rationale). Otherwise +1 from me. I have a slight reservation about the name. On the one hand it's clear the canonical use will be for indexing sequences, and __index__ doesn't look enough like __int__ to get people confused on the difference. On the other hand, there are other places (in C) that want an actual int, and they could use __index__ too. Even more so if a PyArg_Parse* grew a format for 'the index-value for this object' ;) On the *other* one hand, I can't think of a good name... but on the other other hand, it would be awkward to have to support an old name just because the real use wasn't envisioned yet. One-time-machine-for-the-shortsighted-quadrumanus-please-ly y'r,s -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On Fri, Feb 10, 2006, Thomas Wouters wrote: I have a slight reservation about the name. On the one hand it's clear the canonical use will be for indexing sequences, and __index__ doesn't look enough like __int__ to get people confused on the difference. On the other hand, there are other places (in C) that want an actual int, and they could use __index__ too. Even more so if a PyArg_Parse* grew a format for 'the index-value for this object' ;) On the *other* one hand, I can't think of a good name... but on the other other hand, it would be awkward to have to support an old name just because the real use wasn't envisioned yet. Can you provide a couple of examples where you think you'd want __index__ functionality but the name would be inappropriate? -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Guido van Rossum wrote: On 2/9/06, Travis Oliphant [EMAIL PROTECTED] wrote: This is very close to acceptance. I think I'd like to see the patch developed and submitted to SF (and assigned to me) prior to acceptance. Copyright This document is placed in the public domain If you agree with the above comments, please send me an updated version of the PEP and I'll check it in over the old one, and approve it. Then just use SF to submit the patch etc. I uploaded a patch to SF against current SVN. The altered code compiles and the functionality works with classes defined in Python. I have yet to test against a C-type that defines the method. The patch adds a new API function int PyObject_AsIndex(obj). This was not specifically in the PEP but probably should be. The name could also be PyNumber_AsIndex(obj) but I was following the nb_nonzero slot example to help write the code. -Travis ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Travis E. Oliphant [EMAIL PROTECTED] wrote: ... The patch adds a new API function int PyObject_AsIndex(obj). This was not specifically in the PEP but probably should be. The name could also be PyNumber_AsIndex(obj) but I was following the nb_nonzero slot example to help write the code. Shouldn't that new API function (whatever its name) also be somehow exposed for easy access from Python code? I realize new builtins are unpopular, so a builtin 'asindex' might not be appropriate, but perhaps operator.asindex might be. My main point is that I don't think we want every Python-coded sequence to have to call x.__index__() instead. Alex ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Alex Martelli [EMAIL PROTECTED] wrote: Shouldn't that new API function (whatever its name) also be somehow exposed for easy access from Python code? I realize new builtins are unpopular, so a builtin 'asindex' might not be appropriate, but perhaps operator.asindex might be. My main point is that I don't think we want every Python-coded sequence to have to call x.__index__() instead. Very good point; this is why we have a PEP discussion phase. If it's x.__index__(), I think it ought to be operator.index(x). I'm not sure we need a builtin (also not sure we don't). I wonder if hasattr(x, __index__) can be used as the litmus test for int-ness? (Then int and long should have one that returns self.) Travis, can you send me additional PEP updates as context or unified diffs vs. the PEP in SVN? (or against python.org/peps/pep-0357.txt if you don't want to download the entire PEP directory). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Thomas Wouters wrote: On Thu, Feb 09, 2006 at 02:32:47PM -0800, Brett Cannon wrote: Looks good to me. Only change I might make is mention why __int__ doesn't work sooner (such as in the rationale). Otherwise +1 from me. I have a slight reservation about the name. On the one hand it's clear the canonical use will be for indexing sequences, and __index__ doesn't look enough like __int__ to get people confused on the difference. On the other hand, there are other places (in C) that want an actual int, and they could use __index__ too. Even more so if a PyArg_Parse* grew a format for 'the index-value for this object' ;) There are other places in Python that check specifically for int objects and long integer objects and fail with anything else. Perhaps all of these should aslo call the __index__ slot. But, then it *should* be renamed to i.e. __true_int__. One such place is in abstract.c sequence_repeat function. The patch I submitted, perhaps aggressivele, changed that function to call the nb_index slot as well instead of raising an error. Perhaps the slot should be called nb_true_int? -Travis On the *other* one hand, I can't think of a good name... but on the other other hand, it would be awkward to have to support an old name just because the real use wasn't envisioned yet. One-time-machine-for-the-shortsighted-quadrumanus-please-ly y'r,s ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Travis E. Oliphant [EMAIL PROTECTED] wrote: Thomas Wouters wrote: I have a slight reservation about the name. On the one hand it's clear the canonical use will be for indexing sequences, and __index__ doesn't look enough like __int__ to get people confused on the difference. On the other hand, there are other places (in C) that want an actual int, and they could use __index__ too. Even more so if a PyArg_Parse* grew a format for 'the index-value for this object' ;) I think we should just change all the existing formats that require int or long to support nb_as_index. There are other places in Python that check specifically for int objects and long integer objects and fail with anything else. Perhaps all of these should aslo call the __index__ slot. Right, absolutely. But, then it *should* be renamed to i.e. __true_int__. One such place is in abstract.c sequence_repeat function. I don't like __true_int__ very much. Personally, I'm fine with calling it __index__ after the most common operation. (Well, I would be since I think I came up with the name in the first place. :-) Since naming is always so subjective *and* important, I'll wait a few days, but if nobody suggests something better then we should just go with __index__. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Brett == Brett Cannon [EMAIL PROTECTED] writes: Brett On 2/9/06, Barry Warsaw [EMAIL PROTECTED] wrote: Maybe we can amend your rules to those people who both have commit privileges and have successfully submitted a PEP before. PEP virgins should go through the normal process. +1 Brett Sounds reasonable to me. Then again I don't think I would Brett ever attempt to get a PEP accepted without at least a Brett single pass over by python-dev or c.l.py . But making it Brett simpler definitely would be nice when you can already check Brett in yourself. Besides Brett's point that in some sense most new authors *want* to go through the normal process, having the normal process means that there are a couple of people you can contact who are default mentor/editors, and TOOWDTI. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can do free software business; ask what your business can do for free software. ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Thomas Wouters wrote: I have a slight reservation about the name. ... On the other hand, there are other places (in C) that want an actual int, and they could use __index__ too. Maybe __exactint__? -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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 for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Add a nb_index slot to PyNumberMethods, and a corresponding __index__ special method. Objects could define a function to place in the sq_index slot that returns an appropriate I presume 'sq_index' should also be 'nb_index' ___ 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
