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

31–40 of 180 posts

Re: Understanding Python through its builtins

#31

Post by Alex3917 »

submeta wrote: post #2

Nicely written article! - Slightly off topic: I love seeing and reading Python code. Used to see many flaws in the language (things like `.append` changing the object, returning `None` instead of creating a copy and returning that), but after ten years of working with Python I really appreciate its versatility, it‘s ubiquitous availability, the large number of libraries and the community. There‘s nothing I can‘t solv…

> things like `.append` changing the object, returning `None` instead of creating a copy and returning that

The obvious question is why it can't return a reference to the list instead of returning None. I feel like if I've been using the language on an almost daily basis for ten years now and I still get burned by that all the time, then it's just a poorly designed feature.

Re: Understanding Python through its builtins

#32

Post by mattficke »

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/

Re: Understanding Python through its builtins

#33

Post by aidos »

goatlover wrote: post #20
Marazan wrote: post #16

Earlier quoted context omitted.

But that's good. Because a string just needs to know aboit interable to perform that operation whereas every iterable would need to implement it's own join if you had it the other way around.

Yet Ruby and JS manage to do it somehow. To me it seems natural that join should be a method on the iterable, and I always have to pause to remember Python is different.

How does that work? Don’t you have to effectively convert your general iterable to an array and then join on that? Array.from(iterable).join(…)?

Re: Understanding Python through its builtins

#34

Post by radarsat1 »

l33tc0der wrote: post #9
radarsat1 wrote: post #5

Earlier quoted context omitted.

> (things like `.append` changing the object, returning `None` instead of creating a copy and returning that) This would be horrendously inefficient without immutable data structures like Clojure's. Very few languages have that, so it's a strange assumption to make, especially for a language as old as Python. Although it is a very nice feature of Clojure.

One of the many reasons why I love Clojure so much! Rich implement his own brand of persistent data structures which makes Clojure's immutability a lot more efficient.

Thanks yeah, persistent is the term I was looking for, did not come to mind as I haven't used Clojure in a few years.

Re: Understanding Python through its builtins

#35

Post by canjobear »

Alex3917 wrote: post #31
submeta wrote: post #2

Nicely written article! - Slightly off topic: I love seeing and reading Python code. Used to see many flaws in the language (things like `.append` changing the object, returning `None` instead of creating a copy and returning that), but after ten years of working with Python I really appreciate its versatility, it‘s ubiquitous availability, the large number of libraries and the community. There‘s nothing I can‘t solv…

> things like `.append` changing the object, returning `None` instead of creating a copy and returning that The obvious question is why it can't return a reference to the list instead of returning None. I feel like if I've been using the language on an almost daily basis for ten years now and I still get burned by that all the time, then it's just a poorly designed feature.

The advantage of mutating operations always returning None is that you can easily tell whether a mutation is happening by looking at the code. If you see y = f(x) that means x is unchanged, whereas if you see just f(x) on a line that means something stateful is happening.

Re: Understanding Python through its builtins

#36

Post by usrme »

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.

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.

Re: Understanding Python through its builtins

#37

Post by matsemann »

dehrmann wrote: post #25
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.

In a way, learning Python is harder for people experienced with another language because so much of the content you find is for first-time programmers. That said, I think I had good luck with Writing Idiomatic Python.

Yes!

When I learned Kotlin, I just read through the docs, and then knew of basically all the different concepts in the language.

For Python, the docs were comparably very bad. For instance, Decorators aren't mentioned even once in the "The Python Tutorial". In "The Python Language Reference" (if one even bother to read such a dry document) it's barely mentioned in passing. How should a new user know it's a concept and how to apply it? And the language reference links only to a glossary item, and none of them specify how parameters in a decorator is supposed to work.

Pretty frustrating experience, put me a bit off the language from the get-go.

Re: Understanding Python through its builtins

#38

Post by dharmab »

eximius wrote: 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!

Agreed. CPython makes readability and maintainability a priority.

Re: Understanding Python through its builtins

#39

Post by pdonis »

tyingq wrote: post #12
tusharsadhwani wrote: post #3

Earlier quoted context omitted.

Thank you! Things like `list.append` modifying in-place might feel like a flaw to some, but I think Python is really consistent when it comes to its behaviour. If you ask a person who comes from an object-oriented world, they'll say it only makes sense for a method on an object to modify that object's data directly. There's always ways to do things the other way, for example you can use x = [*x, item] to append and c…

>Python is really consistent when it comes to its behaviour True, though you end up with things like: ' '.join(thelist) Instead of thelist.join(' ') Because of the somewhat aggressive mantra to be consistent.

In the cases you give, the original list is not being mutated; a new object (a string, not a list) is being created. So it does make sense not to have it be a method call on the list.
Post reply on HN