3 ms·

Nice concept, great work! As a side note: I found your extra whitespace before function arguments to be very strange. I haven't seen this type of spacing befor

Nice concept, great work! As a side note: I found your extra whitespace before function arguments to be very strange. I haven't seen this type of spacing before. Is there a reason why you do this? I personally use and encourage the use of the "pep8" python tool (link below) to validate my codestyle as I find it makes working with other developers easier (this extra whitespace is pointed out as an error). pep8 tool: https://pypi.python.org/pypi/pep8 https://pypi.python.org/pypi/pep8

jaytaylor 11y ago
What whitespace? I took a glance and noticed only the tabs.. E.g.: https://github.com/JdeH/Transcrypt/blob/master/Transcrypt/modules/org/transcrypt/compiler.py https://github.com/JdeH/Transcrypt/blob/master/Transcrypt/mo...
- anglebracket 11y ago
  See https://github.com/JdeH/Transcrypt/blob/master/Transcrypt/demos/hello/hello.py#L29-L33 https://github.com/JdeH/Transcrypt/blob/master/Transcrypt/de... There are spaces before subscript operators, before `.method()` calls, and between `def name` and `(param1, param2)`.
  - StavrosK 11y ago
    Yep, as a Python dev that's used to Python looking a certain way, this is very offputting. This is a great project, and I would hate for it to look "off" by something as trivial as Javascriptish whitespace and formatting conventions.
    - JdeH 11y ago
      You're encouraged to follow PEP8 completely for your Transcrypt apps and libs. As for interop with JS libs, following JS conventions is probably best, although some often use libs may acquire a PEP8 facade.
      - StavrosK 11y ago
        Well, it's the documentation that looks off, not my apps and libs.
        JdeH 11y ago
        You mean the docs of Transcrypt? In what way should it be improved? Any critisism to make it better is very welcome!
Spiritus 11y ago
On a related note, pep8 (the tool) will actually be renamed "pycodestyle" by request from Guido himself. https://github.com/PyCQA/pep8/issues/466 https://github.com/PyCQA/pep8/issues/466
JdeH 11y ago
My coding style took shape long before PEP8 or even Python emerged. I tried following PEP8 for a few months, but since I mosty use C++ and Python in combination, pure PEP8 didn't work on the C++ side of things. So I stick with a kind of geometric mean of my Fortran, Basic, Cobol, Algol, Ada, Pascal, Modula2, C, C++, Python, JavaScript, asssembler and PLC AWL coding styles. But that's just the way Transcrypt itself is coded. Feel free to follow PEP8 completely in your code using Transcrypt. It's parsed by the CPython parser, so no problem there. However, if you use JS libs they won't follow PEP 8 either. And that's probably something to accept, as, however big the Python world, one cannot ignore the JS world when programming for the browser. By the way of all those languages I like Python best. But since I write technical (signal processing) apps, C++ interoperation is an inevitable fact for me. To be more exact about the braces: I started out numerical programming in Fortran66, and wanted a formula to look like this: (a + b) * (c + d), so with blanks surrounding the braces, rather than (a+b)*(c+d) which I found harder to decipher at that time. I stuck with that ever since, for any braces, unless adjacent to each other.
- jsnathan 11y ago
  FWIW I prefer the same kind of spacing. So there's at least two of us.
  - JdeH 11y ago
    Nice to know!
- deadbeef404 11y ago
  Thanks for the response, man! To be completely honest, I definitely don't follow PEP8 100% (especially in regards to continuing-line indentation) because to do so would make some lines quite nasty looking simply for compliance to guidelines (also, I've seen many many projects ignore those rules too). But I don't recall ever seeing any libraries break that specific spacing rule which as some others have pointed out, make the documentation look a bit.. unexpected. In regards to: > if you use JS libs they won't follow PEP 8 either. > And that's probably something to accept, as, however > big the Python world, one cannot ignore the JS world. I totally agree. I spend about half of my time writing JS and half in Python and I definitely don't try to enforce PEP8 guidelines onto JS code, simply because it's a Python style guide, not a JS guide. I would try to follow a largely accepted code style of the JS community if I was made aware of one, but there only seems to be a large collection of non-official guides, so just I try to adjust my code style to what seems to be common among all of the "nice"/readable code around the web, or, if I'm working in a large existing code base, the style that is followed in that codebase, unless there's reason good not to. I guess my general approach is that I prefer to style the code I write based upon the language (sometimes, for example, this requires placing open braces in different positions), and I find this actually helps my mind to switch between languages as they have their own look-and-feel to them. Thanks for reading, and thanks for writing a very interesting library!

jaytaylor 11y ago

What whitespace? I took a glance and noticed only the tabs.. E.g.: https://github.com/JdeH/Transcrypt/blob/master/Transcrypt/modules/org/transcrypt/compiler.py https://github.com/JdeH/Transcrypt/blob/master/Transcrypt/mo...

anglebracket 11y ago
See https://github.com/JdeH/Transcrypt/blob/master/Transcrypt/demos/hello/hello.py#L29-L33 https://github.com/JdeH/Transcrypt/blob/master/Transcrypt/de... There are spaces before subscript operators, before `.method()` calls, and between `def name` and `(param1, param2)`.
- StavrosK 11y ago
  Yep, as a Python dev that's used to Python looking a certain way, this is very offputting. This is a great project, and I would hate for it to look "off" by something as trivial as Javascriptish whitespace and formatting conventions.
  - JdeH 11y ago
    You're encouraged to follow PEP8 completely for your Transcrypt apps and libs. As for interop with JS libs, following JS conventions is probably best, although some often use libs may acquire a PEP8 facade.
    - StavrosK 11y ago
      Well, it's the documentation that looks off, not my apps and libs.
      - JdeH 11y ago
        You mean the docs of Transcrypt? In what way should it be improved? Any critisism to make it better is very welcome!

Spiritus 11y ago

On a related note, pep8 (the tool) will actually be renamed "pycodestyle" by request from Guido himself. https://github.com/PyCQA/pep8/issues/466 https://github.com/PyCQA/pep8/issues/466

JdeH 11y ago

My coding style took shape long before PEP8 or even Python emerged. I tried following PEP8 for a few months, but since I mosty use C++ and Python in combination, pure PEP8 didn't work on the C++ side of things. So I stick with a kind of geometric mean of my Fortran, Basic, Cobol, Algol, Ada, Pascal, Modula2, C, C++, Python, JavaScript, asssembler and PLC AWL coding styles. But that's just the way Transcrypt itself is coded. Feel free to follow PEP8 completely in your code using Transcrypt. It's parsed by the CPython parser, so no problem there. However, if you use JS libs they won't follow PEP 8 either. And that's probably something to accept, as, however big the Python world, one cannot ignore the JS world when programming for the browser. By the way of all those languages I like Python best. But since I write technical (signal processing) apps, C++ interoperation is an inevitable fact for me. To be more exact about the braces: I started out numerical programming in Fortran66, and wanted a formula to look like this: (a + b) * (c + d), so with blanks surrounding the braces, rather than (a+b)*(c+d) which I found harder to decipher at that time. I stuck with that ever since, for any braces, unless adjacent to each other.

jsnathan 11y ago
FWIW I prefer the same kind of spacing. So there's at least two of us.
- JdeH 11y ago
  Nice to know!
deadbeef404 11y ago
Thanks for the response, man! To be completely honest, I definitely don't follow PEP8 100% (especially in regards to continuing-line indentation) because to do so would make some lines quite nasty looking simply for compliance to guidelines (also, I've seen many many projects ignore those rules too). But I don't recall ever seeing any libraries break that specific spacing rule which as some others have pointed out, make the documentation look a bit.. unexpected. In regards to: > if you use JS libs they won't follow PEP 8 either. > And that's probably something to accept, as, however > big the Python world, one cannot ignore the JS world. I totally agree. I spend about half of my time writing JS and half in Python and I definitely don't try to enforce PEP8 guidelines onto JS code, simply because it's a Python style guide, not a JS guide. I would try to follow a largely accepted code style of the JS community if I was made aware of one, but there only seems to be a large collection of non-official guides, so just I try to adjust my code style to what seems to be common among all of the "nice"/readable code around the web, or, if I'm working in a large existing code base, the style that is followed in that codebase, unless there's reason good not to. I guess my general approach is that I prefer to style the code I write based upon the language (sometimes, for example, this requires placing open braces in different positions), and I find this actually helps my mind to switch between languages as they have their own look-and-feel to them. Thanks for reading, and thanks for writing a very interesting library!