Re: [BangPypers] The Python I would like to see - Armin Ronacher
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
Re: [BangPypers] The Python I would like to see - Armin Ronacher
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 RegardskracekumarTalk 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
Re: [BangPypers] The Python I would like to see - Armin Ronacher
On Tue, Aug 19, 2014 at 1:12 AM, Gora Mohanty g...@mimirtech.com wrote: On 18 August 2014 21:45, chandrakant kumar k.03chan...@gmail.com wrote: Python 3 has been a disappointment. I am bemused by absolutist comments like this. Could you explain how exactly it was a disappointment for you in day-to-day work? I also want to know the reasons. Kushal -- CPython Core Developer http://fedoraproject.org http://kushaldas.in ___ BangPypers mailing list BangPypers@python.org https://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] The Python I would like to see - Armin Ronacher
On Tue, Aug 19, 2014 at 1:12 AM, Gora Mohanty g...@mimirtech.com wrote: On 18 August 2014 21:45, chandrakant kumar k.03chan...@gmail.com wrote: Python 3 has been a disappointment. I am bemused by absolutist comments like this. Could you explain how exactly it was a disappointment for you in day-to-day work? Regards, Gora Following are the problems i faced that made me revert back to Python 2.7 - 1. Lack of packages ported to Python 3, one of the main advantages of using Python is a large set of ready to be used packages, so that you can build something very quickly. 2. Performance is same if not less than that of Python 2.7. If i have to rewrite my code, with limited 3rd party packages, resulting in little or no performance gains, i would rather move to CLISP, at least the performance gains would be worth it. And, about the day-to-day work, i have a SAAS application built with Python 3, and the inconvenience it caused without the rewards, made me regret my decision to move to Python 3. It has more to do with the Python 3 ecosystem, rather than the language itself. Python is much more than the language itself, almost any serious Python application makes heavy use of 3rd party packages. -- regards ___ BangPypers mailing list BangPypers@python.org https://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] The Python I would like to see - Armin Ronacher
On Tue, Aug 19, 2014 at 11:23 AM, Noufal Ibrahim nou...@nibrahim.net.in wrote: On 2014-08-19 11:11, Sriram Narayanan wrote: Hi Noufal, could you elaborate on this? I have enjoyed the freedom of non-static typing that Python and Ruby offer, but also sometimes miss the static type checking that C# and Java offer. Yes. I like the freedom and they're great for prototyping. When things get large with a lot of moving parts, you need to write elaborate tests at every layer to validate the whole thing and even then, things slip through. That's just a question of testing strategy. If you're writing 'elaborate' tests at every layer, you're probably validating too much or exercising too much of the system at each layer of testing. The cartesian product of tests required to validate every implementation at a level of abstraction is inevitable if you want confidence in all those implementations; but these need to be limited to each pair of collaborator as far as possible so that so single test becomes too elaborate. But that's a different discussion altogether. However, I always got the sense that dynamic languages made this both easier and hard at the same time. Easier in that you didn't have to declare explicit interfaces between layers; harder in that all barking ducks are only identified at runtime! I've also felt that the freedom encourages a kind of loose thinking that I have to guard against. I'm glad somebody finally said this; and doubly so that it was Noufal! ;) - d ___ BangPypers mailing list BangPypers@python.org https://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] The Python I would like to see - Armin Ronacher
On 2014-08-19 12:31, Saager Mhatre wrote: That's just a question of testing strategy. If you're writing 'elaborate' tests at every layer, you're probably validating too much or exercising too much of the system at each layer of testing. The cartesian product of tests required to validate every implementation at a level of abstraction is inevitable if you want confidence in all those implementations; but these need to be limited to each pair of collaborator as far as possible so that so single test becomes too elaborate. But that's a different discussion altogether. However, I always got the sense that dynamic languages made this both easier and hard at the same time. Easier in that you didn't have to declare explicit interfaces between layers; harder in that all barking ducks are only identified at runtime! I suppose so. My epiphany was that tests, at the end of the day, are code. They need to be maintained, refactored, cleaned up, optimised, cajoled and worshipped just like one does with the actual application. The less code I write, the better. So, yes, it's a tradeoff. Once upon a time, a more naive version of myself loved the freedom that I got from this kind of thing. The cynical version of myself that's typing this email is not so sure anymore. He, at some level, feels that the extra headache of specifying interfaces is a better investment than using a dynamic language and writing tests to validate all the possible inputs. I'm glad somebody finally said this; and doubly so that it was Noufal! ;) I'm surprised that you've never heard this from me before. It's something that I decided on a LONG time ago. ___ BangPypers mailing list BangPypers@python.org https://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] The Python I would like to see - Armin Ronacher
On Tue, Aug 19, 2014 at 12:45 PM, Noufal Ibrahim nou...@nibrahim.net.in wrote: On 2014-08-19 12:31, Saager Mhatre wrote: That's just a question of testing strategy. If you're writing 'elaborate' tests at every layer, you're probably validating too much or exercising too much of the system at each layer of testing. The cartesian product of tests required to validate every implementation at a level of abstraction is inevitable if you want confidence in all those implementations; but these need to be limited to each pair of collaborator as far as possible so that so single test becomes too elaborate. But that's a different discussion altogether. However, I always got the sense that dynamic languages made this both easier and hard at the same time. Easier in that you didn't have to declare explicit interfaces between layers; harder in that all barking ducks are only identified at runtime! I suppose so. My epiphany was that tests, at the end of the day, are code. They need to be maintained, refactored, cleaned up, optimised, cajoled and worshipped just like one does with the actual application. The less code I write, the better. So, yes, it's a tradeoff. Once upon a time, a more naive version of myself loved the freedom that I got from this kind of thing. The cynical version of myself that's typing this email is not so sure anymore. He, at some level, feels that the extra headache of specifying interfaces is a better investment than using a dynamic language and writing tests to validate all the possible inputs. Hear, hear! All he younglings pay heed, the master hath spoken. Again, glad this was said without beating about the bush; and glad *you* said it! ;) I'm glad somebody finally said this; and doubly so that it was Noufal! ;) I'm surprised that you've never heard this from me before. It's something that I decided on a LONG time ago. I realized this myself a long time ago, around the time I joined TW and started putting Ruby in production. However, all the dynlang love in the air at the time seemed to be blinding people to it. Since then I've sensed this sentiment among those that have grown wiser with age and experience. But you're the first one I've heard call it out without mincing words. - d On 2014-08-19 12:31, Saager Mhatre wrote: That's just a question of testing strategy. If you're writing 'elaborate' tests at every layer, you're probably validating too much or exercising too much of the system at each layer of testing. The cartesian product of tests required to validate every implementation at a level of abstraction is inevitable if you want confidence in all those implementations; but these need to be limited to each pair of collaborator as far as possible so that so single test becomes too elaborate. But that's a different discussion altogether. However, I always got the sense that dynamic languages made this both easier and hard at the same time. Easier in that you didn't have to declare explicit interfaces between layers; harder in that all barking ducks are only identified at runtime! I suppose so. My epiphany was that tests, at the end of the day, are code. They need to be maintained, refactored, cleaned up, optimised, cajoled and worshipped just like one does with the actual application. The less code I write, the better. So, yes, it's a tradeoff. Once upon a time, a more naive version of myself loved the freedom that I got from this kind of thing. The cynical version of myself that's typing this email is not so sure anymore. He, at some level, feels that the extra headache of specifying interfaces is a better investment than using a dynamic language and writing tests to validate all the possible inputs. I'm glad somebody finally said this; and doubly so that it was Noufal! ;) I'm surprised that you've never heard this from me before. It's something that I decided on a LONG time ago. ___ 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
Re: [BangPypers] The Python I would like to see - Armin Ronacher
On 2014-08-19 14:05, Saager Mhatre wrote: [..] I realized this myself a long time ago, around the time I joined TW and started putting Ruby in production. However, all the dynlang love in the air at the time seemed to be blinding people to it. Since then I've sensed this sentiment among those that have grown wiser with age and experience. But you're the first one I've heard call it out without mincing words. [..] I don't want to be misconstrued as taking a side though. I still like dynamic languages for glue kind of work and when I want the dynamism. Scripting rules, places where quick turn around is more important than correctness e.g. elisp for Emacs, perl for quick and dirty text processing and things like that. It's just that apart from a more general use the right tool for the job and everything has it's place attitude, I'm leaning towards actually putting these things in a hierarchy of some kind and saying that X is, on the whole, better than Y rather than just hand waving about how they're all equal. Two points. It's very likely that I'm wrong about this in which case, it's one of those stepping stones that people slip on more often than not and secondly, with all the new work on languages and implementations going on recently, it's a great (and prudent) time to embrace the virtues of being a polyglot programmer. ___ BangPypers mailing list BangPypers@python.org https://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] The Python I would like to see - Armin Ronacher
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. I would love to install single statically linked binaries for deployment. Building these binaries should be very fact also, say less than 1 minute. This is one of the reason I am getting attracted to Golang :-) -- Baiju M ___ BangPypers mailing list BangPypers@python.org https://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] The Python I would like to see - Armin Ronacher
On 19 August 2014 12:32, chandrakant kumar k.03chan...@gmail.com wrote: [...] Following are the problems i faced that made me revert back to Python 2.7 - 1. Lack of packages ported to Python 3, one of the main advantages of using Python is a large set of ready to be used packages, so that you can build something very quickly. This is not a criticism of Python 3 per se. 2. Performance is same if not less than that of Python 2.7. I have not been closely following this, but I did not think that performance was a criterion for Python 3. As I am sure that you are aware, projects like PyPi are addressing this, but again I do not know that performance was ever touted as a Python 3 feature. If i have to rewrite my code, with limited 3rd party packages, resulting in little or no performance gains, i would rather move to CLISP, at least the performance gains would be worth it. And, about the day-to-day work, i have a SAAS application built with Python 3, and the inconvenience it caused without the rewards, made me regret my decision to move to Python 3. [...] Why then did you decide to move to Python 3? Unlike, say major revisions to PHP, most Python people that I have met are happy with 2.7, and there does not seem to me a critical feature like, say improved security, that provides a strong incentive to make the move. Not trying to show you up, but seriously would like to know your rationale. We have been itching to goto Python 3, but the deal-breaker for us was Django not being ready. Now that Django does support Python 3, we did think again about moving, but held off exactly because of what you mention: Lack of Python 3 support in several third-party apps that were critical for us. Regards, Gora ___ BangPypers mailing list BangPypers@python.org https://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] The Python I would like to see - Armin Ronacher
On Tue, Aug 19, 2014 at 9:53 PM, Gora Mohanty g...@mimirtech.com wrote: snip/ We have been itching to goto Python 3, but the deal-breaker for us was Django not being ready. Now that Django does support Python 3, we did think again about moving, but held off exactly because of what you mention: Lack of Python 3 support in several third-party apps that were critical for us. I've suggested to one of my customers that they could sponsor some dev time for helping migrate to Python 3. After some consideration, they moved to Go Lang. Regards, Gora -- Ram ___ BangPypers mailing list BangPypers@python.org https://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] The Python I would like to see - Armin Ronacher
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. 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 :-) 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. Regards, Gora ___ BangPypers mailing list BangPypers@python.org https://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] The Python I would like to see - Armin Ronacher
On 19 August 2014 21:58, Sriram Narayanan sriram...@gmail.com wrote: On Tue, Aug 19, 2014 at 9:53 PM, Gora Mohanty g...@mimirtech.com wrote: snip/ We have been itching to goto Python 3, but the deal-breaker for us was Django not being ready. Now that Django does support Python 3, we did think again about moving, but held off exactly because of what you mention: Lack of Python 3 support in several third-party apps that were critical for us. I've suggested to one of my customers that they could sponsor some dev time for helping migrate to Python 3. After some consideration, they moved to Go Lang. Sorry, but again this makes no sense to outsiders without the context of why such a choice was made, and IMHO leads to pointless flame-wars about my programming language is better than yours when the truth is that they all suck, though in different ways. In this day and age, machines should be doing the grunt work that we seem to still be doing. To revive an ancient meme about whom to credit memorable quotes to: anonDo not write code. Write code that writes code/anon Regards, Gora ___ BangPypers mailing list BangPypers@python.org https://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] The Python I would like to see - Armin Ronacher
On Tuesday, August 19, 2014 at 9:24 PM, Baiju M wrote: I would love to install single statically linked binaries for deployment. Building these binaries should be very fact also, say less than 1 minute. There are multiple solutions to to this. One that twitter uses is called PEX, a concept adopted from the Java world of deployable jars. My thought is, if the deployment environment is under control (like the versions of Python and the access to PyPI and dependency information and versions well established), then the standard python of using pip and requirements is good too. The problem usually lies in out of control dependencies and environment and sometimes we tend to prefer a static binary. -- Senthil Kumaran ___ BangPypers mailing list BangPypers@python.org https://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] The Python I would like to see - Armin Ronacher
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
Re: [BangPypers] The Python I would like to see - Armin Ronacher
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 RegardskracekumarTalk 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
Re: [BangPypers] The Python I would like to see - Armin Ronacher
Python 3 has been a disappointment. regards On Aug 18, 2014 5:21 PM, Navin Pai lifeofna...@gmail.com wrote: An interesting take by Armin Ronacher on what he would like to see in Python: http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/ Can't say I disagree :) Navin Pai ___ 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
Re: [BangPypers] The Python I would like to see - Armin Ronacher
Hi, On Mon, Aug 18, 2014 at 9:45 PM, chandrakant kumar k.03chan...@gmail.com wrote: Python 3 has been a disappointment. http://asmeurer.github.io/python3-presentation/slides.html Here we go. :) Thanks -- Thank you Balachandran Sivakumar Arise Awake and stop not till the goal is reached. - Swami Vivekananda ___ BangPypers mailing list BangPypers@python.org https://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] The Python I would like to see - Armin Ronacher
On 18 August 2014 21:45, chandrakant kumar k.03chan...@gmail.com wrote: Python 3 has been a disappointment. I am bemused by absolutist comments like this. Could you explain how exactly it was a disappointment for you in day-to-day work? Regards, Gora ___ BangPypers mailing list BangPypers@python.org https://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] The Python I would like to see - Armin Ronacher
On 2014-08-18 21:45, chandrakant kumar wrote: Python 3 has been a disappointment. I haven't used it enough to judge (and this has, in my experience, been the case with most critics). However, as the projects I deal with grow larger, I'm becoming increasingly frustrated with Python (and dynamic languages in general). ___ BangPypers mailing list BangPypers@python.org https://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] The Python I would like to see - Armin Ronacher
On Tue, Aug 19, 2014 at 10:06 AM, Noufal Ibrahim nou...@nibrahim.net.in wrote: On 2014-08-18 21:45, chandrakant kumar wrote: Python 3 has been a disappointment. I haven't used it enough to judge (and this has, in my experience, been the case with most critics). However, as the projects I deal with grow larger, I'm becoming increasingly frustrated with Python (and dynamic languages in general). Hi Noufal, could you elaborate on this? I have enjoyed the freedom of non-static typing that Python and Ruby offer, but also sometimes miss the static type checking that C# and Java offer. -- Ram ___ BangPypers mailing list BangPypers@python.org https://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] The Python I would like to see - Armin Ronacher
On 2014-08-19 11:11, Sriram Narayanan wrote: Hi Noufal, could you elaborate on this? I have enjoyed the freedom of non-static typing that Python and Ruby offer, but also sometimes miss the static type checking that C# and Java offer. Yes. I like the freedom and they're great for prototyping. When things get large with a lot of moving parts, you need to write elaborate tests at every layer to validate the whole thing and even then, things slip through. I've also felt that the freedom encourages a kind of loose thinking that I have to guard against. This is completely subjective though and based mostly on vague feelings that have accumulated inside my head over my career trying to tame these computer creatures. ___ BangPypers mailing list BangPypers@python.org https://mail.python.org/mailman/listinfo/bangpypers
