Python 3.12 Brings New Features and Fixes (infoworld.com) 30
"The Python programming language releases new versions yearly, with a feature-locked beta release in the first half of the year and the final release toward the end of the year," writes InfoWorld.
So now Python 3.12 beta 1 has just been released, and InfoWorld compiled a list of its most significant new features. Some highlights: - The widely used Linux profiler tool perf works with Python, but only returns information about what's happening at the C level in the Python runtime. Information about actual Python program functions doesn't show up. Python 3.12 enables an opt-in mode to allow perf to harvest details about Python programs...
- Programs can run as much as an order of magnitude slower when run through a debugger or profiler. PEP 669 provides hooks for code object events that profilers and debuggers can attach to, such as the start or end of a function. A callback function could be registered by a tool to fire whenever such an event is triggered. There will still be a performance hit for profiling or debugging, but it'll be greatly reduced...
- Comprehensions, a syntax that lets you quickly construct lists, dictionaries, and sets, are now constructed "inline" rather than by way of temporary objects. The speedup for this has been clocked at around 11% for a real-world case and up to twice as fast for a micro-benchmark.
- Python's type-hinting syntax, added in Python 3.5, allows linting tools to catch a wide variety of errors ahead of time. With each new version, typing in Python gains features to cover a broader and more granular range of use cases... The type parameter syntax provides a cleaner way to specify types in a generic class, function, or type alias...
- Every object in Python has a reference count that tracks how many times other objects refer to it, including built-in objects like None. PEP 683 allows objects to be treated as "immortal," so that they never have their reference count changed. Making objects immortal has other powerful implications for Python in the long run. It makes it easier to implement multicore scaling, and to implement other optimizations (like avoiding copy-on-write) that would have been hard to implement before.
- With earlier versions of Python, the base size of an object was 208 bytes. Objects have been refactored multiple times over the last few versions of Python to make them smaller, which doesn't just allow more objects to live in memory but helps with cache locality. As of Python 3.12, the base size of an object is now 96 bytes — less than half of what it used to be.
So now Python 3.12 beta 1 has just been released, and InfoWorld compiled a list of its most significant new features. Some highlights: - The widely used Linux profiler tool perf works with Python, but only returns information about what's happening at the C level in the Python runtime. Information about actual Python program functions doesn't show up. Python 3.12 enables an opt-in mode to allow perf to harvest details about Python programs...
- Programs can run as much as an order of magnitude slower when run through a debugger or profiler. PEP 669 provides hooks for code object events that profilers and debuggers can attach to, such as the start or end of a function. A callback function could be registered by a tool to fire whenever such an event is triggered. There will still be a performance hit for profiling or debugging, but it'll be greatly reduced...
- Comprehensions, a syntax that lets you quickly construct lists, dictionaries, and sets, are now constructed "inline" rather than by way of temporary objects. The speedup for this has been clocked at around 11% for a real-world case and up to twice as fast for a micro-benchmark.
- Python's type-hinting syntax, added in Python 3.5, allows linting tools to catch a wide variety of errors ahead of time. With each new version, typing in Python gains features to cover a broader and more granular range of use cases... The type parameter syntax provides a cleaner way to specify types in a generic class, function, or type alias...
- Every object in Python has a reference count that tracks how many times other objects refer to it, including built-in objects like None. PEP 683 allows objects to be treated as "immortal," so that they never have their reference count changed. Making objects immortal has other powerful implications for Python in the long run. It makes it easier to implement multicore scaling, and to implement other optimizations (like avoiding copy-on-write) that would have been hard to implement before.
- With earlier versions of Python, the base size of an object was 208 bytes. Objects have been refactored multiple times over the last few versions of Python to make them smaller, which doesn't just allow more objects to live in memory but helps with cache locality. As of Python 3.12, the base size of an object is now 96 bytes — less than half of what it used to be.
Re: (Score:2)
And too bad the PyPI is still tracking you so much that it gets legal subpoenas for user data. Don't worry, you don't have to do anything, we'll do it all for you! Where have I heard that before?
Re: (Score:2)
The syntax is fine. For something designed in 1991, it is remarkably elegant.
Performance was not a design priority for Python. It was always intended to be used with C etc.
If it bothers you, try Julia instead. It was designed with more modern functional, numeric and performance considerations and principles.
Other features listed in the article (Score:1)
Other features listed in the article:
o Better error messages
o Buffer protocol dunders
- Easier access to raw memory in Python objects
o Subinterpreters
- Each with its own GIL (global lock)
o Removal of deprecated modules
- di
Re: (Score:2)
> o Subinterpreters
> - Each with its own GIL (global lock)
So... local global locks?
Re: (Score:2)
Re: Whitespace is dumb (Score:1)
Marry me.
Re:Whitespace is dumb (Score:4, Insightful)
Yeahwhitespaceispointlessitaddsnothingandweshouldgetridofit!
Re: (Score:2)
Yet you used it to make this comment, curious. I am very smart.
Re: Abomination (Score:2)
the retarded idea of using white space as part of language gramma is still there,
Why is this such a sticking point?
You indent the code blocks when writing in your favorite language, don't you? And you apply the "don't repeat yourself" principle when coding?
So why is it such a problem if the language drops the redundant brackets around code blocks and semicolons at the end of lines?
Re: Abomination (Score:1)
Re: (Score:2)
Yeah I can indent code in other languages and they will compile if I miss an indent or use a space instead of a tab. One single out of place space and your python code is dead. Like how every line of Arduino code must end in a semicolon? That’s the same as every line not requiring a semicolon.
Re: (Score:1)
Yeah I can indent code in other languages and they will compile if I miss an indent or use a space instead of a tab. One single out of place space and your python code is dead. Like how every line of Arduino code must end in a semicolon? That’s the same as every line not requiring a semicolon.
It will complain on compile, just like your COMPILED language. You are a person looking to be mad at ... literally nothing -- whitespace. Stay mad, keep your ignorance over nothing and stay the F*** away from my hiring pools.
Re: (Score:2)
Yeah I can indent code in other languages and they will compile if I miss an indent or use a space instead of a tab. One single out of place space and your python code is dead. Like how every line of Arduino code must end in a semicolon? That’s the same as every line not requiring a semicolon.
An editor setting will clean up your sloppy tab/space intermingling as you type. An editor command (e.g. retab in vim) will correct tabs and spaces that other people have messed up. Visualization settings can make tabs visible in the listing so you know who to blame.
Re: (Score:2)
You've never had to do any programming as a job, have you?
In the real world, code had to be edited under uncertain circumstances quite often, and usually when doing so time is an issue. Having code fail to work because the editor at the end of three ssh hops isn't set up for whatever magic invisible formatting the fucking retarded language insists on is not acceptable.
Why is this such a sticking point?
Braces cost nothing, do they? They make the parser easier to write. And there's no issues with printed code
Re: (Score:3)
> You've never had to do any programming as a job, have you?
Really? You think people don't have Python as a programming job, especially when it has been around for decades and is at the top of the popularity boards?
> In the real world, code had to be edited under uncertain circumstances quite often, and usually when doing so time is an issue. Having code fail to work because the editor at the end of three ssh hops isn't set up for whatever magic invisible formatting the fucking retarded language insis
Re: (Score:2)
> You've never had to do any programming as a job, have you?
Really? You think people don't have Python as a programming job, especially when it has been around for decades and is at the top of the popularity boards?
I think most Python is written by amateurs who don't have to maintain it. In certain situations the language's terrible design choices have minimal impact. But it is unsuited to real world work where code might be expected to run for decades without having to worry that the idiots upstream have decided to break backwards compatibility more or less on a whim and without even bothering with correct version numbering. More broadly, formatting that resembles what used to be done on punched-cards is not acceptab
Re: (Score:2)
> I think most Python is written by amateurs who don't have to maintain it.
Technically true. Python was designed as a teaching language. It is probably the easiest language you can teach that is also completely practical. So yeah, it attracts a lot of first time programmers. That used to be BASIC in the decades past. First time programmers do write bad code.
Python code that you would encounter in recognized libraries, like the ones included in Anaconda, are all quite cleanly written and are very easy to
Re: (Score:2)
I think this is the crux of the debate.
Most languages care little about whitespace as long as you stick in at least one instance where needed to keep tokens from crashing into each other. In this regard, Python is an outlier. Many experienced programmers work in a variety of languages over time - some
Re: (Score:2)
I've started to see indentation-as-syntax as a misfeature.
But not a huge one.
Not compared to the constant deprecation of various libraries during a single major version.
Not compared to the difficulty of packaging a Python app for multiple different OS versions.
Not compared to tons of things.
Yet, it is still my go-to language for short- to medium-sized scripting applications, and for gluing things together. Far better for those purposes than its major peers (Perl, Ruby, arguably PowerScript, certainly VBScr
Channels that lstrip every line (Score:2)
No more frustrating than code failing because a brace or a semi-colon is missing. For those of us who used Python as our main language, finding incorrect indentation is as effortless as finding a missing brace.
Discussion platforms strip indentation more often than they strip punctuation. Say you collaborate with other developers through a channel that is broken enough that it ends up running lstrip() on each line of text passed through it, such as HTML's default behavior. In any popular language other than Python, you can correct the indentation later by running a formatter on your source code file. The formatter will look at the braces and guess what indentation should have been applied. In Python, by contrast,
Re: Abomination (Score:2)
Re: (Score:2)
I've never warmed up to Python largely because of the whitespace being significant to execution nesting.
For quick stuff I don't use an IDE but just fire up an editor (of course emacs as only a poorly educated caveman would use vi/vim :)) and start writing. Often I decide to move code around and change the nesting level in the process (pushing stuff out of loops, moving things to procedures, moving function to an existing procedure etc.). Too often in Python that requires significant (i.e., more than three s
Re: (Score:2)
Python was conceived in late eighties and first published in 1991. Still complaining about significant whitespace, and idea that originated in 1966, which is in its fundamental design decisions, is like complaining about pointer syntax in C or begin and end blocks in Pascal. It's not going to change.
https://en.wikipedia.org/wiki/... [wikipedia.org]
It's not the first and it won't be the last language to adopt it.
The only abomination here is your inability to appreciate things for what they are. The world isn't centered arou
It's not compatible with Python 3.11... (Score:2)
Re: (Score:2)
I didn't check, but why wouldn't it? Except for the Python 2.7 to 3.0 transition, all Python versions are compatible with previous versions.
Oh my gosh (Score:2)