Earlier quoted context omitted.
Is this a 2x -> 3x gripe, or is there something specific in this release that breaks compatibility?
I gave up before this release. edit: oh my, that's a lot of downvotes for answering a question.
[deleted]
Python 3.3.0 released
91–100 of 119 posts
Re: Python 3.3.0 released
#92I've done quite a bit of python development. One of the things that really bugs me about python is how they keep breaking older stuff. Other languages have been much more careful about maintaining backwards compatibility and I think that is a big factor in the retention of users. Having to re-do any part of your code from one release of a language to another became a real deal breaker for me. For an interpreted langu…
> you don't know you have a problem until that bit of code gets hit
The easiest way around this problem is to have tests and run them before you upgrade your production boxes. It's not that hard to do.
Re: Python 3.3.0 released
#93I've done quite a bit of python development. One of the things that really bugs me about python is how they keep breaking older stuff. Other languages have been much more careful about maintaining backwards compatibility and I think that is a big factor in the retention of users. Having to re-do any part of your code from one release of a language to another became a real deal breaker for me. For an interpreted langu…
The problem is in the type system. Dynamic typing makes it difficult to ever change APIs, because a change could break anything that depends on them. pylint and other such tools help a little bit, but they can only do so much when the language doesn't support static typing. Another Python feature that makes upgrades hard is monkeypatching, where one piece of code can inject arbitrary code into another piece of code.…
Monkey patching is a clear violation of the API contract and is expected to break when versions change.
It's really not clear to me how your claims can be backed up. Lack of static typing is a fundamental feature of Python, it's part of the design philosophy. The majority of the language functionality is built in the standard library, where modules and interfaces can be swapped out and deprecated easily. Modules in pypi can have different codebases for different interpreter versions, and programs/projects can declare their dependencies using virtualenv; multiple Python interpreter versions can coexist on the same system. Your claim boils down to saying that static typing allows languages to develop faster and cut down maintenance costs, but I don't think you can conclusively demonstrate either point.
Re: Python 3.3.0 released
#94There are two significant factions in the Python community: the scientific group and the web-dev group. The scientific group is pretty much on board with Python 3. Perhaps due to unicode handling intricacies, that the web-dev group ain't exactly on board with Python 3 yet. But this needs to change and it takes leadership. Fortunately, bit and pieces such as webob are Python 3 compatible. And personally, I feel the Py…
> The scientific group is pretty much on board with Python 3. Ah .. NO! I can assure you that we are still stuck with Python 2.x (2.7 to be more precise). I am not too sure the others would have moved either.
Can you list the reasons?
Re: Python 3.3.0 released
#95I've done quite a bit of python development. One of the things that really bugs me about python is how they keep breaking older stuff. Other languages have been much more careful about maintaining backwards compatibility and I think that is a big factor in the retention of users. Having to re-do any part of your code from one release of a language to another became a real deal breaker for me. For an interpreted langu…
The problem is in the type system. Dynamic typing makes it difficult to ever change APIs, because a change could break anything that depends on them. pylint and other such tools help a little bit, but they can only do so much when the language doesn't support static typing. Another Python feature that makes upgrades hard is monkeypatching, where one piece of code can inject arbitrary code into another piece of code.…
Java is statically typed and it is ugly as hell. It also breaks stuff between major versions.
Implying that a language is doomed to be ugly or hard to evolve because it doesn't use static types is not a logical conclusion.
Besides, Perl 6 is not Perl 5 continued, and never pretended to be. Perl 5 continues to evolve (e.g. Moose) and is not getting uglier. You could argue that it was already ugly when it was created, but it is not growing uglier.
Re: Python 3.3.0 released
#96Earlier quoted context omitted.
The problem is in the type system. Dynamic typing makes it difficult to ever change APIs, because a change could break anything that depends on them. pylint and other such tools help a little bit, but they can only do so much when the language doesn't support static typing. Another Python feature that makes upgrades hard is monkeypatching, where one piece of code can inject arbitrary code into another piece of code.…
Monkey patching is a clear violation of the API contract and is expected to break when versions change. It's really not clear to me how your claims can be backed up. Lack of static typing is a fundamental feature of Python, it's part of the design philosophy. The majority of the language functionality is built in the standard library, where modules and interfaces can be swapped out and deprecated easily. Modules in p…
virtualenv is a symptom of the disease, not the cure. People get stuff working with a specific version of all the libraries and of Python, and then they forget about upgrading. And why should they upgrade? It will just break their code in mysterious ways. It would be different if the compiler could tell them about changes in type signatures, but it can't.
In the real world, monkeypatching happens. And you may not always know that your libraries or framework are doing it, either. Ruby on Rails does extensive monkeypatching, even of core classes such as String. I don't think you can patch str in CPython due to implementation issues, but that's not the point.
Re: Python 3.3.0 released
#97I've done quite a bit of python development. One of the things that really bugs me about python is how they keep breaking older stuff. Other languages have been much more careful about maintaining backwards compatibility and I think that is a big factor in the retention of users. Having to re-do any part of your code from one release of a language to another became a real deal breaker for me. For an interpreted langu…
Be careful what you wish for. The extreme alternative is Java, whose slavish obsession with backwards compatibility has effectively crippled the language. There's enough cruft in the standard library to keep newbies guessing for years, plus fundamental language design failures like type erasure and "beans". At some point you need to burn bridges in order to move forward. Doing this frequently destroys the community.…
I think in Python's case there was really no compelling reason to burn the bridges between 2 and 3. Burning the bridges should be done when something will be significantly improved.
Re: Python 3.3.0 released
#98Earlier quoted context omitted.
Be careful what you wish for. The extreme alternative is Java, whose slavish obsession with backwards compatibility has effectively crippled the language. There's enough cruft in the standard library to keep newbies guessing for years, plus fundamental language design failures like type erasure and "beans". At some point you need to burn bridges in order to move forward. Doing this frequently destroys the community.…
I think in Python's case there was really no compelling reason to burn the bridges between 2 and 3. Burning the bridges should be done when something will be significantly improved.
Python's Unicode support was significantly improved between 2 and 3.
Re: Python 3.3.0 released
#99There are two significant factions in the Python community: the scientific group and the web-dev group. The scientific group is pretty much on board with Python 3. Perhaps due to unicode handling intricacies, that the web-dev group ain't exactly on board with Python 3 yet. But this needs to change and it takes leadership. Fortunately, bit and pieces such as webob are Python 3 compatible. And personally, I feel the Py…
> There are two significant factions in the Python community: the scientific group and the web-dev group.
You forget the animation group. And the hardware/embedded group (Raspberry-Pi, anyone?). And the C-wrapper-writing group. And the sysadmin group. And and and...
The Python ecosystem is very large and diverse. That's part of its strength, and part of its weakness as well (it's very difficult to "herd" all these people, as this 3k migration has shown), but don't make the error of reducing it to the most vocal sectors -- they're not necessarily the most significant ones.
Re: Python 3.3.0 released
#100Earlier quoted context omitted.
Monkey patching is a clear violation of the API contract and is expected to break when versions change. It's really not clear to me how your claims can be backed up. Lack of static typing is a fundamental feature of Python, it's part of the design philosophy. The majority of the language functionality is built in the standard library, where modules and interfaces can be swapped out and deprecated easily. Modules in p…
virtualenv is a symptom of the disease, not the cure. People get stuff working with a specific version of all the libraries and of Python, and then they forget about upgrading. And why should they upgrade? It will just break their code in mysterious ways. It would be different if the compiler could tell them about changes in type signatures, but it can't. In the real world, monkeypatching happens. And you may not alw…
Ruby's culture is FAR more tolerant of monkeypatching than Python's culture - monkeypatching str, for example, just isn't a thing you would do. So what constitutes 'the real world' differs between the two.