Re: ValueError vs IndexError, unpacking arguments with string.split
On Sun, Dec 2, 2018 at 1:20 PM Chris Angelico wrote: > On Sun, Dec 2, 2018 at 11:08 PM Morten W. Petersen > wrote: > > > > On Sun, Dec 2, 2018 at 12:49 PM Chris Angelico wrote: > >> To my knowledge, len(x) == len(list(x)) for any core data type that > >> has a length. > > > > >>> len(range(0,100,3)) > > 34 > > >>> range(0,100,3).__len__ > > > > >>> range(0,100,3).__len__() > > 34 > > >>> > > > > But again, I guess an integer-to-be-calculated would be suitable > > for iterators where it is very expensive to do a list or other > > similar calculation. > > > > These operations take quite a bit of time: > > > > >>> x=list(range(0,1,3)) > > >>> y=len(list(range(0,1,3))) > > >>> > > > > Of course they take a lot of time - you're asking for the generation > of some thirty-three million integer objects, each one individually > built and refcounted (in CPython), just so you can count them. But my > point about the equivalency is that, rather than calculating > len(list(range(...))), you can calculate len(range(...)), and you can > be confident that you WILL get the same result. > Mm, yes, I was aware that it took up references, one more zero and it would dump a MemoryError. I hacked a bit of code today, got get my head around the concept of integer-of-unknown-size, and ended up with this so far: https://github.com/morphex/misc/blob/98e44915ffeb1cc3ec3050135ea503eb901c01e2/iterator.py I guess there could be of some (contrived?) use to have an iterator that will take different fractions, which will stop iterating over digits once a repeating pattern has been found. Anyway, the more I meddled with the idea of an integer-of-unknown-size, the more I think that it isn't necessary with the right use of other concepts and abstractions. It could however be a smaller part of a nice, clean pattern/concept. -Morten -- Videos at https://www.youtube.com/user/TheBlogologue Twittering at http://twitter.com/blogologue Blogging at http://blogologue.com Playing music at https://soundcloud.com/morten-w-petersen Also playing music and podcasting here: http://www.mixcloud.com/morten-w-petersen/ On Google+ here https://plus.google.com/107781930037068750156 On Instagram at https://instagram.com/morphexx/ -- https://mail.python.org/mailman/listinfo/python-list
Re: ValueError vs IndexError, unpacking arguments with string.split
On Sun, Dec 2, 2018 at 11:08 PM Morten W. Petersen wrote: > > On Sun, Dec 2, 2018 at 12:49 PM Chris Angelico wrote: >> To my knowledge, len(x) == len(list(x)) for any core data type that >> has a length. > > >>> len(range(0,100,3)) > 34 > >>> range(0,100,3).__len__ > > >>> range(0,100,3).__len__() > 34 > >>> > > But again, I guess an integer-to-be-calculated would be suitable > for iterators where it is very expensive to do a list or other > similar calculation. > > These operations take quite a bit of time: > > >>> x=list(range(0,1,3)) > >>> y=len(list(range(0,1,3))) > >>> > Of course they take a lot of time - you're asking for the generation of some thirty-three million integer objects, each one individually built and refcounted (in CPython), just so you can count them. But my point about the equivalency is that, rather than calculating len(list(range(...))), you can calculate len(range(...)), and you can be confident that you WILL get the same result. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: ValueError vs IndexError, unpacking arguments with string.split
On Sun, Dec 2, 2018 at 12:49 PM Chris Angelico wrote: > On Sun, Dec 2, 2018 at 10:36 PM Morten W. Petersen > wrote: > > While we're on the subject, I did a test in my Python interpreter: > > > > Python 3.6.7 (default, Oct 22 2018, 11:32:17) > > [GCC 8.2.0] on linux > > Type "help", "copyright", "credits" or "license" for more information. > > >>> range(0,3,100) > > range(0, 3, 100) > > >>> len(range(0,3,100)) > > 1 > > >>> range(0,100) > > range(0, 100) > > >>> len(range(0,100)) > > 100 > > >>> > > > > Where a range with a step, gives the length 1, while a plain range gives > > the right length. > > > > I think that's confusing and inconsistent, and it would be nice to have > some > > "value to be calculated" for the length integer as well. > > > > Possibly you're misinterpreting the arguments here. > > >>> list(range(0, 3, 100)) > [0] > > class range(object) > | range(stop) -> range object > | range(start, stop[, step]) -> range object > | > > The *third* argument is the step, so if you were expecting "every > third number up to 100", you'd be looking for this: > > >>> len(range(0, 100, 3)) > 34 > >>> len(list(range(0, 100, 3))) > 34 > > To my knowledge, len(x) == len(list(x)) for any core data type that > has a length. > Ah yes, of course. I haven't had my coffee yet. :) >>> len(range(0,100,3)) 34 >>> range(0,100,3).__len__ >>> range(0,100,3).__len__() 34 >>> But again, I guess an integer-to-be-calculated would be suitable for iterators where it is very expensive to do a list or other similar calculation. These operations take quite a bit of time: >>> x=list(range(0,1,3)) >>> y=len(list(range(0,1,3))) >>> -Morten -- Videos at https://www.youtube.com/user/TheBlogologue Twittering at http://twitter.com/blogologue Blogging at http://blogologue.com Playing music at https://soundcloud.com/morten-w-petersen Also playing music and podcasting here: http://www.mixcloud.com/morten-w-petersen/ On Google+ here https://plus.google.com/107781930037068750156 On Instagram at https://instagram.com/morphexx/ -- https://mail.python.org/mailman/listinfo/python-list
Re: ValueError vs IndexError, unpacking arguments with string.split
On Sun, Dec 2, 2018 at 10:36 PM Morten W. Petersen wrote: > While we're on the subject, I did a test in my Python interpreter: > > Python 3.6.7 (default, Oct 22 2018, 11:32:17) > [GCC 8.2.0] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> range(0,3,100) > range(0, 3, 100) > >>> len(range(0,3,100)) > 1 > >>> range(0,100) > range(0, 100) > >>> len(range(0,100)) > 100 > >>> > > Where a range with a step, gives the length 1, while a plain range gives > the right length. > > I think that's confusing and inconsistent, and it would be nice to have some > "value to be calculated" for the length integer as well. > Possibly you're misinterpreting the arguments here. >>> list(range(0, 3, 100)) [0] class range(object) | range(stop) -> range object | range(start, stop[, step]) -> range object | The *third* argument is the step, so if you were expecting "every third number up to 100", you'd be looking for this: >>> len(range(0, 100, 3)) 34 >>> len(list(range(0, 100, 3))) 34 To my knowledge, len(x) == len(list(x)) for any core data type that has a length. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: ValueError vs IndexError, unpacking arguments with string.split
On Sun, Dec 2, 2018 at 2:23 AM Chris Angelico wrote: > On Sun, Dec 2, 2018 at 11:55 AM Morten W. Petersen > wrote: > > > > On Sat, Dec 1, 2018 at 1:11 AM Chris Angelico wrote: > >> > >> On Sat, Dec 1, 2018 at 10:55 AM Morten W. Petersen > wrote: > >> > But this raises the question of how to write Python code, > >> > short and sweet, that could handle infinite iterators in > >> > such an unpack with multiple variables to assign to. > >> > > >> > Which I guess is mostly theoretical, as there are other > >> > ways of designing code to avoid needing to unpack > >> > an infinite iterator using the * prefix. > >> > >> It could only be done with the cooperation of the iterable in > >> question. For instance, a range object could implement a "remove > >> first" operation that does this, and several itertools types wouldn't > >> need to change at all. But it can't be done generically other than the > >> way it now is (pump the iterator the rest of the way). > > > > I wasn't able to follow this, could you elaborate? > > > > The way *x works in unpacking is that the entire iterable gets > unpacked, and everything gets put into a list that is then assigned to > x. This is generic, works on any iterable, but doesn't take advantage > of anything. Consider: > > >>> x = range(3, 20, 5) > >>> first, *rest = x > >>> first > 3 > >>> rest > [8, 13, 18] > > If a range object were asked to yield its first-and-rest in this way, > it could instead return range(8, 20, 5) - add the step onto the start, > job done. Same if you ask for some off the beginning and some off the > end And with a number of the itertools iterables/iterators, the "rest" > wouldn't actually need to change anything, since the iterator will get > consumed. This would need explicit support from the iterable, though, > as Python can't know how to do this generically; so there would need > to be a protocol for "unpack". > Aha, yes - I see. While we're on the subject, I did a test in my Python interpreter: Python 3.6.7 (default, Oct 22 2018, 11:32:17) [GCC 8.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> range(0,3,100) range(0, 3, 100) >>> len(range(0,3,100)) 1 >>> range(0,100) range(0, 100) >>> len(range(0,100)) 100 >>> Where a range with a step, gives the length 1, while a plain range gives the right length. I think that's confusing and inconsistent, and it would be nice to have some "value to be calculated" for the length integer as well. -Morten -- Videos at https://www.youtube.com/user/TheBlogologue Twittering at http://twitter.com/blogologue Blogging at http://blogologue.com Playing music at https://soundcloud.com/morten-w-petersen Also playing music and podcasting here: http://www.mixcloud.com/morten-w-petersen/ On Google+ here https://plus.google.com/107781930037068750156 On Instagram at https://instagram.com/morphexx/ -- https://mail.python.org/mailman/listinfo/python-list
Re: ValueError vs IndexError, unpacking arguments with string.split
On Sun, Dec 2, 2018 at 11:55 AM Morten W. Petersen wrote: > > On Sat, Dec 1, 2018 at 1:11 AM Chris Angelico wrote: >> >> On Sat, Dec 1, 2018 at 10:55 AM Morten W. Petersen wrote: >> > But this raises the question of how to write Python code, >> > short and sweet, that could handle infinite iterators in >> > such an unpack with multiple variables to assign to. >> > >> > Which I guess is mostly theoretical, as there are other >> > ways of designing code to avoid needing to unpack >> > an infinite iterator using the * prefix. >> >> It could only be done with the cooperation of the iterable in >> question. For instance, a range object could implement a "remove >> first" operation that does this, and several itertools types wouldn't >> need to change at all. But it can't be done generically other than the >> way it now is (pump the iterator the rest of the way). > > I wasn't able to follow this, could you elaborate? > The way *x works in unpacking is that the entire iterable gets unpacked, and everything gets put into a list that is then assigned to x. This is generic, works on any iterable, but doesn't take advantage of anything. Consider: >>> x = range(3, 20, 5) >>> first, *rest = x >>> first 3 >>> rest [8, 13, 18] If a range object were asked to yield its first-and-rest in this way, it could instead return range(8, 20, 5) - add the step onto the start, job done. Same if you ask for some off the beginning and some off the end And with a number of the itertools iterables/iterators, the "rest" wouldn't actually need to change anything, since the iterator will get consumed. This would need explicit support from the iterable, though, as Python can't know how to do this generically; so there would need to be a protocol for "unpack". ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: ValueError vs IndexError, unpacking arguments with string.split
On Sat, Dec 1, 2018 at 1:11 AM Chris Angelico wrote: > On Sat, Dec 1, 2018 at 10:55 AM Morten W. Petersen > wrote: > > But this raises the question of how to write Python code, > > short and sweet, that could handle infinite iterators in > > such an unpack with multiple variables to assign to. > > > > Which I guess is mostly theoretical, as there are other > > ways of designing code to avoid needing to unpack > > an infinite iterator using the * prefix. > > It could only be done with the cooperation of the iterable in > question. For instance, a range object could implement a "remove > first" operation that does this, and several itertools types wouldn't > need to change at all. But it can't be done generically other than the > way it now is (pump the iterator the rest of the way). > I wasn't able to follow this, could you elaborate? Regards, Morten -- Videos at https://www.youtube.com/user/TheBlogologue Twittering at http://twitter.com/blogologue Blogging at http://blogologue.com Playing music at https://soundcloud.com/morten-w-petersen Also playing music and podcasting here: http://www.mixcloud.com/morten-w-petersen/ On Google+ here https://plus.google.com/107781930037068750156 On Instagram at https://instagram.com/morphexx/ -- https://mail.python.org/mailman/listinfo/python-list
Re: ValueError vs IndexError, unpacking arguments with string.split
On Sat, Dec 1, 2018 at 10:55 AM Morten W. Petersen wrote: > But this raises the question of how to write Python code, > short and sweet, that could handle infinite iterators in > such an unpack with multiple variables to assign to. > > Which I guess is mostly theoretical, as there are other > ways of designing code to avoid needing to unpack > an infinite iterator using the * prefix. It could only be done with the cooperation of the iterable in question. For instance, a range object could implement a "remove first" operation that does this, and several itertools types wouldn't need to change at all. But it can't be done generically other than the way it now is (pump the iterator the rest of the way). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: ValueError vs IndexError, unpacking arguments with string.split
On Sat, Dec 1, 2018 at 12:25 AM Chris Angelico wrote: > On Sat, Dec 1, 2018 at 10:18 AM Morten W. Petersen > wrote: > > > > On Fri, Nov 30, 2018 at 7:25 PM Dan Sommers < > > 2qdxy4rzwzuui...@potatochowder.com> wrote: > > > > > On 11/30/18 12:00 PM, Morten W. Petersen wrote: > > > > > > > I guess syntax could be added, so that > > > > > > > > a, b, @c = some sequence > > > > > > > > would initialize a and b, and leave anything remaining in c. We > could > > > > then call this @ syntax "teh snek". > > > > > > Close. ;-) Try this: > > > > > > a, b, *c = [4, 5, 6, 7] > > > > > > > > > > > I did not know that. Or maybe I read it somewhere and it was in the > > subconscious. > > > > Be aware that this isn't the same as "leaving" everything in c. It > will specifically gather everything in the rest of the iterable and > put it all into a list in c. For this example, that wouldn't be a > problem, but consider: > > >>> x = range(10) > >>> a, b, *c = x > >>> print(x) > range(0, 10) > >>> print(a, b, c) > 0 1 [2, 3, 4, 5, 6, 7, 8, 9] > > But as long as you never dive into infinite iterators, it's going to be > fine. > Mm, yes. This was the intuitive understanding I had of it. The range in Python 3 is what xrange was in Python 2, and if I do x=list(range(1)) it takes quite a bit of time, as opposed to x = range(1) But this raises the question of how to write Python code, short and sweet, that could handle infinite iterators in such an unpack with multiple variables to assign to. Which I guess is mostly theoretical, as there are other ways of designing code to avoid needing to unpack an infinite iterator using the * prefix. -Morten -- Videos at https://www.youtube.com/user/TheBlogologue Twittering at http://twitter.com/blogologue Blogging at http://blogologue.com Playing music at https://soundcloud.com/morten-w-petersen Also playing music and podcasting here: http://www.mixcloud.com/morten-w-petersen/ On Google+ here https://plus.google.com/107781930037068750156 On Instagram at https://instagram.com/morphexx/ -- https://mail.python.org/mailman/listinfo/python-list
Re: ValueError vs IndexError, unpacking arguments with string.split
On Sat, Dec 1, 2018 at 10:18 AM Morten W. Petersen wrote: > > On Fri, Nov 30, 2018 at 7:25 PM Dan Sommers < > 2qdxy4rzwzuui...@potatochowder.com> wrote: > > > On 11/30/18 12:00 PM, Morten W. Petersen wrote: > > > > > I guess syntax could be added, so that > > > > > > a, b, @c = some sequence > > > > > > would initialize a and b, and leave anything remaining in c. We could > > > then call this @ syntax "teh snek". > > > > Close. ;-) Try this: > > > > a, b, *c = [4, 5, 6, 7] > > > > > > I did not know that. Or maybe I read it somewhere and it was in the > subconscious. > Be aware that this isn't the same as "leaving" everything in c. It will specifically gather everything in the rest of the iterable and put it all into a list in c. For this example, that wouldn't be a problem, but consider: >>> x = range(10) >>> a, b, *c = x >>> print(x) range(0, 10) >>> print(a, b, c) 0 1 [2, 3, 4, 5, 6, 7, 8, 9] But as long as you never dive into infinite iterators, it's going to be fine. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: ValueError vs IndexError, unpacking arguments with string.split
On Fri, Nov 30, 2018 at 7:25 PM Dan Sommers < 2qdxy4rzwzuui...@potatochowder.com> wrote: > On 11/30/18 12:00 PM, Morten W. Petersen wrote: > > > I guess syntax could be added, so that > > > > a, b, @c = some sequence > > > > would initialize a and b, and leave anything remaining in c. We could > > then call this @ syntax "teh snek". > > Close. ;-) Try this: > > a, b, *c = [4, 5, 6, 7] > ☺ I did not know that. Or maybe I read it somewhere and it was in the subconscious. -Morten -- Videos at https://www.youtube.com/user/TheBlogologue Twittering at http://twitter.com/blogologue Blogging at http://blogologue.com Playing music at https://soundcloud.com/morten-w-petersen Also playing music and podcasting here: http://www.mixcloud.com/morten-w-petersen/ On Google+ here https://plus.google.com/107781930037068750156 On Instagram at https://instagram.com/morphexx/ -- https://mail.python.org/mailman/listinfo/python-list
Re: ValueError vs IndexError, unpacking arguments with string.split
On 11/30/18 12:00 PM, Morten W. Petersen wrote: > I guess syntax could be added, so that > > a, b, @c = some sequence > > would initialize a and b, and leave anything remaining in c. We could > then call this @ syntax "teh snek". Close. ;-) Try this: a, b, *c = [4, 5, 6, 7] -- https://mail.python.org/mailman/listinfo/python-list
Re: ValueError vs IndexError, unpacking arguments with string.split
On Fri, Nov 30, 2018 at 6:21 PM Dan Sommers < 2qdxy4rzwzuui...@potatochowder.com> wrote: > On 11/30/18 10:57 AM, Morten W. Petersen wrote: > > On Fri, Nov 30, 2018 at 4:25 PM Dan Sommers > <2qdxy4rzwzuui...@potatochowder.com> wrote: > [...] > > But since you mention it, why is it necessary to ensure a successful > > operation? > > > > Is it so that when > > > > a,b,c = [1,2] > > > > fails, none of the variables a,b,c have been assigned to, and because > > of that, one avoids "rolling back" any assignment that would have been > > done without checking the right-hand argument first ? > > That's what I was getting at, but apparently failed to express clearly. > > Yes, there are use cases for a short iterator just not assigning the > rest of the variables, and for a long iterator using only what it needs, > but also explicit is better than implicit, and errors should never pass > silently, and other bits of wisdom learned from horrible debugging > experiences. > Aha, yes well you have head, tail, etc. I guess syntax could be added, so that a, b, @c = some sequence would initialize a and b, and leave anything remaining in c. We could then call this @ syntax "teh snek". 😂 ..I guess I haven't punished myself with enough Perl yet. Regards, Morten -- Videos at https://www.youtube.com/user/TheBlogologue Twittering at http://twitter.com/blogologue Blogging at http://blogologue.com Playing music at https://soundcloud.com/morten-w-petersen Also playing music and podcasting here: http://www.mixcloud.com/morten-w-petersen/ On Google+ here https://plus.google.com/107781930037068750156 On Instagram at https://instagram.com/morphexx/ -- https://mail.python.org/mailman/listinfo/python-list
Re: ValueError vs IndexError, unpacking arguments with string.split
On 11/30/18 10:57 AM, Morten W. Petersen wrote: > On Fri, Nov 30, 2018 at 4:25 PM Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote: >> Python validates that the right hand side contains exactly the right >> number of elements before beginning to unpack, presumably to ensure a >> successful operation before failing part way through. > Hm. Well I like the simplicity and abstraction of Python, it makes it > a very productive language. Agreed, and hold that thought. > But since you mention it, why is it necessary to ensure a successful > operation? > > Is it so that when > > a,b,c = [1,2] > > fails, none of the variables a,b,c have been assigned to, and because > of that, one avoids "rolling back" any assignment that would have been > done without checking the right-hand argument first ? That's what I was getting at, but apparently failed to express clearly. Yes, there are use cases for a short iterator just not assigning the rest of the variables, and for a long iterator using only what it needs, but also explicit is better than implicit, and errors should never pass silently, and other bits of wisdom learned from horrible debugging experiences. -- https://mail.python.org/mailman/listinfo/python-list
Re: ValueError vs IndexError, unpacking arguments with string.split
On Fri, Nov 30, 2018 at 4:25 PM Dan Sommers < 2qdxy4rzwzuui...@potatochowder.com> wrote: > On 11/30/18 7:35 AM, Morten W. Petersen wrote: > > > ... but isn't it logical that the > > string is parsed and split, and then later the unpacking operation fails > > with an IndexError? > > With slightly simpler code and the full text of the exception, > the details becomes more apparent: > > >>> x, y = [4] > Traceback (most recent call last): >File "", line 1, in > ValueError: not enough values to unpack (expected 2, got 1) > > Python validates that the right hand side contains exactly the > right number of elements before beginning to unpack, presumably > to ensure a successful operation before failing part way through. > > Effectively, Python is saying that you can't unpack a one-element > array into two pieces *before* it gets to the indexing logic. > Hm. Well I like the simplicity and abstraction of Python, it makes it a very productive language. And since iterable object can be used, I guess it makes sense to raise a ValueError. And trying >>> a,b,c = None Traceback (most recent call last): File "", line 1, in TypeError: 'NoneType' object is not iterable >>> raises a TypeError, and this is all in-hand with the Python docs. But since you mention it, why is it necessary to ensure a successful operation? Is it so that when a,b,c = [1,2] fails, none of the variables a,b,c have been assigned to, and because of that, one avoids "rolling back" any assignment that would have been done without checking the right-hand argument first ? Regards, Morten -- Videos at https://www.youtube.com/user/TheBlogologue Twittering at http://twitter.com/blogologue Blogging at http://blogologue.com Playing music at https://soundcloud.com/morten-w-petersen Also playing music and podcasting here: http://www.mixcloud.com/morten-w-petersen/ On Google+ here https://plus.google.com/107781930037068750156 On Instagram at https://instagram.com/morphexx/ -- https://mail.python.org/mailman/listinfo/python-list
Re: ValueError vs IndexError, unpacking arguments with string.split
On 11/30/18 7:35 AM, Morten W. Petersen wrote: ... but isn't it logical that the string is parsed and split, and then later the unpacking operation fails with an IndexError? With slightly simpler code and the full text of the exception, the details becomes more apparent: >>> x, y = [4] Traceback (most recent call last): File "", line 1, in ValueError: not enough values to unpack (expected 2, got 1) Python validates that the right hand side contains exactly the right number of elements before beginning to unpack, presumably to ensure a successful operation before failing part way through. Effectively, Python is saying that you can't unpack a one-element array into two pieces *before* it gets to the indexing logic. HTH, Dan -- https://mail.python.org/mailman/listinfo/python-list
Re: ValueError vs IndexError, unpacking arguments with string.split
On Fri, Nov 30, 2018 at 4:02 PM Peter Otten <__pete...@web.de> wrote:
> Morten W. Petersen wrote:
>
> > I've been reading up on a bit of C++, Assembler etc. lately, so maybe my
> > mind expected an IndexError because of that, but isn't it logical that
> the
> > string is parsed and split, and then later the unpacking operation fails
> > with an IndexError?
>
> You might think that
>
> a, b = c
>
> is equivalent to
>
> a = c[0]
> b = c[1]
>
> but the c above can be an arbitrary iterable:
>
> >>> a, b = iter("ab")
> >>> a, b
> ('a', 'b')
> >>> a, b = iter("abc")
> Traceback (most recent call last):
> File "", line 1, in
> ValueError: too many values to unpack (expected 2)
>
> So there is not necessarily a lookup by index.
>
Ah, of course. OK, right you are. :)
-Morten
--
Videos at https://www.youtube.com/user/TheBlogologue
Twittering at http://twitter.com/blogologue
Blogging at http://blogologue.com
Playing music at https://soundcloud.com/morten-w-petersen
Also playing music and podcasting here:
http://www.mixcloud.com/morten-w-petersen/
On Google+ here https://plus.google.com/107781930037068750156
On Instagram at https://instagram.com/morphexx/
--
https://mail.python.org/mailman/listinfo/python-list
Re: ValueError vs IndexError, unpacking arguments with string.split
Morten W. Petersen wrote:
> Hi there.
>
> I was adding a port specification feature to my surveil project as shown
> here:
>
>
https://github.com/morphex/surveil/commit/703318f87c4c450a37944b565a10718ef27b57b4
>
> A bit later I was surprised when the script raised an exception, and that
> I had to catch a ValueError instead of an IndexError:
>
>
https://github.com/morphex/surveil/commit/d5c49c54d4037557aaca1f78178b76441853c7af
>
> I've been reading up on a bit of C++, Assembler etc. lately, so maybe my
> mind expected an IndexError because of that, but isn't it logical that the
> string is parsed and split, and then later the unpacking operation fails
> with an IndexError?
You might think that
a, b = c
is equivalent to
a = c[0]
b = c[1]
but the c above can be an arbitrary iterable:
>>> a, b = iter("ab")
>>> a, b
('a', 'b')
>>> a, b = iter("abc")
Traceback (most recent call last):
File "", line 1, in
ValueError: too many values to unpack (expected 2)
So there is not necessarily a lookup by index.
--
https://mail.python.org/mailman/listinfo/python-list
