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
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
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
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
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,
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:
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
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).
I
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
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
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:
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
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
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
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:
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:
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
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
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
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
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.
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
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
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
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
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
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
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
others
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
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
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
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
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
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
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
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.
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
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
42 matches
Mail list logo