28 ms·
I am afraid that, the python community has messed up 2.x => 3.X transition. Until 3.3, there seemed no incentive to port your codebase to Python 3.X. With gola
by ram_rar 10y ago
I am afraid that, the python community has messed up 2.x => 3.X transition. Until 3.3, there seemed no incentive to port your codebase to Python 3.X.
With golang getting a lot of traction and compiler tools like grumpy (python -> Go), I would rather invest time to transition into golang as apposed to transition to 3.X.
- Cyph0n 10y agoTransitioning from Python to Go isn't as easy as you make it out to be. Good luck finding solid alternatives to the likes of Numpy, scikit-learn, Pandas, SQLAlchemy, BeautifulSoup, Flask etc. Oh, and not to mention the community surrounding these and other popular Python libraries.
- deleted 10y ago[deleted]
- tyfon 10y agoAll of them work in python 3.x too. Well. I'm not sure about flask, it's not one i use personally.
- ram_rar 10y agoNumpy / scipy and scikit-learn are the only things that are holding me back. Apart from that, I think its just a matter of time golang will have similar libraries in its ecosystem. Afaik, for regular CRUD apps golang can pretty much replace whole of python with better performance (in terms of concurrency).
- kevml 10y agoThose toolkits often rely on generics/duck typing, and tend towards very simple REPL style exploration.
- dekhn 10y agoAgreed, my main reason for not switching to Go fulltime is numpy and scipy. I was recently pointed at https://github.com/gonum https://github.com/gonum which has a subset of the functionality of numpy and scipy.
- ubernostrum 10y agoI am afraid that, the python community has messed up 2.x => 3.X transition. Until 3.3, there seemed no incentive to port your codebase to Python 3.X. Just to bring up a small counterpoint: I don't think anyone really expected the early 3.x releases to be used in production. They were, as I recall, intended primarily as proof-of-concept releases to let people start looking at what porting would involve, and to get feedback and make improvements in the 3.x series to make porting easier and production deployments nicer.
- ram_rar 10y ago> I don't think anyone really expected the early 3.x releases to be used in production. I see this as a huge red flag. Its ok, to break/experiment things until you reach 1.0. After that, the core development team must factor in the consequences of breaking backwards compatibility.
- ubernostrum 10y agoI think you're reading it wrong there; this is not a statement of "3.0 came out and then they kept breaking compatibility all the time until 3.3", it's a statement of "3.0 declared what the changes were so people could play with the new APIs, and then 3.1, 3.2 and 3.3 spent time on performance and making porting easier so that people could actually port to and deploy on later 3.x releases".