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: $D
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 concept
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, lon
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:
ht
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 implem
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
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 ot
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.or
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 rea
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 ob
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 N
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
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
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 reason
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 lo
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 coor
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 c
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 alr
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 th
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
Ver
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
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
>
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
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
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
On Thu, Feb 09, 2006 at 03:39:46PM -0800, Aahz wrote:
> Can you provide a couple of examples where you think you'd want __index__
> functionality but the name would be inappropriate?
Not really, or I wouldn't have had only a _slight_ reservation :) There are
many functioncalls and methodcalls tha
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 dom
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
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
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
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 differen
> "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 th
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 o
> 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
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 t
Adam Olsen wrote:
> 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?
The general rule is th
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 d
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
On 2/13/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> 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 o
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 c
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 l
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
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
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
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 th
45 matches
Mail list logo
