Forwarded to python list:
Original Message
Subject:Re: Negative array indicies and slice()
Date: Sat, 03 Nov 2012 15:32:04 -0700
From: Andrew Robinson
Reply-To: andr...@r3dsolutions.com
To: Ian Kelly <>
On 11/01/2012 05:32 PM, Ian Kelly wrote:
On 11/2/12 8:57 AM, Andrew Robinson wrote:
Hi Ian,
I apologize for trying your patience with the badly written code example. All
objects were meant to be ThirdParty(), the demo was only to show how a slice()
filter could have been applied for the reasons PEP357 made index() to exist.
eg: becaus
Hi Ian,
I apologize for trying your patience with the badly written code
example. All objects were meant to be ThirdParty(), the demo was only
to show how a slice() filter could have been applied for the reasons
PEP357 made index() to exist.
eg: because numpy items passed to __getitems__ via
On Thu, 01 Nov 2012 15:25:51 -0700, Andrew Robinson wrote:
> On 11/01/2012 12:07 PM, Ian Kelly wrote:
>>> Pep 357 merely added cruft with index(), but really solved nothing.
>>> Everything index() does could be implemented in __getitem__ and
>>> usually is.
>>
>> No. There is a significant diff
andrew...@gmail.com於 2012年10月29日星期一UTC+8上午11時12分11秒寫道：
> The slice operator does not give any way (I can find!) to take slices from
> negative to positive indexes, although the range is not empty, nor the
> expected indexes out of range that I am supplying.
>
>
>
> Many programs that I write w
On Thu, Nov 1, 2012 at 4:25 PM, Andrew Robinson
wrote:
> The bottom line is: __getitem__ must always *PASS* len( seq ) to slice()
> each *time* the slice() object is-used. Since this is the case, it would
> have been better to have list, itself, have a default member which takes the
> raw slice
On 11/01/2012 12:07 PM, Ian Kelly wrote:
On Thu, Nov 1, 2012 at 5:32 AM, Andrew Robinson
wrote:
H was that PEP the active state of Python, when Tim rejected the bug
report?
Yes. The PEP was accepted and committed in March 2006 for release in
Python 2.5. The bug report is from June 2
Ian Kelly wrote:
On Thu, Nov 1, 2012 at 5:32 AM, Andrew Robinson wrote:
Don't bother to fix the bug; allow Python to crash with a subtle bug that often take weeks to track
down by the very small minority doing strange things (Equivalent to the "monkey patch"
syndrome of D'Aprano; BTW: The long
On Thu, Nov 1, 2012 at 5:32 AM, Andrew Robinson
wrote:
> H was that PEP the active state of Python, when Tim rejected the bug
> report?
Yes. The PEP was accepted and committed in March 2006 for release in
Python 2.5. The bug report is from June 2006 has a version
classification of Pytho
On Thu, Nov 1, 2012 at 10:32 PM, Andrew Robinson
wrote:
> presently slice() allows memory leaks through GC loops.
Forgive me if I've missed something here, but isn't it only possible
to make a refloop by decidedly abnormal behaviour? Stuff like:
a=[]; a.append(slice(a))
Seriously, who does this
On 11/01/2012 07:12 AM, Ethan Furman wrote:
Andrew Robinson wrote:
On 10/31/2012 02:20 PM, Ian Kelly wrote:
On Wed, Oct 31, 2012 at 7:42 AM, Andrew Robinson wrote:
Then; I'd note: The non-goofy purpose of slice is to hold three
data values; They are either numbers or None. These *normall
Chris Angelico wrote:
On Fri, Nov 2, 2012 at 1:12 AM, Ethan Furman wrote:
In other words, the slice contains the strings, and my code calculates
the offsets -- Python doesn't do it for me.
That's correct, but you're still translating those strings into
numeric indices.
True, but the point i
On Fri, Nov 2, 2012 at 1:12 AM, Ethan Furman wrote:
> In other words, the slice contains the strings, and my code calculates
> the offsets -- Python doesn't do it for me.
That's correct, but you're still translating those strings into
numeric indices. You can slice a database record based on colu
Andrew Robinson wrote:
On 10/31/2012 02:20 PM, Ian Kelly wrote:
On Wed, Oct 31, 2012 at 7:42 AM, Andrew Robinson wrote:
Then; I'd note: The non-goofy purpose of slice is to hold three
data values; They are either numbers or None. These *normally*
encountered values can't create a memory l
On 10/31/12 8:16 PM, Andrew Robinson wrote:
On 10/31/2012 02:20 PM, Ian Kelly wrote:
On Wed, Oct 31, 2012 at 7:42 AM, Andrew Robinson wrote:
Then; I'd note: The non-goofy purpose of slice is to hold three data
values; They are either numbers or None. These *normally* encountered
On 10/31/2012 02:20 PM, Ian Kelly wrote:
On Wed, Oct 31, 2012 at 7:42 AM, Andrew Robinson wrote:
Then; I'd note: The non-goofy purpose of slice is to hold three
data values; They are either numbers or None. These *normally*
encountered values can't create a memory loop.
So, FO
On Wed, Oct 31, 2012 at 7:42 AM, Andrew Robinson
wrote:
> Then; I'd note: The non-goofy purpose of slice is to hold three data
> values; They are either numbers or None. These *normally* encountered
> values can't create a memory loop.
> So, FOR AS LONG, as the object representing slice does no
On 31/10/2012 10:07, Steven D'Aprano wrote:
On Tue, 30 Oct 2012 21:33:32 +, Mark Lawrence wrote:
Absolutely bloody typical, turned down because of an idiot. Who the
hell is Tim Peters anyway? :)
I see your smiley, but for the benefit of those who actually don't know
who Tim Peters, a.k.a
On Tue, 30 Oct 2012 21:33:32 +, Mark Lawrence wrote:
> On 30/10/2012 18:02, Ian Kelly wrote:
>> On Tue, Oct 30, 2012 at 10:14 AM, Ethan Furman
>> wrote:
>>> File a bug report?
>>
>> Looks like it's already been wontfixed back in 2006:
>>
>> http://bugs.python.org/issue1501180
>>
>>
> Absolute
On Tue, Oct 30, 2012 at 4:25 PM, Andrew Robinson
wrote:
> Ian,
>
>> Looks like it's already been wontfixed back in 2006:
>
>> http://bugs.python.org/issue1501180
>
> Absolutely bloody typical, turned down because of an idiot. Who the hell is
> Tim Peters anyway?
>
>> I don't really disagree with
On 10/30/2012 10:29 PM, Michael Torrie wrote:
As this is the case, why this long discussion? If you are arguing for
a change in Python to make it compatible with what this fork you are
going to create will do, this has already been fairly thoroughly
addressed earl on, and reasons why the semant
On 10/30/2012 09:47 AM, Andrew Robinson wrote:
> Let's not confound an issue here -- I am going to implement the python
> interpreter; and am not bound by optimization considerations of the
> present python interpreter -- There are things I can do which as a
> python programmer -- you can't. I
Ian,
> Looks like it's already been wontfixed back in 2006:
> http://bugs.python.org/issue1501180
Absolutely bloody typical, turned down because of an idiot. Who the hell is
Tim Peters anyway?
> I don't really disagree with him, anyway. It is a rather obscure bug
> -- is it worth increasi
On 10/30/2012 04:48 PM, Mark Lawrence wrote:
On 30/10/2012 15:47, Andrew Robinson wrote:
I would refer you to a book written by Steve Maguire, Writing Solid
Code; Chapter 5; Candy machine interfaces.
The book that took a right hammering here
http://accu.org/index.php?module=bookreviews&func
On 30/10/2012 15:47, Andrew Robinson wrote:
I would refer you to a book written by Steve Maguire, Writing Solid
Code; Chapter 5; Candy machine interfaces.
The book that took a right hammering here
http://accu.org/index.php?module=bookreviews&func=search&rid=467 ?
--
Cheers.
Mark Lawrence.
On 30/10/2012 21:47, Ian Kelly wrote:
On Tue, Oct 30, 2012 at 3:33 PM, Mark Lawrence wrote:
On 30/10/2012 18:02, Ian Kelly wrote:
On Tue, Oct 30, 2012 at 10:14 AM, Ethan Furman wrote:
File a bug report?
Looks like it's already been wontfixed back in 2006:
http://bugs.python.org/issue15
On 10/30/2012 01:17 AM, Steven D'Aprano wrote:
By the way Andrew, the timestamps on your emails appear to be off, or
possibly the time zone. Your posts are allegedly arriving before the
posts you reply to, at least according to my news client.
:D -- yes, I know about that problem. Every time I r
On Tue, Oct 30, 2012 at 3:55 PM, Ian Kelly wrote:
> On Tue, Oct 30, 2012 at 8:21 AM, Andrew Robinson
> wrote:
>> D'Apriano mentioned the named values, start, stop, step in a slice() which
>> are an API and legacy issue; These three names must also be stored in the
>> interpreter someplace. Sinc
On Wed, Oct 31, 2012 at 8:47 AM, Ian Kelly wrote:
> On Tue, Oct 30, 2012 at 3:33 PM, Mark Lawrence
> wrote:
>> On 30/10/2012 18:02, Ian Kelly wrote:
>>>
>>> On Tue, Oct 30, 2012 at 10:14 AM, Ethan Furman wrote:
File a bug report?
>>>
>>>
>>> Looks like it's already been wontfixed back
On Tue, Oct 30, 2012 at 8:21 AM, Andrew Robinson
wrote:
> D'Apriano mentioned the named values, start, stop, step in a slice() which
> are an API and legacy issue; These three names must also be stored in the
> interpreter someplace. Since slice is defined at the "C" level as a struct,
> have yo
On Tue, Oct 30, 2012 at 3:33 PM, Mark Lawrence wrote:
> On 30/10/2012 18:02, Ian Kelly wrote:
>>
>> On Tue, Oct 30, 2012 at 10:14 AM, Ethan Furman wrote:
>>>
>>> File a bug report?
>>
>>
>> Looks like it's already been wontfixed back in 2006:
>>
>> http://bugs.python.org/issue1501180
>>
>
> Absol
On 30/10/2012 18:02, Ian Kelly wrote:
On Tue, Oct 30, 2012 at 10:14 AM, Ethan Furman wrote:
File a bug report?
Looks like it's already been wontfixed back in 2006:
http://bugs.python.org/issue1501180
Absolutely bloody typical, turned down because of an idiot. Who the
hell is Tim Peters
Andrew Robinson wrote:
I can see that the slice() function can pass in arbitrary arguments.
I'm not sure for lists, which is what the range is applied to, why an
argument like "a" would be part of a slice.
Well, in my dbf.py Record class you can use the names of fields as the slice arguments,
On 10/30/2012 11:02 AM, Ian Kelly wrote:
On Tue, Oct 30, 2012 at 10:14 AM, Ethan Furman wrote:
File a bug report?
Looks like it's already been wontfixed back in 2006:
http://bugs.python.org/issue1501180
Thanks, IAN, you've answered the first of my questions and have been a
great help.
(And y
On Tue, Oct 30, 2012 at 10:14 AM, Ethan Furman wrote:
> File a bug report?
Looks like it's already been wontfixed back in 2006:
http://bugs.python.org/issue1501180
--
http://mail.python.org/mailman/listinfo/python-list
On Tue, Oct 30, 2012 at 1:21 AM, Ian Kelly wrote:
> I'm not entirely certain why collection objects get this special
> treatment, but there you have it.
Thinking about it some more, this makes sense. The GC header is there
to support garbage collection for the object. Atomic types like ints
do
By the way Andrew, the timestamps on your emails appear to be off, or
possibly the time zone. Your posts are allegedly arriving before the
posts you reply to, at least according to my news client.
On Mon, 29 Oct 2012 12:34:24 -0700, Andrew Robinson wrote:
> On 10/29/2012 05:02 PM, Steven D'Apr
On Mon, Oct 29, 2012 at 5:54 PM, Andrew Robinson
wrote:
>> I don't know of a reason why one might need to use a negative start
>> with a positive stop, though.
>
> I've already given several examples; and another poster did too
I meant that I don't know of a reason to do that given the existing
s
On Mon, Oct 29, 2012 at 6:17 PM, Andrew Robinson
wrote:
> If you re-check my post to chris, I listed the struct you mention.
> The C code is what is actually run (by GDB breakpoint test) when a tuple is
> instantiated.
When you were running GDB, were you debugging the interactive
interpreter or a
On Mon, Oct 29, 2012 at 7:49 PM, Chris Kaynor wrote:
> NOTE: The above is taken from reading the source code for Python 2.6.
> For some odd reason, I am getting that an empty tuple consists of 6
> pointer-sized objects (48 bytes on x64), rather than the expected 3
> pointer-sized (24 bytes on x64)
On 10/29/2012 11:51 PM, Ian Kelly wrote:
On Mon, Oct 29, 2012 at 4:39 PM, Andrew Robinson
As above, you're looking at the compiler code, which is why you're
finding things like "line" and "column". The tuple struct is defined
in tupleobject.h and stores tuple elements in a tail array.
If you
On 10/29/2012 10:53 PM, Michael Torrie wrote:
On 10/29/2012 01:34 PM, Andrew Robinson wrote:
No, I don't think it big and complicated. I do think it has timing
implications which are undesirable because of how *much* slices are used.
In an embedded target -- I have to optimize; and I will have
On 10/29/2012 04:01 PM, Ian Kelly wrote:
On Mon, Oct 29, 2012 at 9:20 AM, Andrew Robinson
wrote:
FYI: I was asking for a reason why Python's present implementation is
desirable...
I wonder, for example:
Given an arbitrary list:
a=[1,2,3,4,5,6,7,8,9,10,11,12]
Why would someone *want* to do:
On Mon, Oct 29, 2012 at 4:39 PM, Andrew Robinson
wrote:
> In addition to those items you mention, of which the reference count is not
> even *inside* the struct -- there is additional debugging information not
> mentioned. Built in objects contain a "line number", a "column number", and
> a "cont
Hi Ian,
There are several interesting/thoughtful things you have written.
I like the way you consider a problem before knee jerk answering.
The copying you mention (or realloc) doesn't re-copy the objects on the
list.
It merely re-copies the pointer list to those objects. So lets see what
it w
On Mon, Oct 29, 2012 at 12:00 PM, Andrew Robinson
wrote:
> I downloaded the source code for python 3.3.0, as the tbz;
> In the directory "Python-3.3.0/Python", look at Python-ast.c, line 2089 &
> ff.
Python-ast.c is part of the compiler code. That's not the struct used
to represent the object at
On 10/29/2012 01:34 PM, Andrew Robinson wrote:
> No, I don't think it big and complicated. I do think it has timing
> implications which are undesirable because of how *much* slices are used.
> In an embedded target -- I have to optimize; and I will have to reject
> certain parts of Python to ma
On 10/29/2012 06:49 PM, Chris Kaynor wrote:
Every Python object requires two pieces of data, both of which are
pointer-sized (one is a pointer, one is an int the size of a pointer).
These are: a pointer to the object's type, and the object's reference
count. A tuple actually does not need a hea
On 10/29/2012 05:02 PM, Steven D'Aprano wrote:
On Mon, 29 Oct 2012 08:42:39 -0700, Andrew Robinson wrote:
But, why can't I just overload the existing __getitem__ for lists and
not bother writing an entire class?
You say that as if writing "an entire class" was a big complicated
effort. It isn'
On Mon, Oct 29, 2012 at 11:00 AM, Andrew Robinson
wrote:
>
> Let's look at the source code rather than the web notes -- the source must
> be the true answer anyhow.
>
> I downloaded the source code for python 3.3.0, as the tbz;
> In the directory "Python-3.3.0/Python", look at Python-ast.c, line 2
On 10/29/2012 06:53 AM, Chris Angelico wrote:
Can you provide links to these notes? I'm looking at
cpython/Include/sliceobject.h that has this comment:
/*
A slice object containing start, stop, and step data members (the
names are from range). After much talk with Guido, it was decided to
let
In article ,
Ian Kelly wrote:
> On Mon, Oct 29, 2012 at 5:24 PM, Roy Smith wrote:
> > I think you're missing the point of "amortized constant time". Yes, the
> > first item appended to the list will be copied lg(20,000,000) ~= 25
> > times, because the list will be resized that many times(*).
On Mon, 29 Oct 2012 08:42:39 -0700, Andrew Robinson wrote:
>>> But, why can't I just overload the existing __getitem__ for lists and
>>> not bother writing an entire class?
You say that as if writing "an entire class" was a big complicated
effort. It isn't. It is trivially simple, a single line:
On Mon, Oct 29, 2012 at 5:43 PM, Ian Kelly wrote:
> The growth factor is approximately 1.125. "Approximately" because
> there is also a small constant term. The average number of copies per
> item converges on 8.
Of course, that is the *maximum* number of copies. The actual number
could be muc
On 29 October 2012 23:01, Ian Kelly wrote:
> On Mon, Oct 29, 2012 at 9:20 AM, Andrew Robinson
> wrote:
>> FYI: I was asking for a reason why Python's present implementation is
>> desirable...
>>
>> I wonder, for example:
>>
>> Given an arbitrary list:
>> a=[1,2,3,4,5,6,7,8,9,10,11,12]
>>
>> Why w
On Mon, Oct 29, 2012 at 5:24 PM, Roy Smith wrote:
> I think you're missing the point of "amortized constant time". Yes, the
> first item appended to the list will be copied lg(20,000,000) ~= 25
> times, because the list will be resized that many times(*). But, on
> average (I'm not sure if "aver
In article ,
Ian Kelly wrote:
> On Mon, Oct 29, 2012 at 9:42 AM, Andrew Robinson
> wrote:
> > The list was generated in a single pass by many .append() 's, and then
> > copied once -- the original was left in place; and then I attempted to slice
> > it.
>
> Note that if the list was generated
On Mon, Oct 29, 2012 at 9:42 AM, Andrew Robinson
wrote:
> The list was generated in a single pass by many .append() 's, and then
> copied once -- the original was left in place; and then I attempted to slice
> it.
Note that if the list was generated by .appends, then it was copied
more than once.
On Mon, Oct 29, 2012 at 9:20 AM, Andrew Robinson
wrote:
> FYI: I was asking for a reason why Python's present implementation is
> desirable...
>
> I wonder, for example:
>
> Given an arbitrary list:
> a=[1,2,3,4,5,6,7,8,9,10,11,12]
>
> Why would someone *want* to do:
> a[-7,10]
> Instead of saying
On Tue, Oct 30, 2012 at 2:42 AM, Andrew Robinson
wrote:
> No, there was no error at all. Pthon just crashed & exited; not even an
> exception that I can recall. It was if it exited normally!
Can you create a reproducible test case? There's usually a cause to
these sorts of things.
ChrisA
--
On 10/29/2012 10:09 AM, Ian Kelly wrote:
On Oct 29, 2012 7:10 AM, "Andrew Robinson" wrote:
I will be porting Python 3.xx to a super low power embedded processor (MSP430),
both space and speed are at a premium.
Running Python on top of Java would be a *SERIOUS* mistake. .NET won't even
run on
On 10/29/2012 06:52 AM, Roy Smith wrote:
Show me an example where someone would write a slice with a negative and
a positive index (both in the same slice);
and have that slice grab a contiguous slice in the *middle* of the list
with orientation of lower index to greater index.
It's possible in b
On Mon, 29 Oct 2012 11:19:38 +, Steven D'Aprano wrote:
> Because xrange represents a concrete sequence of numbers, all three of
> start, end and stride must be concrete, known, integers:
>
> py> xrange(4, None, 2)
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: an i
On Mon, 29 Oct 2012 23:40:53 +1100, Chris Angelico wrote:
> On Mon, Oct 29, 2012 at 3:52 PM, Andrew Robinson
> wrote:
>> I am curious as to how quickly it constructs the result compared to a
>> slice operation.
>>
>> Eg:
>> a[1:5]
>> vs.
>> [ a[i] for i in xrange[1:5] ]
>
> For the most part, do
On Mon, Oct 29, 2012 at 1:54 AM, Andrew wrote:
> My intended inferences about the iterator vs. slice question was perhaps not
> obvious to you; Notice: an iterator is not *allowed* in __getitem__().
Yes, I misconstrued your question. I thought you wanted to change the
behavior of slicing to wra
On Oct 29, 2012 7:10 AM, "Andrew Robinson" wrote:
> I will be porting Python 3.xx to a super low power embedded processor
> (MSP430), both space and speed are at a premium.
> Running Python on top of Java would be a *SERIOUS* mistake. .NET won't even
> run on this system. etc.
If that's the ca
In article ,
Andrew Robinson wrote:
> Show me an example where someone would write a slice with a negative and
> a positive index (both in the same slice);
> and have that slice grab a contiguous slice in the *middle* of the list
> with orientation of lower index to greater index.
It's possib
On Mon, Oct 29, 2012 at 5:01 PM, Andrew Robinson
wrote:
> Looking at some of the online programming notes -- a slice apparently
> doesn't use an integer storage variable that is capable of arbitrary
> expansion. =-O -- and hence, won't work for very large sized lists. That
> actually explains so
On 10/29/2012 04:19 AM, Steven D'Aprano wrote:
On Mon, 29 Oct 2012 00:54:29 -0700, Andrew wrote:
Slices and iterators have different purposes and therefore have not been
made interchangeable. Yes, there are certain similarities between a slice
and xrange, but there are also significant differenc
On Mon, Oct 29, 2012 at 3:52 PM, Andrew Robinson
wrote:
> I am curious as to how quickly it constructs the result compared to a slice
> operation.
>
> Eg:
> a[1:5]
> vs.
> [ a[i] for i in xrange[1:5] ]
For the most part, don't concern yourself with performance. Go with
functionality and readabili
On 10/29/2012 04:32 AM, Chris Angelico wrote:
I wonder if what the OP is looking for is not slicing, but something
more akin to map. Start with a large object and an iterator that
produces keys, and create an iterator/list of their corresponding
values. Something like: a=[1,2,3,4,5,6,7,8,9,10]
On Mon, Oct 29, 2012 at 10:19 PM, Steven D'Aprano
wrote:
>> In 'C', where Python is written,
>
> That's a popular misapprehension. Python is written in Java, or Lisp, or
> Haskell, or CLR (dot Net), or RPython, or Ocaml, or Parrot. Each of those
> languages have, or had, at least one Python implem
On Mon, 29 Oct 2012 00:54:29 -0700, Andrew wrote:
> Actually, I said in the OP:
>
> "I also don't understand why slice() is not equivalent to an iterator,
> but can replace an integer in __getitem__() whereas xrange() can't."
Slices and iterators have different purposes and therefore have not be
On Mon, 29 Oct 2012 01:59:06 -0700, andrewr3mail wrote:
> Note: I subscribed to the python-list, and am able to recieve e-mails,
> but I don't see how to write a post for this particular thread nor
> subscribe to this particular thread...
The beauty of email is that you don't have to subscribe to
On 29/10/2012 02:31, Andrew Robinson wrote:
Ok, hopefully this is better. I love my own e-mail editor...
I can see that the slice() function can pass in arbitrary arguments.
I'm not sure for lists, which is what the range is applied to, why an
argument like "a" would be part of a slice.
I *real
Ok, hopefully this is better. I love my own e-mail editor...
I can see that the slice() function can pass in arbitrary arguments.
I'm not sure for lists, which is what the range is applied to, why an
argument like "a" would be part of a slice.
I *really* don't see what the advantage of a slice
On 29/10/2012 08:59, andrewr3m...@gmail.com wrote:
Note: I subscribed to the python-list, and am able to recieve e-mails, but I
don't see how to write a post for this particular thread nor subscribe to this
particular thread...
A brief suggestion, or link to a howto would be *much* appreciate
On Monday, October 29, 2012 1:38:04 AM UTC-7, Chris Rebert wrote:
> On Mon, Oct 29, 2012 at 1:24 AM,
>
> > On Sunday, October 28, 2012 9:44:56 PM UTC-7, alex23 wrote:
>
> >> On Oct 29, 2:09 pm, Andrew < wrote:
>
> You never wrapped `a` in a RangedSlicer or otherwise made use of RangedSlicer!
>
On Mon, Oct 29, 2012 at 1:24 AM, wrote:
> On Sunday, October 28, 2012 9:44:56 PM UTC-7, alex23 wrote:
>> On Oct 29, 2:09 pm, Andrew wrote:
>> class RangedSlicer(list):
>> Then wrap your lists with your RangedSlicer class as needed.
>
> Hmmm...
>
> I began a test in an interactive shell:
>>
On Mon, Oct 29, 2012 at 1:08 AM, wrote:
> On Sunday, October 28, 2012 10:14:03 PM UTC-7, Paul Rubin wrote:
>> Andrew writes:
> I'm getting very frustrated with the editor provided for this group... It
> keeps posting prematurely, and putting my email in even when I tell it not to
> each time;
On Sunday, October 28, 2012 9:44:56 PM UTC-7, alex23 wrote:
> On Oct 29, 2:09 pm, Andrew wrote:
>
> > I use this arbitrary range code *often* so I need a general purpose
> > solution.
>
> > I looked up slice() but the help is of no use, I don't even know how I might
>
> > overload it to embed
On Mon, Oct 29, 2012 at 12:54 AM, Andrew wrote:
> On Sunday, October 28, 2012 9:26:01 PM UTC-7, Ian wrote:
>> On Sun, Oct 28, 2012 at 10:00 PM, Andrew wrote:
> The slice class when passed to __getitem__() was created to merely pass two
> numbers and a stride to __getitem__; As far as I know s
On Sunday, October 28, 2012 10:14:03 PM UTC-7, Paul Rubin wrote:
> Andrew writes:
>
> > So: Why does python choose to convert them to positive indexes, and
>
> > have slice operate differently than xrange
>
>
>
> There was a thread a few years back, I think started by Bryan Olson,
>
> that m
On Sunday, October 28, 2012 9:26:01 PM UTC-7, Ian wrote:
> On Sun, Oct 28, 2012 at 10:00 PM, Andrew wrote:
>
> > Hi Ian,
>
> > Well, no it really isn't equivalent.
>
> > Consider a programmer who writes:
>
> > xrange(-4,3) *wants* [-4,-3,-2,-1,0,1,2]
>
> >
>
> > That is the "idea" of a range
Andrew writes:
> So: Why does python choose to convert them to positive indexes, and
> have slice operate differently than xrange
There was a thread a few years back, I think started by Bryan Olson,
that made the case that slice indexing is a Python wart for further
reasons than the above, and s
On Oct 29, 2:09 pm, Andrew wrote:
> I use this arbitrary range code *often* so I need a general purpose solution.
> I looked up slice() but the help is of no use, I don't even know how I might
> overload it to embed some logic to concatenate ranges of data; nor even if
> it is possible.
Slices ar
On Sun, Oct 28, 2012 at 10:00 PM, wrote:
> Hi Ian,
> Well, no it really isn't equivalent.
> Consider a programmer who writes:
> xrange(-4,3) *wants* [-4,-3,-2,-1,0,1,2]
>
> That is the "idea" of a range; for what reason would anyone *EVER* want -4 to
> +3 to be 6:3???
That is what ranges do, bu
On Sunday, October 28, 2012 8:43:30 PM UTC-7, Ian wrote:
> On Sun, Oct 28, 2012 at 9:12 PM, wrote:
>
> > The slice operator does not give any way (I can find!) to take slices from
> > negative to positive indexes, although the range is not empty, nor the
> > expected indexes out of range that
On Sunday, October 28, 2012 8:43:30 PM UTC-7, Ian wrote:
> On Sun, Oct 28, 2012 at 9:12 PM, andrew wrote:
>
> > The slice operator does not give any way (I can find!) to take slices from
> > negative to positive indexes, although the range is not empty, nor the
> > expected indexes out of range
On 2012-10-29 03:12, andrewr3m...@gmail.com wrote:
The slice operator does not give any way (I can find!) to take slices from
negative to positive indexes, although the range is not empty, nor the expected
indexes out of range that I am supplying.
Many programs that I write would require intro
On Sun, Oct 28, 2012 at 9:12 PM, wrote:
> The slice operator does not give any way (I can find!) to take slices from
> negative to positive indexes, although the range is not empty, nor the
> expected indexes out of range that I am supplying.
>
> Many programs that I write would require introdu
91 matches
Mail list logo
