4 ms·
I haven't written any code that doesn't run on Python 3 since 2010. I'm in the comfortable position of generally getting to use Python 3 for new projects (my li
by sho_hn 15y ago
I haven't written any code that doesn't run on Python 3 since 2010. I'm in the comfortable position of generally getting to use Python 3 for new projects (my library dependencies are met), and when I don't, the shared subset of Python 2.7 and 3 is useful enough to get the job done.
There's lots of reasons I find coding in Python 3 more enjoyable and productive. Unicode by default, removing x*() functions and returning generators where appropriate instead, removing old-style classes, improved consistency in standard object interfaces/protocols, standard lib cleanups, etc. Yes, even print() - keyword args are a lot nicer than the old hackish syntax for things like the output file.
These are often called minor and "no compelling reason to upgrade", but I'd submit that when a language does more often what you expect it to do, when the number of gotchas you need to keep in mind is reduced significantly, that's not minor. It might not be a reason to switch a large existing codebase over, but it's certainly a reason to write the next large codebase in it, and that's what Python 3 aims at: The future of Python and its future users.
No, that doesn't make for a fast transition, but indeed, it was never expected to be ("five years" is the plan, we're not there yet, and things look to be on track). Eventually, there just won't be any reasons left not to use Python 3, but plenty of reasons to do so (the better core language, the sum of improvements in the standard lib, the continued maintenance), and then it'll be done.
- trimbo 15y agoHonest question though: do you think that, given all of the breaking changes and toughness of upgrading, _even more_ should have been broken in this release to improve the language? I guess that's my most major beef with it. The upgrade has been tough, and a lot of the most inconsistent aspects of Python weren't fixed. (A good example: "len()") BTW, I tried using Python 3 on that project in 2010, if that helps anyone gauge my opinion on it.
- sho_hn 15y ago> Honest question though: do you think that, given all of the breaking changes and toughness of upgrading, _even more_ should have been broken in this release to improve the language? Yeah, sure, there are still some things in there that make me wonder why they didn't go one step further to fix it too. Little things even, like the names of the special methods to intercept attribute access: __getattr__ and __getattribute__ should have been swapped for consistency, since __getattribute__ is closer in behavior to __setattr__ and __delattr__, making the current __getattr__ the behavioral outlier. But meh, any language has its odd little warts, and so has Python 3. It does have significantly less than Python 2, though.
- chrismsnz 15y agoI think that len() is not a good example, it was actually designed that way for a very good reason. [0] [0]. http://lucumr.pocoo.org/2011/7/9/python-and-pola/ http://lucumr.pocoo.org/2011/7/9/python-and-pola/
- rictic 15y agoI love python. It took a while but it has won me over, and I've come to appreciate its commitment to legibility and consistency. At this point it only loses out to javascript in my heart because javascript is universally deployed on users' machines. However this is complete and utter bullshit. Other languages are inconsistent? The answer is not to be inconsistent, and you can be consistent as a method or as a builtin function. Don't know if it should be a method or an attribute? Python has properties now, the user doesn't have to care. The 'special meaning' section that follows seems a bit confused as well. Why is it so special to get the length of a collection? Sorry for going off on a rant, please correct me if I'm wrong here. I just get so frustrated with the eagerness of the Python community's apologetics for things that no longer make sense to be in the language. I can feel it working within me too, I'm more and more on the fence about explicit self.
- irahul 15y ago> Don't know if it should be a method or an attribute? Python has properties now, the user doesn't have to care. Python didn't have properties when the len protocol was implemented. What exactly will be gained if Python replaces len(a) with a.length(where a.length translates to a.__len__())? If properties were there from the beginning, that would have been the implementation; but since they weren't, len(a) is just fine and I don't see any reason for it to be changed. > The 'special meaning' section that follows seems a bit confused as well. Why is it so special to get the length of a collection? Personally I would have preferred __len__ to be just length, because length of a sequence is part of it's public interface, as opposed to other special methods viz. __getattr__, __getitem__. Apart from that, his 'special meaning' section is just saying that following a weird naming convention for the special methods permits programttacily differentiating between public interface and special methods. > I can feel it working within me too, I'm more and more on the fence about explicit self. The main reason it is that way is decorators. http://neopythonic.blogspot.in/2008/10/why-explicit-self-has-to-stay.html http://neopythonic.blogspot.in/2008/10/why-explicit-self-has... > However this is complete and utter bullshit. This isn't an appropriate response to a well thought out article.
- craigyk 15y agoThis was my exact view as well. Especially since I've learned a few languages since I first learned Python, and I just don't understand why they didn't take the opportunity to implement more good features from other languages.
- ronnix 15y agoWhat are some examples of features from other languages that you would like to see in Python?