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), 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. 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. 3. Allow C/C++/JS style comments: JS:[ //, /* ] vs Python # This one is pretty self-explanatory. 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.
-----Original Message----- From: Python-ideas [mailto:python-ideas-bounces+tritium- list=sdamon.com@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),
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
And Django and pyramid. And don't forget youtube. Python has NO weakness on the web. 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.
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
// 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. 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/
On Sat, Aug 12, 2017 at 12:57 AM, Jason H <jhihn@gmx.com> 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.
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), 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.
Python has a number of strong web frameworks - Django is probably the best known.
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. The point here is this is
Disagreed. Python is both more consistent and more flexible than JS here. More flexible in that dict keys can be any hashable type, where JS object properties are always strings; and more consistent in that a value is always represented the same way. Consider literals and variables as dict keys in Python: # Literal d = {'a': 1} print(d['a']) d['a'] = 2 # Variable key = 'a' d = {key: 1} print(d[key]) d[key] = 2 Contrast JS: // Literal d = {a: 1} console.log(d.a) d.a = 2 // Variable key = 'a' d = {[key]: 1} console.log(d[key]) d[key] = 2 In Python, a literal string is always in quotes, and an unquoted symbol is always a name lookup. In JS, you can use the shorthand of dot notation for literals that are valid symbols, but to use a variable, you need to switch syntax. (To be fair, this is simply adding a shorthand that Python doesn't have; you could use square brackets and string literals in JS too. But people don't do that, so a programmer has to know to read it using dot notation primarily.) Coupled with the increased flexibility in what you can have in a dict key, Python's requirement to quote keys is a small price to pay for consistency.
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.
This might be safe to add; but it needs to be well worth adding, since it's just a different spelling for the exact same thing. -0.
3. Allow C/C++/JS style comments: JS:[ //, /* ] vs Python # This one is pretty self-explanatory.
If you'd asked for this a few years ago, maybe, but since // is a division operator, that part of it won't fly. Possibly /* comments */ could be added though. That's about all that I'd support adding, though. ChrisA
Thank for all the feedback so far, even if it's not the most enthusiastic response to the ideas. One thing I missed, and I don't know how I could (total face-palm) is: 4. Other list methods: i.e. and specifically: [].push(item) vs [].append()
Sent: Friday, August 11, 2017 at 10:57 AM From: "Jason H" <jhihn@gmx.com> 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), 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. 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.
3. Allow C/C++/JS style comments: JS:[ //, /* ] vs Python # This one is pretty self-explanatory.
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/
On Sat, Aug 12, 2017 at 1:35 AM, Jason H <jhihn@gmx.com> wrote:
Thank for all the feedback so far, even if it's not the most enthusiastic response to the ideas.
One thing I missed, and I don't know how I could (total face-palm) is: 4. Other list methods: i.e. and specifically: [].push(item) vs [].append()
Like [].join, this is simply adding a duplicate spelling for something that already exists. That means that everyone who reads Python code would have to know both forms. That's not a good use of programmer time. And unlike [].join, it's purely a duplicate keyword, not giving you even the benefit of writing something in either order. So I'm definitely -1 on this. Have you considered making JS more like Python instead of the other way around? You can mess with core data types in JS, adding methods to them. For example: String.prototype.join = function(arr) { return arr.join(this); } var strings = ["Hello", "world"]; console.log(" ".join(strings)); That doesn't require any core language changes, and will cover most of your issues. (You can simply choose to always use quoted strings for JS keys, for instance.) You can't implement #comment but you can do all the rest. Try that for a while, and then see how people like it who collaborate with you. That's really the key. ChrisA
"Jason" == Jason H <jhihn@gmx.com> writes:
Jason> While JS is strongly for web (Node.JS, Browsers) and Python has a weak Jason> showing (Tornado, Flask), Python is very popular on everything else on Jason> the backend where JS isn't and isn't likely to be. The I'm making Jason> point is not to choose a 'winner', but to make the observation that: Jason> given that the tight clustering of the two languages there will be Jason> considerable overlap. People like me are asked to do both quite Jason> frequently. So I'd like a little more harmony to aid in my Jason> day-to-day. I have just as many python files as JS files open in my Jason> editor at this moment. I too do much work on both "sides" Jason> There are several annoyances that if removed, would go a long way. Jason> 1. Object literals: JS: {a:1} vs Python: {'a':1} Jason> Making my fingers dance on ' or " is not a good use of keystrokes, Jason> and it decreases readability. However a counter argument here is what Jason> about when the a is a variable? JS allows o[a] as a way to assigned to Jason> a property that is a variable. Python of course offers functions that Jason> do this, but for simple objects, this would very much be appreciated. Jason> The point here is this is Jason> 2. Join: JS: [].join(s) vs Python: s.join([]) Jason> 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. Jason> 3. Allow C/C++/JS style comments: JS:[ //, /* ] vs Python # Jason> This one is pretty self-explanatory. Other friction points to me are (just to name a few): * when you have to check if a variable contains a string, you have to check for both "typeof foo == 'string'" and "foo instanceof String" * you cannot use negative indexes on Array * when you want to know the length of a sized object you have to know (and to remember) how to ask it: Array has .length, newer Map and Set objects have .size For the goal of reducing the friction (the mind switching when working with both the languages) I have created a tool ( https://github.com/azazel75/metapensiero.pj ) which allows me to write valid Python and translates this to nice JS while taking care of most of these nuances. At the same time it doesn't raise any barrier between the translated code and any other JS library around (and I use them a lot). When I created I wasn't unsure if the goal was worthy, but after developing some large library with it I must say than I'm quite happy using it and that I had positive feedbacks from other developers. I suggest you to take a look at it. cheers, Alberto
On Sat, Aug 12, 2017 at 3:04 AM, Alberto Berti <alberto@metapensiero.it> wrote:
For the goal of reducing the friction (the mind switching when working with both the languages) I have created a tool ( https://github.com/azazel75/metapensiero.pj ) which allows me to write valid Python and translates this to nice JS while taking care of most of these nuances. At the same time it doesn't raise any barrier between the translated code and any other JS library around (and I use them a lot).
What do you do about all the places where the languages have significantly different semantics? For instance, a Python integer can store more values than a Python float (which is broadly compatible with a JS Number), but in JS, bitwise operations restrict the value to 32-bit. And subscripting or iterating over a string containing astral (non-BMP) characters will do different things. Or when you use non-string keys in a dictionary (notably integers). Transpiling is an extremely dangerous thing to do a partial job of. ChrisA
"Chris" == Chris Angelico <rosuav@gmail.com> writes:
Chris> On Sat, Aug 12, 2017 at 3:04 AM, Alberto Berti <alberto@metapensiero.it> wrote: >> For the goal of reducing the friction (the mind switching when working >> with both the languages) I have created a tool ( >> https://github.com/azazel75/metapensiero.pj ) which allows me to write >> valid Python and translates this to nice JS while taking care of most of >> these nuances. At the same time it doesn't raise any barrier between the >> translated code and any other JS library around (and I use them a lot). Chris> What do you do about all the places where the languages have Chris> significantly different semantics? For instance, a Python integer can Chris> store more values than a Python float (which is broadly compatible Chris> with a JS Number), but in JS, bitwise operations restrict the value to Chris> 32-bit. As of now, I do nothing. As I said, the goal of the tool is not to shield you from JS, for this reason it's not meant for beginners (in both JS or Python). You always manipulate JS objects, but allows you to to be naive on all that plethora of JS idiosyncrasies (from a Python pow at least) that you have to think about when you frequently switch from python to js. Because such list of idiosyncrasies may be subjective, I hope to add to it a kind of "layered" translation where the user can add its own set of rules and/or runtime checking or conversion. I've helped porting macropy ( https://github.com/azazel75/macropy ) especially for the purpose of simplify AST manipulation, but it's not done yet. Chris> And subscripting or iterating over a string containing astral Chris> (non-BMP) characters will do different things. This is strange... i tested it with javascripthon embedded interpreter (which is ES5 compatible) and it indeed shows that for example the string '😼😼😼😼😼' isn't correctly (in the python sense) iterated over but testing it on an ES6 compatible interpreter (more or less latest V8) does the right thing. Something has changed between the two. Chris> Or when you use Chris> non-string keys in a dictionary (notably integers). you should use a Map in such case, as the tool doesn't reimplement most of the Python data api. That would mean build some wrapping type that maybe would simplify converting existing Python code to run on JS, but that would probably mean a more difficult interfacing with JS third party libraries (React, Angular, name your here) that i don't want to reimplement... See here ( https://github.com/azazel75/metapensiero.pj/issues/19 ) for a brief discussion on this matter. Chris> Transpiling is an Chris> extremely dangerous thing to do a partial job of. Even breathing can be dangerous in some environments... Bridging two different concepts together is always a partial job... Again, the use case may seem minimal to you but I can assure that it helps on the day to day work with JS.
On Sat, Aug 12, 2017 at 5:13 AM, Alberto Berti <alberto@metapensiero.it> wrote:
Chris> What do you do about all the places where the languages have Chris> significantly different semantics? For instance, a Python integer can Chris> store more values than a Python float (which is broadly compatible Chris> with a JS Number), but in JS, bitwise operations restrict the value to Chris> 32-bit.
As of now, I do nothing. As I said, the goal of the tool is not to shield you from JS, for this reason it's not meant for beginners (in both JS or Python). You always manipulate JS objects, but allows you to to be naive on all that plethora of JS idiosyncrasies (from a Python pow at least) that you have to think about when you frequently switch from python to js.
Chris> Transpiling is an Chris> extremely dangerous thing to do a partial job of.
Even breathing can be dangerous in some environments... Bridging two different concepts together is always a partial job...
Again, the use case may seem minimal to you but I can assure that it helps on the day to day work with JS.
Speaking as someone whose day job is teaching Python and JavaScript, I don't like the idea of this kind of thing. You're bringing (some) Python syntax, but sticking to JS semantics. That means your source code looks like Python, but runs like JS. You can't afford to ever run it through a Python interpreter (the semantics will be wrong). There's already plenty of confusion in the world. I don't want to add more. It would be far better to base your language on JS syntax, since it's using JS semantics; just add in a handful of Python features that you really miss. ChrisA
On 11 August 2017 at 16:19, Chris Angelico <rosuav@gmail.com> wrote:
On Sat, Aug 12, 2017 at 5:13 AM, Alberto Berti <alberto@metapensiero.it> wrote:
Chris> What do you do about all the places where the languages have Chris> significantly different semantics? For instance, a Python
integer can
Chris> store more values than a Python float (which is broadly
compatible
Chris> with a JS Number), but in JS, bitwise operations restrict the
value to
Chris> 32-bit.
As of now, I do nothing. As I said, the goal of the tool is not to shield you from JS, for this reason it's not meant for beginners (in both JS or Python). You always manipulate JS objects, but allows you to to be naive on all that plethora of JS idiosyncrasies (from a Python pow at least) that you have to think about when you frequently switch from python to js.
Chris> Transpiling is an Chris> extremely dangerous thing to do a partial job of.
Even breathing can be dangerous in some environments... Bridging two different concepts together is always a partial job...
Again, the use case may seem minimal to you but I can assure that it helps on the day to day work with JS.
Speaking as someone whose day job is teaching Python and JavaScript, I don't like the idea of this kind of thing. You're bringing (some) Python syntax, but sticking to JS semantics. That means your source code looks like Python, but runs like JS. You can't afford to ever run it through a Python interpreter (the semantics will be wrong).
There's already plenty of confusion in the world. I don't want to add more. It would be far better to base your language on JS syntax, since it's using JS semantics; just add in a handful of Python features that you really miss.
Well,I hope you both had at least skimmed over "brython" - it started a couple years ago with somewhat the same "won't o full Python purpose" - but nowadays they have a very conformant implementation of Python3 that is transpiled client-side into working javascript. (It does use some JS third party library to be able to implement Python integers, for example - but I think one can use a "pragma" like statement to use "native" numbers for performance) http://brython.info ChrisA
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Sat, Aug 12, 2017 at 5:42 AM, Joao S. O. Bueno <jsbueno@python.org.br> wrote:
Well,I hope you both had at least skimmed over "brython" - it started a couple years ago with somewhat the same "won't o full Python purpose" - but nowadays they have a very conformant implementation of Python3 that is transpiled client-side into working javascript.
(It does use some JS third party library to be able to implement Python integers, for example - but I think one can use a "pragma" like statement to use "native" numbers for performance)
I'm aware of Brython; its purpose is not to let you use JS semantics with Py syntax, but to let you run Python code in a web browser, with full Python semantics. You'll also find PyPyJS, which does a similar job - it uses JS code as a form of machine code, JIT compiling to JS. Taking this off the list as it's no longer on topic. ChrisA
Taking this off the list as it's no longer on topic.
not totally -- I'm going to add my thoughts: 1) If you want a smoother transition between server-side Python and in-browser code, maybe you're better off using one of the "python in the browser" solutions -- there are at least a few viable ones. 2) a javascript "object" is quite a different beast than a pyton dict, dispite similar syntax for a literal. Making the literals even more similar would simpily add confusion. a JS object is a bit more like a types.SimpleNamespace in python, actually. Making Python look a bit more like JS is NOT a good goal! -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 12 August 2017 at 06:10, Chris Barker <chris.barker@noaa.gov> wrote:
Taking this off the list as it's no longer on topic.
not totally -- I'm going to add my thoughts:
1) If you want a smoother transition between server-side Python and in-browser code, maybe you're better off using one of the "python in the browser" solutions -- there are at least a few viable ones.
More experimentally, there's also toga's "web" backend (which allows you to take an application you developed with the primary intention of running it as a rich client application on mobile or desktop devices, and instead publishing it as a Django web application with a JavaScript frontend). Essentially, the relationship we see between Python and JavaScript is similar to the one that exists between Python and C/C++/Rust/Go/etc, just on the side that sits between the Python code and the GUI, rather than between the Python code and the compute & storage systems. As such, there are various libraries and transpilers that are designed to handle writing the JavaScript *for* you (bokeh, toga, JavaScripthon, etc), and the emergence of WASM as a frontend equivalent to machine code on the backend is only going to make the similarities in those dynamics more pronounced. In that vein, it's highly *un*likely we'd add any redundant constructs to Python purely to make it easier for JS developers to use JS idioms in Python instead of Pythonic ones, but JavaScript *is* one of the languages we look at for syntactic consistency when considering potential new additions to Python. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Alberto, CoffeeScript is a popular language that is widely considered to represent JavaScript's best bits, and it only has anonymous functions, so there's a large part of the JS community that disagrees with you there. Browsers actually do identify anonymous functions, based on the variable/property names that reference them, so the following function would be identified as `square` in tracebacks: let square = function(x) { return x * x }; In any case, passing anonymous functions to higher order functions is commonplace in real-world JS. Chris may be right about using decorators as a Pythonic alternative [I haven't really considered that properly to be honest], but you can't just tell people not to do something that they see as elegant and idiomatic. Best -- Carl Smith -- Carl Smith carl.input@gmail.com On 12 August 2017 at 17:22, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 12 August 2017 at 06:10, Chris Barker <chris.barker@noaa.gov> wrote:
Taking this off the list as it's no longer on topic.
not totally -- I'm going to add my thoughts:
1) If you want a smoother transition between server-side Python and in-browser code, maybe you're better off using one of the "python in the browser" solutions -- there are at least a few viable ones.
More experimentally, there's also toga's "web" backend (which allows you to take an application you developed with the primary intention of running it as a rich client application on mobile or desktop devices, and instead publishing it as a Django web application with a JavaScript frontend).
Essentially, the relationship we see between Python and JavaScript is similar to the one that exists between Python and C/C++/Rust/Go/etc, just on the side that sits between the Python code and the GUI, rather than between the Python code and the compute & storage systems.
As such, there are various libraries and transpilers that are designed to handle writing the JavaScript *for* you (bokeh, toga, JavaScripthon, etc), and the emergence of WASM as a frontend equivalent to machine code on the backend is only going to make the similarities in those dynamics more pronounced.
In that vein, it's highly *un*likely we'd add any redundant constructs to Python purely to make it easier for JS developers to use JS idioms in Python instead of Pythonic ones, but JavaScript *is* one of the languages we look at for syntactic consistency when considering potential new additions to Python.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
"Chris" == Chris Angelico <rosuav@gmail.com> writes:
Chris> Speaking as someone whose day job is teaching Python and Chris> JavaScript, I have some "I'm a good teacher" stickers laying somewhere, do you want me to send them to you so you can put them somewhere? Chris> I don't like the idea of this kind of thing. You're bringing (some) Chris> Python syntax, but sticking to JS semantics. That means your source Chris> code looks like Python, but runs like JS. You can't afford to ever run Chris> it through a Python interpreter (the semantics will be wrong). Not always, The tool has a bunch of tests that do evaluate some code with the two interpreters and then check the results. To some degree it works... Chris> There's already plenty of confusion in the world. I don't want to add Chris> more. YOU don't want to add? :-) Chris> It would be far better to base your language on JS syntax, since Chris> it's using JS semantics; just add in a handful of Python features that Chris> you really miss. It's not really so confusing, most code I wrote with it it's perfectly understandable Python code. For me, one thing is the language, one other thing are the libraries or the builtin classes it's usually shipped with. The tool reads valid Python and writes valid ES6 JavaScript. As the documentation states, it allows you to retain most of Python language semantics (like for example you can have a working try...except...finally statement, instead of what vanilla JS gives you) and some of the library semantics. nothing more, nothing less.
On Sat, Aug 12, 2017 at 6:31 AM, Alberto Berti <alberto@metapensiero.it> wrote:
It's not really so confusing, most code I wrote with it it's perfectly understandable Python code. For me, one thing is the language, one other thing are the libraries or the builtin classes it's usually shipped with.
The tool reads valid Python and writes valid ES6 JavaScript. As the documentation states, it allows you to retain most of Python language semantics (like for example you can have a working try...except...finally statement, instead of what vanilla JS gives you) and some of the library semantics. nothing more, nothing less.
Hold on. Make up your mind:
As of now, I do nothing. As I said, the goal of the tool is not to shield you from JS, for this reason it's not meant for beginners (in both JS or Python). You always manipulate JS objects, but allows you to to be naive on all that plethora of JS idiosyncrasies (from a Python pow at least) that you have to think about when you frequently switch from python to js.
Do you "retain most of Python language semantics", or do you "always manipulate JS objects"? As shown in a previous post, there are some subtle and very dangerous semantic differences between the languages. You can't have it both ways. ChrisA
Python is not a good fit for the browser, in part, because of the syntax. JavaScript has issues, but its syntax is better suited to creating GUIs in the browser. For example, in browsers everything revolves around a single threaded event loop, so you have a lot of callbacks and event handlers, which makes function expressions really useful, but Python doesn't have expressions that contain blocks, because of significant indentation. As a result, ordinary JS, like this... $(function(){ $("spam").click(function(){ alert("spam clicked") }) }); ...ends up looking like this... def on_ready(): def click_handler(): alert("spam clicked") jQuery("spam").click(click_handler) jQuery(on_ready) JS semantics means JS libraries, which have APIs that assume JS syntax. Python library developers make heavy use of language specific features to define elegant, Pythonic APIs, which is a big part of what makes the language so nice to use. -- Carl Smith carl.input@gmail.com On 11 August 2017 at 21:58, Chris Angelico <rosuav@gmail.com> wrote:
On Sat, Aug 12, 2017 at 6:31 AM, Alberto Berti <alberto@metapensiero.it> wrote:
It's not really so confusing, most code I wrote with it it's perfectly understandable Python code. For me, one thing is the language, one other thing are the libraries or the builtin classes it's usually shipped with.
The tool reads valid Python and writes valid ES6 JavaScript. As the documentation states, it allows you to retain most of Python language semantics (like for example you can have a working try...except...finally statement, instead of what vanilla JS gives you) and some of the library semantics. nothing more, nothing less.
Hold on. Make up your mind:
As of now, I do nothing. As I said, the goal of the tool is not to shield you from JS, for this reason it's not meant for beginners (in both JS or Python). You always manipulate JS objects, but allows you to to be naive on all that plethora of JS idiosyncrasies (from a Python pow at least) that you have to think about when you frequently switch from python to js.
Do you "retain most of Python language semantics", or do you "always manipulate JS objects"? As shown in a previous post, there are some subtle and very dangerous semantic differences between the languages. You can't have it both ways.
ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
"Carl" == Carl Smith <carl.input@gmail.com> writes:
Carl> Python is not a good fit for the browser, in part, because of the syntax. Carl> JavaScript has issues, but its syntax is better suited to creating GUIs in Carl> the browser. Just so? Carl> For example, in browsers everything revolves around a single Carl> threaded event loop, so you have a lot of callbacks and event Carl> handlers, You can write applications full of callbacks using libraries like Twisted or even asyncio and you can build entire applications involving ajax and such without callbacks as JS got async/await too in ES8 event handlers are written more or less the same in Pyhton or Javascript Carl> which makes function expressions really useful, but Python doesn't have Carl> expressions that contain blocks, because of significant Carl> indentation. yes, i agree that the difference between lambda an anonymous function is very significant on the way you may think to write your code. Carl> As a result, ordinary JS, like this... Carl> $(function(){ $("spam").click(function(){ alert("spam clicked") }) }); I don't think you mean this is real JS application code :-) Carl> ...ends up looking like this... Carl> def on_ready(): Carl> def click_handler(): alert("spam clicked") Carl> jQuery("spam").click(click_handler) Carl> jQuery(on_ready) or just jQuery(lambda: jQuery("spam").click(lambda: alert("spam clicked"))) Carl> JS semantics means JS libraries, which have APIs that assume JS syntax. Carl> Python library developers make heavy use of language specific features to Carl> define elegant, Pythonic APIs, which is a big part of what makes the Carl> language so nice to use. language specific features... like?
Using lambdas doesn't solve the problem. I just kept the example short, but had I used more than one expression in each function, you'd be back to square one. You took advantage of the brevity of the example, but it's not realistic. There are lots of language specific features that library authors use, like operator overloading, ABCs etc... Python is a great language, and I always opt for it when it's an option, but I've used it to write front-end code, and it sucks. -- Carl Smith carl.input@gmail.com On 12 August 2017 at 00:46, Alberto Berti <alberto@metapensiero.it> wrote:
"Carl" == Carl Smith <carl.input@gmail.com> writes:
Carl> Python is not a good fit for the browser, in part, because of the syntax. Carl> JavaScript has issues, but its syntax is better suited to creating GUIs in Carl> the browser.
Just so?
Carl> For example, in browsers everything revolves around a single Carl> threaded event loop, so you have a lot of callbacks and event Carl> handlers,
You can write applications full of callbacks using libraries like Twisted or even asyncio and you can build entire applications involving ajax and such without callbacks as JS got async/await too in ES8
event handlers are written more or less the same in Pyhton or Javascript
Carl> which makes function expressions really useful, but Python doesn't have Carl> expressions that contain blocks, because of significant Carl> indentation.
yes, i agree that the difference between lambda an anonymous function is very significant on the way you may think to write your code.
Carl> As a result, ordinary JS, like this...
Carl> $(function(){ $("spam").click(function(){ alert("spam clicked") }) });
I don't think you mean this is real JS application code :-)
Carl> ...ends up looking like this...
Carl> def on_ready(): Carl> def click_handler(): alert("spam clicked") Carl> jQuery("spam").click(click_handler) Carl> jQuery(on_ready)
or just
jQuery(lambda: jQuery("spam").click(lambda: alert("spam clicked")))
Carl> JS semantics means JS libraries, which have APIs that assume JS syntax. Carl> Python library developers make heavy use of language specific features to Carl> define elegant, Pythonic APIs, which is a big part of what makes the Carl> language so nice to use.
language specific features... like?
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Sat, Aug 12, 2017 at 10:15 AM, Carl Smith <carl.input@gmail.com> wrote:
Using lambdas doesn't solve the problem. I just kept the example short, but had I used more than one expression in each function, you'd be back to square one. You took advantage of the brevity of the example, but it's not realistic.
There are lots of language specific features that library authors use, like operator overloading, ABCs etc...
Python is a great language, and I always opt for it when it's an option, but I've used it to write front-end code, and it sucks.
Code to its strengths. A few well-written function decorators will solve your problems elegantly. If you start with JS code and then try to port it, of course that won't look good - but if you start with idiomatic Python, it looks great. ChrisA
"Carl" == Carl Smith <carl.input@gmail.com> writes:
Carl> Using lambdas doesn't solve the problem. I just kept the example short, but Carl> had I used more than one expression in each function, you'd be back to Carl> square one. You took advantage of the brevity of the example, but it's not Carl> realistic. I already told you that it wasn't real application code, it was your example by the way. Carl> There are lots of language specific features that library authors use, like Carl> operator overloading, ABCs etc... Those are features that I do not consider core Python and probably they have similar, already done implementations in some javascript libraries. I'm not stating that JS hasn't its limitations, we are all well aware of that. JavaScripthon just reduces the effort of recontextualize your mind when jumping between python and js code and in doing that it just solves some of the more evindent shortcomings of JS for you. But maybe it's just my impression, i've done it for me anyway ;-) . It produces so uncluttered JS that allows even to redistribute just the JS transpiled sources when necessary. As I said before, it's not a reimplementation of Python's standard library in JS, there are plenty of libraries in JS that cover the same areas of Python's standard library and more and more that deal with things related to manipulating dom and browsers. I do not intend to replace those even because sooner or later you will have to use them (I'm talking about libraries like react, angular and so on)... there's no point for me in trying to build your own "python in the browser" ecosystem. Carl> Python is a great language, and I always opt for it when it's an option, Carl> but I've used it to write front-end code, and it sucks. What do you have used?
"Carl" == Carl Smith <carl.input@gmail.com> writes:
Carl> Using lambdas doesn't solve the problem. I just kept the example short, but Carl> had I used more than one expression in each function, you'd be back to Carl> square one. You took advantage of the brevity of the example, but it's not Carl> realistic. Let me elaborate more on this... yes, i took "advantage" of the brevity of your example, but there's a another side of it. In my JS coding I usually avoid non trivial anonymous functions in real applications. The reason is that if an error happens inside an anonymous function and maybe it was the last one in a series of anonymous functions the stack trace of that error will end up with references like "in anonymous function at line xy of 'foo.js'" and that doesn't allows me get a first idea of what the code was doing when the error was thrown. That's why I don't like them and why I don't have a great opinion of large codebases making extensive usage of them. It also appears to me that the trend in some (relevant) part of the JS community if to refrain from use them when possible towards a more structured approach to coding that resembles more of a class based componentization, like in react. cheers, Alberto
"Chris" == Chris Angelico <rosuav@gmail.com> writes:
Chris> On Sat, Aug 12, 2017 at 6:31 AM, Alberto Berti <alberto@metapensiero.it> wrote: >> As of now, I do nothing. As I said, the goal of the tool is not to >> shield you from JS, for this reason it's not meant for beginners (in >> both JS or Python). You always manipulate JS objects, but allows you to >> to be naive on all that plethora of JS idiosyncrasies (from a Python pow >> at least) that you have to think about when you frequently switch from >> python to js. Chris> Do you "retain most of Python language semantics", or do you "always Chris> manipulate JS objects"? As shown in a previous post, there are some Chris> subtle and very dangerous semantic differences between the languages. Chris> You can't have it both ways. that's right you can't have both ways. That's the difficult decision to make, because as you add more and more Python APIs to those supported, probably you'll end up creating your "Python island in JS" where you need to transform the objects you manipulate from/to JS on the functions that are called by external JS code (either manually or automatically). And on the other end, if don't add any Pythonic API you will end up with ugly Python code that yes, is valid Python code, but that's nothing you would like to see. JavaScripthon was and is an experiment to see how much of the "Pythonic way of expressing alogrithms" can be retained adding as less "runtime" as possible. That's the reason why it targets ES6+ JavaScript, because the "point of contacts" between the two languages are much higher in number. As an example let's take the following simple code: def test(): a = 'foo' d = {a: 'bar'} return d[a] one can naively translate it to: function test() { var a, d; a = 'foo'; d = {a: 'bar'}; return d[a]; } but it returs 'bar' in Python and undefined in JS. But even if it's just a simple case expressed in a four lines function, it one of those things that can slip through when coding in both languages at the same time (at least for me). So I asked myself if it was worthwhile to have a tool that: * allows me to use Python syntax to write some amount of JS code. I'm more accustomed to Python syntax and I like it more. It's generally more terse and has less distractions (like variable declarations and line terminations); * fixes as many as possible of this things automatically, without having to precisely remember that this is a "corner case" in JS and that must be handled with care (so that reduces the "context-switching" effort); * produces a good looking JS code that's still possible to read and follow without much trouble. How many "corner cases" like this there are in JS? In my coding experience, "thanks" to the fact that JS is much less "harmonious" than Python ( my opinion ) I've encountered many of those, and also there are many simple Python coding habits that are translatable in a simple way. So what the tools does in this case? $ pj -s - def test(): a = 'foo' d = {a: 'bar'} return d[a] function test() { var a, d; a = "foo"; d = {[a]: "bar"}; return d[a]; } It turns out that ES6 has a special notation for wath JS calls "computed property names", keys in object literals that aren't strings does it evaluates the way a Python developer expects when run? let's see $ pj -s - -e def test(): a = 'foo' d = {a: 'bar'} return d[a] test() bar
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
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
participants (10)
-
Alberto Berti -
Alex Walters -
Brendan Barnwell -
Carl Smith -
Chris Angelico -
Chris Barker -
Jason H -
Joao S. O. Bueno -
Nick Coghlan -
Steven D'Aprano