Gosh, I am really late to this party. But it is interesting to see many views (and changes in views) mirroring my own.
To address chandrakant kumar <k.03chan...@gmail.com>'s criticism of Python 3: > 1. Lack of packages ported to Python 3... Take a look at Python 3 Wall of SuperPowers <https://python3wos.appspot.com/>. 83% of packages are green. The rest are mostly work in progress. There is a good chance that all the packages you need are already ported to Python 3. Besides, the incompatibility is the very point. Python 3 is a major version change not because it is big update with dramatic new features, but due to its backward incompatibility. This is a good practice, according to semantic version. API has changed. Language is cleaned up and most of the ugly warts are gone. The upgrade path is quite painless. > 2. Performance is same if not less ... Which wouldn't be surprising considering that it is not a complete rewrite. But each Python 3 release is significantly faster <https://docs.python.org/3.5/whatsnew/3.4.html#significant-optimizations> than the previous one. Iterators are now the default leading to significant savings in memory usage. Often, Python is chosen for its simplicity than speed. > 3, and the inconvenience it caused without the rewards, made me regret my decision to move to Python 3. The reward is supposed to be cleaner code. I have struggled with Unicode handling in Python 2 until I added enough hacks in an web scraping project till I had lost track of the encoding of any given string. That is now a non-issue in Python 3. My latest Django project in Python 3 reads a lot easier thanks to clearer super() syntax and new-style classes. Almost all my Django dependencies except Fabric (being replaced by Ansible) are now Python 3 compatible. There is a much better written article about Python 3 here: http://sealedabstract.com/rants/python-3-is-fine/ In my opinion, Python 3 has become a really viable option in last few months. If you considered it in the past and gave it a miss, then you should definitely check it out again. Cheers, Arun On Wed, Aug 20, 2014 at 5:52 PM, Vishal <vsapr...@gmail.com> wrote: > Dear All, > > Interesting to note that this same point (about instantiating multiple > interpreters was raised on our mailing list...about 3-4 years back).... > by Yours Truly :)) > > See the mail chain titled: *"Ideas for Python concurrency..."* > > Life is coming full circle :) > > Take care, > Vishal Sapre > > > > Thanks and best regards, > Vishal Sapre > > --- > Please DONT print this email, unless you really need to. Save Energy & > Paper. Save the Earth. > > > On Wed, Aug 20, 2014 at 2:09 AM, kracekumar ramaraju < > kracethekingma...@gmail.com> wrote: > > > Hi > > > > I am late to the party, adding my thoughts. > > > > - It is good to have Python spec and implementation decoupled from each > > other. By that it would be possible to have different run time. Lot of > > people say rust memory management is good, so someone can implement > Python > > in rust. Though library compatibility and C code integration will be > always > > an issue. > > > > - In my opinion other than logical error most of the error I have > > encountered working with Python is passing dict to function where model > > object was expected and KeyError. Though KeyError in dict can be avoided > by > > using .get and other technique. Still I haven't figured linter for > > Emacs/Sublime which can notify about the type of the argument. Yes, I am > > aware of function annotation in Python 3, but I can't see linter/IDE > which > > has integrated this. When I pass wrong type argument I would like to see > > hint in the editor. Without function annotation in python 2.7 it is > harder > > to make linter aware of types. Though docstring can help to solve this > > issue but not completely. > > > > - Though pip, venv solve issue to certain extent. If there are 100+ > > packages need to be installed, pip will take atleast 60 - 90 seconds to > > check all the packages are installed considering venv have all packages > > (AWS). Then deploy will look like code deploy + package install + restart > > of service. There are high chances request may pile up if restart of > > service takes more than 30 - 40 seconds if the app is single page app > > (Initial load during peak hours). Also if PyPi is down my deployment will > > fail, having PyPi mirror isn't affordable. So far I haven't faced any > issue > > with PyPi, but there were times when npmjs.org is down :-) Yes you can > > package all your dependencies in .deb files and distribute but there is a > > cost associated with it. With golang style of deployment all the > > installation time and packaging issue is solved with single binary. > > > > +1 for https://talks.golang.org/2012/zen.slide#1. > > > > - At some point I was looking into PEX for deployment, felt it isn't > ready > > yet, probably will try once again. > > > > > > > > > > > > > > > > > > On Wed, Aug 20, 2014 at 1:14 AM, Baiju M <baiju.m.m...@gmail.com> wrote: > > > > > On Tue, Aug 19, 2014 at 9:42 PM, Gora Mohanty <g...@mimirtech.com> > > wrote: > > > > On 19 August 2014 21:24, Baiju M <baiju.m.m...@gmail.com> wrote: > > > >> > > > >> I would like to add one point about deployment of large and complex > > > >> applications written in Python. Deployment of these types of > > > applications > > > >> are very difficult in Python. > > > > > > > > Would you please elaborate on the difficulties? We are reasonably > > > > happy with AWS images to bootstrap the system, then virtualenv, pip, > > > > fabric and now ansible to deploy Django apps. > > > > > > Using cloud based images, orchestration tools like Ansible, container > > > technologies like Docker all helps to make application deployment > easier. > > > However, it's still complex compared to copying a single binary and > > > running it. > > > > > > >> I would love to > > > install single statically > > > >> linked binaries for deployment. Building these binaries should be > very > > > fact > > > >> also, say less than 1 minute. > > > > > > > > Statically-linked binaries are so 1990s :-) > > > > > > Modern languages like Rust ( http://www.rust-lang.org/ ) & Go ( > > > http://golang.org/ ) > > > seems to produce statically linked binaries by default. > > > > > > > > > > >> This is one of the > > reason > > > I am getting > > > >> attracted to Golang :-) > > > > > > > > For me, the main attraction of Go is the concurrency features. Syntax > > > still > > > > seems strange, though. > > > > > > I felt Go more Pythonic :) > > > > > > https://talks.golang.org/2012/zen.slide#1 > > > > > > Regards, > > > Baiju M > > > _______________________________________________ > > > BangPypers mailing list > > > BangPypers@python.org > > > https://mail.python.org/mailman/listinfo/bangpypers > > > > > > > > > > > -- > > > > *Thanks & Regardskracekumar"Talk is cheap, show me the code" -- Linus > > Torvaldshttp://kracekumar.com <http://kracekumar.com>* > > _______________________________________________ > > BangPypers mailing list > > BangPypers@python.org > > https://mail.python.org/mailman/listinfo/bangpypers > > > _______________________________________________ > BangPypers mailing list > BangPypers@python.org > https://mail.python.org/mailman/listinfo/bangpypers > _______________________________________________ BangPypers mailing list BangPypers@python.org https://mail.python.org/mailman/listinfo/bangpypers
