Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding Python through its builtins

sadh.life

Post reply on HN
Print view View original

171–180 of 180 posts

Re: Understanding Python through its builtins

#171

Post by Doxin »

andi999 wrote: post #168
masklinn wrote: post #148

Earlier quoted context omitted.

Depends. The issue is that since `assert` is stripped out in “O” mode, if the codebase depends on `assert` for correctness… they’re not compatible.

What do you mean by depends on assert for correctness? How?

    get_president_inside_bunker()
    assert president_is_inside_bunker()
    close_bunker_doors()
    assert bunker_doors_are_closed()
    send_nukes()
With asserts enabled this is fine. With asserts disabled you might start sending nukes while the president is still outside or the doors to the bunker are still open.

Re: Understanding Python through its builtins

#172

Post by Doxin »

weatherlight wrote: post #63
matsemann wrote: post #62

> List comprehensions are basically a more Pythonic, more readable way to write these exact same things More pythonic maybe, but you can't have more than a single expression in a list comprehension without it becoming completely unintelligible. I also often miss other standard list features. Reduce, flatmap, indexed versions, utils like first of predicate, split, filternonnull etc

Anything remotely interesting like that is dumped in itertools. Python's creator, Guido van Rossum, doesn't like functional/functional-ish programming a lot. That's well-known. Guido: "I value readability and usefulness for real code. There are some places where map() and filter() make sense, and for other places Python has list comprehensions. I ended up hating reduce() because it was almost exclusively used (a) to…

Also definitely learn about using sum on non-numbers, and the key argument to min and max. They can be incredibly handy, but I hardly see them used. Have a contrived example:

    >>> max(['aaa', 'bb', 'c'], key=lambda item: len(item))
    'aaa'

Re: Understanding Python through its builtins

#173

Post by xojoc »

In a similar vein you may like "WTF Python: Exploring and understanding Python through surprising snippets":

https://github.com/satwikkansal/wtfpython

HN thread: https://news.ycombinator.com/item?id=26097732 (163 comments)

PS: found with a site I'm building: https://discussions.xojoc.pw/?q=Understanding+Python+through...

Re: Understanding Python through its builtins

#174

Post by cinntaile »

mattficke wrote: post #32
cinntaile wrote: post #8

Are there any good books that deal with writing pythonic code? As well as being focused on more intermediate or advanced features like this? If the book is project focused that's a bonus. Performance trade-offs another bonus.

Effective Python [0] is my favorite book in this category. [0] https://effectivepython.com/

I'm giving this one a go as well, thanks!

Re: Understanding Python through its builtins

#175

Post by BerislavLopac »

matsemann wrote: post #62

> List comprehensions are basically a more Pythonic, more readable way to write these exact same things More pythonic maybe, but you can't have more than a single expression in a list comprehension without it becoming completely unintelligible. I also often miss other standard list features. Reduce, flatmap, indexed versions, utils like first of predicate, split, filternonnull etc

Are you saying that:

    l = []
    for a in range(10):
        for b in range(10):
            for c in range (10):
                l.append(a + b + c)
is more intelligible than:

    l = [
        a + b + c
        for a in range(10)
        for b in range(10)
        for c in range(10)
    ]
???

Re: Understanding Python through its builtins

#176

Post by andi999 »

Doxin wrote: post #171
andi999 wrote: post #168

Earlier quoted context omitted.

What do you mean by depends on assert for correctness? How?

get_president_inside_bunker() assert president_is_inside_bunker() close_bunker_doors() assert bunker_doors_are_closed() send_nukes() With asserts enabled this is fine. With asserts disabled you might start sending nukes while the president is still outside or the doors to the bunker are still open.

Thanks! I never thought anybody would do such a thing.

Re: Understanding Python through its builtins

#177

Post by Doxin »

andi999 wrote: post #176
Doxin wrote: post #171

Earlier quoted context omitted.

get_president_inside_bunker() assert president_is_inside_bunker() close_bunker_doors() assert bunker_doors_are_closed() send_nukes() With asserts enabled this is fine. With asserts disabled you might start sending nukes while the president is still outside or the doors to the bunker are still open.

Thanks! I never thought anybody would do such a thing.

No one should, but it happens.

Re: Understanding Python through its builtins

#178

Post by adrusi »

Blikkentrekker wrote: post #54
adrusi wrote: post #52

Earlier quoted context omitted.

Random access into a clojure vector is going to need more memory lookups than conventional sequential buffer array (I don't recall the constants used in the implementation, I think it's either 4 or 8 lookups). But when you're indexing into the vector sequentially, the memory layout plays rather well with memory caching behavior, and most lookups are going to be in L1 cache, just like they would be in a conventional a…

How? I don't see how that's possible. The actual data of a Pvector is not in contiguous memory but scattered however the JVM wills it, and on top of that in order to find which address to retrieve it, an algorithm that runs in logarithmic time with respect to the length of the vector must be used opposed to a constant time one. How can most lookups end up in L1 cache if an element that is 32 indices removed is statis…

So I don't recall what size of chunks Clojure's implementation uses, but I'll assume it uses 64-bit indices with 16-word chunks, because I want to use numbers.

    (loop [i 0]
      (println (get my-vector i))
      (recur (inc i)))
Assuming no part of my-vector is cached at first, the first iteration needs to make a full 16 round trips to main memory — quite bad. But on the next iteration, all of that is cached, and we don't hit main memory at all, and the same until i=16, which requires one round trip. Then when i=16², we need to hit main memory twice, etc.

No doubt this is quite a bit worse than having everything nicely laid out sequentially in memory, but it's not as bad as you're describing.

Of course, all of that is not that material to begin with given that most elements will be pointers to begin with

I guess this is sort of true. If you're doing random lookups, then using a persistent vector instead of an array list mean 17 trips to main memory instead of just 1, so it's not totally inconsequential.

But I think (hope?) that modern JVMs can optimize collections of small immutable objects so that they're not represented as pointers to the heap. Surely ArrayList x gets represented as int x[], and not int *x[], at least with the most optimizing JIT level.

Re: Understanding Python through its builtins

#179

Post by patviafore »

cinntaile wrote: post #127
usrme wrote: post #36

Earlier quoted context omitted.

I would recommend "Robust Python" by Patrick Viafore. It teaches you a lot about type annotations (among other thing) and gave me personally a whole new way of looking at the code that I write.

Thanks for the different suggestions, I went with this one. Fluent Python also looked promising but I can't buy the 2nd ed yet.

Author of Robust Python here: I definitely recommend Fluent Python as well once the 2nd edition is available. I wrote Robust Python to focus very much on how to write Python in a long-lived codebase and how to do trade-offs for readability/maintainability/testability/etc. It also covers a lot of things outside of standard built-ins (such as acceptance testing, mutation testing, pydantic, type checkers, etc.). I find Fluent Python to be more focused on more of the built-ins, and I think it might cover some of the performance trade-offs you might be looking for.

Long story short : I think both have a lot of value (but beware I'm quite biased on Robust Python)

Re: Understanding Python through its builtins

#180

Post by asdfgeoff »

cinntaile wrote: post #8

Are there any good books that deal with writing pythonic code? As well as being focused on more intermediate or advanced features like this? If the book is project focused that's a bonus. Performance trade-offs another bonus.

Not a book, but I have found Trey Hunner's https://www.pythonmorsels.com/ exercises very useful on this front.

The solutions presented typically include both a "basic" approach, a "as pythonic as possible" approach, and a brief discussion of the trade-offs between elegance and readability, etc.

Post reply on HN