7 ms·

Did not know that such things could be accomplished by registering a new file coding format. Reminds me of https://pypi.org/project/goto-statement/ https://pyp

Did not know that such things could be accomplished by registering a new file coding format. Reminds me of https://pypi.org/project/goto-statement/ https://pypi.org/project/goto-statement/

zahlman 1y ago
This one is arguably even more of a hack; it's working at the source code level rather than the AST level. The "coding" here is a bytes-to-text encoding. The Python lexer expects to see character data; you get to insert arbitrary code to convert the bytes to characters (or just use existing schemes the implement standards like UTF-8).
- almostgotcaught 1y ago
  > it's working at the source code level rather than the AST level. this (lexing) is the only use of the codec hack - if you want to manipulate the AST you do not need this and can just to `ast.parse` and then recompile the function.
  - zahlman 1y ago
    Indeed; the goto hack works that way (and uses a decorator to make it easier to invoke the AST-manipulation logic).
deleted 1y ago
[deleted]
crabbone 1y ago
I think there's a package to treat Jupyter notebooks as source code (so you can import them as modules). While the OP package is obviously a joke, the one with notebooks is kind of useful. And, of course, obligatory quote about how languages that don't have meta-programming at the design level will reinvent it, but poorly.
- Y_Y 1y ago
  You talking about this? https://jupyter-notebook.readthedocs.io/en/stable/examples/Notebook/Importing%20Notebooks.html https://jupyter-notebook.readthedocs.io/en/stable/examples/N...
- xg15 1y ago
  I'd argue "import from notebooks" is still only helpful in the "space bar heating" sense. I think Notebooks are great for quick, "explorative" sketches of code. They are absolutely terrible for organizing "production" code. I know it often happens that something starts in a notebook and then sort of morphs into a generic script or full-on application. But I think, this is usually the signal you should refactor, pull out the "grown" parts from the notebooks and organize them into proper Python modules. If you have parts that are still experimental or explorative, consider importing your new modules into the notebook instead of the other way around. Source: personal experience

Did not know that such things could be accomplished by registering a new file coding format. Reminds me of https://pypi.org/project/goto-statement/ https://pypi.org/project/goto-statement/

zahlman 1y ago

This one is arguably even more of a hack; it's working at the source code level rather than the AST level. The "coding" here is a bytes-to-text encoding. The Python lexer expects to see character data; you get to insert arbitrary code to convert the bytes to characters (or just use existing schemes the implement standards like UTF-8).

almostgotcaught 1y ago
> it's working at the source code level rather than the AST level. this (lexing) is the only use of the codec hack - if you want to manipulate the AST you do not need this and can just to `ast.parse` and then recompile the function.
- zahlman 1y ago
  Indeed; the goto hack works that way (and uses a decorator to make it easier to invoke the AST-manipulation logic).

deleted 1y ago

[deleted]

crabbone 1y ago

I think there's a package to treat Jupyter notebooks as source code (so you can import them as modules). While the OP package is obviously a joke, the one with notebooks is kind of useful. And, of course, obligatory quote about how languages that don't have meta-programming at the design level will reinvent it, but poorly.

Y_Y 1y ago
You talking about this? https://jupyter-notebook.readthedocs.io/en/stable/examples/Notebook/Importing%20Notebooks.html https://jupyter-notebook.readthedocs.io/en/stable/examples/N...
xg15 1y ago
I'd argue "import from notebooks" is still only helpful in the "space bar heating" sense. I think Notebooks are great for quick, "explorative" sketches of code. They are absolutely terrible for organizing "production" code. I know it often happens that something starts in a notebook and then sort of morphs into a generic script or full-on application. But I think, this is usually the signal you should refactor, pull out the "grown" parts from the notebooks and organize them into proper Python modules. If you have parts that are still experimental or explorative, consider importing your new modules into the notebook instead of the other way around. Source: personal experience