Live data from Hacker News

Understanding Python through its builtins

sadh.life

101–110 of 180 posts

Re: Understanding Python through its builtins

#101
post #98

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…

The “complex > real > int” thing is true in mathematics. In Python, `bool` inherits from `int`.

Re: Understanding Python through its builtins

#102

Earlier 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…

map! would mean a function that performs a map in-place on the array by replacing the values. So it would depend on if the callback was encouraged to mutate the array or discouraged from doing so.

Re: Understanding Python through its builtins

#103
post #98

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…

The “complex > real > int” thing is true in mathematics. In Python, `bool` inherits from `int`.

Yeah, but we're not talking about pure mathematics. We're talking about floats, and I find that it's very important to be clear about the limitations. It's easy to get some nasty bugs if you start assuming that you can cram just any int into a float.

And I have no objections to the article's description of the bool type.

Re: Understanding Python through its builtins

#105

Very 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...

cool!

  >>> 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

#106
post #56
post #28

In 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...

That's amazing. Wish there was something similar for the JVM and V8.

Re: Understanding Python through its builtins

#107
post #79

Very 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) ])

Fantastic

Re: Understanding Python through its builtins

#108
post #98

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…

> Attribute lookup in Python is [...] an enormous tar pit

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

#109
post #81

Earlier 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?

Mostly language design.

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

#110
post #70

Earlier 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().

There's a not unreasonable position implicit in Python's way that the "most significant" operation should be most visible.

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.

Post reply on HN