2008/4/26, Benjamin Peterson <[EMAIL PROTECTED]>:
> First of all, should the length of range be completely constricted by
> Py_ssize_t? (issue 2690) Since indexing already is constrained by
> this, it would make sense to make the whole object live under that
What is range()?
help(range) shows
Facundo Batista gmail.com> writes:
>
> 2008/4/26, Benjamin Peterson gmail.com>:
..
> What is range()?
>
> help(range) shows me that range "Returns an iterator that generates
> the numbers in the range on demand."
>
This is not correct in 3.x: range does not return an iterator. There is an
i
Alexander Belopolsky wrote:
Facundo Batista gmail.com> writes:
Ahá! So, as ints are unbound in Python, I could easily do:
r = range(1,10)
The problem with supporting this is that len(r) will raise overflow error.
It would be nice to get rid of the limitation on len(), bu
2008/4/26 Alexander Belopolsky <[EMAIL PROTECTED]>:
> > What is range()?
> >
> > help(range) shows me that range "Returns an iterator that generates
> > the numbers in the range on demand."
>
> This is not correct in 3.x: range does not return an iterator. There is an
> iterator similar to r
On Sat, Apr 26, 2008 at 1:49 PM, Facundo Batista
<[EMAIL PROTECTED]> wrote:
> Which should the range() definition be, in your words?
"A set of integers from start to stop skipping step."
[ ... ]
> At this moment I stopped writing this mail, and I went to code a
> Range() class to have the sem
2008/4/26, Benjamin Peterson <[EMAIL PROTECTED]>:
> lens are forced to be <= Py_ssize_t because that's the limit put on
> sequence sizes.
But this should be a secuence issue... or not? Why I'm limiting the
general len()/__len__ infrastructure?
Thanks!
--
.Facundo
Blog: http://www.taniqu
On Sat, Apr 26, 2008 at 2:06 PM, Facundo Batista
<[EMAIL PROTECTED]> wrote:
> 2008/4/26, Benjamin Peterson <[EMAIL PROTECTED]>:
>
>
> > lens are forced to be <= Py_ssize_t because that's the limit put on
> > sequence sizes.
>
> But this should be a secuence issue... or not? Why I'm limiting th
Benjamin Peterson schrieb:
On Sat, Apr 26, 2008 at 1:49 PM, Facundo Batista
<[EMAIL PROTECTED]> wrote:
Which should the range() definition be, in your words?
"A set of integers from start to stop skipping step."
[ ... ]
"Set" is definitely misleading -- it has no ordering.
Georg
--
Thus
Hi,
Would it be a good idea to make memoryview indexing consistent with
the behaviour of bytes object?
>>> memoryview(b'hello')[0]
bytearray(b'h')
>>> b'hello'[0]
104
-- Alexandre
___
Python-3000 mailing list
[email protected]
http://mail.
Hm, yes this seems reasonable. Travis, what do you think of this?
On Sat, Apr 26, 2008 at 1:51 PM, Alexandre Vassalotti
<[EMAIL PROTECTED]> wrote:
> Would it be a good idea to make memoryview indexing consistent with
> the behaviour of bytes object?
>
> >>> memoryview(b'hello')[0]
> bytearra
Hi,
Since _abcoll shouldn't be used directly, would changing its __name__
module attribute to 'collections' be justified? This would hide the
module from appearing in the subclasses listing of help().
-- Alexandre
___
Python-3000 mailing list
Python-300
On Sat, Apr 26, 2008 at 3:34 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> "Set" is definitely misleading -- it has no ordering.
True. I was trying to convey the unrepeated part of the set
definition. Is "an ordered set of integers" better?
--
Cheers,
Benjamin Peterson
I'm not in favor of lying regarding the origin of objects; it makes it
harder to find the source and can confuse other introspection tools.
This is an inherent limitation of help(), and not one I'm inclined to
lose sleep over.
On Sat, Apr 26, 2008 at 3:21 PM, Alexandre Vassalotti
<[EMAIL PROTECTED
Although I am not totally convinced that it would make harder to find
to source or that it could confuse other introspection tools, I don't
feel that something worth arguing about. So, I guess that pretty much
kill the idea.
Thanks,
-- Alexandre
On Sat, Apr 26, 2008 at 6:53 PM, Guido van Rossum <
Guido van Rossum wrote:
Hm, yes this seems reasonable. Travis, what do you think of this?
On Sat, Apr 26, 2008 at 1:51 PM, Alexandre Vassalotti
<[EMAIL PROTECTED]> wrote:
Would it be a good idea to make memoryview indexing consistent with
the behaviour of bytes object?
>>> memoryview(b'hel
>> lens are forced to be <= Py_ssize_t because that's the limit put on
>> sequence sizes.
>
> But this should be a secuence issue... or not? Why I'm limiting the
> general len()/__len__ infrastructure?
Because a C type is used to represent it, not a Python object. Any
C type (whichever you chos
Travis Oliphant wrote:
My feel right now is to not do the special case at all and
actually return a memory-view object even for element access
That could be very tedious in the case where the elements
are actually bytes, though.
Maybe there should be a separate bytesview() object to
use instea
Benjamin Peterson wrote:
On Sat, Apr 26, 2008 at 3:34 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
"Set" is definitely misleading -- it has no ordering.
True. I was trying to convey the unrepeated part of the set
definition. Is "an ordered set of integers" better?
What's wrong with 'sequence
18 matches
Mail list logo
