[Python-ideas] Re: giving set.add a return value
On Fri, Jun 26, 2020 at 10:10:22PM +1000, Chris Angelico wrote:
> On Fri, Jun 26, 2020 at 7:58 PM Steven D'Aprano wrote:
> > Most importantly, it matches the way people think about the task:
> >
> > # Task: look for duplicates
> > if element in seen:
> > # it's a duplicate
> > ...
> > else:
> > # never seen before, so remember it
> > ...
>
> Do you do this:
>
> if file exists:
> # read the file
> else:
> # create the file
No, because I have learned that this is both unreliable and dangerous.
But that's how I *think* about the problem, at least initially. I
expect that if you were prototyping the code on a whiteboard, you
probably would too.
Checking existence of an element in a set is not comparable to file
access. File access has a lot more that can go wrong than just whether
or not the file exists. There are permission errors and transient errors
that bulletproof code needs to deal with. And file access is always
concurrent, since the OS is concurrent. (Unless you have the luxury
of working on a single user, single process OS.)
So long as you know you are dealing with hashable objects, `set.add`
should always succeed.
> Or would you try/except around an open call? The TOCTOU issue may be
> less obvious with sets, but it's still a reasonable thing to concern
> yourself with.
Unless you are in the [Quadrant of Hell](https://imgur.com/a/jjA52vI)
you don't even need to think about this for sets. There are no Time
Of Check to Time Of Use issues worth thinking about in the given
example, and frankly Chris I doubt that you surround ever set access
with locks in single-threaded code because TOCTOU is "stronger" (more
important?) than writing clear and simple code. And if you do, you're
probably wondering why Python is so slow *wink*
But I'll grant you that I wasn't thinking about threaded code. The
example given was single-threaded, but maybe a better example would
involve threading. But that supports my point: thinking concurrently
doesn't come naturally.
Is this check and insert version of `add` threadsafe? If not, then you
still need manual locking and this proposal doesn't get you much; if
anything it's an attractive nuisance because it looks atomic but isn't:
seen = {}
assert seen.add(None) is False
This could fail in threaded code if the underlying `add` method
is not thread-safe:
- your thread calls `add`, which checks that None is not an element;
- between the check and the actual insertion, another thread adds None;
- and your thread redundently adds it a second time and returns False.
I don't know about Python sets, but most Java collections are not
thread safe unless explicitly documented as such, so I wouldn't be the
least bit surprised if this could happen.
So `add` would have to be atomic at the C level. If it is already
atomic, great, that's one objection neutralised. But if not, then will
making it atomic have a performance impact?
I'm not very interested in slowing down every single `set.add` just so I
have the opportunity to write less understandable code when I don't need
to. But if `set.add` is already atomic and hence thread safe, and the
other issues with this proposal are addressed, then I don't object to
this proposal. (I reserve the right to change my mind :-)
Just don't tell me that this:
was_already_there = seen.add(element)
if was_already_there:
...
is a more natural way of thinking about the problem of checking for
duplicates than:
if element in seen:
...
> > This idiom works with sets, it works with lists, it works with trees, it
> > works with anything that supports membership testing and inserting into
> > a collection. It is the natural way to think about the task.
>
> So would "ensure this is here, and let me know if you created it".
Are you proposing to add this to lists, deques, dicts, Mappings,
Sequences and all other collections? I think you'll need a PEP :-)
> > But either way, you also have to decide whether the `add` (or the new
> > method) should *unconditionally* insert the element, or only do so if it
> > wasn't present. This makes a big difference:
> >
> > seen = {2}
> > already_there = seen.add(2.0)
> >
> >
> > At this point, is `seen` the set {2} or {2.0}? Justify why one answer is
> > the best answer.
> >
>
> It should do the same thing that happens already: keep the existing
> one.
I actually thought that the existing behaviour was the opposite, and
for once I failed to check it before posting. Oops!
But that's not really important. What is important is the question of
which of these we wish to match:
# 1
if element in seen:
print("duplicate element")
seen.add(element)
# 2
if element in seen:
print("duplicate element")
else:
seen.add(element)
They have different semantics, and I can imagine cases where both would
be useful. Although I suppos
[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On 27/06/20 5:30 pm, David Mertz wrote: My point is that _Elements of Style_ is not a set of rules. It's a nice book with generally good advice; it's not a style guide in a formal sense. Also, does it actually say anything that would forbid or discourage use of terms such as "chocker" and "chuck out"? -- Greg ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2YJHM7QILPRXTVMDBB62YQMRVSMUYN43/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: giving set.add a return value
On 27/06/20 4:25 pm, Steven D'Aprano wrote: Seriously, I genuinely thought that the existing behaviour was the opposite and that `add` unconditionally added the element. "Last seen wins". The fact that you haven't noticed until now suggests that you've never written any code that depends on the difference. If I was designing sets, that's probably how I would design it. After all, it's called *add*, not *add if not already there*. But equally, if it's already there, there's no need to do anything, right? I don't think it's possible to intuit the behaviour from the name "add". I also think that it doesn't matter, and if it does, then a set probably isn't the right data structure for your application. -- Greg ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WDNSZDNHGYBXFEIFXY3XYHW6CZGPIN2E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On 27/06/20 4:33 pm, Steven D'Aprano wrote: Take the word out of the sentence, and does the sentence still mean the same thing? Then the word was needless. That's an objective test. But in something a fuzzy as natural language, "the same thing" is not a boolean value. How close in meaning does it have to be? Different people will have different opinions. -- Greg ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RSDOQEK7IZMHU6G4LBZTDCS4BCMYLKGU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
My point is that _Elements of Style_ is not a set of rules. It's a nice book with generally good advice; it's not a style guide in a formal sense. If we wanted rules, _The Chicago Manual of Style_ or the_Associated Press Style Guide_ would be much closer to that. But neither of those actually removes subjectivity about what's clear either. On Sat, Jun 27, 2020, 1:24 AM Steven D'Aprano wrote: > On Sat, Jun 27, 2020 at 12:37:35AM -0400, David Mertz wrote: > > > Objectively, could I have dropped "most"? Both "most famous"? > > > > Could you have dropped "still," objectively? > > Yes, we probably could have. What's your point? I'm not arguing in > favour of S&W here on this mailing list, and I've explicitly said that I > don't even like their rules. > > But having a set of rules as (1) guidance for those who need guidance, > especially those who have difficulty telling what is *clear and > understandable to others*, and (2) for use in disputes, is not a bad > thing. > > > > -- > Steven > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/EN2RMKA5ZACAW5F4FWTKOYILIUAVHJOR/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3MOFSENG4TYK3BYGRJT36ZG4IWT3ETRE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On Sat, Jun 27, 2020 at 12:37:35AM -0400, David Mertz wrote: > Objectively, could I have dropped "most"? Both "most famous"? > > Could you have dropped "still," objectively? Yes, we probably could have. What's your point? I'm not arguing in favour of S&W here on this mailing list, and I've explicitly said that I don't even like their rules. But having a set of rules as (1) guidance for those who need guidance, especially those who have difficulty telling what is *clear and understandable to others*, and (2) for use in disputes, is not a bad thing. -- Steven ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EN2RMKA5ZACAW5F4FWTKOYILIUAVHJOR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On Sat, Jun 27, 2020 at 2:44 PM Soni L. wrote: > > > Take word out of sentence, does sentence still mean same? Then word > needless. Is objective test. That sounds like the way the Heavy Weapons Guy talks (when he speaks English - his native language is Russian). What you've done is make a sentence that isn't grammatically correct, but can be interpreted unambiguously, which isn't the same thing. But if we want to debate linguistics, we should probably move to python-list... or to Savoynet, which does a pretty good job of arguing minutiae in the English language. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TFSBVFUGN4T3DBVC3SLFPL7GHUCK33GK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On 2020-06-27 1:33 a.m., Steven D'Aprano wrote: On Fri, Jun 26, 2020 at 11:36:47PM -0400, David Mertz wrote: > On Fri, Jun 26, 2020, 8:40 PM Steven D'Aprano wrote: > > > "Clear and easily understandable" is subjective. What is clear and > > understandable to me may be impenetrably confusing to others, or > > obnoxiously dumbed down. > > > > Strunk and White's most famous mandate of "omit needless words" is likewise > subjective. Take the word out of the sentence, and does the sentence still mean the same thing? Then the word was needless. That's an objective test. Take word out of sentence, does sentence still mean same? Then word needless. Is objective test. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LM34VNRWPJPMM4HH45FWVFAGAYSY6HP6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: giving set.add a return value
On Sat, Jun 27, 2020 at 2:29 PM Steven D'Aprano wrote: > Seriously, I genuinely thought that the existing behaviour was the > opposite and that `add` unconditionally added the element. "Last seen > wins". If I was designing sets, that's probably how I would design it. > After all, it's called *add*, not *add if not already there*. I was so > sure that this was the current behaviour that I didn't bother to check > it before posting, which is rare for me. > > So I think this counts as the principle of maximal surprise :-) Well, that's not how Python's dicts OR sets work, so that would be inconsistent. But feel free to do it your own way in your own language. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LT74WCVQSXAYZEDOEIVHL73QZ4YJHLI3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
Objectively, could I have dropped "most"? Both "most famous"? Could you have dropped "still," objectively? On Sat, Jun 27, 2020, 12:34 AM Steven D'Aprano wrote: > On Fri, Jun 26, 2020 at 11:36:47PM -0400, David Mertz wrote: > > On Fri, Jun 26, 2020, 8:40 PM Steven D'Aprano > wrote: > > > > > "Clear and easily understandable" is subjective. What is clear and > > > understandable to me may be impenetrably confusing to others, or > > > obnoxiously dumbed down. > > > > > > > Strunk and White's most famous mandate of "omit needless words" is > likewise > > subjective. > > Take the word out of the sentence, and does the sentence still mean the > same thing? Then the word was needless. That's an objective test. > > > -- > Steven > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/SXUJNGR6EFCCPYJ7Y6RWKWMM72K33LPI/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DYPNEGXRLMXVIC5HT6DHRMH6IAGGREDI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On Fri, Jun 26, 2020 at 11:36:47PM -0400, David Mertz wrote: > On Fri, Jun 26, 2020, 8:40 PM Steven D'Aprano wrote: > > > "Clear and easily understandable" is subjective. What is clear and > > understandable to me may be impenetrably confusing to others, or > > obnoxiously dumbed down. > > > > Strunk and White's most famous mandate of "omit needless words" is likewise > subjective. Take the word out of the sentence, and does the sentence still mean the same thing? Then the word was needless. That's an objective test. -- Steven ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SXUJNGR6EFCCPYJ7Y6RWKWMM72K33LPI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: giving set.add a return value
On Fri, Jun 26, 2020 at 06:16:05AM -0500, Dan Sommers wrote:
> >already_there = seen.add(element)
> >if already_there:
> ># handle the duplicate case
> >
> >Who thinks like that? *wink*
>
> Anyone who practices EAFP rather than LBYL? Or is that why you're
> winking?
That doesn't come naturally, and in single-threaded code it's also
unnecessary.
By the way, since there's no try...except involved and no need to catch
an exception, it's not EAFP.
> >But either way, you also have to decide whether the `add` (or
> >the new
> >method) should *unconditionally* insert the element, or only do
> >so if it
> >wasn't present. This makes a big difference:
> >
> >seen = {2}
> >already_there = seen.add(2.0)
> >
> >At this point, is `seen` the set {2} or {2.0}? Justify why one
> >answer is
> >the best answer.
>
> The actual best answer is left as an exercise for the interested
> reader, but whatever it is, it's justified by backwards
> compatibility, the existing definition of "present," and the
> principle of least surprise:
The documentation doesn't guarantee one behaviour or another:
https://docs.python.org/3/library/stdtypes.html#frozenset.add
>Python 3.8.3 (default, May 17 2020, 18:15:42)
>[GCC 10.1.0] on linux
>Type "help", "copyright", "credits" or "license" for more
>information.
>>>> seen = {2}
>>>> 2.0 in seen
>True
>>>> seen.add(2.0)
>>>> seen
>{2}
Well I'm completely surprised, because I expected `add` to, you know,
actually add the element replacing the one that was already there!
Seriously, I genuinely thought that the existing behaviour was the
opposite and that `add` unconditionally added the element. "Last seen
wins". If I was designing sets, that's probably how I would design it.
After all, it's called *add*, not *add if not already there*. I was so
sure that this was the current behaviour that I didn't bother to check
it before posting, which is rare for me.
So I think this counts as the principle of maximal surprise :-)
Should the flag be "element was already present and nothing was added"
or "element was not there, so something was added"?
--
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/3Z5KH7FCAUK6WLXOBLMBSKC54BMZ2H57/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On Fri, Jun 26, 2020, 8:40 PM Steven D'Aprano wrote: > "Clear and easily understandable" is subjective. What is clear and > understandable to me may be impenetrably confusing to others, or > obnoxiously dumbed down. > Strunk and White's most famous mandate of "omit needless words" is likewise subjective. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KDFW46TNDBK7E3OOMCW5LY3VNKFDSVMG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
I can't say that I've ever assessed the quality of a code comment based on how well it adheres to Strunk & White, nor have I ever been involved with an environment that tries to strongly enforce that specific style of writing. So FWIW, I agree that "clear and concise English" is more relevant to most. On Fri, Jun 26, 2020 at 9:49 PM Guido van Rossum wrote: > > Steven just likes an argument. Nobody has ever taken the idea of a standard > for language in comments seriously. It Just doen come up. > > On Fri, Jun 26, 2020 at 18:35 Bernardo Sulzbach > wrote: >> >> On Fri, Jun 26, 2020 at 9:43 PM Steven D'Aprano wrote: >>> >>> I dislike Strunk and White, and don't follow it myself (except by >>> accident, as it were) but I've worked with neuro-atypical programmers >>> who found it really useful to have a common standard that they could >>> follow and reduce the uncertainty of what makes for good writing. >> >> >> I agree. >> >> I would like to reinforce that many software engineers today are _not_ >> native English speakers but work with English codebases and write >> documentation in English. >> >> Any standard is better than just asking for "clear and easily >> understandable" and hoping that for some reason every person, no matter >> where they were born and how they learned English, will share your >> definition of "clear and easily understandable" by accident. >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/3MOO4LSWEAOAULDPN4LBHQWIHIRR7U5K/ >> Code of Conduct: http://python.org/psf/codeofconduct/ > > -- > --Guido (mobile) > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/XG4J5U4OVV752TXC66KS7OCVF7XD6TP2/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/Q6YTS77EORYS4MLDB22O4XREO7ZGWMR3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
Steven just likes an argument. Nobody has ever taken the idea of a standard for language in comments seriously. It Just doen come up. On Fri, Jun 26, 2020 at 18:35 Bernardo Sulzbach < berna...@bernardosulzbach.com> wrote: > On Fri, Jun 26, 2020 at 9:43 PM Steven D'Aprano > wrote: > >> I dislike Strunk and White, and don't follow it myself (except by >> accident, as it were) but I've worked with neuro-atypical programmers >> who found it really useful to have a common standard that they could >> follow and reduce the uncertainty of what makes for good writing. >> > > I agree. > > I would like to reinforce that many software engineers today are _not_ > native English speakers but work with English codebases and write > documentation in English. > > Any standard is better than just asking for "clear and easily > understandable" and hoping that for some reason every person, no matter > where they were born and how they learned English, will share your > definition of "clear and easily understandable" by accident. > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/3MOO4LSWEAOAULDPN4LBHQWIHIRR7U5K/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XG4J5U4OVV752TXC66KS7OCVF7XD6TP2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allow signal suppression
Hmm, interesting thought! I'll try that out. Thanks! On Fri, Jun 26, 2020, 01:51 Antoine Pitrou wrote: > On Thu, 25 Jun 2020 18:32:48 -0700 > Yonatan Zunger via Python-ideas > wrote: > > > > So that's an example of why you might find yourself in such a situation > in > > userland. And overall, Python's signal handling mechanism is pretty good; > > it's *way* nicer than having to deal with it in C, since signal handlers > > run in the main thread as more-or-less ordinary Python code, and you > don't > > have to deal with the equivalent of signal-safety and the like. The > > downside of that flexibility, though, is that some tasks like deferring > > signals end up being *really hard* in the Python layer, because even > > appending the signum to an array isn't atomic enough to guarantee that it > > won't be interrupted by another signal. > > If you want to serialize execution of signal handlers, it seems like > the best course of action would be to use signal.set_wakeup_fd() and > process incoming signals in an event loop. > > Other than that, SimpleQueue may help as well, since it's specifically > meant to be reentrant: > https://docs.python.org/3/library/queue.html#simplequeue-objects > > Regards > > Antoine. > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/WOZ4TJHZ3AOSYIWWWKS4QUC6TYJIQP2J/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RLFVMHQGJJVLNRMESG3SNH4474K4GYQS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On Fri, Jun 26, 2020 at 9:43 PM Steven D'Aprano wrote: > I dislike Strunk and White, and don't follow it myself (except by > accident, as it were) but I've worked with neuro-atypical programmers > who found it really useful to have a common standard that they could > follow and reduce the uncertainty of what makes for good writing. > I agree. I would like to reinforce that many software engineers today are _not_ native English speakers but work with English codebases and write documentation in English. Any standard is better than just asking for "clear and easily understandable" and hoping that for some reason every person, no matter where they were born and how they learned English, will share your definition of "clear and easily understandable" by accident. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3MOO4LSWEAOAULDPN4LBHQWIHIRR7U5K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Access (ordered) dict by index; insert slice
On Fri, Jun 26, 2020 at 10:45:07AM -0700, Brett Cannon wrote: > Why can't you do `tuple(dict.items())` to get your indexable pairs? I don't think that an immutable copy is going to help Hans with his use-case, since he already mentions that tuples don't solve his problem. Swapping to a list gives you a mutable sequence that makes inserting columns easy, but now lookups by column name are O(N) instead of O(1). Hans, I think that a dict is probably not the best solution here, but you can use a dict in an augmented data structure. I would consider keeping your columns in a list, indexed by position, and keeping a table of columns to index in a dict. Whenever you insert or remove a column, you can update the table. If this sounds like a lot of work, yes, it probably is, and making dicts perform that work for *every single dict* would slow down the language a lot. Dicts are critical for speed and performance because they are used so extensively. Globals, builtins, almost every module, class and instance use dicts internally, so they need to be as fast as possible. If your experience with Perl tells you differently, please explain to us how Perl hashes work in order that they support both fast hash indexing and positional indexing at the same time. -- Steven ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/POHINM764UHZKVXK3GWOYIJPF525IDCS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
On Fri, Jun 26, 2020 at 09:08:31PM -, Keara Berlin wrote: > Hi all, this is a very small change, but I thought I would field it > here to see if anyone has suggestions or ideas. Instead of requiring > that comments be written in Strunk & White Standard English, PEP-8 > should require instead that English-language comments be clear and > easily understandable by other English speakers. "Clear and easily understandable" is subjective. What is clear and understandable to me may be impenetrably confusing to others, or obnoxiously dumbed down. Language that is clear and understandable to a Geordie, Brummie or Weegie could be incomprehensible to others. I've intentionally used only examples of white people here because this issue is not about "people of color" and it transcends parochial concerns about race. How would you feel about this as documentation for collections.deque? "If maxlen is set and the deque is chockers, appending a new item at one end will chuck out the item at the other end." That's perfectly clear and understandable to me and me mates. Strunk & White (which, by the way is not my first choice, not by a long, long way) at least offers a common standard that anyone can use, regardless of skin colour or native language. Far from putting up barriers, it levels the playing field by agreeing on a set of rules when we have a doubt about idiomatic written English. We don't have to engage in tedious arguments about whether Indian English or Singlish or Derry English or Pennsylvania Dutch English are "correct" or better or worse, we just have to agree on a set of rules to decide the troublesome cases. And this especially goes for people whose native tongue is no dialect of English at all, but a "foreign" language (except of course it's not foreign to them, English is the foreign language). > This accomplishes the > same goal without alienating or putting up barriers for people > (especially people of color) whose native dialect of English is not > Standard English. No, it doesn't accomplish the same goal. It strips us of a common set of standards and divides us instead of bringing us together. We have been remarkably light on arguments about grammar and spelling in the docs because we had a common standard. It is not a standard I like, and the American-centric spelling offends my sensibilities, but having a standard is better than on-going arguments about who is correct and who isn't. > This change is a simple way to correct that while > maintaining the original intent of the requirement. This change may > even make the requirement more clear to people who are not familiar > with Strunk & White, since for programmers, the main relevant aspect > of that standard is "be clear and concise;" simply saying that instead > of referencing Strunk & White may communicate this more effectively. That's prejudicial against neuro-atypical programmers (of whom there are many) who are not certain what *clear and concise* should mean. Clear and concise according to whom, according to what rules? I dislike Strunk and White, and don't follow it myself (except by accident, as it were) but I've worked with neuro-atypical programmers who found it really useful to have a common standard that they could follow and reduce the uncertainty of what makes for good writing. -- Steven ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KU6HQ44D3ODAGZ7AJRQDW7H5UT4VM6AU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
Good idea - I'll submit that now. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/26BOWJ2EED4X24524LQ6YBDSVXCM3HGO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
Your minor change is certainly an improvement. _The Elements of Style_ ( https://en.wikipedia.org/wiki/The_Elements_of_Style) is certainly a good text, but it's not even actually a style guide in the formal sense. On Fri, Jun 26, 2020 at 5:26 PM Keara Berlin wrote: > Hi all, this is a very small change, but I thought I would field it here > to see if anyone has suggestions or ideas. Instead of requiring that > comments be written in Strunk & White Standard English, PEP-8 should > require instead that English-language comments be clear and easily > understandable by other English speakers. This accomplishes the same goal > without alienating or putting up barriers for people (especially people of > color) whose native dialect of English is not Standard English. This change > is a simple way to correct that while maintaining the original intent of > the requirement. This change may even make the requirement more clear to > people who are not familiar with Strunk & White, since for programmers, the > main relevant aspect of that standard is "be clear and concise;" simply > saying that instead of referencing Strunk & White may communicate this more > effectively. > Here is the current line in PEP-8: "When writing English, follow Strunk > and White." > I propose changing this line to "When writing English, ensure that your > comments are clear and easily understandable to other English speakers." > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/AE2M7KOIQR37K3XSQW7FSV5KO4LMYHWX/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LRV7JKNXMKVWMX3VUQ7BRAEGL53YWHPL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
Given I've never even heard of Strunk & White (my own privilege i'd assume)... yeah. I don't actually know what the existing "When writing English, follow Strunk and White." text in PEP-8 even means. It doesn't hyperlink to an online source for English style probably because this was written so long ago, but I wouldn't want it to anyways. People shouldn't be arguing about "proper" English within comments anyways. Is it readable to all involved and to the next folks involved (future selves included) who will read it several years later? Good enough. Perhaps just send a PR removing that sentence to simplify things? -gps On Fri, Jun 26, 2020 at 2:29 PM Keara Berlin wrote: > Hi all, this is a very small change, but I thought I would field it here > to see if anyone has suggestions or ideas. Instead of requiring that > comments be written in Strunk & White Standard English, PEP-8 should > require instead that English-language comments be clear and easily > understandable by other English speakers. This accomplishes the same goal > without alienating or putting up barriers for people (especially people of > color) whose native dialect of English is not Standard English. This change > is a simple way to correct that while maintaining the original intent of > the requirement. This change may even make the requirement more clear to > people who are not familiar with Strunk & White, since for programmers, the > main relevant aspect of that standard is "be clear and concise;" simply > saying that instead of referencing Strunk & White may communicate this more > effectively. > Here is the current line in PEP-8: "When writing English, follow Strunk > and White." > I propose changing this line to "When writing English, ensure that your > comments are clear and easily understandable to other English speakers." > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/AE2M7KOIQR37K3XSQW7FSV5KO4LMYHWX/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OHI2I6U3TRCOK7DVD46FRMR3JEEK223T/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
Hi all, this is a very small change, but I thought I would field it here to see if anyone has suggestions or ideas. Instead of requiring that comments be written in Strunk & White Standard English, PEP-8 should require instead that English-language comments be clear and easily understandable by other English speakers. This accomplishes the same goal without alienating or putting up barriers for people (especially people of color) whose native dialect of English is not Standard English. This change is a simple way to correct that while maintaining the original intent of the requirement. This change may even make the requirement more clear to people who are not familiar with Strunk & White, since for programmers, the main relevant aspect of that standard is "be clear and concise;" simply saying that instead of referencing Strunk & White may communicate this more effectively. Here is the current line in PEP-8: "When writing English, follow Strunk and White." I propose changing this line to "When writing English, ensure that your comments are clear and easily understandable to other English speakers." ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/AE2M7KOIQR37K3XSQW7FSV5KO4LMYHWX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Access (ordered) dict by index; insert slice
It sounds like you're asking if the iteration order can be changed to be something other than the original insertion order, or if you can cause a new key-value pair to be added somewhere other than the end. I wonder if you can achieve the desired outcome without a change to the language. At any time, you can take the items in the dictionary, sort them however you'd like, and then put them into a new dictionary. sorted_items = sorted(my_dict.items(), key=lambda x: x[0].upper()) sorted_dict = dict(sorted_items) There's probably a more elegant way to do the first line. But you could do this before you perform the operation wherein you need the dict to be ordered a certain way. Steele On Fri, Jun 26, 2020 at 1:30 PM Hans Ginzel wrote: > Date: Fri, 26 Jun 2020 18:47:44 +0200 > From: Hans Ginzel > To: Hans Ginzel > Subject: Access (ordered) dict by index; insert slice > > Hello, > > thank you for making dict ordered. > Is it planned to access key,value pair(s) by index? See > https://stackoverflow.com/a/44687752/2556118 for example. Both for > reading and (re)writing? > Is it planned to insert pair(s) on exact index? Or generally to slice? See > splice() in Perl, https://perldoc.perl.org/functions/splice.html. > > Use case: Represent database table metadata (columns). It is useful as to > access columns both by name and by index as to insert column on specific > position, https://dev.mysql.com/doc/refman/8.0/en/alter-table.html, > “ALTER TABLE ADD COLUMN [FIRST |AFTER col]” (consider default order or > table storage size optimisation by aligning). > > Thank you in advance, > Hans > PS1: Named tuples cannot be used, are immutable. > PS2: See > https://metacpan.org/pod/perlref#Pseudo-hashes:-Using-an-array-as-a-hash > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/S7UMTWK65X6BJDYZ3SSU7I7HOIASDMMJ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2IXSBCDXKI3JIX5PNU7ELCVNBPIDWPPE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Access (ordered) dict by index; insert slice
I think Hans would like to do `my_dict.items()[0]` for example, which shouldn't conflict with anything. On Fri, Jun 26, 2020 at 7:48 PM Brett Cannon wrote: > Why can't you do `tuple(dict.items())` to get your indexable pairs? > > Otherwise there are no plans as you would have to introduce a new method > as you can't assume e.g. `0` is being used as a dictionary key. > > On Fri, Jun 26, 2020 at 10:32 AM Hans Ginzel wrote: > >> Date: Fri, 26 Jun 2020 18:47:44 +0200 >> From: Hans Ginzel >> To: Hans Ginzel >> Subject: Access (ordered) dict by index; insert slice >> >> Hello, >> >> thank you for making dict ordered. >> Is it planned to access key,value pair(s) by index? See >> https://stackoverflow.com/a/44687752/2556118 for example. Both for >> reading and (re)writing? >> Is it planned to insert pair(s) on exact index? Or generally to slice? >> See splice() in Perl, https://perldoc.perl.org/functions/splice.html. >> >> Use case: Represent database table metadata (columns). It is useful as to >> access columns both by name and by index as to insert column on specific >> position, https://dev.mysql.com/doc/refman/8.0/en/alter-table.html, >> “ALTER TABLE ADD COLUMN [FIRST |AFTER col]” (consider default order or >> table storage size optimisation by aligning). >> >> Thank you in advance, >> Hans >> PS1: Named tuples cannot be used, are immutable. >> PS2: See >> https://metacpan.org/pod/perlref#Pseudo-hashes:-Using-an-array-as-a-hash >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/S7UMTWK65X6BJDYZ3SSU7I7HOIASDMMJ/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/AQQVNZ6XZWJOY37Q42LULNS7ZEV4DEZ6/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/F4CGODEDDVWMFNBKBSHEPW3RPPVMJMU2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Access (ordered) dict by index; insert slice
On Fri, 26 Jun 2020 at 14:30, Hans Ginzel wrote: > Date: Fri, 26 Jun 2020 18:47:44 +0200 > From: Hans Ginzel > To: Hans Ginzel > Subject: Access (ordered) dict by index; insert slice > > Hello, > > thank you for making dict ordered. > Is it planned to access key,value pair(s) by index? See > https://stackoverflow.com/a/44687752/2556118 for example. Both for > reading and (re)writing? > Is it planned to insert pair(s) on exact index? Or generally to slice? See > splice() in Perl, https://perldoc.perl.org/functions/splice.html. > > Use case: Represent database table metadata (columns). It is useful as to > access columns both by name and by index as to insert column on specific > position, https://dev.mysql.com/doc/refman/8.0/en/alter-table.html, > “ALTER TABLE ADD COLUMN [FIRST |AFTER col]” (consider default order or > table storage size optimisation by aligning). > > These are odd requirements. No - Python dictionaries are ordered, by order of insertion only, but one can't generally do any manipulation by the numeric index of a dictionary entry - and it will stay that way. If you need such an hybrid data structure, you could just have a list of tuples as data structure, and use collections.abc.MutableMapping to provide a dict-like interface to it (and even a parallel dictionary to be used as an index for better than linear search). I could create such a data structure if you want, but I don't see that as useful enough to be part of the language. The part allowing slice-assignment seems, actually, quite confusion prone - since in dictionaries the order is order of insertion, not alphabetical order or any other. > Thank you in advance, > Hans > PS1: Named tuples cannot be used, are immutable. > PS2: See > https://metacpan.org/pod/perlref#Pseudo-hashes:-Using-an-array-as-a-hash > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/S7UMTWK65X6BJDYZ3SSU7I7HOIASDMMJ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JKFZB2AGNPKD55CU75IMZQOCVGCPHMND/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Access (ordered) dict by index; insert slice
Why can't you do `tuple(dict.items())` to get your indexable pairs? Otherwise there are no plans as you would have to introduce a new method as you can't assume e.g. `0` is being used as a dictionary key. On Fri, Jun 26, 2020 at 10:32 AM Hans Ginzel wrote: > Date: Fri, 26 Jun 2020 18:47:44 +0200 > From: Hans Ginzel > To: Hans Ginzel > Subject: Access (ordered) dict by index; insert slice > > Hello, > > thank you for making dict ordered. > Is it planned to access key,value pair(s) by index? See > https://stackoverflow.com/a/44687752/2556118 for example. Both for > reading and (re)writing? > Is it planned to insert pair(s) on exact index? Or generally to slice? See > splice() in Perl, https://perldoc.perl.org/functions/splice.html. > > Use case: Represent database table metadata (columns). It is useful as to > access columns both by name and by index as to insert column on specific > position, https://dev.mysql.com/doc/refman/8.0/en/alter-table.html, > “ALTER TABLE ADD COLUMN [FIRST |AFTER col]” (consider default order or > table storage size optimisation by aligning). > > Thank you in advance, > Hans > PS1: Named tuples cannot be used, are immutable. > PS2: See > https://metacpan.org/pod/perlref#Pseudo-hashes:-Using-an-array-as-a-hash > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/S7UMTWK65X6BJDYZ3SSU7I7HOIASDMMJ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/AQQVNZ6XZWJOY37Q42LULNS7ZEV4DEZ6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Access (ordered) dict by index; insert slice
Date: Fri, 26 Jun 2020 18:47:44 +0200 From: Hans Ginzel To: Hans Ginzel Subject: Access (ordered) dict by index; insert slice Hello, thank you for making dict ordered. Is it planned to access key,value pair(s) by index? See https://stackoverflow.com/a/44687752/2556118 for example. Both for reading and (re)writing? Is it planned to insert pair(s) on exact index? Or generally to slice? See splice() in Perl, https://perldoc.perl.org/functions/splice.html. Use case: Represent database table metadata (columns). It is useful as to access columns both by name and by index as to insert column on specific position, https://dev.mysql.com/doc/refman/8.0/en/alter-table.html, “ALTER TABLE ADD COLUMN [FIRST |AFTER col]” (consider default order or table storage size optimisation by aligning). Thank you in advance, Hans PS1: Named tuples cannot be used, are immutable. PS2: See https://metacpan.org/pod/perlref#Pseudo-hashes:-Using-an-array-as-a-hash ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/S7UMTWK65X6BJDYZ3SSU7I7HOIASDMMJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: giving set.add a return value
On Fri, Jun 26, 2020 at 7:58 PM Steven D'Aprano wrote:
> Most importantly, it matches the way people think about the task:
>
> # Task: look for duplicates
> if element in seen:
> # it's a duplicate
> ...
> else:
> # never seen before, so remember it
> ...
Do you do this:
if file exists:
# read the file
else:
# create the file
Or would you try/except around an open call? The TOCTOU issue may be
less obvious with sets, but it's still a reasonable thing to concern
yourself with.
> This idiom works with sets, it works with lists, it works with trees, it
> works with anything that supports membership testing and inserting into
> a collection. It is the natural way to think about the task.
So would "ensure this is here, and let me know if you created it". Or
"add this, and throw an exception if it was already there", which
comes to the same thing, but uses exception handling as its mechanism.
> Now, I agree that sometimes for the sake of efficiency, we need to do
> things in a weird way. But membership testing in sets is cheap, it's
> not a linear search of a huge list. So the efficiency argument here is
> weak.
TOCTOU is stronger.
> But either way, you also have to decide whether the `add` (or the new
> method) should *unconditionally* insert the element, or only do so if it
> wasn't present. This makes a big difference:
>
> seen = {2}
> already_there = seen.add(2.0)
>
>
> At this point, is `seen` the set {2} or {2.0}? Justify why one answer is
> the best answer.
>
It should do the same thing that happens already: keep the existing
one. I don't see why this is even in question. Are you searching that
hard for objections?
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/G2RRY7BJLFROU7DMTOWL44X455254RBC/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: giving set.add a return value
On Friday, June 26, 2020, at 04:54 -0500, Steven D'Aprano wrote:
On Thu, Jun 25, 2020 at 05:27:16PM +0300, Ben Avrahami wrote:
Hey all,
Often I've found this kind of code:
seen = set()
for i in iterable:
if i in seen:
... # do something in case of duplicates
else:
seen.add(i)
... # do something in case of first visit
This kind of code appears whenever one needs to check for
duplicates in
case of a user-submitted iterable, or when we loop over a
recursive
iteration that may involve cycles (graph search or the
like). This code
could be improved if one could ensure an item is in the set,
and get
whether it was there before in one operation.
Whereas this:
# Check for duplicates.
add element to the collection
was it already there before you just added it?
is a weird way to think about the problem.
already_there = seen.add(element)
if already_there:
# handle the duplicate case
Who thinks like that? *wink*
Anyone who practices EAFP rather than LBYL? Or is that why you're
winking?
But either way, you also have to decide whether the `add` (or
the new
method) should *unconditionally* insert the element, or only do
so if it
wasn't present. This makes a big difference:
seen = {2}
already_there = seen.add(2.0)
At this point, is `seen` the set {2} or {2.0}? Justify why one
answer is
the best answer.
The actual best answer is left as an exercise for the interested
reader, but whatever it is, it's justified by backwards
compatibility, the existing definition of "present," and the
principle of least surprise:
Python 3.8.3 (default, May 17 2020, 18:15:42)
[GCC 10.1.0] on linux
Type "help", "copyright", "credits" or "license" for more
information.
>>> seen = {2}
>>> 2.0 in seen
True
>>> seen.add(2.0)
>>> seen
{2}
Unless the new method is called set.add_with_different_semantics.
;-)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/X7MDBK5BGA4G3W4H7UNGNGJSSWI3ZT7G/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: giving set.add a return value
On Thu, Jun 25, 2020 at 05:27:16PM +0300, Ben Avrahami wrote:
> Hey all,
> Often I've found this kind of code:
>
> seen = set()
> for i in iterable:
> if i in seen:
> ... # do something in case of duplicates
> else:
> seen.add(i)
> ... # do something in case of first visit
>
> This kind of code appears whenever one needs to check for duplicates in
> case of a user-submitted iterable, or when we loop over a recursive
> iteration that may involve cycles (graph search or the like). This code
> could be improved if one could ensure an item is in the set, and get
> whether it was there before in one operation.
I disagree that it would be improved. The existing idiom is simple and
flexible and perfectly understandable even if you don't known the gory
details about how sets work.
Most importantly, it matches the way people think about the task:
# Task: look for duplicates
if element in seen:
# it's a duplicate
...
else:
# never seen before, so remember it
...
This idiom works with sets, it works with lists, it works with trees, it
works with anything that supports membership testing and inserting into
a collection. It is the natural way to think about the task.
Whereas this:
# Check for duplicates.
add element to the collection
was it already there before you just added it?
is a weird way to think about the problem.
already_there = seen.add(element)
if already_there:
# handle the duplicate case
Who thinks like that? *wink*
Now, I agree that sometimes for the sake of efficiency, we need to do
things in a weird way. But membership testing in sets is cheap, it's
not a linear search of a huge list. So the efficiency argument here is
weak.
If you can demonstrate a non-contrived case where the efficiency
argument was strong, then I might be persuaded that a new method (not
`add`) could be justified.
But either way, you also have to decide whether the `add` (or the new
method) should *unconditionally* insert the element, or only do so if it
wasn't present. This makes a big difference:
seen = {2}
already_there = seen.add(2.0)
At this point, is `seen` the set {2} or {2.0}? Justify why one answer is
the best answer.
--
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/M4BDA4AR555XY666ZNU5A5O4TNYDZLGR/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allow signal suppression
On Thu, 25 Jun 2020 18:32:48 -0700 Yonatan Zunger via Python-ideas wrote: > > So that's an example of why you might find yourself in such a situation in > userland. And overall, Python's signal handling mechanism is pretty good; > it's *way* nicer than having to deal with it in C, since signal handlers > run in the main thread as more-or-less ordinary Python code, and you don't > have to deal with the equivalent of signal-safety and the like. The > downside of that flexibility, though, is that some tasks like deferring > signals end up being *really hard* in the Python layer, because even > appending the signum to an array isn't atomic enough to guarantee that it > won't be interrupted by another signal. If you want to serialize execution of signal handlers, it seems like the best course of action would be to use signal.set_wakeup_fd() and process incoming signals in an event loop. Other than that, SimpleQueue may help as well, since it's specifically meant to be reentrant: https://docs.python.org/3/library/queue.html#simplequeue-objects Regards Antoine. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WOZ4TJHZ3AOSYIWWWKS4QUC6TYJIQP2J/ Code of Conduct: http://python.org/psf/codeofconduct/
