This is a neat article, but it does have some errors. One subtle point that the post gets wrong: > So where does that come from? The answer is that Python stores everything inside dictionaries associated with each local scope. Which means that every piece of code has its own defined “local scope” which is accessed using locals() inside that code, that contains the values corresponding to each variable name. The dicti…
Understanding Python through its builtins
101–110 of 180 posts
Re: Understanding Python through its builtins
#102Earlier quoted context omitted.
I really like ruby's method naming convention for this: * `sort(arr)` returns a sorted copy of the input * `sort!(arr)` returns the sorted original methods that return booleans end in `?`, like `arr.sorted?` It's just a convention, but it's a nice way to let the writer know what will happen.
The ! convention is ok but I don't think it's optimal because, in the presence of higher-order functions and related concepts, it's often not clear if a function should be marked as !. For example if I have a map function that applies a function f to a sequence, should I call it map! because I might pass in a function f that mutates the input? If so then it seems like any function that takes a function as input, or a…
Re: Understanding Python through its builtins
#103This is a neat article, but it does have some errors. One subtle point that the post gets wrong: > So where does that come from? The answer is that Python stores everything inside dictionaries associated with each local scope. Which means that every piece of code has its own defined “local scope” which is accessed using locals() inside that code, that contains the values corresponding to each variable name. The dicti…
The “complex > real > int” thing is true in mathematics. In Python, `bool` inherits from `int`.
And I have no objections to the article's description of the bool type.
Re: Understanding Python through its builtins
#104Re: Understanding Python through its builtins
#105Very well written. Fun little tidbit, Django abuses the fact that bools are ints in it's partition util: https://github.com/django/django/blob/01bf679e59850bb7b3e639...
>>> l = ['a','b']
>>> l[False]
'a'
>>> l[True]
'b'
>>> d = {0: 'a', 1: 'b'}
>>> d[False]
'a'
>>> d[True]
'b'
>>> # TIL!Re: Understanding Python through its builtins
#106In addition to this, I highly recommend just reading the codebase. I haven't written C since college and it's remarkably readable. I once tried to catalogue all the stdlib operations which release the GIL, meaning if you use only those (well, only those "heavy" bits, you can still use other small blocking glue bits), you can do "real" multithreading. It was a fun exercise!
There's a really nice (although old now) walk through of the cpython code base on YouTube. I watched it on a long 24 hour flight between Canada and Sweden a couple of years back. Edit: Found it! You're in for about 9 hours of quality watching. https://youtube.com/playlist?list=PLwyG5wA5gIzgTFj5KgJJ15lxq...
Re: Understanding Python through its builtins
#107Very well written. Fun little tidbit, Django abuses the fact that bools are ints in it's partition util: https://github.com/django/django/blob/01bf679e59850bb7b3e639...
It does make for some amusing code golf techniques, e.g.: print([ f"{(not x % 3) * 'Fizz'}{(not x % 5) * 'Buzz'}" or x for x in range(1, 20) ])
Re: Understanding Python through its builtins
#108This is a neat article, but it does have some errors. One subtle point that the post gets wrong: > So where does that come from? The answer is that Python stores everything inside dictionaries associated with each local scope. Which means that every piece of code has its own defined “local scope” which is accessed using locals() inside that code, that contains the values corresponding to each variable name. The dicti…
Spot on. Python is widely described as a simple language, but the complexity of attribute lookup is one thing that shows that's not true at all.
Many things in Python are easy, such as adding `@property` above a method definition to turn it into a getter. But `@property` is far from simple - the way it actually works is very complex (for example, properties have to be data descriptors, because non-data descriptors cannot override object attributes of the same name).
Re: Understanding Python through its builtins
#109Earlier quoted context omitted.
I strongly dislike python, I often wonder if it would have been as popular if Guido didn't work at Google early on.
Why do you strongly dislike Python? Language design, standard library, community, leadership?
Guido van Rossum doesn't appreciate FP and he really genuinely doesn't understand it. That's not to say he's dumb or not a nice guy or anything. It's just not his area. And this is reflected in the language.
His attitude of you have to be "really smart" to understand FP is a mistake.
https://developers.slashdot.org/story/13/08/25/2115204/inter...
https://blog.finxter.com/about-guidos-fate-of-reduce-in-pyth...
Re: Understanding Python through its builtins
#110Earlier quoted context omitted.
Yes, lots of them are available. But I also would like to be able to call .sum() on my iterable at the end of a chain, instead of having to mentally unwrap sum(map(filter(filter(map(...))))
But you only ever need to unwrap one sum(). And with sequence comprehensions, what you get instead is sum(... for ... if ... for ... if ...) - I don't think that's improved by rewriting it as (...).sum().
The problem with filter chaining is the final assignment and the actual value are separated by the rest of the chain.
i.e. x = strList.filter(parseInt).sum() doesn't tell me what type x is till I read the whole line.
Whereas:
x = sum( parseInt(v) for v in strList ) tells me as quickly as possible that I'm dealing with a single value output that will be a sum.