On Monday, December 4, 2017 at 7:10:01 PM UTC, Jason Maldonis wrote:
> I was extending a `list` and am wondering why slicing lists will never
> raise an IndexError, even if the `slice.stop` value if greater than the
> list length.
>
> Quick example:
>
> my_list = [1, 2, 3]
&g
Steve D'Aprano wrote:
[...]
> You've already been told that there's no indication or
> reason to believe that it is a non-action. You've already
> been given at least one possible action. It isn't a non-
> action, it is two distinct actions:
>
> - the action you take when the slice is non-empty;
I was extending a `list` and am wondering why slicing lists will never raise an
IndexError, even if the `slice.stop` value if greater than the list length.
Quick example:
my_list = [1, 2, 3]
my_list[:100] # does not raise an IndexError, but instead returns the full
list
Is there any
On Mon, Dec 4, 2017, at 13:54, Jason Maldonis wrote:
> Is there any background on why that doesn't raise an IndexError? Knowing
> that might help me design my extended list class better. For my specific
> use case, it would simplify my code (and prevent `if isinstance(item,
> slice)` checks) if the
On Fri, Dec 08, 2017 at 05:12:35AM -0800, Rick Johnson wrote:
> I have already backed my argument with multiple code
> examples, exhaustive explanations
Which were all false and/or nonsensical.
> > if item:
> > process(item)
> > else:
> > do_without_item()
>
> The above c
Python wrote:
[...]
>
> In this snippet (which again, we agreed was an incomplete
> academic example):
>
> if item:
> process(item)
> else:
> do_without_item()
>
> Can you please explain to me what sort of Python
> syntactical construct do_without_item() could be, other
> t
On 12/7/17 9:02 PM, Python wrote:
Can you please explain to me
Really, you just have to ignore him.
--Ned.
--
https://mail.python.org/mailman/listinfo/python-list
Hi Rick!
On Wed, Dec 06, 2017 at 04:05:42PM -0800, Rick Johnson wrote:
> Python wrote:
>
> [...]
>
> > THIS IS FALSE. CALLING A FUNCTION
>
> What *FUNCTION*?
In this snippet (which again, we agreed was an incomplete academic
example):
if item:
process(item)
else:
do_w
Alexandre Brault wrote:
[...]
> process() wasn't defined either, nor were n and seq and yet
> you're not complaining about them.
Why would i? Both are highly relevant to the example of
performing a slice. "Don't throw the baby out with the
bathwater", as they say...
> It seems it was clear
After a certain point, the only thing you can do with a troll is ignore
them.
--Ned.
--
https://mail.python.org/mailman/listinfo/python-list
process() wasn't defined either, nor were n and seq and yet you're not
complaining about them.
It seems it was clear to everyone but you that seq was a sequence
defined elsewhere, n was an index defined elsewhere, and both process
and do_without_item were functions defined elsewhere.
And eve
Python wrote:
[...]
> THIS IS FALSE. CALLING A FUNCTION
What *FUNCTION*?
You think you can just slap a function-y looking symbol
willy-nilly in the middle of a chunk of code and then have
it "magically" transform into a python function object?
>>> do_without_item()
Traceback (most re
Terry Reedy wrote:
[...]
> Rick, cut the crap. If you do not understand that
> 'something_else()' != 'pass', re-read the tutorial.
How is the official tutorial going to give me any insight
into an undefined symbol that you invented?
Of course, we all understand that "something_else()" is
merel
On Wed, Dec 06, 2017 at 03:08:51PM -0800, Rick Johnson wrote:
> The following is Terry's original:
>
> if item:
> process(item)
> else:
> do_without_item()
>
> And here is the functioning equivalent, sans any fuzzy
> semantics:
>
> if item:
> process(item)
>
On Wednesday, December 6, 2017 at 3:13:41 PM UTC-6, Python wrote:
[...]
> Geez, seriously? The snippet is purely academic, obviously
> not a complete or useful program,
Who ever made the claim that it was?
> intended to illustrate that python can take two different
> branches depending on whethe
On 12/5/2017 9:23 PM, Rick Johnson wrote:
Steve D'Aprano wrote:
[...]
You've already been told that there's no indication or
reason to believe that it is a non-action. You've already
been given at least one possible action. It isn't a non-
action, it is two distinct actions:
- the action you
On Tue, Dec 05, 2017 at 06:23:04PM -0800, Rick Johnson wrote:
> [bunch of old, irrelevant context snipped]
> > item = seq[n:n+1]
> > if item:
> > process(item)
> > else:
> > do_without_item()
>
> When Python follows a logic clause like a train skating
> along a set of railroad tracks, an
Steve D'Aprano wrote:
[...]
> You've already been told that there's no indication or
> reason to believe that it is a non-action. You've already
> been given at least one possible action. It isn't a non-
> action, it is two distinct actions:
>
> - the action you take when the slice is non-empty;
On Tue, 5 Dec 2017 11:31 pm, Rick Johnson wrote:
> Ned Batchelder wrote:
> [...]
>> Your original statement sounded like, "The else clause can
>> never be executed,"
>
> No. Of course not. Note that i mentioned _pragmatism_. My
> complaint about the else-clause was not that it could
> _never_ be
Ned Batchelder wrote:
[...]
> Your original statement sounded like, "The else clause can
> never be executed,"
No. Of course not. Note that i mentioned _pragmatism_. My
complaint about the else-clause was not that it could
_never_ be executed, my complaint that was that the else-
clause (in Terry
On 12/4/17 10:41 PM, Rick Johnson wrote:
I think we've demonstrated the slicing semantics well.
Indeed. And i never questioned this aspect. I merely wanted
to inform the lurkers that the else-clause was handling a
non-action, and therefore, could be omitted.
Your original statement sounded lik
On Tuesday, December 5, 2017 at 12:40:01 AM UTC+5:30, Jason Maldonis wrote:
> I was extending a `list` and am wondering why slicing lists will never
> raise an IndexError, even if the `slice.stop` value if greater than the
> list length.
>
> Quick example:
>
> my_list = [1,
Ned Batchelder wrote:
[...]
> The point of the example was to demonstrate what happens
> when slicing beyond the bounds of the list. It's beyond
> the scope of the thread to debate whether you might want to
> perform an action in that case.
But, nevertheless, the else-clause is there! And th
On 12/4/17 9:31 PM, Rick Johnson wrote:
On Monday, December 4, 2017 at 7:47:20 PM UTC-6, Ned Batchelder wrote:
[...]
Here are details filled in:
$ python3.6
Python 3.6.3 (default, Oct 4 2017, 06:03:25)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)] on darwin
On Tue, Dec 5, 2017 at 1:31 PM, Rick Johnson
wrote:
> On Monday, December 4, 2017 at 7:47:20 PM UTC-6, Ned Batchelder wrote:
>
> [...]
>
>> Here are details filled in:
>>
>> $ python3.6
>> Python 3.6.3 (default, Oct 4 2017, 06:03:25)
>> [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-90
On Monday, December 4, 2017 at 7:47:20 PM UTC-6, Ned Batchelder wrote:
[...]
> Here are details filled in:
>
> $ python3.6
> Python 3.6.3 (default, Oct 4 2017, 06:03:25)
> [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)] on darwin
> Type "help", "copyright", "credits
On 2017-12-05 01:37, Jason Maldonis wrote:
[snip]
So I guess the conclusion (as far as I can tell) is that: `my_string[:n]`
is more convenient than `my_string[:min(n, len(my_string))]`, and that
sounds okay enough to me.
If I'm being completely honest I kinda like the logical explicitness of t
On 12/4/17 8:03 PM, Rick Johnson wrote:
On Monday, December 4, 2017 at 6:13:19 PM UTC-6, Chris Angelico wrote:
[...]
Ahhh, I see how it is. You didn't run the code, ergo you
don't understand it. Makes perfect sense. :)
Being that Terry didn't offer any declarations or defintions
for his
I'll try to summarize what I've learned with a few responses in hodge-podge
order and to no one in particular:
>That's a feature dude, not a bug.
Absolutely. I _do not_ think that how slicing works in python should be
changed, but I _do_ want to understand its design decisions because it will
mak
On Monday, December 4, 2017 at 6:13:19 PM UTC-6, Chris Angelico wrote:
[...]
> Ahhh, I see how it is. You didn't run the code, ergo you
> don't understand it. Makes perfect sense. :)
Being that Terry didn't offer any declarations or defintions
for his variables or functions, i assumed,
On Tue, Dec 5, 2017 at 10:50 AM, Rick Johnson
wrote:
> Chris Angelico wrote:
>> wrote:
>> > Terry Reedy wrote:
>> >
>> > [...]
>> >
>> >> try:
>> >> item = seq[n]
>> >> except IndexError
>> >> do_without_item()
>> >> else:
>> >> process(item)
>> >>
>> >> item = seq[n:n+1]
>> >> if
Chris Angelico wrote:
> wrote:
> > Terry Reedy wrote:
> >
> > [...]
> >
> >> try:
> >> item = seq[n]
> >> except IndexError
> >> do_without_item()
> >> else:
> >> process(item)
> >>
> >> item = seq[n:n+1]
> >> if item:
> >> process(item)
> >> else:
> >> do_without_item()
>
On 04Dec2017 14:13, Jason Maldonis wrote:
And I'll be honest -- I like the implementation of the LazyList I wrote
above. I think it's pretty logical, because it allows you to think about
the lazy list like this: "Treat the list like a norma list. If you run out
of bounds, get more data, then tr
Against my better judgement, I'm going to ask...
On Tue, Dec 5, 2017 at 9:22 AM, Rick Johnson
wrote:
> Terry Reedy wrote:
>
> [...]
>
>> try:
>> item = seq[n]
>> except IndexError
>> do_without_item()
>> else:
>> process(item)
>>
>> item = seq[n:n+1]
>> if item:
>> process(ite
Terry Reedy wrote:
[...]
> try:
> item = seq[n]
> except IndexError
> do_without_item()
> else:
> process(item)
>
> item = seq[n:n+1]
> if item:
> process(item)
> else:
> do_without_item()
>
> Many prefer the second.
And they'll prefer it even more when they real
On 12/4/2017 1:54 PM, Jason Maldonis wrote:
I was extending a `list` and am wondering why slicing lists will never
raise an IndexError, even if the `slice.stop` value if greater than the
list length.
Is there any background on why that doesn't raise an IndexError?
Slicing is perhaps
On 2017-12-04 21:22, Jason Maldonis wrote:
>> This is explained in the Python tutorial for strings
>> https://docs.python.org/3/tutorial/introduction.html#strings, as a list
>> is a sequence just like a string it will act in exactly the same way.
>>
>
> The only relevant bit I found in that link
On Monday, December 4, 2017 at 1:10:01 PM UTC-6, Jason Maldonis wrote:
> I was extending a `list` and am wondering why slicing lists will never
> raise an IndexError, even if the `slice.stop` value if greater than the
> list length.
>
> Quick example:
>
> my_list = [1,
On 4 December 2017 at 20:13, Jason Maldonis wrote:
> And I'll be honest -- I like the implementation of the LazyList I wrote
> above. I think it's pretty logical, because it allows you to think about
> the lazy list like this: "Treat the list like a norma list. If you run out
> of bounds, get mor
>
> >> This is explained in the Python tutorial for strings
> >> https://docs.python.org/3/tutorial/introduction.html#strings, as a list
> >> is a sequence just like a string it will act in exactly the same way.
> >>
> >
> > The only relevant bit I found in that link is: "However, out of range
> >
On Tue, Dec 5, 2017 at 8:03 AM, Jason Maldonis wrote:
>>
>> This is explained in the Python tutorial for strings
>> https://docs.python.org/3/tutorial/introduction.html#strings, as a list
>> is a sequence just like a string it will act in exactly the same way.
>>
>
> The only relevant bit I found
>
> This is explained in the Python tutorial for strings
> https://docs.python.org/3/tutorial/introduction.html#strings, as a list
> is a sequence just like a string it will act in exactly the same way.
>
The only relevant bit I found in that link is: "However, out of range
slice indexes are hand
On Monday, December 4, 2017 at 7:10:01 PM UTC, Jason Maldonis wrote:
> I was extending a `list` and am wondering why slicing lists will never
> raise an IndexError, even if the `slice.stop` value if greater than the
> list length.
>
> Quick example:
>
> my_list = [1,
>Why would this simplify your code? What are you doing that would benefit
>from an IndexError here?
Without simplifying too much, I'm writing a wrapper around a REST API. I
want lazy-loading functionality for lists-of-things, so I am creating a
LazyList class.
This LazyList class will load items
>
> Have you ever used a language that does that?
I have.
> The String class in the C# language does that, and it's /really/ annoying.
> I have to add extra code to prevent such exceptions.
> In practice, I find that the way that Python does it is much nicer. (And
> Python isn't unique in this res
On 2017-12-04 18:54, Jason Maldonis wrote:
I was extending a `list` and am wondering why slicing lists will never
raise an IndexError, even if the `slice.stop` value if greater than the
list length.
Quick example:
my_list = [1, 2, 3]
my_list[:100] # does not raise an IndexError, but instead
On Mon, Dec 4, 2017, at 13:54, Jason Maldonis wrote:
> Is there any background on why that doesn't raise an IndexError? Knowing
> that might help me design my extended list class better. For my specific
> use case, it would simplify my code (and prevent `if isinstance(item,
> slice)` checks) if the
I was extending a `list` and am wondering why slicing lists will never
raise an IndexError, even if the `slice.stop` value if greater than the
list length.
Quick example:
my_list = [1, 2, 3]
my_list[:100] # does not raise an IndexError, but instead returns the full
list
Is there any background
On May 9, 3:17 pm, [EMAIL PROTECTED] wrote:
> On May 9, 10:11 am, Yves Dorfsman <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > [EMAIL PROTECTED] wrote:
> > > The only thing is, is there is another natural meaning to [a,b:c].
>
> > > Counting grids on the diagonals, the rational set is well defined:
>
> >
On May 9, 10:11 am, Yves Dorfsman <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > The only thing is, is there is another natural meaning to [a,b:c].
>
> > Counting grids on the diagonals, the rational set is well defined:
>
> > 0: 0, 0
> > 1: 1, 0
> > 2: 0, 1
> > 3: 2, 0
> > 4: 1, 1
> > 5
[EMAIL PROTECTED] wrote:
The only thing is, is there is another natural meaning to [a,b:c].
Counting grids on the diagonals, the rational set is well defined:
0: 0, 0
1: 1, 0
2: 0, 1
3: 2, 0
4: 1, 1
5: 0, 2
6: 3, 0
7: 2, 1
...
Thencefore ( 2, 0 ) : ( 3, 0 ) is well defined. Thencefore,
a,b:
On May 9, 1:23 am, "Ian Kelly" <[EMAIL PROTECTED]> wrote:
> On Wed, May 7, 2008 at 5:29 PM, Yves Dorfsman <[EMAIL PROTECTED]> wrote:
> > Is there a way to do:
> > x = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
> > x[0,2:6]
>
> > That would return:
> > [0, 3, 4, 5, 6]
>
> > I am surprised this notation is not
On Wed, May 7, 2008 at 5:29 PM, Yves Dorfsman <[EMAIL PROTECTED]> wrote:
> Is there a way to do:
> x = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
> x[0,2:6]
>
> That would return:
> [0, 3, 4, 5, 6]
>
> I am surprised this notation is not supported, it seems intuitive.
> A concrete example of the sort of thing
MRAB wrote:
You should've read the thread entitled "Why don't generators execute
until first yield?"! :-) Michael Torrie gave the URL
http://www.dabeaz.com/generators/Generators.pdf. Your example can be
rewritten as follows:
p = file('/etc/passwd') # No need for readlines() because file's
itera
On May 8, 4:34 am, Yves Dorfsman <[EMAIL PROTECTED]> wrote:
> Miles wrote:
> > On Wed, May 7, 2008 at 7:46 PM, Ivan Illarionov
> > > > Is there a way to do:
> > > > x = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
> > > > x[0,2:6]
>
> > > > That would return:
> > > > [0, 3, 4, 5, 6]
>
> Arg... Yes, th
Yves Dorfsman wrote:
So would it be a worthy addition to python, to add it right in the core
of the language, and hopefully in an efficient manner ?
Note that the s[0,2:6] syntax is currently allowed because of the distinct
semantics that the Numeric module and its successors numarray and
On May 7, 11:34 pm, Yves Dorfsman <[EMAIL PROTECTED]> wrote:
> So would it be a worthy addition to python, to add it right in the core of
> the language, and hopefully in an efficient manner ?
Given that it's a straightforward generalization of the existing
slicing syntax, it sure does make sense
Miles wrote:
On Wed, May 7, 2008 at 7:46 PM, Ivan Illarionov
> > Is there a way to do:
> > x = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
> > x[0,2:6]
> >
> > That would return:
> > [0, 3, 4, 5, 6]
Arg... Yes, this is a typo, I meant:
[1, 3, 4, 5, 6]
I think Yves meant to return [1, 3, 4, 5
On May 7, 6:13 pm, Miles <[EMAIL PROTECTED]> wrote:
(snipped)
> I think Yves meant to return [1, 3, 4, 5, 6], as in Perl's list slicing:
>
> my @x = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
> return @x[0, 2..6]; // returns (1, 3, 4, 5, 6)
>
> This isn't incredibly efficient, but it does what you want
On Thu, 08 May 2008 01:15:43 +, Ivan Illarionov wrote:
> On Wed, 07 May 2008 21:13:27 -0400, Miles wrote:
>
>> On Wed, May 7, 2008 at 7:46 PM, Ivan Illarionov
>> <[EMAIL PROTECTED]> wrote:
>> > On Wed, 07 May 2008 23:29:27 +, Yves Dorfsman wrote:
>> >
>> > > Is there a way to do:
>>
On Wed, 07 May 2008 21:13:27 -0400, Miles wrote:
> On Wed, May 7, 2008 at 7:46 PM, Ivan Illarionov
> <[EMAIL PROTECTED]> wrote:
> > On Wed, 07 May 2008 23:29:27 +, Yves Dorfsman wrote:
> >
> > > Is there a way to do:
> > > x = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
> > > x[0,2:6]
> > >
>
On Wed, May 7, 2008 at 7:46 PM, Ivan Illarionov
<[EMAIL PROTECTED]> wrote:
> On Wed, 07 May 2008 23:29:27 +, Yves Dorfsman wrote:
>
> > Is there a way to do:
> > x = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
> > x[0,2:6]
> >
> > That would return:
> > [0, 3, 4, 5, 6]
>
> IMHO this notat
On May 7, 6:58 pm, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
> On Wed, 07 May 2008 23:46:33 +, Ivan Illarionov wrote:
> > On Wed, 07 May 2008 23:29:27 +, Yves Dorfsman wrote:
>
> >> Is there a way to do:
> >> x = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
> >> x[0,2:6]
>
> >> That would return:
> >>
On Wed, 07 May 2008 23:46:33 +, Ivan Illarionov wrote:
> On Wed, 07 May 2008 23:29:27 +, Yves Dorfsman wrote:
>
>> Is there a way to do:
>> x = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
>> x[0,2:6]
>>
>> That would return:
>> [0, 3, 4, 5, 6]
>
> IMHO this notation is confusing.
>
> What's wrong
On Wed, 07 May 2008 23:29:27 +, Yves Dorfsman wrote:
> Is there a way to do:
> x = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
> x[0,2:6]
>
> That would return:
> [0, 3, 4, 5, 6]
IMHO this notation is confusing.
What's wrong with:
[0]+x[2:6]
> I am surprised this notation is not supported, it seems
Is there a way to do:
x = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
x[0,2:6]
That would return:
[0, 3, 4, 5, 6]
I am surprised this notation is not supported, it seems intuitive.
A concrete example of the sort of thing I want to do:
p = file('/etc/passwd').readlines()
q = [ e.strip().split(':')[0,2:] for
66 matches
Mail list logo
