I know that there is no such thing as python 4.x versions but what if there where. I think by the time python is done with it’s 3.x versions, python will be faster then Java lol. Any opinions/ thoughts.
38 comments · 18% upvoted · other discussions
static typing!
But you know you can use typing in Python since years? Typing and annotations work great. Bigger projects often require it.
Typing is optional. Isn't that great? Beginners can do their stuff with dynamic types until their program crashes. Later they learn that typing helps a lot. Even to generate docs.
I genuinely wonder what Python could do with static typing to be honest.
I'm no expert on the internals of Python, but the impression I have is that the dynamic nature of types is part of what makes it slow. Surely mandatory correct types (when provided) could help with interpreter optimisation?
That's my understanding.
I traced the memory usage in my Python 2.6 program back in the day. I figured oh, my 32-bit float is 8 bytes (64-bit python FTW), so my 1M values should take up 8M bytes + some waste for the keys. I was using dictionary of dictionaries and it took something like 10x what I calculated. I looked into the memory in more detail and there were pointers all over the place.
I replaced it with a numpy array with my admittedly lousy way to load an array and got a memory usage down by 20x cause I could finally use float32s. It was ~10% slower for the loading step, but I stopped hitting my 4 GB memory cap and could load much larger files.
Later on I figured out how to actually load a large array and directly type it without casting. Oh...it loads at the rated speed of my SSD.
numpy is basically C or C++ under the hood.
I know. My point was all that object nonsense on things like and integers, floats and tuples are massively inefficient. Static typing would allow for more optimizations such that you wouldn't need numpy for things like that. Numpy would still be better, but not an absolute necessity.
Objects in Python, even integer numbers are objects. Because they also have methods, conversion functions and all classes are inheritable. Speaking of integers... You can do math with huge numbers beyond 64bit... That requires some magic that costs CPU time.
Compared to C/C++ Python is slow, because it can't just do a few CPU cycles on raw memory for basic math. Python has a lot of overhead. Not because of bad implementation. The magic of Python just requires more CPU cycles.
If you need extensive calculations, just use numpy. You then basically handle with data types your CPU can handle directly. Handling thousands or millions of calculations by arrays can be as fast as in C. Because numpy is written in a low level language.
Python can't just switch to be something like C. It would change everything in Python. Older programs could break.
The developers always improved Python in speed. But there's always a limit.
I wish XD
[removed]
Python has private class members. At least a convention for that. If you use a good IDE you get a warning on accessing private members of other classes. If you decide to access private members anyway, it's your problem then.
When people access these under-methods, they often just don't know the proper function for that.
The thing is 4.0 will happen sort of. Based on the 3.0 launch experience the PSF does things differently now gradually introducing features. The GIL removal will not trigger a 4.0, but will slowly be worked on across subsequent releases, and then at some version will be switched from optional to default. The End.
And Python >= 3.10 is quite different from say 3.0-3.3 and is moving forward.
[deleted]
Yea but upgrading may have actually been a challenge. These days, its not hard to stay close to the current version.
I think for one project, we were able to upgrade from 3.5 to 3.7, then 3.7 to 3.9. Then 3.9 to 3.11. All zero or minor code changes for python compat. A lot more changes being induced by being forced to new major versions of dependencies
Maybe Python 4 could be the clean break from the packaging malarkey we've endured for want of backward compatibility.
A clean slate, backwards incompatible, move to "one true" packaging and deployment scenario (whatever that means) that perhaps looks like PEP-582 (rejected in the current landscape), or perhaps looks different again. Just fix the mess, without concern for how existing tools would be broken.
The only thing I'd like to see in the language itself is a shift towards structured concurrency in the standard library, with the existing concurrency primitives being "deprecated" at least in terms of what the (currently missing) concurrency overview in the docs suggests users should do.
I only want a stdlib that matches with the PEP standards. But PSF is too afraid to change things because of what heppen with python 3
[removed]
Algebraic data types would definitely make python better
The break between 2 and 3 was to fix fundamentally broken things about Python. There aren't big flaws in Python 3 that would necessitate another version with many breaking changes.
We could get a Python 4 but it would be more akin to the difference between Java 8 and 9. Marginal and backwards-compatible.
Not just braces, but...
DOUBLE BRACES.
def func(name): {{
if name == 'Alice':
{{
print('Hello!')
}}
}}
Double braces = double speed
Double braces plus the colon Loved your book by the way
Why stop at double braces? What about double colons and parentheses?
Mojo
The love-child of Python and Rust... the correctness and speed of Rust with the ergonomics of Python
It’s still not a compiled language…so doubt it’ll get faster than Java anytime soon
Will never be faster than Java anytime soon or ever.
4.0x? What about a 5.0x?! You gotta think bigger! 10.0x! 20.0x! 50.0.x!!! All equally meaningless to ask about because nobody is planning for them!
They will continue to go beyond 3.100.y which is a good versioning scheme for a language as they always maintain backward compatibility so there is no incentive for them to increment the major version.
Even for projects, I discourage aggressive increments in versions. After 3 years, some projects go from 1.x.y to 6.x.y like how and why? This causes a huge fragmentation in industrial projects. Imagine that you were able to convince the compliance team of your organization to approve some package for your new service which was at 1.x.y and after 3 years, you want to use the updated version of the package. The hesitation it produces after seeing the package is now at version 6 causes too much panic because you have to go through the entire release history to see how many breaking, deprecated and removed changes are there with each major version. Then, you have to give a convincing justification to the compliance team about why you want to move that far. Not to mention, the amount of testing you will have to do to ensure that the service has not been affected with bugs after updating the version.
I like how SQLAlchemy increments its versions. They keep it slow and steady so that every industrial projects can safely adopt version 2 who are at version 1.
So your looking at dotnet packages I see... I noticed quite a few that did that with net5+, matching the version it's supposed to go with, even when they still support the older ones. (Glares at MS)
And then almost worse, using the year as the major version, and jumping to that after like 1-3.
I want all the legacy code that was made before the style peps, classes in UpperCase (like datetime), function names that are not in snake_case, etc, to be cleaned up.
I feel like it's a huge headscratcher and confusing for newbies to have the standard libraries not following the languages own style guidelines.
sausix 2 points · Sep 2023
Some packages made aliases and dirty tricks to support OOP or other conventions. Turtle for example. The standard lib could rename their classes and functions and add aliases. That would work until someone would compare a class name by string directly.
But to be honest. Beginners are far away from PEP8 and naming conventions. They will probably learn OOP before following naming conventions. Don't you think?
IcedThunder 6 points · Sep 2023
I think programming language should adhere to its own official style standard so as to reduce confusion for newcomers.
"Hey, here's a convention to help separate functions from classes, but a bunch of regular stuff you're going to use a lot doesn't adhere to it" is dumb.
I believe this standard is good to help new people, and thay by not having the standard libraries adhere to it, it adds unnecessary confusion.
Wether or not they learn OOP has nothing to do with anything. It's about having an entirely consistent language that is suppose to be easy on beginners.
And if we're gonna introduce a major version update, it's the perfect time to correct that kind of thing.
PhoenixStorm1015 2 points · Sep 2023
Idk the resources I used and the docs I read very much encouraged proper stylization.