[Python-ideas] Towards harmony with JavaScript?

[Brendan Barnwell]

On 2017-08-11 07:57, Jason H wrote:
> 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.

	In general I am instinctively opposed to any changes aimed at making 
Python more like JavaScript, because I think that overall Python is a 
much better designed language than JavaScript, and JavaScript has 
numerous profound flaws, so almost anything that makes Python more like 
JavaScript is likely to make it worse.

	In particular, all of the changes you propose are very minor things 
which amount to adding some duplicate or more convenient or 
almost-the-same way to do something that can already be done.  This kind 
of accumulation of confusing alternatives is exactly the kind of thing 
that makes JS suck.  You have == vs ===, for vs for..in vs for..of, 
optional semicolons, and on and on and on.  This is because people did 
not think about the right way to do things the first time in JS, and 
they don't want to break backward compatibility, so they just keep 
adding new features to paper over the deeper problems.  Happily, Python 
avoids the most damaging cases of this, because Python has far fewer 
deep problems, and small problems aren't worth the clutter of having 
multiple ways to do the same thing.

>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. The point
> here is this is

	Was your message truncated here?  "The point here is this is" what?

	In any case, the objection you've already raised is enough to kill this 
proposal for me.  Being able to use a variable for a key is a huge and 
very real difference in functionality between Python and JS.  Being able 
to not type quotes is a small advantage in comparison to that.  You can 
already do dict(a=1, b=2) if you really want to.

> 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.

	I agree it is confusing at first.  Once you know it, you know it. 
Also, adding it to list still wouldn't make it available for tuples, 
dicts, or any other iterables.  (JavaScript "avoided" this problem by 
not providing any way to define your own iterables until 2015, so 
everyone was stuck using plain arrays.)  I do think a case could be made 
for designing a more comprehensive iterable class hierarchy that would 
provide things like this, but just adding a single method to a single 
type isn't worth it.

> 3. Allow C/C++/JS style comments: JS:[ //, /* ] vs Python # This one
> is pretty self-explanatory.

	Again, the gain is tiny.  Python is already quite a readable language. 
  I don't see "make it easily writable for people who don't know Python 
without looking up how to write comments" as a useful goal.  As with 
.join(), once you learn that Python uses #, you know it, and it's not 
really a problem.  Also, as someone else mentioned, // is a valid 
operator in Python, making its use as a comment marker potentially 
ambiguous.

-- 
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no
path, and leave a trail."
    --author unknown