How to use a regexp here
I have a script that was running perfectly for some time. It uses: array = [elem for elem in output if 'CPU_TEMP' in elem] But because output has changed, I have to check for CPU_TEMP at the beginning of the line. What would be the best way to implement this? -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Blog for basic python programming
Python for Engineers - Solve Problems by Coding Solutions https://pythonforengineers.blogspot.in -- https://mail.python.org/mailman/listinfo/python-list
Please tell me how to execute python file in Ubuntu by double clicking on file.
Respected Sir/Mam, I am Dhananjay Singh,Student of IIIT Manipur. Sir/Mam when i am double click in python program (Dhananjay.py),it is opening in Text Editor by Default in Ubuntu.I want to run this program when i double click on it as any *.Exe file executes as in Window. Sir please help me. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use a regexp here
On Monday, December 4, 2017 at 9:44:27 AM UTC, Cecil Westerhof wrote: > I have a script that was running perfectly for some time. It uses: > array = [elem for elem in output if 'CPU_TEMP' in elem] > > But because output has changed, I have to check for CPU_TEMP at the > beginning of the line. What would be the best way to implement this? > > -- > Cecil Westerhof > Senior Software Engineer > LinkedIn: http://www.linkedin.com/in/cecilwesterhof Use https://docs.python.org/3/library/stdtypes.html#str.startswith instead of the test for `in`. -- Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use a regexp here
On 12/4/17 4:36 AM, Cecil Westerhof wrote:
I have a script that was running perfectly for some time. It uses:
array = [elem for elem in output if 'CPU_TEMP' in elem]
But because output has changed, I have to check for CPU_TEMP at the
beginning of the line. What would be the best way to implement this?
No need for a regex just yet:
array = [elem for elem in output if elem.startswith('CPU_TEMP')]
(btw, note that the result of this expression is a list, not an array,
for future Googling.)
--Ned.
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to use a regexp here
On Mon, Dec 4, 2017 at 5:21 AM, Ned Batchelder
wrote:
> On 12/4/17 4:36 AM, Cecil Westerhof wrote:
>
>> I have a script that was running perfectly for some time. It uses:
>> array = [elem for elem in output if 'CPU_TEMP' in elem]
>>
>> But because output has changed, I have to check for CPU_TEMP at the
>> beginning of the line. What would be the best way to implement this?
>>
>>
> No need for a regex just yet:
>
> array = [elem for elem in output if elem.startswith('CPU_TEMP')]
>
> (btw, note that the result of this expression is a list, not an array, for
> future Googling.)
>
> --Ned.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
I like Ned's clear answer, but I'm wondering why the original code would
fail because the substring is at the start of the line, since 'in' would
still be true no matter where the desired string is placed. It would be
useful to see some sample data of the old data, and the new data
--
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays
--
https://mail.python.org/mailman/listinfo/python-list
Re: Please tell me how to execute python file in Ubuntu by double clicking on file.
On 2017-12-04 10:48, [email protected] wrote: > Respected Sir/Mam, > I am Dhananjay Singh,Student of IIIT Manipur. Sir/Mam when i am > double click in python program (Dhananjay.py),it is opening in Text Editor by > Default in Ubuntu.I want to run this program when i double click on it as any > *.Exe file executes as in Window. > Sir please help me. > https://askubuntu.com/a/544544 -- Thomas Jollans -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use a regexp here
Ned Batchelder writes:
> On 12/4/17 4:36 AM, Cecil Westerhof wrote:
>> I have a script that was running perfectly for some time. It uses:
>> array = [elem for elem in output if 'CPU_TEMP' in elem]
>>
>> But because output has changed, I have to check for CPU_TEMP at the
>> beginning of the line. What would be the best way to implement this?
>>
>
> No need for a regex just yet:
>
> array = [elem for elem in output if elem.startswith('CPU_TEMP')]
Yes, that is it. I should have known that. :'-(
--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to use a regexp here
Joel Goldstick writes:
> On Mon, Dec 4, 2017 at 5:21 AM, Ned Batchelder
> wrote:
>
>> On 12/4/17 4:36 AM, Cecil Westerhof wrote:
>>
>>> I have a script that was running perfectly for some time. It uses:
>>> array = [elem for elem in output if 'CPU_TEMP' in elem]
>>>
>>> But because output has changed, I have to check for CPU_TEMP at the
>>> beginning of the line. What would be the best way to implement this?
>>>
>>>
>> No need for a regex just yet:
>>
>> array = [elem for elem in output if elem.startswith('CPU_TEMP')]
>>
>> (btw, note that the result of this expression is a list, not an array, for
>> future Googling.)
>>
>> --Ned.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
> I like Ned's clear answer, but I'm wondering why the original code would
> fail because the substring is at the start of the line, since 'in' would
> still be true no matter where the desired string is placed. It would be
> useful to see some sample data of the old data, and the new data
There is now also a line that starts with:
PCH_CPU_TEMP:
And I do not want that one.
--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to use a regexp here
Cecil Westerhof wrote:
> Joel Goldstick writes:
[...]
> > I like Ned's clear answer, but I'm wondering why the
> > original code would fail because the substring is at the
> > start of the line, since 'in' would still be true no
> > matter where the desired string is placed. It would be
> > useful to see some sample data of the old data, and the
> > new data
@Goldstick
"Inclusion testing" will return false positives when the
target is part of a larger structure (aka: word). Observe:
>>> s = "Complex is better than complicated."
>>> "plex" in s
True
>>> "om" in s
True
>>> s.count("om")
2
I'm sure you already know this, and only made the comment
because you did not have all the data, but i thought it would
be good to mention for any lurkers who may be watching.
> There is now also a line that starts with: PCH_CPU_TEMP:
> And I do not want that one.
Yes. But be aware, that while the `str.startswith(target)`
method is indeed more efficient than a more generalized
"inclusion test", if the target is not _always_ at the
beginning of the string, then your code is going to skip
right over valid match like a round stone skipping across
the surface of a glass-smooth lake. But if you are sure the
target will always be at the beginning of the string, then
it is the best choice.
> --
> Cecil Westerhof
> Senior Software Engineer
Perhaps it's not politically correct for me to say this, but
i've never been one who cared much about political
correctness, so i'm just going to say it...
If you really are a "_Senior_ software engineer", and that
title is not simply an ego-booster bestowed by your boss to
a one-person-dev-team in order to avoid pay raises, then i
would expect more competence from someone who holds such an
esteemed title.
And even *IF* you are only vaguely familiar with Python, and
even *IF*, you rarely use Python in your projects, i don't
think it's too much to ask of a ~~Senior~~ Software Engineer
that they possess the basic skills required to peruse the
Python documentation and decide which method is most
appropriate for the situation at hand. And if you're using
Python on a regular basis, then you should be intimately
familiar with _all_ methods of each major type.
Granted, your question did "hint" about the possibility of
using a regexp (although, based on the data you have
provided so far, a string method will suffice), but i would
also expect a ~~Senior~~ Software Engineer to not only be
knowledgeable of regexps, but also know when they are a
strength and when they are a weakness.
Now, there are one of two ways you can take this advice:
(1) You can take it as a personal attack; get all huffy
about it; drop to the floor and flail your arms and legs
like a petulant two-year-old who didn't get the toy he
wanted; and learn nothing in the process.
or
(2) You can take it as what it is -> constructive criticism;
shower me with gratitude[1]; and become a better person and
a better programmer in the process.
The choice is yours.
[1] Well, i had to sneak something in there for myself,
after all, it is the season of giving, yes? O:-)
Here comes santa claws...
Here comes santa claws...
...
--
https://mail.python.org/mailman/listinfo/python-list
Re: Please tell me how to execute python file in Ubuntu by double clicking on file.
On Monday, December 4, 2017 at 3:49:11 AM UTC-6, [email protected] wrote: > I am Dhananjay Singh,Student of IIIT Manipur. Sir/Mam when > i am double click in python program (Dhananjay.py),it is > opening in Text Editor by Default in Ubuntu.I want to run > this program when i double click on it as any *.Exe file > executes as in Window. Sir please help me. Sounds like your OS file associations are all botched-up and the ".py" extention has been linked (either by you purposefully, as a system default, or as the side-effect of something else) to a texteditor program. It's easy enough to change this setting in the OS, and i believe there is a Python module or two for the task -- if that's your cup-o-tea. Granted, opening a text editor for unknown files is always a wise default system setting as it avoids any exploits that may be initiated by a hapless neophyte. Take, for example, the braindead Windozes default setting for autorun, which has been the source of many nasty exploits. I suppose that Gates figures his user base is so dumb that they can't even find the My Computer icon and double click it in order to access the contents of a removable drive, CD-ROM, or whatever STD riddled device they happen to plug in. The wise windoze user knows that disabling autorun is paramount to ensuring a secure experience, among other braindead defaults. This is not really a "python" question, and is actually generally applicable to Operating Systems. And the solution is specific to each platform. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use a regexp here
On 12/4/17 9:13 AM, Rick Johnson wrote: Perhaps it's not politically correct for me to say this, but i've never been one who cared much about political correctness, so i'm just going to say it... Cecil, feel free to ignore the rest of Rick's message. His messages are famous for their outrageous and/or abrasive tone, something he seems to revel in. Luckily, it's not typical of the Python community. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use a regexp here
On 12/4/2017 11:14 AM, Ned Batchelder wrote: On 12/4/17 9:13 AM, Rick Johnson wrote: Perhaps it's not politically correct for me to say this, but i've never been one who cared much about political correctness, so i'm just going to say it... Cecil, feel free to ignore the rest of Rick's message. His messages are famous for their outrageous and/or abrasive tone, something he seems to revel in. Luckily, it's not typical of the Python community. Or take Rick's 'rest' as a suggestion to reread Library Reference chapters 2, 3, 4 and in particular 4.7. As for your idea of an RE, '^' matches the beginning of a line, and '$' the end, though using .startswith, and .endswith, are easier if no other RE syntax is needed for matching. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use a regexp here
On 2017-12-04, Cecil Westerhof wrote:
> Joel Goldstick writes:
>
>> On Mon, Dec 4, 2017 at 5:21 AM, Ned Batchelder
>> wrote:
>>
>>> On 12/4/17 4:36 AM, Cecil Westerhof wrote:
>>>
I have a script that was running perfectly for some time. It uses:
array = [elem for elem in output if 'CPU_TEMP' in elem]
But because output has changed, I have to check for CPU_TEMP at the
beginning of the line. What would be the best way to implement this?
>>> No need for a regex just yet:
>>>
>>> array = [elem for elem in output if elem.startswith('CPU_TEMP')]
>>>
>>> (btw, note that the result of this expression is a list, not an array, for
>>> future Googling.)
>>>
>>> --Ned.
>>> --
>>> https://mail.python.org/mailman/listinfo/python-list
>>>
>>
>> I like Ned's clear answer, but I'm wondering why the original code would
>> fail because the substring is at the start of the line, since 'in' would
>> still be true no matter where the desired string is placed. It would be
>> useful to see some sample data of the old data, and the new data
>
> There is now also a line that starts with:
> PCH_CPU_TEMP:
>
> And I do not want that one.
You'll probably want to include the ':' in the startswith check,
in case someday they also add CPU_TEMP_SOMETHING:.
--
Neil Cerutti
--
https://mail.python.org/mailman/listinfo/python-list
why won't slicing lists raise IndexError?
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 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 slicing raised an IndexError in the example I gave. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use a regexp here
Rick Johnson writes: >> There is now also a line that starts with: PCH_CPU_TEMP: >> And I do not want that one. > > Yes. But be aware, that while the `str.startswith(target)` > method is indeed more efficient than a more generalized > "inclusion test", if the target is not _always_ at the > beginning of the string, then your code is going to skip > right over valid match like a round stone skipping across > the surface of a glass-smooth lake. But if you are sure the > target will always be at the beginning of the string, then > it is the best choice. Yes, I am sure it is always at the beginning of the line. (It is output from the Linux sensors command.) -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use a regexp here
Neil Cerutti writes:
> On 2017-12-04, Cecil Westerhof wrote:
>> Joel Goldstick writes:
>>
>>> On Mon, Dec 4, 2017 at 5:21 AM, Ned Batchelder
>>> wrote:
>>>
On 12/4/17 4:36 AM, Cecil Westerhof wrote:
> I have a script that was running perfectly for some time. It uses:
> array = [elem for elem in output if 'CPU_TEMP' in elem]
>
> But because output has changed, I have to check for CPU_TEMP at the
> beginning of the line. What would be the best way to implement this?
>
>
No need for a regex just yet:
array = [elem for elem in output if elem.startswith('CPU_TEMP')]
(btw, note that the result of this expression is a list, not an array, for
future Googling.)
--Ned.
--
https://mail.python.org/mailman/listinfo/python-list
>>>
>>> I like Ned's clear answer, but I'm wondering why the original code would
>>> fail because the substring is at the start of the line, since 'in' would
>>> still be true no matter where the desired string is placed. It would be
>>> useful to see some sample data of the old data, and the new data
>>
>> There is now also a line that starts with:
>> PCH_CPU_TEMP:
>>
>> And I do not want that one.
>
> You'll probably want to include the ':' in the startswith check,
> in case someday they also add CPU_TEMP_SOMETHING:.
I already did. And to be really sure also included a space after it.
--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
--
https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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 slicing raised an IndexError in the example I > gave. Slicing (of strings, lists, tuples, anyway) never raises an IndexError. If the start is out of range it will return an empty list. I don't know. As for "why", it's just how the operation was designed. Perhaps it was considered that an exception isn't needed because there's no ambiguity (i.e. there's no other reason a slice operation can return a list shorter than the length implied by the slice parameters). Why would this simplify your code? What are you doing that would benefit from an IndexError here? -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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 returns the full list 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 slicing raised an IndexError in the example I gave. 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 respect, either.) -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
> > 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 respect, either.) > I'm not here to criticize one way or the other, just understand. As far as I'm aware, I don't rely on python's slicing functionality allowing indexes that are over the length of a list. But I'm just one person and I'm sure there are many other use cases I'm not thinking about. If you think what you wrote is a good explanation for why slicing doesn't raise IndexErrors in python, I'd be interesting in seeing some of your use cases about when you had to explicitly check bounds of list slices in C#. -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
>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 as needed, and store them on the list. When a user triggers `__getitem__`, the LazyList may not yet have data for the index the user requests, in which case it needs to load more data. I'll write out the basic functionality of the LazyList class so you can explicitly see how slicing is impacting the implementation: class LazyList(list): def __getitem__(item): try: return super().__getitem__(item) except IndexError: self._generate_more_data(item) # If, for example, item == 10, this function will keep generating more data until there are 10 items in the list return super().__getitem__(item) This works great when `item` is an integer. However, when `item` is a slice, the IndexError is never triggered, and so new data will never be loaded. Consider this snippet: lazy_list = LazyList() sublist = lazy_list[:10] In this case, `sublist` will always be empty, because the first `return super().__getitem__(item)` "succeeds" by returning an empty list. If slicing raised an IndexError, the above code would work great. Instead, I need to add a check before the try/except to check if the `item` is a `slice`, and if it is, I need to do bounds checking on the list. It seems a bit unpythonic to have to do an isinstance check here, so I am wondering if I am missing something important about why slices don't raise IndexErrors. 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 treat the list like a normal list again." And I really like that clean logic. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python installer hangs in Windows 7
Same with me, except that I tried to install Python 3.6.3. Unchecking "Install launcher for all users" helped, however. -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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] > my_list[:100] # does not raise an IndexError, but instead returns the full > list > > 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 slicing raised an IndexError in the example I gave. 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. -- Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
> > 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 handled gracefully when used for slicing". I do understand _how_ slices work, but I would really like to know a bit more about why slices will never throw out-of-bounds IndexErrors. -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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 in that link is: "However, out of range > slice indexes are handled gracefully when used for slicing". I do > understand _how_ slices work, but I would really like to know a bit more > about why slices will never throw out-of-bounds IndexErrors. That's what "handled gracefully" means. Instead of throwing, they get clamped. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
> > >> 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 handled gracefully when used for slicing". I do > > understand _how_ slices work, but I would really like to know a bit more > > about why slices will never throw out-of-bounds IndexErrors. > > That's what "handled gracefully" means. Instead of throwing, they get > clamped. > > ChrisA Cool! Why? I know I'm being a bit pedantic here, but I truly would like to understand _why_ slices get clamped. I've been writing python code every day for almost 7 years, so usually I can figure stuff like this out, but I'm struggling here and would really appreciate some insight. -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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 more data, then treat the list like a normal list again." > And I really like that clean logic. I can't give you a definitive answer as to why slices behave as they do, any more than anyone else (barring probably Guido). But as a user, I can say that I find the ability to use slices without checking for out of bounds cases or handling exceptions to be really convenient. And one thing Python consistently emphasises is making things easy for the user, even if that convenience comes at a cost to the implementer. Certainly, you're a user of the built in list class, but you're using it to build a wrapper around it, and that makes you a non-core use case (as I see it). At the end of the day, whether to clamp the values or raise IndexError is a trade-off in terms of which type of user to inconvenience, and as I say, in my experience user code wins when that sort of trade-off comes up. That's not to say Python makes it deliberately difficult for people writing code like yours. For your lazy list class, do you know the maximum amount of data available? If you don't, then supporting lst[:-1] will be hard, so you're pretty much bound to have to handle slices differently than built in lists. If you *do* know the maximum length of the underlying data, then the indices() method of slices will probably help: Help on built-in function indices: indices(...) method of builtins.slice instance S.indices(len) -> (start, stop, stride) Assuming a sequence of length len, calculate the start and stop indices, and the stride length of the extended slice described by S. Out of bounds indices are clipped in a manner consistent with the handling of normal slices. Using indices(), you'll get (from "stop") the amount of data you need to load. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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, 2, 3] > my_list[:100] # does not raise an IndexError, but instead returns the full > list That's a feature dude, not a bug. In this case, it only seems illogical because you already know the extents of the buffer, and that's because you created it. However, outside of hand-stiched arts and crafts projects in the interactive basement of your parent's home, you have no way of knowing how large a buffer may be in the wild. And many times, you just need a "transparent slice" from it. What does "transparent slice" mean, you ask? Well, for example, (contrived example here) consider a case where you want the first N chars from a collection of N strings. In such a case, even if `s[:100]` returns a null string from the first target, 55 chars from the next target, 99 chars from the next target, and so on and so forth -- you don't care -- because all you want is a "transparent slice" of each target string. And the onerous exception handling required to deal with disparate buffer lengths would just get in the way of doing that job _cleanly_. Now, some might argue that such a feature breaks the Python Zen. Okay. Let's investigate, shall we> ZEN SAYS: "SPECIAL CASES ARE NOT SPECIAL ENOUGH TO BREAK THE RULES" Hmm, with this "feature" being applicable to so many problems, i would hardly consider it to be a "special case". Next! ZEN SAYS: "EXPLICIT IS BETTER THAN IMPLICIT" Hmm, this one may be difficult to overcome, but we need to conduct a cost-benefit analysis _first_. And, since i have not encountered, in my many years of writing Python code, even one instance of a negative side-effect to this transparent slicing feature, and, furthermore, i have not even ~heard~ of one instance of this feature causing havoc, i will, at this time, and until compelling evidence is provided to the contrary, conclude that the Zen is wrong in this case. *GASP* Next! ZEN SAYS: "ALTHOUGH PRACTICALITY BEATS PURITY. ERRORS SHOULD NEVER PASS SILENTLY. UNLESS EXPLICITLY SILENCED." Some might accuse this feature of "masking errors", however, i don't agree, And while technically speaking -- yes -- a requested slice range which overlaps the actual physical boundaries of a target buffer _is_ violating the physical laws which govern disparate entities existing in a material universe, code exists beyond the material universe, So this beef boils down to a petty qualm over semantics. Next! -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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 is: "However, out of range > slice indexes are handled gracefully when used for slicing". I do > understand _how_ slices work, but I would really like to know a bit more > about why slices will never throw out-of-bounds IndexErrors. That's what "handled gracefully" means. Instead of throwing, they get clamped. ChrisA Cool! Why? I know I'm being a bit pedantic here, but I truly would like to understand _why_ slices get clamped. I've been writing python code every day for almost 7 years, so usually I can figure stuff like this out, but I'm struggling here and would really appreciate some insight. Here's an example: You have a string of at least n characters. You want to get the first n characters and leave the remainder. The first n characters is my_string[ : n]. The remainder is my_string[n : ]. What if len(my_string) == n? Wouldn't my_string[n : ] raise an IndexError? Another example: You want at most n characters of my_string. What if len(my_string) < n? my_string[ : n] would raise an IndexError. You'd need to do my_string[ : min(n, len(my_string))]. Although Python's slicing behaviour doesn't help in your use-case, in the majority of cases it does. -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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 most commonly used on strings, and clamping is probably most useful for strings. Example 1: s[0:k] gets the k or fewer initial characters of the string, perhaps to put in a fixed-width display or storage field. Example 2: below are two equivalent (I believe) code snippets. 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. Note that moving process(item) in the first into the try clause makes the two non-equivalent. Example 3: 'if s[k:k+1] in okset' versus 'if len(s) >= k+1 and s[k] in okset'. There are many examples like this where is slicing did not clamp, the user would have to reproduce some of the logic done by slices. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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 realize the entire ELSE clause of your latter example is superfluous. But there are many usages where the conditional logic is not needed at all. Sometimes you don't care what you get back from a slice. Yep, even when the slice is a null string. -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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(item) >> else: >> do_without_item() >> >> Many prefer the second. > > And they'll prefer it even more when they realize the entire ELSE > clause of your latter example is superfluous. ... how is it superfluous? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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 treat the list like a normal list again."
And I really like that clean logic.
Yes, it is very attractive. I've got a buffer class with that behaviour which
is very useful for parsing data streams.
I think the salient difference between your LazyList's API and my buffer's API
is that in mine, the space allocation is a distinct operation from the
__getitem__.
My buffer class keeps an internal buffer of unconsumed data, and its
__getitem__ indexes only that. It has two methods for "on demand": .extend(),
which ensures that the internal buffer has at least n bytes, and .take(), which
does a .extend and then returns the leading n bytes (trimming them from the
internal buffer of course).
So if I need to inspect the buffer I do a .extend to ensure there's enough
data, then one can directly use [] to look at stuff, or use .take to grab a
known size chunk.
The .extend and .take operation accept an optional "short_ok" boolean, default
False. When false, .extend and .take raise an exception if there aren't enough
data available, otherwise they can return with a short buffer containing what
was available.
That covers your slice situation: true implies Python-like slicing and false
(the default) acts like you (and I) usually want: an exception.
And it sidesteps Python's design decisions because it leaves the __getitem__
semantics unchanged. One ensures the require preconditions (enough data) by
calling .extend _first_.
Here's some example code parsing an ISO14496 Box header record, which has 2 4
byte values at the start. The code uses short_ok to probe for immediate
end-of-input. But if there are data, it uses .extend and .take in default mode
so that an _incomplete_ record raises an exception:
def parse_box_header(bfr):
''' Decode a box header from the CornuCopyBuffer `bfr`. Return (box_header,
new_buf, new_offset) or None at end of input.
'''
# return BoxHeader=None if at the end of the data
bfr.extend(1, short_ok=True)
if not bfr:
return None
# note start point
offset0 = bfr.offset
user_type = None
bfr.extend(8)
box_size, = unpack('>L', bfr.take(4))
box_type = bfr.take(4)
In summary, I think you should give your LazyList a .extend method to establish
your code's precondition (enough elements) and then you can proceed with your
slicing in surety that it will behave correctly.
Cheers,
Cameron Simpson (formerly [email protected])
--
https://mail.python.org/mailman/listinfo/python-list
zlib OverflowError: 'size does not fit in an int'
Trying to zip a large file is failing with OverflowError: 'size does not fit in an int'. Googling I found this: https://bugs.python.org/issue23306 and this: https://hg.python.org/cpython/rev/2192edcfea02 which seems to make me think this was fixed this was fixed on Jul 23 2016. I am running CentOS 7 and I have python version: Python 2.7.5 (default, Sep 15 2016, 22:37:39) Which I guess does not have this fix. How can I get a version with that fix (that doesn't break CentOS) -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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() > >> > >> Many prefer the second. > > > > And they'll prefer it even more when they realize the entire ELSE > > clause of your latter example is superfluous. > > ... how is it superfluous? If the only purpose of an if/else logic structure is to process an arbitrary value _only_ when that value is "truthy", and futhermore, the else clause does nothing of any significance (and in the example provided, appears to be nothing but a placeholder for dead code) then why bother writing the else clause in the first place? I'm not questioning Terry's skills here. I'm merely pointing out that there seems to be no justification for the else clause in this example. Indeed, there are valid instances when a decision making process requires an explicit binary choice (aka: if/else), but the provided example seems to be saying something more like this: # BEGIN CODE (Py2.x, Untested!) ## if item: do_something_with(item) else: import cons as cons try: try: h = get_handle_for_current_module() except NameError: import gvrs_backdoor h = gvrs_backdoor.force_connection(cons.CURRENT_MODULE) # # Assume we have a valid module handle here. # with h.request_connection(cons.PYTHON) as py: py.send_message(cons.EXIT_CONDITIONAL) except Exception as e: # # Alas, now we must wipe the sweat from our brow # and accept our unavoidable fate. ':-( # # But first! We shall be good stewards and log # this error message. # msg = e.message print msg[len(msg):] del msg # # Now: 1. 2.. 3... JUMP! # pass ## END CODE ## Of course, we could have accomplished the same goal -- and burned a few less processor cycles in the meantime -- by omitting the superflouous else clause. But to each, his or her own, i suppose. -- https://mail.python.org/mailman/listinfo/python-list
Re: Please tell me how to execute python file in Ubuntu by double clicking on file.
On 12/04/2017 04:49 AM, Thomas Jollans wrote: > On 2017-12-04 10:48, [email protected] wrote: >> Respected Sir/Mam, >> I am Dhananjay Singh,Student of IIIT Manipur. Sir/Mam when i am >> double click in python program (Dhananjay.py),it is opening in Text Editor >> by Default in Ubuntu.I want to run this program when i double click on it as >> any *.Exe file executes as in Window. >> Sir please help me. >> > > https://askubuntu.com/a/544544 Oops! You misread his question. The question was, how can he run a python script by simply double clicking on it in the file browser in Ubuntu? Now I don't know the answer to that question, but I can say that nearly all the time you just don't want to do that anyway, for reasons I state below. Instead, open a terminal, change to the directory where you python script is and either run it directly (if it's chmod'd as exectuable) using "./myscript.py" or use the python interpreter: "python3 /path/to/myscript.py" The reason scripts are rarely launched from the file browser like you want to do is that often scripts communicate with the user via standard out, so you need to run them from a terminal. There are some GUI programs written in Python, but those are usually launched from a .desktop file shortcut. -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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 item: >> >> process(item) >> >> else: >> >> do_without_item() >> >> >> >> Many prefer the second. >> > >> > And they'll prefer it even more when they realize the entire ELSE >> > clause of your latter example is superfluous. >> >> ... how is it superfluous? > > If the only purpose of an if/else logic structure is to > process an arbitrary value _only_ when that value is > "truthy", and futhermore, the else clause does nothing of > any significance (and in the example provided, appears to > be nothing but a placeholder for dead code) then why > bother writing the else clause in the first place? Ahhh, I see how it is. You didn't run the code, ergo you don't understand it. Makes perfect sense. :) Hint: Truthiness is fairly clearly defined here, regardless of the value of item. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: zlib OverflowError: 'size does not fit in an int'
On Tue, Dec 5, 2017 at 10:46 AM, Larry Martell wrote: > Trying to zip a large file is failing with OverflowError: 'size does > not fit in an int'. Googling I found this: > > https://bugs.python.org/issue23306 > > and this: > > https://hg.python.org/cpython/rev/2192edcfea02 > > which seems to make me think this was fixed this was fixed on Jul 23 2016. > > I am running CentOS 7 and I have python version: > > Python 2.7.5 (default, Sep 15 2016, 22:37:39) > > Which I guess does not have this fix. How can I get a version with > that fix (that doesn't break CentOS) First thing I'd consider is a Python 3.x version. Is there one in your CentOS repositories? If not, worst case, you can compile one from source or get one from some other repo, and it can't possibly break your system because it won't mess with anything you're using. If you absolutely HAVE to stick with 2.7, you may do well to compile from source and NOT install - just run the binary from the source directory. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Please tell me how to execute python file in Ubuntu by double clicking on file.
On 05/12/17 01:03, Michael Torrie wrote: > On 12/04/2017 04:49 AM, Thomas Jollans wrote: >> On 2017-12-04 10:48, [email protected] wrote: >>> Respected Sir/Mam, >>> I am Dhananjay Singh,Student of IIIT Manipur. Sir/Mam when i am >>> double click in python program (Dhananjay.py),it is opening in Text Editor >>> by Default in Ubuntu.I want to run this program when i double click on it >>> as any *.Exe file executes as in Window. >>> Sir please help me. >>> >> >> https://askubuntu.com/a/544544 > > Oops! You misread his question. The question was, how can he run a > python script by simply double clicking on it in the file browser in > Ubuntu? No, I was just being (rudely, perhaps) terse. The file browser used by default in Ubuntu/Gnome (aka Nautilus) has a setting, as described in that Ask Ubuntu answer, that makes it execute scripts, Python or otherwise, on double click (as long as they have a correct #! line and are executable) > > Now I don't know the answer to that question, but I can say that nearly > all the time you just don't want to do that anyway, for reasons I state > below. I absolutely agree. > > Instead, open a terminal, change to the directory where you python > script is and either run it directly (if it's chmod'd as exectuable) > using "./myscript.py" or use the python interpreter: "python3 > /path/to/myscript.py" > > The reason scripts are rarely launched from the file browser like you > want to do is that often scripts communicate with the user via standard > out, so you need to run them from a terminal. > > There are some GUI programs written in Python, but those are usually > launched from a .desktop file shortcut. > > > -- https://mail.python.org/mailman/listinfo/python-list
Re: zlib OverflowError: 'size does not fit in an int'
On Mon, Dec 4, 2017 at 7:15 PM, Chris Angelico wrote: > On Tue, Dec 5, 2017 at 10:46 AM, Larry Martell > wrote: >> Trying to zip a large file is failing with OverflowError: 'size does >> not fit in an int'. Googling I found this: >> >> https://bugs.python.org/issue23306 >> >> and this: >> >> https://hg.python.org/cpython/rev/2192edcfea02 >> >> which seems to make me think this was fixed this was fixed on Jul 23 2016. >> >> I am running CentOS 7 and I have python version: >> >> Python 2.7.5 (default, Sep 15 2016, 22:37:39) >> >> Which I guess does not have this fix. How can I get a version with >> that fix (that doesn't break CentOS) > > First thing I'd consider is a Python 3.x version. Is there one in your > CentOS repositories? If not, worst case, you can compile one from > source or get one from some other repo, and it can't possibly break > your system because it won't mess with anything you're using. > > If you absolutely HAVE to stick with 2.7, you may do well to compile > from source and NOT install - just run the binary from the source > directory. This is a django app, using version 1.9, installed on many sites that do not have external internet access, so any changes are onerous. Possible, but a PITA. I will look into building from source. -- https://mail.python.org/mailman/listinfo/python-list
Re: zlib OverflowError: 'size does not fit in an int'
On 05/12/17 01:15, Chris Angelico wrote: > On Tue, Dec 5, 2017 at 10:46 AM, Larry Martell > wrote: >> Trying to zip a large file is failing with OverflowError: 'size does >> not fit in an int'. Googling I found this: >> >> https://bugs.python.org/issue23306 >> >> and this: >> >> https://hg.python.org/cpython/rev/2192edcfea02 >> >> which seems to make me think this was fixed this was fixed on Jul 23 2016. >> >> I am running CentOS 7 and I have python version: >> >> Python 2.7.5 (default, Sep 15 2016, 22:37:39) >> >> Which I guess does not have this fix. How can I get a version with >> that fix (that doesn't break CentOS) > > First thing I'd consider is a Python 3.x version. Is there one in your > CentOS repositories? If not, worst case, you can compile one from > source or get one from some other repo, and it can't possibly break > your system because it won't mess with anything you're using. For CentOS, I recommend using either an SCL (https://www.softwarecollections.org/en/scls/rhscl/rh-python36/) or perhaps Anaconda. Installing Python 3 with an SCL is nice because it's managed through your package manager, but is completely independent of the system Python (so it won't break anything). You have to enable it on a case-by-case basis when you want to use it, which can be a bit finicky. > > If you absolutely HAVE to stick with 2.7, you may do well to compile > from source and NOT install - just run the binary from the source > directory. > > ChrisA > -- https://mail.python.org/mailman/listinfo/python-list
Re: zlib OverflowError: 'size does not fit in an int'
On 05/12/17 01:21, Larry Martell wrote: > On Mon, Dec 4, 2017 at 7:15 PM, Chris Angelico wrote: >> On Tue, Dec 5, 2017 at 10:46 AM, Larry Martell >> wrote: >>> Trying to zip a large file is failing with OverflowError: 'size does >>> not fit in an int'. Googling I found this: >>> >>> https://bugs.python.org/issue23306 >>> >>> and this: >>> >>> https://hg.python.org/cpython/rev/2192edcfea02 >>> >>> which seems to make me think this was fixed this was fixed on Jul 23 2016. >>> >>> I am running CentOS 7 and I have python version: >>> >>> Python 2.7.5 (default, Sep 15 2016, 22:37:39) >>> >>> Which I guess does not have this fix. How can I get a version with >>> that fix (that doesn't break CentOS) >> >> First thing I'd consider is a Python 3.x version. Is there one in your >> CentOS repositories? If not, worst case, you can compile one from >> source or get one from some other repo, and it can't possibly break >> your system because it won't mess with anything you're using. >> >> If you absolutely HAVE to stick with 2.7, you may do well to compile >> from source and NOT install - just run the binary from the source >> directory. > > This is a django app, using version 1.9, installed on many sites that > do not have external internet access, so any changes are onerous. > Possible, but a PITA. I will look into building from source. > FWIW, there is also an SCL with a newer version of Python 2.7 (loathe as I am to point it out) See also: https://pythonclock.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: zlib OverflowError: 'size does not fit in an int'
On Mon, Dec 4, 2017 at 7:36 PM, Thomas Jollans wrote: > On 05/12/17 01:21, Larry Martell wrote: >> On Mon, Dec 4, 2017 at 7:15 PM, Chris Angelico wrote: >>> On Tue, Dec 5, 2017 at 10:46 AM, Larry Martell >>> wrote: Trying to zip a large file is failing with OverflowError: 'size does not fit in an int'. Googling I found this: https://bugs.python.org/issue23306 and this: https://hg.python.org/cpython/rev/2192edcfea02 which seems to make me think this was fixed this was fixed on Jul 23 2016. I am running CentOS 7 and I have python version: Python 2.7.5 (default, Sep 15 2016, 22:37:39) Which I guess does not have this fix. How can I get a version with that fix (that doesn't break CentOS) >>> >>> First thing I'd consider is a Python 3.x version. Is there one in your >>> CentOS repositories? If not, worst case, you can compile one from >>> source or get one from some other repo, and it can't possibly break >>> your system because it won't mess with anything you're using. >>> >>> If you absolutely HAVE to stick with 2.7, you may do well to compile >>> from source and NOT install - just run the binary from the source >>> directory. >> >> This is a django app, using version 1.9, installed on many sites that >> do not have external internet access, so any changes are onerous. >> Possible, but a PITA. I will look into building from source. >> > > FWIW, there is also an SCL with a newer version of Python 2.7 (loathe as > I am to point it out) > > See also: https://pythonclock.org/ Where is there a link on that page to download a new version of 2.7? -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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, i suppose, like any other rational person, that it was all just pseudo code. But, in any event, i don't see how running the code and then watching helplessly as a volley of NameErrors come rip- roaring down a stdout stream like a half naked, middle-aged drunk feller bobbing precariously along a river rapid -- hey, look out for that rock! -- is going to help shed any light on any of this. But i suppose it's possible i missed an esoteric joke somewhere... -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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 make me a better programmer. >one thing Python consistently emphasises is making things easy for >the user, even if that convenience comes at a cost to the implementer. I completely agree, and I'm always happy to do the work as a developer to make the user experience better. That's something I really appreciate about python as well. >I've got a buffer class with that behaviour which is very useful for parsing data streams. [...] >In summary, I think you should give your LazyList a .extend method to establish your code's precondition (enough elements) and then you can proceed with your slicing in surety that it will behave correctly. Thanks for this detailed response, I'll have to reread it a few times to understand it but I think I'll understand how I might improve my implementation from your example. In particular, that last "In summary" sentence hit on something I'd been thinking about. A `.extend` method might clean things up nicely. -- It seems to me that the consensus on the reason for why slices don't throw IndexErrors is essentially "It's very convenient for them not to" and I'm just fine with that response (not super thrilled, but happy enough). There were two comments in particular that sounded pretty good: >But as a user, I can say that I find the ability to use slices without checking for >out of bounds cases or handling exceptions to be really convenient. That's fair. The alternative would be something that someone else mentioned: `my_string[ : min(n, len(my_string))]` and that's not very pretty, although I don't think it's absolutely horrible. And: the use case where you are trying to split a list or string at index `n` is: `first_half, second_half = my_string[:n], my_string[n:]` and if n > len(my_string) then this use case becomes a bit annoying to write (although it could use the `min` example above). 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 the latter, but it's way less convenient. And I'm 100% sure the people who made this decision are incredibly smart, and I certainly trust their decision. Thanks everyone for the responses. On Mon, Dec 4, 2017 at 6:13 PM, Chris Angelico wrote: > 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 item: > >> >> process(item) > >> >> else: > >> >> do_without_item() > >> >> > >> >> Many prefer the second. > >> > > >> > And they'll prefer it even more when they realize the entire ELSE > >> > clause of your latter example is superfluous. > >> > >> ... how is it superfluous? > > > > If the only purpose of an if/else logic structure is to > > process an arbitrary value _only_ when that value is > > "truthy", and futhermore, the else clause does nothing of > > any significance (and in the example provided, appears to > > be nothing but a placeholder for dead code) then why > > bother writing the else clause in the first place? > > Ahhh, I see how it is. You didn't run the code, ergo you don't > understand it. Makes perfect sense. :) > > Hint: Truthiness is fairly clearly defined here, regardless of the > value of item. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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 variables or functions, i assumed, i suppose, like
any other rational person, that it was all just pseudo code.
But, in any event, i don't see how running the code and then
watching helplessly as a volley of NameErrors come rip-
roaring down a stdout stream like a half naked, middle-aged
drunk feller bobbing precariously along a river rapid --
hey, look out for that rock! -- is going to help shed any
light on any of this.
But i suppose it's possible i missed an esoteric joke
somewhere...
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" or "license" for more information.
>>> def do_the_thing(seq, n):
... item = seq[n:n+1]
... if item:
... print(f"process({item})")
... else:
... print("do_without_item()")
...
>>> do_the_thing([1, 2, 3], 2)
process([3])
>>> do_the_thing([1, 2, 3], 5)
do_without_item()
>>>
--Ned.
--
https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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 the latter, but it's way less convenient. And I'm 100% sure the people who made this decision are incredibly smart, and I certainly trust their decision. Thanks everyone for the responses. The first sentence of this paragraph can be summarised as "Practicality beats purity". It's in the Zen. -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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" or "license" for more information.
> >>> def do_the_thing(seq, n):
> ... item = seq[n:n+1]
> ... if item:
> ... print(f"process({item})")
> ... else:
> ... print("do_without_item()")
> ...
> >>> do_the_thing([1, 2, 3], 2)
> process([3])
> >>> do_the_thing([1, 2, 3], 5)
> do_without_item()
> >>>
Thanks for filling in the blanks. However, my objection to
this else-clause stems from a perspective based in
pragmatics. Specifically, i see no benefit here in logging
the "non-action". Sure, perhaps logging a non-action may serve a
useful purpose during debugging sessions, but i find them to
be nothing but useless noise in production code.
Do you agree or disagree with my assessment?
If you disagree, please explain why.
--
https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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-900.0.37)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> def do_the_thing(seq, n):
>> ... item = seq[n:n+1]
>> ... if item:
>> ... print(f"process({item})")
>> ... else:
>> ... print("do_without_item()")
>> ...
>> >>> do_the_thing([1, 2, 3], 2)
>> process([3])
>> >>> do_the_thing([1, 2, 3], 5)
>> do_without_item()
>> >>>
>
> Thanks for filling in the blanks. However, my objection to
> this else-clause stems from a perspective based in
> pragmatics. Specifically, i see no benefit here in logging
> the "non-action". Sure, perhaps logging a non-action may serve a
> useful purpose during debugging sessions, but i find them to
> be nothing but useless noise in production code.
>
> Do you agree or disagree with my assessment?
>
> If you disagree, please explain why.
Why do you believe this to be a non-action? There is no indication
that do_without_item does nothing.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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
Type "help", "copyright", "credits" or "license" for more information.
>>> def do_the_thing(seq, n):
... item = seq[n:n+1]
... if item:
... print(f"process({item})")
... else:
... print("do_without_item()")
...
>>> do_the_thing([1, 2, 3], 2)
process([3])
>>> do_the_thing([1, 2, 3], 5)
do_without_item()
>>>
Thanks for filling in the blanks. However, my objection to
this else-clause stems from a perspective based in
pragmatics. Specifically, i see no benefit here in logging
the "non-action". Sure, perhaps logging a non-action may serve a
useful purpose during debugging sessions, but i find them to
be nothing but useless noise in production code.
Do you agree or disagree with my assessment?
If you disagree, please explain why.
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. I
think we've demonstrated the slicing semantics well.
--Ned.
--
https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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 that's the point i've been trying to make. The inclusion of this else- clause only serves to distract from the intent of the lesson and also the main topic of the thread. Hence my objection. > 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. I believe strongly that bad examples are worse than no examples at all. Consider the following: Take for example the Tkinter method `root.quit()`, a method that was presented in a famous web tutorial many years ago, and has since (even to this _day_!) caused misconceptions in the mind's of noobs as to its _true_ function. Sure, part of that misconception can be blamed on a poor name choice, as root.suspend_event_processing() would have been self- explanatory. But this method is for advanced usage, and thus, should not be a part of _any_ introductory or even intermediate lesson. Of course, once the tut owner posted this bad code, other tut owners just blindly copy/pasted, and the damage has spread all over the web. Or the example code presented as an introductory to defining functions in the official Python documentation, one which distracts from the main topic with an algorithm which builds a Fibonacci sequence. Both of these examples underscore the importance of clear presentation, and what can go wrong if one fails to heed this protocol of good teaching. -- https://mail.python.org/mailman/listinfo/python-list
Re: why won't slicing lists raise IndexError?
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, 2, 3] > my_list[:100] # does not raise an IndexError, but instead returns the full > list > > 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 slicing raised an IndexError in the example I gave. Data Structures have invariants. Some of these are just side-notes… interesting, cute Some are more fundamental, the raison d'être for the data structure Whether the following inv is that fundamental or not I wont offer an opinion It certainly seems important (to me) Python slice inv: (∀ n:ℤ, l:sequence | l[:n] + l[n:] == l) Your preferred inv: (∀ n:ℤ, l:sequence ∧ jason_caveat(n) | l[:n] + l[n:] == l) where def jason_caveat(n,l): return 0 ≤ n ≤ len(l) Do you consider it arguable that your preferred invariant is at least more heavy-weight if not downright clunkier? Note I am not offering a view on this. eg for zip python does this >>> zip([1,2,3], [4,5,6,7,8]) [(1, 4), (2, 5), (3, 6)] I find myself sometimes needing this Sometimes needing it extended to the longer (with what??) Sometimes needing your preferred behavior — an exception On a more fundamental note: def const(x): return 42 has the invariant that const(x) == 42 when x is well-defined This is true for most mainstream languages Lazy functional languages (like Haskell) make a big deal of not having the definedness caveat. People (like me) not quite on the FP bandwagon are conflicted on whether the mathematical elegance is worth the computational mess -- https://mail.python.org/mailman/listinfo/python-list
