3 ms·

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

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

recuter 5y ago
Which language(s) did you switch to?
- chrismorgan 5y ago
  Personally, Rust; professionally, mostly web frontend stuff (HTML/CSS/JavaScript, plenty of each) rather than Python web backend stuff.
JNRowe 5y ago
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 https://docs.python.org/3/whatsnew/index.html
- cjohnson318 5y ago
  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/ https://docs.python-guide.org/
  - JNRowe 5y ago
    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/ https://docs.python-guide.org/scenarios/cli/
    - cjohnson318 5y ago
      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.
- albertzeyer 5y ago
  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 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.
pyuser583 5y ago
What do you think you would have to learn to become expert again?
- chrismorgan 5y ago
  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.
  - biorach 5y ago
    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.
    - alduin32 5y ago
      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.
bcwarner 5y ago
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.
CogitoCogito 5y ago
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.
irrational 5y ago
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.
- biorach 5y ago
  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.
- bakuninsbart 5y ago
  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.

recuter 5y ago

Which language(s) did you switch to?

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

JNRowe 5y ago

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 https://docs.python.org/3/whatsnew/index.html

cjohnson318 5y ago
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/ https://docs.python-guide.org/
- JNRowe 5y ago
  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/ https://docs.python-guide.org/scenarios/cli/
  - cjohnson318 5y ago
    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.
albertzeyer 5y ago
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 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.

pyuser583 5y ago

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

chrismorgan 5y ago
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.
- biorach 5y ago
  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.
  - alduin32 5y ago
    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.

bcwarner 5y ago

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.

CogitoCogito 5y ago

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.

irrational 5y ago

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.

biorach 5y ago
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.
bakuninsbart 5y ago
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.