> -----Original Message----- > From: Python-ideas [mailto:python-ideas-bounces+tritium- > list=sdamon....@python.org] On Behalf Of Jason H > Sent: Friday, August 11, 2017 10:58 AM > To: python-ideas@python.org > Subject: [Python-ideas] Towards harmony with JavaScript? > > Before I done my firesuit, I'd like to say that I much prefer python and I rail > on JS whenever I can. However these days it is quite common to be doing > work in both Python and Javascript. Harmonizing the two would help JS > developers pick up the language as well as people like me that are stuck > working in JS as well. > > TIOBE has Python at 5 and JS at 8 https://www.tiobe.com/tiobe-index/ > Redmonk: 1 and 1, respectively > http://redmonk.com/sogrady/2017/06/08/language-rankings-6-17/ > PYPL: 2 and 5 respectively http://pypl.github.io/PYPL.html > > While JS is strongly for web (Node.JS, Browsers) and Python has a weak > showing (Tornado, Flask),
And Django and pyramid. And don't forget youtube. Python has NO weakness on the web. > Python is very popular on everything else on the > backend where JS isn't and isn't likely to be. The I'm making point is not to > choose a 'winner', but to make the observation that: given that the tight > clustering of the two languages there will be considerable overlap. People > like me are asked to do both quite frequently. So I'd like a little more > harmony to aid in my day-to-day. I have just as many python files as JS files > open in my editor at this moment. > > There are several annoyances that if removed, would go a long way. > 1. Object literals: JS: {a:1} vs Python: {'a':1} > Making my fingers dance on ' or " is not a good use of keystrokes, and it > decreases readability. However a counter argument here is what about > when the a is a variable? JS allows o[a] as a way to assigned to a property that > is a variable. Python of course offers functions that do this, but for simple > objects, this would very much be appreciated. Been discussed. Python will not make the same design flaw as JS in this case. If you really want bare keys, do `dict(a=1)` > The point here is this is > > 2. Join: JS: [].join(s) vs Python: s.join([]) > I've read the justification for putting join on a string, and it makes sense. > But I think we should put it on the list too. Again, design decision python actually got right - you don't have to implement a join method, you just have to pass an iterable of strings to the one join method. There is no question as to if an iterable of strings has a join method - as long as its iterable, it's joinable. This too has been discussed ad nauseum, and is not going to change. > > 3. Allow C/C++/JS style comments: JS:[ //, /* ] vs Python # > This one is pretty self-explanatory. > // is valid python syntax (for an operator) - that makes the parser a pain to implement. I don't actually see any value at all in unifying the comment characters... its not like this is Windows Batch, where the comment character is `REM` - # is used in a metric ton of languages. > Some might want even more harmony, but I don't know the repercussions of > all of that. I think the above could be implemented without breaking > anything. What I do know is that 85% of my friction would be removed if the > above were implemented. > > > > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/