Comment by chrismorgan | Hacker News Reader

Comment by chrismorgan | Hacker News Reader

I didn’t know about breakpoint(), which landed in 3.7, about a year after I stopped using Python regularly (I considered myself an expert at the time; now, the ecosystem has moved on enough and I’m rusty enough that I’d rate myself below expert, but able to become expert again in a very short time). Until hearing about this, if I were needing to debug Python stuff I’d have been perfectly happy continuing to use pdb.set_trace(), but breakpoint() is nicer now that I know about it.

This reveals something important that is easy to overlook: while you’re actively working in an ecosystem, you may hear about new things that come along, but if you spend some time away, things may well happen that you didn’t hear about, and so in some cases beginners may even surpass you in current idioms. It’s worthwhile, in such cases, at least skimming over some materials and especially the release notes since you were last an expert—if I were going back to working with Python/Django extensively, I’d read at the very least the headings of the release notes for Python 3.6–3.10 and Django 1.8–.

I tend to drift in and out of Python, and follow the same pattern as you suggest when coming back after a couple of releases. Python's version notes are truly excellent¹.

The only thing I really wish for is an ecosystem "what's now" guide, it would list things such as where the community has moved for common libraries. Off the top of my head it would have covered things like nose to pytest and such. Obvious problem being I just can't imagine how you'd get buy-in to make such a thing work, especially without it getting overrun with grifters.

¹ https://docs.python.org/3/whatsnew/index.html

There's the Hitchhiker's Guide to Python which has a lot of advice and covers best practices and/or projects over a number of big areas like web frameworks, databases, command line tools, etc.: https://docs.python-guide.org/

Yeah, something like that.

However, taking "Command-line Applications"¹ as an example it lists six alternatives. I think in the version I'd like to see a good few of them would disappear. For example, I'll presume plac/fire/cement aren't in common use given that only two are packaged in Debian and the two that are don't have reverse dependencies. Cliff looks largely uninteresting too, as outside of OpenStack nothing seems to use it.

I think my ideal implementation would probe recent releases of popular packages for dependencies to see what the community has settled on or moved to. I also suspect this comment that somewhat moves the goalposts also points to the difficulties of maintaining such a document.

¹ https://docs.python-guide.org/scenarios/cli/

Totally agree with you. I would put argparse, the built-in command line argument parser, over Click on that list. Click is great, but it's one more API to internalize, for something that's not really the meat and potatoes of your application.

That said, when I started out using Python professionally, I got a lot of mileage out of this guide.

The problem is, any such whats-now guide is very soon already outdated, at least in some aspects. It should be a Wiki which everyone can edit.

And btw, such Wiki exists, even officially: https://wiki.python.org/moin/FrontPage

Although, as you might expect, it is a mixture of outdated, more recent, messy, detailed, lists or guides and everything.

What are the current common libraries also doesn't really have a simple answer. Maybe this should be auto-generated based on Google or GitHub trends.

>> What are the current common libraries also doesn't really have a simple answer. Maybe this should be auto-generated based on Google or GitHub trends.

I followed the Python and PSF community very closely for about 12 years through 2018. I haven't kept up for personal reasons. I suspect they are uncomfortable with doing this because they don't want to feel like they are picking winners. Whatever they list will be "blessed" no matter how many disclaimers are attached. In a way, I observe a similar problem impacting how they've approached ecosystem problems like packaging. There is a clear issue and a central authority was needed to sort it out and that never emerged when it was originally required.

Right now PyPI highlights some trends (https://pypi.org), but there is more they could do. Python success stories at https://www.python.org/success-stories/ could probably be evolved to highlight some of the libraries and tools which get serious usage. Anything that's autogenerated from other sources probably has value, but would only be something that would be compatible if it's detached from python.org. Expanding PyPI trend information would be more compatible with python.org.

I’ve been using JS continually since the mid 90s. But once the changes started coming fast and furious with ES6, I just couldn’t keep up with them. I think the only thing I’ve really adopted is template literals. People who are newly coming into JS probably know and use the newer changes. For example, I’m so used to prototype inheritance that I don’t think I’ll ever use class. But I imagine new people use class and might never even learn what is actually happening under the syntactic sugar.

Of all the new features I think `class` is the one I've seen least adoption of. Not that I've read a huge amount of JS.

There are some cases where it can be nice, but often it feels like a somewhat unnatural bolt-on to the language. I guess OO isn't that widely used in JS anyway.

Stuff like nullish coalescing and spread operators however... those things are great - they can save a lot of code.

JS classes are one of the things I'm most unsure about in the direction of the language. On the one hand, it is nice to have a form of abstraction of prototypes that is quite close to the typical mode of programming used in popular languages like Python and Java. On the other hand, it is quite a needless abstraction for a well-functioning system. The ease with which a class system can be implemented on top of prototypes just shows how prototypes embody the JS spirit: Flexible, powerful, a bit too easy to shoot yourself in the foot with.

I learned about breakpoint() while prepping for an internship interview. I ended up not getting that internship, but it ended up massively improving my workflow. Now I annoy all my friends into using it whenever we run into bugs while working on Python together.

I seem totally incapable of stopping using “import pdb; pdb.set_trace()” in my code. Once every couple months I’m reminded breakpoint() exists and that I’m still apparently not using it.

What do you think you would have to learn to become expert again?

Mostly it’d just be about dusting off the cobwebs and using it all again; I still know it all, but my skill will doubtless have atrophied at least a little from six or seven years of disuse. In such a case, having been familiar with Python 2.5–2.7 first probably also works against me, as the distance of time will probably make recollecting the ancient Python 2 way occur more often relative to the Python 3 way than it would have while I was actively using Python 3. As far as actual ecosystem changes are concerned, packaging practices are probably the most significant area where I gather there’s been a fair bit of change happening.

I think you're really overestimating the gap between python 2 and 3. My experience was that just diving into a large python3 codebase got me most of the way really quickly.

The only thing I can think of that I had to really read up on was string handling. Everything else I could just google as I came across it. And even after 6 or 7 years, it all comes back really quickly.

Packaging stuff... weren't we using virtualenv 6 or 7 years ago? And even that - it's hardly difficult to get working with.

The advent of declarative package management (poetry et al.) is a significant change. Not that hard to get working with, but definitely a big departure from previous practices.

Which language(s) did you switch to?

Personally, Rust; professionally, mostly web frontend stuff (HTML/CSS/JavaScript, plenty of each) rather than Python web backend stuff.

Reply on news.ycombinator.com