[Python-ideas] Towards harmony with JavaScript?

[Alex Walters]

> -----Original Message-----
> From: Python-ideas [mailto:python-ideas-bounces+tritium-
> list=sdamon.com at python.org] On Behalf Of Jason H
> Sent: Friday, August 11, 2017 10:58 AM
> To: python-ideas at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/