Hi Jason, and welcome!
On Fri, Aug 11, 2017 at 04:57:46PM +0200, 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.
I must say you're a brave man for coming here with a plan which is going
to be read as "Let's make Python worse!".
Have you considered going to the Javascript forums and suggesting that
they harmonise their language to be more like Python? After all:
- Python came first (1991 versus 1995);
- Python is already one of the stated influences on Javascript;
- whereas most of Javascript's influence on Python (the language)
can be summed up as "whew, we avoided making that silly mistake!"
(the world of web frameworks may be more kind to JS);
- according to the "popularity" links you give (and others!) Python
is more popular than Javascript.
> 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.
I disagree -- it *increases* readability, because I can always tell the
difference between a literal string key and a name. I don't have to try
to do a whole-program analysis of the entire application in my head to
work out whether {a: 1} refers to a name or the literal string 'a'.
{address: "123 Main Street"}
*always* refers to the variable address, while:
{"address": "123 Main Street"}
*always* refers to the literal string "address".
Or worse... if you're suggesting that Python should make the
backwards-incompatible change that {address: ...} should always be the
literal string key, thus breaking millions of working programs, just to
save two keystrokes, sorry, that isn't going to happen.
If you wish to avoid typing quotes, and your keys are valid identifiers,
you can use the dict constructor with keyword arguments:
dict(address="123 Main Street")
> 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.
And tuples, and dicts, and sets, and deques, and iterators, and
generators, and strings, and bytes, and bytearrays, and arrays, and
every other iterable type, including people's custom ones.
No thank you. We don't need that enormous amount of code duplication and
documentation bloat just for the sake of OOP syntactic purity.
Or worse... we add it *just* to lists, not other iterables, and then
we're confused why
values.join(sep)
sometimes works and sometimes fails. The obvious fix is clearly:
if isinstance(values, list):
values.join(sep)
else:
sep.join(values)
but that has an unnecessary isinstance check and can be re-written as:
sep.join(values)
guaranteed to work for any well-behaved iterable, regardless of whether
it is a list or not.
> 3. Allow C/C++/JS style comments: JS:[ //, /* ] vs Python #
> This one is pretty self-explanatory.
What's not self-explanatory is why on earth you would want to type two
characters // instead of one # ?
Besides, // is already valid syntax in Python. Consider:
result = x // 2 + y // -2
> but I don't know the repercussions of all of that. I think the above
> could be implemented without breaking anything.
It would break lots.
--
Steve
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
