[BangPypers] "The Python I would like to see" - Armin Ronacher
Arun Ravindran
arunvr at gmail.com
Sun Aug 24 23:45:17 CEST 2014
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.03chandra at 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 <vsapre80 at 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 <
> kracethekingmaker at 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.mail at gmail.com> wrote:
> >
> > > On Tue, Aug 19, 2014 at 9:42 PM, Gora Mohanty <gora at mimirtech.com>
> > wrote:
> > > > On 19 August 2014 21:24, Baiju M <baiju.m.mail at 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 at 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 at python.org
> > https://mail.python.org/mailman/listinfo/bangpypers
> >
> _______________________________________________
> BangPypers mailing list
> BangPypers at python.org
> https://mail.python.org/mailman/listinfo/bangpypers
>
More information about the BangPypers
mailing list