I used to wait 9 months before upgrading, so the third party packages could be update. Is that still an issue?
Python 3.12
301–310 of 344 posts
Re: Python 3.12
#302Ooh, seems there is a new syntax for declaring the types of kwargs [1]: from typing import TypedDict, Unpack class Movie(TypedDict): name: str year: int def foo(*kwargs: Unpack[Movie]): ... Maybe now I'll be able to actually figure out what data to send libraries without actually reading their source code. 1. https://docs.python.org/3.12/whatsnew/3.12.html#pep-692-usin...
Finally! I've been waiting for this for years. Now I just have to wait 5 more years until 3.12 is sufficiently old that work lets me use it. Bets on user-upgradable Python on Linux by 2030?
> Bets on user-upgradable Python on Linux by 2030?
Use asdf. You don’t want to manage your project’s dependencies at the system level any more than you have to.
Re: Python 3.12
#303Oh hey, the useless (except for leetcode) language got an update. Yay, maybe more people try to write boring business logic without type safety. Can't wait.
I recently took part A of Dan Grossman's Programming Languages' course, and he focus on Standard ML which is strongly-typed. It was enlightening to learn about, and after completing Part A, I too felt that any language that lacks type safety can't be a serious language.
I recently started using Python again for a side project, and I had forgotten how good of a dev experience Python offers. I wish I could explain better than that though.
Part B of that course is about weakly typed languages like Ruby. Your comment is motivating me to go and finish Part B, because I wish I could articulate better what exactly it is that makes weakly typed languages useful in their own right.
Re: Python 3.12
#304I used to wait 9 months before upgrading, so the third party packages could be update. Is that still an issue?
Check the list here for the biggest packages: https://pyreadiness.org/3.12/
Re: Python 3.12
#305Earlier quoted context omitted.
It feels like we're going in cycles. C was somewhat lax with type checking, thus C++ and Java were both made more strict. Looking to escape the tyranny of static typing, the rise of Python, Ruby, or JavaScript instead left us with a desire that Rust, Go, and TypeScript now fulfill. I wonder what's the next step? LLMs are extremely broad in what they accept, but don't exactly fill the same niches.
I always saw C++ and Java addressing other issues, like low level memory management, and higher level abstractions like objects. Not so much type policy. Anyways I see a strong tendency in lots of programmers dismissing anything that is not type static-strict-safe, and others advocating for a more relaxed system.
I see C++ as a scientific DSL definition language. It lets you create an abstraction and define arithmetic operators, iterators and even lets you control dereference and call semantics. The standard helps this scheme by defining return value optimization.
Re: Python 3.12
#306Everything aside, I enjoyed the "And now for something completely different" part.
It's a poem advocating empathy, people, not an edict on border control policy. Are people really so sensitive that they can't handle being reminded that other people may think differently than them?
[deleted]
Re: Python 3.12
#307What's new: https://docs.python.org/dev/whatsnew/3.12.html Summary, sorry for poor formatting, I'm not sure HN can do a list of any kind? New features More flexible f-string parsing, allowing many things previously disallowed (PEP 701). Support for the buffer protocol in Python code (PEP 688). A new debugging/profiling API (PEP 669). Support for isolated subinterpreters with separate Global Interpreter Locks (PEP 684…
Tbh the f-string stuff sounds pretty in-pythonic to me… like it would make it much harder to read and abuse.
Python tends to be permissive and rely on convention over preventing certain practices, sometimes summed up as "we are all consenting adults." E.g., there's multiple inheritance, no private variables, and monkeypatching. I see this change as in the same vein. This change also makes it conceptually simpler [0]. It also appears to reduce technical debt by reducing differences between expressions in f-strings and in the rest of the language.
Re: Python 3.12
#308Earlier quoted context omitted.
The Azure SDK generally have a lot of silliness in the Python implementation. Functions that take string as inputs, except of course they don't, they take two or three very specific string values and use them to control functionality. What those values are... Well, you should take a look at the ENUM in the C# implementation to figure that part out.
Python has enums though :(
Sure, but Microsoft doesn't always use them.
Re: Python 3.12
#309Earlier quoted context omitted.
Isolated subinterpreters (PEP 684): Just how isolated are those? Is it simply a more complicated version of multiprocessing, with all the same drawbacks (communication via pipes/socket/some-other-stream)?
It's a less complicated version of multiprocessing because you don't have to deal with multiple processes and all the complexity that that entails. It's basically web workers / isolates for Python.
It looks more complicated. You get the same cumbersome communication primitive (channels), except now native code can easily get messed up. And it requires more care when developing the interpreter itself.
Using multiprocessing was actually pretty easy (apart from the communication primitives, which obviously suck).
Re: Python 3.12
#310Earlier quoted context omitted.
It's better than "polarised but unbalanced".
I’m not sure; an unbalanced opinion is obviously unbalanced, and it’s easier to see it as not being the whole picture. But a seemingly reasonable opinion combined with a straw man of an opposing view, is harder to unlearn.
That is true enough. In this case, I think a useful learning outcome is that the backwards reading is, in theory and ignoring the emotional word choices, as politically extreme as the forwards reading. However, I doubt most will see it this way.