4 ms·
I really think this writer doth protest too much. Yes, the base async interface is confusing and overly complex. It's a downside! As they note lots of people h
by aeturnum 4y ago
I really think this writer doth protest too much.
Yes, the base async interface is confusing and overly complex. It's a downside! As they note lots of people have stepped in to provide better helpers (like TaskGroups) - but these are the docs for the base library!
> But who reads all the docs? And who has perfect recall if they do?
Everyone reads the docs? That is why you don't need perfect recall because you can read them whenever you want.
Python has lots of confusing corner cases ("" is truthy, you need to remember to call copy [or maybe deepcopy!] sometimes, all the other situations where you confuse weak v.s. strong references). They cause really common bugs. It's just a hazard of the language in general and the choices it makes (much like tasks being objects is a hazard). I do understand why people think they can throw away task references (based on other languages) - but this is Python! The garbage collector exists and you gotta check if you own the object or something else does.
Edit: this feels like an experienced Python developer, who has already internalized all the older, non-async Python weirdness, being taken aback by weirdness they didn't expect. Like, I feel you, it does suck - but it's not a bug that values you don't retain may get garbage collected.
- raverbashing 4y ago> "" is truthy Humm, no? Unless you mean ("",) >>> not "" True
- aeturnum 4y agoOh, sorry, you are right - "" is false-y, even though it's a valid empty value. So it's hard to tell the difference between a value not being filled and a value being filled with an empty value. ex: answers = {} answers["I exist"] = "" if answers["I exist"]: print("a") does not print.
- fbdab103 4y agoI guess I am too deeply in the Python ecosystem to see a problem here. Unless you want to check for the existence of "I exist"? In which case, the Python Way would be answers = {} answers["I exist"] = "" if "I exist" in answers: print("a")
- aeturnum 4y agoIt's not a problem? The async interface isn't a problem either. It's just a thing you have to remember about python: "most input is truthy except for the input that isn't" "Most of the time you don't disrupt your program by not keeping the returned reference in scope except for when you do" It's just a thing that trips people up.
- fbdab103 4y agoTruthy is a Pythonic core principle of the language. It is not an edge case phenomenon in the language which I would expect a regular practitioner to confuse. https://docs.python.org/3/library/stdtypes.html#truth-value-testing https://docs.python.org/3/library/stdtypes.html#truth-value-...
- aeturnum 4y agoI mean, I've seen bugs around that in code I've worked on and I've created bugs where it's a factor. Weakrefs are also a core part of the language: https://docs.python.org/3/library/weakref.html https://docs.python.org/3/library/weakref.html . You can't use python without using them.
- fiddlerwoaroof 4y agoWhat I learned when I wrote Python professionally was “never rely on truthiness” explicitly writing out a boolean expression that does what you want is more explicit (“explicit is better than implicit”, PEP 8) and prevents a whole class of bugs down the line.
- nemetroid 4y agoPEP 8, which you mention, explicitly recommends relying on truthiness: > For sequences, (strings, lists, tuples), use the fact that empty sequences are false: # Correct: if not seq: if seq: # Wrong: if len(seq): if not len(seq):
- 4y ago
- heavyset_go 4y ago> if answers["I exist"]: if "I exist" in answers: ...
- wizzwizz4 4y ago> So it's hard to tell the difference between a value not being filled and a value being filled with an empty value. >>> answers = {} >>> if answers["I don't exist"]: ... print("a") Traceback (most recent call last): File "<pyshell#3>", line 1, in <module> if answers["I don't exist"]: KeyError: "I don't exist" The method you're trying to use doesn't work anyway: it doesn't matter that it's confusing. You'd have the same problem with the value False.
- hn_throwaway_99 4y agoI mean, that's the fundamental reason it's called falsey, that is, Python does automatic type coercion if it is evaluating things in a boolean context. FWIW this is the exact same behavior in javascript.
- mixmastamyk 4y agoA string is a container in Python. Containers are false when they are empty.
- No1 4y agoHe didn't even have to read "all the docs" - just the ones that pertain the the function that he is using. And then not ignore the section marked "Important" and the highlighted "Note".
- richbell 4y agoWhat if he read the docs for that function prior to the "important" note being added?
- Karunamon 4y ago>Everyone reads the docs? The author goes on to say they found this pattern lurking in various projects on github. So, no. The problem is that this behavior is subtle, not intuitive, and unless you are reading the actual documentation top to bottom (and not just the function signature and first paragraph from the pop up in your IDE) you will likely get bitten by this. What is the point of your comment? The author shouldn't have called out the upturned rake in the darkened shed?
- rollcat 4y ago> The author goes on to say they found this pattern lurking in various projects on github. I'd call it an anti-pattern. If you spawn a process/thread, and never wait/join it, it means you don't actually care what it does, if it crashes, etc. I don't see a problem with Python's behavior here.
- hn_throwaway_99 4y agoSeriously?? I think the vast majority of developers would find it very surprising that the Python runtime would GC a task in the middle of execution. I would expect that the runtime would by default do what the example in the doc says, which is keep a strong reference to the Task object until it finished execution.
- mannykannot 4y agoThe chances are that most people doing this are introducing some nondeterminism that they did not expect, and will have a hard time dealing with it when it bites them in the ass. What's more to the point is that I am going to have a hard time when it leads to a serious outage or security violation at some major corporation that has become too pervasive in its reach for me to avoid its influence. No amount of schadenfreude is going to compensate for that.
- aeturnum 4y agoI wouldn't say shouldn't - they are free to do what they want. But this is a blog post about something that can trip you up that the docs highlight - which the author calls a "heisenbug". The author doesn't even have a suggestion for the docs, which already calls out the problem they encountered, they just note that there are helpers for this problem (which is true). The point of my comment is that subtle, non intuitive things like this are all over Python and, while this one is particularly bad, this blog post makes it seem like more of an aberration than it is.
- iforgotpassword 4y ago> Everyone reads the docs? For Python? The language where everyone just cobbles together random code from the internet and other repos? I can totally see how this mistake happens left and right. The bar of entry for this language is way too low to assume only rigorous senior devs use it.
- leni536 4y agoConsidering how many times I need to add site:python.org to my python search queries to actually get to the docs, I assume that a surprisingly low number of python developers actually read the docs.
- 0x008 4y agoIf you use Druck duck go you can prefix search with “!py3”
- IshKebab 4y ago> Everyone reads the docs? Wow I've heard people say that everyone should read all of the docs (which isn't really true) but I've never heard anyone claim that everyone does read all of the docs! Wild.
- Etheryte 4y agoI think you may be too bold with the assumption here, personally I would wager that the majority of people who write Python don't even know Python has official docs outside of a site called Stack Overflow.
- brundolf 4y agoIn 15 years of programming I’ve never read the docs for anything front-to-back. I look at the docs when I have a specific question It’s crazy to suggest something this surprising wouldn’t be a problem just because it’s technically in the docs
- sidlls 4y agoThis is unfortunately all too common. I am often dinged by my manager about my throughput when investigating the integration of new libraries because I read the docs, front-to-back, as part of my research and that takes time.
- brundolf 4y agoI don't think it's really appropriate or feasible or even helpful for most things. At least for myself, if I read through the entirety of a language's documentation I wouldn't remember half of it, and I probably wouldn't need everything I remembered. Language and library designs should optimize for least-surprise.
- sidlls 4y agoMost libraries are quite poorly documented (to my taste, anyhow). It is certainly worth spending the time reading at the very least documentation pertinent to the components of the library intended for use.
- davesque 4y agoHow is "" truthy? I just double checked and `bool("")` is `False` as I expected (in Python 3.9 at least).