I know this PEP is rejected. However I have a problem that
would benefit from having extreme values and the sample
implementation that is given in the PEP is unsatifactory
for my purpose.
I had written my own module, which works similarly but
is somewhat extended. Here is an example of how it can
be used and how I would like to use it but get stuck.
from extreme import Top
>>Top
Top
>>Top + 1
Top
>>Top - 30
Top
>>Top 1e99
True
>>lst = range(10)
lst[:Top]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: slice indices must be integers or None
So this is where I am stuck. I need this Top value in
a context where it can be used as a start or stop value
in a slice. My idea was that since a stop value greater
than the length of lst in this context would simply return
a copy of lst, using Top in such a way should behave so
too. However I don't see a way of doing that.
So can someone provide ideas to get this behaviour?
If not is there a chance that PEP 326 gets revived?
--
Antoon Pardon 23  1679 
In message <sl********************@rcpc42.vub.ac.be>, Antoon Pardon wrote:
I need this Top value in
a context where it can be used as a start or stop value
in a slice.
But the only valid values allowed for indices are 0 up to the length of the
array inclusive. Larger integers are not allowed, so why should Top be
allowed?
Lawrence D'Oliveiro wrote:
In message <sl********************@rcpc42.vub.ac.be>, Antoon Pardon wrote:
I need this Top value in
a context where it can be used as a start or stop value
in a slice.
But the only valid values allowed for indices are 0 up to the length of the
array inclusive. Larger integers are not allowed, so why should Top be
allowed?
Larger integers are not allowed as subscripts, but slicing is more
tolerant:
| >>array = ['a', 'b', 'c']
| >>array[:1]
| ['a']
| >>array[:2]
| ['a', 'b']
| >>array[:3]
| ['a', 'b', 'c']
| >>array[:4]
| ['a', 'b', 'c']
| >>array[:987654321]
| ['a', 'b', 'c']
BTW, negative subscripts are allowed, too; see e.g. http://docs.python.org/tut/node5.htm...00000000000000
HTH,
John
Antoon Pardon wrote:
I had written my own module, which works similarly but
is somewhat extended. Here is an example of how it can
be used and how I would like to use it but get stuck.
from extreme import Top
>>>Top
Top
>>>Top + 1
Top
>>>Top - 30
Top
>>>Top 1e99
True
>>>lst = range(10)
lst[:Top]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: slice indices must be integers or None
So this is where I am stuck. I need this Top value in
a context where it can be used as a start or stop value
in a slice. My idea was that since a stop value greater
than the length of lst in this context would simply return
a copy of lst, using Top in such a way should behave so
too. However I don't see a way of doing that.
So can someone provide ideas to get this behaviour?
>>import sys
class Top(object):
.... def __index__(self):
.... return sys.maxint
....
>>Top = Top()
range(5)[:Top]
[0, 1, 2, 3, 4]
This can of course fail in many interesting ways...
Peter
On 2006-09-27, Peter Otten <__*******@web.dewrote:
Antoon Pardon wrote:
>I had written my own module, which works similarly but
is somewhat extended. Here is an example of how it can
be used and how I would like to use it but get stuck.
from extreme import Top
>>>>Top
Top
>>>>Top + 1
Top
>>>>Top - 30
Top
>>>>Top 1e99
True
>>>>lst = range(10)
lst[:Top]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: slice indices must be integers or None
So this is where I am stuck. I need this Top value in
a context where it can be used as a start or stop value
in a slice. My idea was that since a stop value greater
than the length of lst in this context would simply return
a copy of lst, using Top in such a way should behave so
too. However I don't see a way of doing that.
So can someone provide ideas to get this behaviour?
>>>import sys
class Top(object):
... def __index__(self):
... return sys.maxint
...
>>>Top = Top()
range(5)[:Top]
[0, 1, 2, 3, 4]
This can of course fail in many interesting ways...
To begin with this already fails:
>>for i in xrange(Top):
.... print i
....
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: an integer is required
What bothers me a bit about the rejection of PEP 326 is that one of the
reasons stated is: http://mail.python.org/pipermail/pyt...ry/042306.html
- it is easily implemented when you really need it
Well I thought it would simplify some things for me, so I tried an
implementation and then found that some of the things that I would
want to do with it wont work. So the "is easily implemented" bit
seems not to be correct.
--
Antoon Pardon
"Antoon Pardon" <ap*****@forel.vub.ac.bewrote in message
news:sl********************@rcpc42.vub.ac.be...
On 2006-09-27, Peter Otten <__*******@web.dewrote:
>Antoon Pardon wrote:
>>I had written my own module, which works similarly but
is somewhat extended. Here is an example of how it can
be used and how I would like to use it but get stuck.
from extreme import Top
>Top
Top
>Top + 1
Top
>Top - 30
Top
>Top 1e99
True
>lst = range(10)
>lst[:Top]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: slice indices must be integers or None
<snip>
What about this?
-- Paul
class TopClass(int):
def __add__(self,other):
return self
def __sub__(self,other):
return self
def __mul__(self,other):
return self
def __div__(self,other):
return self
def __iadd__(self,other):
return self
def __isub__(self,other):
return self
def __imul__(self,other):
return self
def __idiv__(self,other):
return self
def __str__(self):
return "Top"
import sys
Top = TopClass(sys.maxint)
print Top
print int(Top)
print int(Top-1e9)
a = range(10)
print a[:Top]
print a[Top:]
print a[3:Top]
Prints:
Top
2147483647
2147483647
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[]
[3, 4, 5, 6, 7, 8, 9]
"Antoon Pardon" <ap*****@forel.vub.ac.bewrote in message
news:sl********************@rcpc42.vub.ac.be...
On 2006-09-27, Peter Otten <__*******@web.dewrote:
>Antoon Pardon wrote:
>>I had written my own module, which works similarly but
is somewhat extended. Here is an example of how it can
be used and how I would like to use it but get stuck.
from extreme import Top
>Top
Top
>Top + 1
Top
>Top - 30
Top
>Top 1e99
True
>lst = range(10)
>lst[:Top]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: slice indices must be integers or None
Here's a little more refined version of my previous post:
class StubbornInt(int):
def invariantOp(self,other):
return self
__add__ = invariantOp
__sub__ = invariantOp
__mul__ = invariantOp
__div__ = invariantOp
__iadd__ = invariantOp
__isub__ = invariantOp
__imul__ = invariantOp
__idiv__ = invariantOp
__radd__ = invariantOp
__rsub__ = invariantOp
__rmul__ = invariantOp
__rdiv__ = invariantOp
def __str__(self):
return self.name
import sys
Top = StubbornInt(sys.maxint)
Top.name = "Top"
Bottom = StubbornInt(-sys.maxint-1)
Bottom.name = "Bottom"
print Top
print int(Top)
print int(Top-1e9)
print Bottom
print Bottom+sys.maxint
print int(Bottom+sys.maxint)
a = range(10)
print a[:Top]
print a[Top:]
print a[3:Top]
print 3+Top
print Top+3
print 5+2/6*Top
print a[Bottom:3]
for i in xrange(Top):
print i
if i 10: break
prints:
Top
2147483647
2147483647
Bottom
Bottom
-2147483648
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[]
[3, 4, 5, 6, 7, 8, 9]
Top
Top
Top
0
1
2
3
4
5
6
7
8
9
10
11
[0, 1, 2]
Lawrence D'Oliveiro <ld*@geek-central.gen.new_zealandwrote:
>In message <sl********************@rcpc42.vub.ac.be>, Antoon Pardon wrote:
>I need this Top value in
a context where it can be used as a start or stop value
in a slice.
But the only valid values allowed for indices are 0
>>range(5)[:-1]
[0, 1, 2, 3]
up to the length of the
array inclusive. Larger integers are not allowed, [ ... ]
>>range(5)[:sys.maxint]
[0, 1, 2, 3, 4]
--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomež se bera eadward ofdun hlęddre heafdes bęce bump bump bump
On 2006-09-27, Paul McGuire <pt***@austin.rr._bogus_.comwrote:
"Antoon Pardon" <ap*****@forel.vub.ac.bewrote in message
news:sl********************@rcpc42.vub.ac.be...
>On 2006-09-27, Peter Otten <__*******@web.dewrote:
>>Antoon Pardon wrote:
I had written my own module, which works similarly but
is somewhat extended. Here is an example of how it can
be used and how I would like to use it but get stuck.
from extreme import Top
>>Top
Top
>>Top + 1
Top
>>Top - 30
Top
>>Top 1e99
True
>>lst = range(10)
>>lst[:Top]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: slice indices must be integers or None
Here's a little more refined version of my previous post:
class StubbornInt(int):
def invariantOp(self,other):
return self
__add__ = invariantOp
__sub__ = invariantOp
__mul__ = invariantOp
__div__ = invariantOp
__iadd__ = invariantOp
__isub__ = invariantOp
__imul__ = invariantOp
__idiv__ = invariantOp
__radd__ = invariantOp
__rsub__ = invariantOp
__rmul__ = invariantOp
__rdiv__ = invariantOp
def __str__(self):
return self.name
import sys
Top = StubbornInt(sys.maxint)
Top.name = "Top"
Bottom = StubbornInt(-sys.maxint-1)
Bottom.name = "Bottom"
Well one problem I have with your solution is the following:
>>for x in xrange(sys.maxint - 2, Top):
... print x
...
2147483645
2147483646
>>>
The idea with a Top (and Bottom) variable is that you once and for
all have a value that is bigger (smaller) than any other value you are
going to use. AFAICS using a subclass of int will always
leave an opportunity open where an other value will be treated
as bigger (smaller), because functions like xrange will just
look at the int value of the object.
--
Antoon Pardon
On Wed, 27 Sep 2006 13:37:40 +0000, Paul McGuire wrote:
Here's a little more refined version of my previous post:
class StubbornInt(int):
def invariantOp(self,other):
return self
__add__ = invariantOp
__sub__ = invariantOp
[snip rest of code]
import sys
Top = StubbornInt(sys.maxint)
Top shouldn't need to depend on a specific integer value, but then it is
easy enough to subclass StubbornInt.
However, there is a more serious problem with your definition of Top:
>>Top sys.maxint+1
False
But Top is supposed to bigger than everything, right?
Okay, let's fix it:
class FixedTop(StubbornInt):
def __init__(self):
super(FixedTop, self).__init__(sys.maxint)
self.name = 'Top'
def _bigger(self, other):
# Top is bigger than everything
return True
def _smaller(self, other):
# Top is smaller than nothing
return False
__lt__ = __le__ = _smaller
__gt__ = __ge__ = _bigger
Let's test it out:
>>Top = FixedTop()
Top 45
True
>>Top sys.maxint
True
>>Top 2L**512
True
>>Top None
True
>>Top "hello"
True
So far so good.
However, the downside of rolling your own Top is the risk that one day
you'll have something like this:
class Funny:
def __init__(self, name):
self.name = name
def __str__(self):
return self.name
def __gt__(self, other):
return len(str(self)) len(str(other))
and then you'll have problems:
>>bottom = Funny("Bottom")
Top bottom
True
>>bottom Top
True
As far as I can see, the only way to avoid edge cases like this is for Top
(and Bottom) to be built-ins that are special-cased by Python.
--
Steven.
Antoon Pardon wrote:
What bothers me a bit about the rejection of PEP 326 is that one of the
reasons stated is:
http://mail.python.org/pipermail/pyt...ry/042306.html
- it is easily implemented when you really need it
Well I thought it would simplify some things for me, so I tried an
implementation and then found that some of the things that I would
want to do with it wont work. So the "is easily implemented" bit
seems not to be correct.
IIRC, the PEP proposed the Smallest and Largest singletons with the
sole purpose of being used in comparisons. No numeric behavior was
implied, i.e. Smallest and Largest are not negative and positive
infinity in the math sense of the word. So I guess the "easily
implemented" refers to this case alone.
George
Antoon Pardon wrote:
To begin with this already fails:
>>>for i in xrange(Top):
... print i
What do you expect this to do? Loop forever?
--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown
>To begin with this already fails:
>>
>>>>for i in xrange(Top):
... print i
What do you expect this to do? Loop forever?
Perhaps the infinite loop should take half as long as
>>for i in xrange(Bottom, Top): print i
Though then the values when the loop first starts are kinda
ambiguous... :)
Given the limits of xrange:
>>for i in
xrange(10000000000000000000000000,1000000000000000 0000000009):
.... print i
Traceback (most recent call last):
File "<stdin>", line 1, in ?
OverflowError: long int too large to convert to int
I suspect one would have an overflow condition to help break you
out of the loop...
>>try:
.... for i in range(Top):
.... print i
.... except OverflowError:
.... print 'done!'
....and then you time your instruction cycles and your disk reads
so they fall under the read-head at just the right time...[*]
-tkc
[*] http://www.catb.org/jargon/html/story-of-mel.html
On 2006-09-27, George Sakkis <ge***********@gmail.comwrote:
Antoon Pardon wrote:
>What bothers me a bit about the rejection of PEP 326 is that one of the
reasons stated is:
http://mail.python.org/pipermail/pyt...ry/042306.html
- it is easily implemented when you really need it
Well I thought it would simplify some things for me, so I tried an
implementation and then found that some of the things that I would
want to do with it wont work. So the "is easily implemented" bit
seems not to be correct.
IIRC, the PEP proposed the Smallest and Largest singletons with the
sole purpose of being used in comparisons. No numeric behavior was
implied, i.e. Smallest and Largest are not negative and positive
infinity in the math sense of the word.
That is true.
So I guess the "easily implemented" refers to this case alone.
This doesn't follow. Take the example were I got stuck.
>>lst = range(10)
lst[:Top]
This doesn't need arithmetics done with Top. The only fact that
you need is: Top >= len(lst). In a way this isn't that difficult
in itself, it becomes difficult because python doesn't allow
ducktyping for a lot of its builtins. I could write my own
function:
def leftslice(lst, num):
return [ tp[1] for tp in enumerate(lst) if tp[0] < num ]
This function works as expected if you substituted Top for num
and as you can see, no arithmetic is done on num, only comparisons.
--
Antoon Pardon
On 2006-09-27, OKB (not okblacke) <br************@NObrenSPAMbarn.netwrote:
Antoon Pardon wrote:
>To begin with this already fails:
>>>>for i in xrange(Top):
... print i
What do you expect this to do? Loop forever?
Yes that is what I would expect. If someone would ask me
to implement a function like xrange it would look something
like the following (*)
def xrange(start=1, stop, step=1):
while start < stop:
yield start
start += step
Since Top is supposed to be bigger than any other value this would
indeed loop forever. The only reason that this doesn't work with
the builtin, is because the builtin xrange insist on its arguments
being ints instead of allowing duck typing.
(*) Yes I know this isn't legal python. I just wrote it like this
to make the intention clear instead of putting in the code that
would actually behave like xrange with regards to its defaults.
IMO that would just detract from the actual code.
--
Antoon Pardon
On 2006-09-27, Tim Chase <py*********@tim.thechases.comwrote:
>>To begin with this already fails:
>for i in xrange(Top):
... print i
What do you expect this to do? Loop forever?
Perhaps the infinite loop should take half as long as
>for i in xrange(Bottom, Top): print i
Though then the values when the loop first starts are kinda
ambiguous... :)
Given the limits of xrange:
>for i in
xrange(10000000000000000000000000,1000000000000000 0000000009):
... print i
Traceback (most recent call last):
File "<stdin>", line 1, in ?
OverflowError: long int too large to convert to int
I suspect one would have an overflow condition to help break you
out of the loop...
Sometime people want an infinite loop.
Personnaly I don't see why I should get an overflow error while
doing this:
import sys
for i in xrange(sys.maxint - 4, sys.maxint + 5):
pass
I remember in the days when longs and ints were being unified,
that some people complained, because without this unification,
a loop in which an int counter was incremented would necessarily
end when the counter overflowed and this was a good indication
there was a bug somewhere. The response to that was, that you
could never foresee how your algorithm would be used and that
maybe someday someone found a good way to use your algoritm
where the counter would go beyond sys.maxint.
Following this logic there is no reason why xrange should be
limited to ints.
>try:
... for i in range(Top):
... print i
... except OverflowError:
... print 'done!'
...and then you time your instruction cycles and your disk reads
so they fall under the read-head at just the right time...[*]
[*] http://www.catb.org/jargon/html/story-of-mel.html
There is no reason to compare what I propose to the story of melvin.
All behaviour of the objects would be well defined and could be
easily understood to those who would read the documentation.
--
Antoon Pardon
On 2006-09-27, Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:
On Wed, 27 Sep 2006 13:37:40 +0000, Paul McGuire wrote:
>Here's a little more refined version of my previous post:
class StubbornInt(int):
def invariantOp(self,other):
return self
__add__ = invariantOp
__sub__ = invariantOp
[snip rest of code]
>import sys
Top = StubbornInt(sys.maxint)
Top shouldn't need to depend on a specific integer value, but then it is
easy enough to subclass StubbornInt.
However, there is a more serious problem with your definition of Top:
>>>Top sys.maxint+1
False
But Top is supposed to bigger than everything, right?
Okay, let's fix it:
class FixedTop(StubbornInt):
def __init__(self):
super(FixedTop, self).__init__(sys.maxint)
self.name = 'Top'
def _bigger(self, other):
# Top is bigger than everything
return True
def _smaller(self, other):
# Top is smaller than nothing
return False
__lt__ = __le__ = _smaller
__gt__ = __ge__ = _bigger
Let's test it out:
>>>Top = FixedTop()
Top 45
True
>>>Top sys.maxint
True
>>>Top 2L**512
True
>>>Top None
True
>>>Top "hello"
True
So far so good.
However, the downside of rolling your own Top is the risk that one day
you'll have something like this:
class Funny:
def __init__(self, name):
self.name = name
def __str__(self):
return self.name
def __gt__(self, other):
return len(str(self)) len(str(other))
and then you'll have problems:
>>>bottom = Funny("Bottom")
Top bottom
True
>>>bottom Top
True
As far as I can see, the only way to avoid edge cases like this is for Top
(and Bottom) to be built-ins that are special-cased by Python.
An other problem is that if you roll your own, they wont be accepted in
a lot of buitins where they would make sense. Take itertools.repeat as
it is now and I understand correctly there are two possibilities.
1) Your extreme values are not a subclass of int, then you won't be able
to use them as a times arguments.
2) Your extreme values are a subclass of int, then they will somehow
have an int value and this int value will be used, so that the repeat
won't be an infinite loop.
--
Antoon Pardon
Antoon Pardon wrote:
On 2006-09-27, George Sakkis <ge***********@gmail.comwrote:
>Antoon Pardon wrote:
>>What bothers me a bit about the rejection of PEP 326 is that one of the
reasons stated is:
http://mail.python.org/pipermail/pyt...ry/042306.html
- it is easily implemented when you really need it
Well I thought it would simplify some things for me, so I tried an
implementation and then found that some of the things that I would
want to do with it wont work. So the "is easily implemented" bit
seems not to be correct.
IIRC, the PEP proposed the Smallest and Largest singletons with the
sole purpose of being used in comparisons. No numeric behavior was
implied, i.e. Smallest and Largest are not negative and positive
infinity in the math sense of the word.
That is true.
>So I guess the "easily implemented" refers to this case alone.
This doesn't follow. Take the example were I got stuck.
>>>lst = range(10)
lst[:Top]
FWIW, this works with 2.5 and the __index__ slot:
>>class Top(object):
.... def __index__(self):
.... return sys.maxint
....
>>a=range(5)
a[:Top()]
[0, 1, 2, 3, 4]
>>>
Georg
Antoon Pardon wrote:
On 2006-09-27, OKB (not okblacke) <br************@NObrenSPAMbarn.netwrote:
>Antoon Pardon wrote:
>>To begin with this already fails:
>for i in xrange(Top):
... print i
What do you expect this to do? Loop forever?
Yes that is what I would expect.
For unterminating loops, use while 1:, and if you need the counter,
itertools.count().
If someone would ask me
to implement a function like xrange it would look something
like the following (*)
def xrange(start=1, stop, step=1):
while start < stop:
yield start
start += step
Since Top is supposed to be bigger than any other value this would
indeed loop forever. The only reason that this doesn't work with
the builtin, is because the builtin xrange insist on its arguments
being ints instead of allowing duck typing.
xrange() *could* be implemented as shown above, but do you realize
that it would be a severe performance hit compared to the current
implementation, which doesn't give almost all users a benefit at all?
Georg
On 2006-09-28, Georg Brandl <g.*************@gmx.netwrote:
Antoon Pardon wrote:
>On 2006-09-27, OKB (not okblacke) <br************@NObrenSPAMbarn.netwrote:
>>Antoon Pardon wrote:
To begin with this already fails:
>>for i in xrange(Top):
... print i
What do you expect this to do? Loop forever?
Yes that is what I would expect.
For unterminating loops, use while 1:, and if you need the counter,
itertools.count().
Neither of these will work if you want an easy way to choose
between repeating a specific number of times and an infinite
loop.
Of course you can include special tests in your code, but the
purpose of values like Top is to eliminate special case code
in a number of situations.
>If someone would ask me
to implement a function like xrange it would look something
like the following (*)
def xrange(start=1, stop, step=1):
while start < stop:
yield start
start += step
Since Top is supposed to be bigger than any other value this would
indeed loop forever. The only reason that this doesn't work with
the builtin, is because the builtin xrange insist on its arguments
being ints instead of allowing duck typing.
xrange() *could* be implemented as shown above, but do you realize
that it would be a severe performance hit compared to the current
implementation, which doesn't give almost all users a benefit at all?
That code was just meant to illustrate behaviour, one could always
code as follows:
def _xrange(start=1, stop, step=1):
# see implemantation above
def xrange(start=1, stop, step=1):
if (type(start), type(stop), type(step)) == (int, int, int):
return builtin.xrange(start, stop, step)
else:
return _xrange(start, stop, step)
Just to show that with some thinking one could come up with
an implementation that was fast in most cases and yet would
allow for other types than ints if that would make sense.
--
Antoon Pardon
On 2006-09-28, Georg Brandl <g.*************@gmx.netwrote:
Antoon Pardon wrote:
>On 2006-09-27, George Sakkis <ge***********@gmail.comwrote:
>>Antoon Pardon wrote:
What bothers me a bit about the rejection of PEP 326 is that one of the
reasons stated is:
http://mail.python.org/pipermail/pyt...ry/042306.html
- it is easily implemented when you really need it
Well I thought it would simplify some things for me, so I tried an
implementation and then found that some of the things that I would
want to do with it wont work. So the "is easily implemented" bit
seems not to be correct.
IIRC, the PEP proposed the Smallest and Largest singletons with the
sole purpose of being used in comparisons. No numeric behavior was
implied, i.e. Smallest and Largest are not negative and positive
infinity in the math sense of the word.
That is true.
>>So I guess the "easily implemented" refers to this case alone.
This doesn't follow. Take the example were I got stuck.
>>>>lst = range(10)
lst[:Top]
FWIW, this works with 2.5 and the __index__ slot:
>class Top(object):
... def __index__(self):
... return sys.maxint
...
>a=range(5)
a[:Top()]
[0, 1, 2, 3, 4]
>>
It is something worth investigating, but I'm not sure it
will suite my purpose. You see I have a table module,
a table is like a list except the base index doesn't need
to be 0. So I could have a table that is indexable from
sys.maxint - 3 to sys.maxint + 7. I'm not sure tbl[:Top]
would do what it is supposed to do in those circumstances.
--
Antoon Pardon
Antoon Pardon <ap*****@forel.vub.ac.bewrites:
It is something worth investigating, but I'm not sure it
will suite my purpose. You see I have a table module,
a table is like a list except the base index doesn't need
to be 0. So I could have a table that is indexable from
sys.maxint - 3 to sys.maxint + 7. I'm not sure tbl[:Top]
would do what it is supposed to do in those circumstances.
Top = object()
class Table(list):
def __getitem__(self, n):
get = super(Table, self).__getitem__
if n is Top:
return get(-1)
return get(n - self.baseindex)
a=Table(range(9))
a.baseindex = 3
>>print a[5], a[Top]
2 8
Paul Rubin <http://ph****@NOSPAM.invalidwrites:
sys.maxint - 3 to sys.maxint + 7. I'm not sure tbl[:Top]
would do what it is supposed to do in those circumstances.
Top = object()
class Table(list):
....
Oh wait, I missed the : in your tbl[:Top] example. Yeah, you could
hair up Table to account for slices, I'll leave the exercise to you.
On 2006-09-28, Paul Rubin <httpwrote:
Paul Rubin <http://ph****@NOSPAM.invalidwrites:
sys.maxint - 3 to sys.maxint + 7. I'm not sure tbl[:Top]
would do what it is supposed to do in those circumstances.
>Top = object()
class Table(list):
...
Oh wait, I missed the : in your tbl[:Top] example. Yeah, you could
hair up Table to account for slices, I'll leave the exercise to you.
Yes, I could hair up Table, but that is missing the point somewhat.
The idea for provinding extreme values is that you don't have to
hair up the code.
In any case it seems I have my answer. I have some suggestions I can
try out, but writing up once own module for extreme values isn't as
easy as is suggested in the rejection of the PEP and there is probably
very little chance to get the PEP reopened.
--
Antoon Pardon This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Christoph Becker-Freyseng |
last post by:
Hello,
recently there was a lot discussion about a new Path-class. So Gerrit
Holl started to write a pre-PEP
http://people.nl.linux.org/~gerrit/creaties/path/pep-xxxx.html
We tried to...
|
by: Gary Robinson |
last post by:
I've recently had a couple of cases of needing exactly what it proposes, and
having to kluge around the fact that it's not there. It's a great idea.
If there anywhere else I should be expressing...
|
by: Helmut Jarausch |
last post by:
Hi,
what does Python do if two objects aren't comparable (to my opinion)
If I've understood "Python in a Nutschell" correctly it should raise an
exception but it doesn't do for me.
Here are...
|
by: Grant Edwards |
last post by:
Perhaps I'm doing something wrong: the struct module docs say
it's IEE 754, but I can't figure out how to get it to handle
NaN values correctly (either packing or unpacking).
>>> x =...
|
by: Darren Dale |
last post by:
Hello,
def test(data):
i = ? This is the line I have trouble with
if i==1: return data
else: return data
a,b,c,d = test()
|
by: Marcin Ciura |
last post by:
Here is a pre-PEP about print that I wrote recently.
Please let me know what is the community's opinion on it.
Cheers,
Marcin
PEP: XXX
Title: Print Without Intervening Space
Version:...
|
by: GTalbot |
last post by:
Hello fellow authoring.stylesheets colleagues,
Can someone please explain why the bottom margin of the last inflow
block-level child in an overflowed parent should not have its margin
reachable....
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
