<div dir="ltr">Thank you everybody for all pieces of information, very interesting.<div><br></div><div>I reply to everybody in the same e-mail:</div><div><br></div><div>1. For Python 3 usage: Where I work, we switched all new projects to Python 3 since almost one year. To be honest with you, it wasn't to be up-to-date, but it was for a new feature not natively present in Python 2: AsyncIO. We made a lot of Twisted (Telephony+WebSockets) and Django/Flask daemons (WebServices), but I wanted to:</div><div> A. Create daemons all-in-one (Telephony+WebSockets+WebServices) to share easier our business logic for a same project.</div><div> B. Simplify architecture: Twisted and Django are very complicated for our simple needs.</div><div>The side effects are:</div><div> A. Our productivity is better, we finish quicker our projects for our clients, because we share more source code and the architecture is simpler to handle.</div><div> B. The performances we have are better compare to the past.</div><div><br></div><div>Why I tell you that ? To give you a concrete example: if you want to motivate Python developers from the battlefield to migrate to Python 3, you need to add features/performances/... in Python 3. Not add all PyPI libraries in CPython, but add features you can't add easily via a library, like yield from, AsyncIO or Type Hinting.</div><div><br></div><div>On production systems, who cares is Python 2/3, Go, Erlang... ? Certainly not clients and even management people. If you want that we use Python 3, please give us arguments to "sell" the migration to Python 3 in the company.</div><div><br></div><div>2. For Python 3 deployment: I use Pythonz: <a href="https://github.com/saghul/pythonz">https://github.com/saghul/pythonz</a> to quickly deploy a Python version on a new server with an Ansible recipe.</div><div>Certainly, some sys admins could be shocked by this behaviour because it's forbidden in packaging religion, but who cares ? We lose less time to deploy, it's more reproducible between dev environment and production, and upgrades are very easy via Ansible.</div><div><br></div><div>3. About PyPy usage: I've made some benchmarks with the same WebService between a Flask daemon on PyPy and an AsyncIO daemon on CPython, it was very interesting: Compare to our needs, asynchronous pattern give us more performance that PyPy.</div><div>Yes, I know, I've compared apples with pears, but at the end, I only want how many customers I can stack on the same server. More I stack, less it costs for my company.</div><div>I'm waiting Python 3.3 support in PyPy to push that on production with a real daemon. No AsyncIO, No PyPy.</div><div><br></div><div>4. About Python performance: Two things changed my mind about the bias "Python is slow":</div><div> A. Python High Performance: <a href="http://shop.oreilly.com/product/0636920028963.do">http://shop.oreilly.com/product/0636920028963.do</a><br></div><div> B. Web Framework Benchmarks: <a href="http://www.techempower.com/benchmarks/">http://www.techempower.com/benchmarks/</a></div><div>Especially with B.: this benchmark isn't the "truth", but at least, you can compare a lot of languages/frameworks based on examples more closer than my use cases, compare to others benchmarks.</div><div>But, for example, if you compare Python frameworks with Erlang frameworks on "multiple queries", you can see that, in fact, Python is very good.</div><div>In my mind, Erlang is very complicated to code compare to Python, but you'll have better performances in all cases, I had a wrong opinion.</div><div>Finally, everybody has bias about programming languages performance.</div><div><br></div><div>5. Type Hinting - Performance booster (the first goal of my e-mail): Thank you Guido, your example is clear.</div><div>I understand that it will be step-by-step, it's a good thing. I took the liberty to send an e-mail, because I didn't sure to understand correctly the global roadmap.</div><div>I'm the first to understand that it's very difficult, and maybe that CPython will never use Type Hinting to improve performances, because it isn't really simple to implement.</div><div>I'm pretty sure I can't help you to implement that, but at least, I can promote to others.</div><div><br></div><div>Thank you everybody again for your attention.</div><div><br></div><div><span style="color:rgb(38,38,38);font-size:12.8000001907349px;line-height:16px">Met vriendelijke groeten,</span><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">--<br>Ludovic Gasc</div></div>
<br><div class="gmail_quote">On Mon, Dec 22, 2014 at 6:06 PM, Sturla Molden <span dir="ltr"><<a href="mailto:sturla.molden@gmail.com" target="_blank">sturla.molden@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 22/12/14 17:42, Nick Coghlan wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
a) communicate the potential of these tools effectively to new Python users<br>
b) ensure these tools are readily available to them (without turning<br>
into a build nightmare)<br>
</blockquote>
<br></span>
For b), Anaconda by Continuum Analytics and Canopy by Enthought are doing a great job.<br>
<br>
But today it is also possible to create a minimalistic environment with only a few 'pip install' commands.<br>
<br>
It is not a build nightmare anymore.<div class="HOEnZb"><div class="h5"><br>
<br>
Sturla<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/<u></u>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/<u></u>codeofconduct/</a><br>
</div></div></blockquote></div><br></div>