151–160 of 413 posts
Earlier quoted context omitted.
> the Python Software Foundation won't let them use the name Python That's how trademarks are supposed to work; they must go after anyone using without permission or they lose it.
Or they could give permission.
People are complaining about Python 3 being named Python because some code breaks under it. That would be hell.
I have a Python 2.7 project that has been running smoothly for many years now and I'm having trouble finding a reason to upgrade to Python 3. The project uses the unicode type to represent all strings, and encodes/decodes as necessary (usually to UTF-8) when doing I/O. I haven't really had any of the Unicode handling problems that people seem to complain about in Python 2. Can someone explain what benefit I would act…
It has always seemed to me that Python 3 was mainly a fix on the philosophy of handling strings, but that it didn't offered a clear practical advantage for programmers already handling strings with care. I don't think there is a practical reason to upgrade to Python 3 in terms of language design. The reason will be in term of survival as the community seems to be willing to follow the Python 3 movement and official s…
Even if you think you would not use those features, other libraries you may use might benefit a lot from it.
A few features: async/await, lists (and others) use iterators, no var leaking in list comprehensions, super().my_method() instead of super(MyClass, self).my_method(), class MyClass: instead of class MyClass(object):, improved exception handling, required arguments, ", ".join(["etc"]* 1000)
Besides that: a much improved standard library, although that technically not is language design.
Time to introduce Python 4.
Earlier quoted context omitted.
> Many of the science libs want to use seem to be in 2.7 with no signs of moving The most important scientific libraries have pledged to drop support before 2020, and are all python3-ready http://www.python3statement.org/
Is there any hope of other libraries and OSes doing the same thing? I used to work on a GUI app in Python. I ported it to Python 3, then switched OSes for various reasons. 5 years on , on Ubuntu Xenial (so new I can't even use it in Travis, but that's a separate whine), I install pykdeuic4 and it's using Python 2. So I've basically abandoned that project for 5 years now, because every time I looked at it I thought "s…
Seriously: if you can, try building your thing with tkinter. It's the standard lib, and will "work"
Earlier quoted context omitted.
It has always seemed to me that Python 3 was mainly a fix on the philosophy of handling strings, but that it didn't offered a clear practical advantage for programmers already handling strings with care. I don't think there is a practical reason to upgrade to Python 3 in terms of language design. The reason will be in term of survival as the community seems to be willing to follow the Python 3 movement and official s…
There are a lot of reasons to upgrade! There is so much more useful stuff in python 3! Even if you think you would not use those features, other libraries you may use might benefit a lot from it. A few features: async/await, lists (and others) use iterators, no var leaking in list comprehensions, super().my_method() instead of super(MyClass, self).my_method(), class MyClass: instead of class MyClass(object):, improve…
You could do ", ".join(["etc"]* 1000) in python2 - what am I missing?
Earlier quoted context omitted.
This sounds like a fork. Nothing need stop someone from forking and maintaining CPython 2.x. Open source is a do-ocracy. But I doubt it'd be worth it. Python 3 is getting great traction and is a fundamentally better language.
Python 3 is already a fork. The problem is that Python 2 cannot evolve freely alongside Python 3, because even if someone wants to maintain it and keep releasing versions, the Python Software Foundation won't let them use the name Python (there was a post some weeks ago about someone who actually tried). So there is no free competition between 2 and 3. 2 has been basically killed by a decision from above. Don't get m…
Earlier quoted context omitted.
What py3 does is it enforces the things that py2 only suggests as far as unicode goes. That means on py2 you can go for the proper handling and if you did do everything right, then py3 migration should be almost boring. The difference is when you didn't handle all the cases correctly. In that situation Py2 will silently do either the right, or the wrong thing and you'll never know. Py3 will likely throw an extension…
I'm fairly sure I'm handling strings correctly under Python 2. What I'm not sure of is the risk of something breaking if I upgrade to Python 3, especially when it comes to upgrading external dependencies. Even if it's just non-backwards compatible API changes, it's more risk to deal with.
Python 2 will allow this to sometimes work, Python 3 will make sure this never works, because there's a bytes/text mismatch. It's nice to rule out entire classes of bugs like this
from sys import argv
import json
with open(argv[1], 'rb') as f:
json.loads(f.read())
Earlier quoted context omitted.
To me, unicode alone was worth the switch. I will go to great length to avoid the hell that is unicode in Python 2. Besides speed, I never seen any good argument that would make me start a new project on 2.7, rather than the latest v3 release. I get that there was a series of data science libraries that wasn't supported initially, but seems to have been solved at this point. So I really do see why people continue to…
> Besides speed, I never seen any good argument that would make me start a new project on 2.7, rather than the latest v3 release. That's because you start "new projects". Some of us have 10+ years of codebases to maintain, and we don't care for Python 3 features...
Earlier quoted context omitted.
There are a lot of reasons to upgrade! There is so much more useful stuff in python 3! Even if you think you would not use those features, other libraries you may use might benefit a lot from it. A few features: async/await, lists (and others) use iterators, no var leaking in list comprehensions, super().my_method() instead of super(MyClass, self).my_method(), class MyClass: instead of class MyClass(object):, improve…
Of which the improved exception handling is my favourite. You could do ", ".join(["etc"]* 1000) in python2 - what am I missing?
", ".join(['ètç']* 1000)
Earlier quoted context omitted.
Is there any hope of other libraries and OSes doing the same thing? I used to work on a GUI app in Python. I ported it to Python 3, then switched OSes for various reasons. 5 years on , on Ubuntu Xenial (so new I can't even use it in Travis, but that's a separate whine), I install pykdeuic4 and it's using Python 2. So I've basically abandoned that project for 5 years now, because every time I looked at it I thought "s…
I've had similar issues with most GUI libraries. Seriously: if you can, try building your thing with tkinter. It's the standard lib, and will "work"