6 ms·

My pet peeve (in general, not specific to UV, which I genuinely appreciate) is using comment sections for controlling code execution. Using comments for linter

by stared 2y ago

My pet peeve (in general, not specific to UV, which I genuinely appreciate) is using comment sections for controlling code execution. Using comments for linters and developer notes is perfectly acceptable. However, for configuration or execution-related data, a far superior pattern would be something like: UV_ENV = { "dependencies": { "requests": "2.32.3", "pandas": "2.2.3" } } This approach has clear advantages: - It's valid Python syntax. - It utilizes standard, easily-parsable data structures rather than ad-hoc comment parsing. It makes creation and validation smooth. - Crucially, it adheres to a core principle: if you remove all comments from your code, it should still execute identically.

petters 2y ago
I completely agree. Hope something like this is eventually standardized. Problem is that uv probably does not want to execute anything to find out dependencies, so it would have to be a very restrictive subset of python syntax. The fact that is is needed at all of course highlights a weakness in the language. The import statements themselves should be able to convey all information about dependencies
- stared 2y ago
  It can be specified that it is a valid, static structure before imports.
  - nemetroid 2y ago
    Between future statements and other imports, then?
- deleted 2y ago
  [deleted]
- pedrosorio 2y ago
  > The fact that is is needed at all of course highlights a weakness in the language. The import statements themselves should be able to convey all information about dependencies What languages convey the version of the dependencies in a script’s import statements?
- SAI_Peregrinus 2y ago
  UV just implemented PEP 723[1], which is now PyPA Inline Script Metadata[2]. That's no longer provisional, it is standardized already! It's unfortunate that Python didn't have some non-comment way to provide this functionality. [1] https://peps.python.org/pep-0723/ https://peps.python.org/pep-0723/ [2] https://packaging.python.org/en/latest/specifications/inline-script-metadata/#inline-script-metadata https://packaging.python.org/en/latest/specifications/inline...
sorenjan 2y ago
This isn't a uv invention, uv is only using the standard PEP 723 like other tools. https://peps.python.org/pep-0723/ https://peps.python.org/pep-0723/
- stared 2y ago
  As I mentioned, it is not criticism of uv, but of this general approach.
gorgoiler 2y ago
I agree, but I would go a step further. You’re using a magic constant that doesn’t do anything at runtime. It’s only there to be parsed by static analysis. In your case that’s uv doing the parsing but another tool might delete it as unused code. In the sense that it’s one thing pretending to be another, for me, it’s in the same category as a magic comment. Instead, why not make a call to uv telling it what to do?: import uv uv.exec( dependencies=[“clown”], python=“>=3.10”, ) from clown import nose The first call can be with any old python runtime capable of locating this hypothetical uv package. The uv package sets up the venv and python runtime and re-exec(3)s with some kind of flag, say, an environment variable. In the second runtime uv.exec is a noop because it detects the flag.
- hanikesn 2y ago
  There's justification for that: https://peps.python.org/pep-0723/#why-not-use-possibly-restricted-python-syntax https://peps.python.org/pep-0723/#why-not-use-possibly-restr...
  - gorgoiler 2y ago
    Thanks for the link. My counterpoints to the PEP’s arguments are (1) we’re about to run Python so we presumably have a Python parser on hand anyway; and (2) for the foreseeable future it is going to be capable of parsing all previous versions of Python. It’s a bit fast and loose though. I can see though that it’s helpful for long term stability to have two completely separate languages for dependencies versus the actual code, with the former being far more reduced and conservative than the latter. If you use Python4.98 triple walrus operators to say requires_version:::=“>=4.98” it would definitely be annoying for any version prior to that to not even be able to parse the requirements, let alone try to meet them.
    - atoav 2y ago
      So but that means instead of uv running python python runs uv now, which (I would imagine) has all kind of implications from a development perspective. I agree that theoretically your proposed way of doing things would be conceptionally among the cleanest, but on the other hand in all kind of scripts the shebang was sort of a comment with big implications as well, so I am not sure if being dogmatic is worth it here.
JimDabell 2y ago
That’s fair. I agree with other replies though that parsing and evaluating imperative code is a lot tougher and less flexible than adhering to the principle of least power and making it declarative data. It’s also worth noting that using comments is exactly how the shebang line works in the first place. It’s just so well-ingrained after 45 years that people don’t notice that it’s a shell comment.
Svoka 2y ago
I generally agree but it literally uses shebang
wavemode 2y ago
> if you remove all comments from your code, it should still execute identically It still -does- execute identically. Provided you install the same dependencies. I don't see this as changing the semantics of the code itself, rather just changing the environment in which the code runs. In that respect it is no different from a `#!/bin/bash` comment at the top of a shell script.

by stared 2y ago

petters 2y ago

I completely agree. Hope something like this is eventually standardized. Problem is that uv probably does not want to execute anything to find out dependencies, so it would have to be a very restrictive subset of python syntax. The fact that is is needed at all of course highlights a weakness in the language. The import statements themselves should be able to convey all information about dependencies

stared 2y ago
It can be specified that it is a valid, static structure before imports.
- nemetroid 2y ago
  Between future statements and other imports, then?
deleted 2y ago
[deleted]
pedrosorio 2y ago
> The fact that is is needed at all of course highlights a weakness in the language. The import statements themselves should be able to convey all information about dependencies What languages convey the version of the dependencies in a script’s import statements?
SAI_Peregrinus 2y ago
UV just implemented PEP 723[1], which is now PyPA Inline Script Metadata[2]. That's no longer provisional, it is standardized already! It's unfortunate that Python didn't have some non-comment way to provide this functionality. [1] https://peps.python.org/pep-0723/ https://peps.python.org/pep-0723/ [2] https://packaging.python.org/en/latest/specifications/inline-script-metadata/#inline-script-metadata https://packaging.python.org/en/latest/specifications/inline...

sorenjan 2y ago

This isn't a uv invention, uv is only using the standard PEP 723 like other tools. https://peps.python.org/pep-0723/ https://peps.python.org/pep-0723/

stared 2y ago
As I mentioned, it is not criticism of uv, but of this general approach.

gorgoiler 2y ago

I agree, but I would go a step further. You’re using a magic constant that doesn’t do anything at runtime. It’s only there to be parsed by static analysis. In your case that’s uv doing the parsing but another tool might delete it as unused code. In the sense that it’s one thing pretending to be another, for me, it’s in the same category as a magic comment. Instead, why not make a call to uv telling it what to do?: import uv uv.exec( dependencies=[“clown”], python=“>=3.10”, ) from clown import nose The first call can be with any old python runtime capable of locating this hypothetical uv package. The uv package sets up the venv and python runtime and re-exec(3)s with some kind of flag, say, an environment variable. In the second runtime uv.exec is a noop because it detects the flag.

hanikesn 2y ago
There's justification for that: https://peps.python.org/pep-0723/#why-not-use-possibly-restricted-python-syntax https://peps.python.org/pep-0723/#why-not-use-possibly-restr...
- gorgoiler 2y ago
  Thanks for the link. My counterpoints to the PEP’s arguments are (1) we’re about to run Python so we presumably have a Python parser on hand anyway; and (2) for the foreseeable future it is going to be capable of parsing all previous versions of Python. It’s a bit fast and loose though. I can see though that it’s helpful for long term stability to have two completely separate languages for dependencies versus the actual code, with the former being far more reduced and conservative than the latter. If you use Python4.98 triple walrus operators to say requires_version:::=“>=4.98” it would definitely be annoying for any version prior to that to not even be able to parse the requirements, let alone try to meet them.
  - atoav 2y ago
    So but that means instead of uv running python python runs uv now, which (I would imagine) has all kind of implications from a development perspective. I agree that theoretically your proposed way of doing things would be conceptionally among the cleanest, but on the other hand in all kind of scripts the shebang was sort of a comment with big implications as well, so I am not sure if being dogmatic is worth it here.

JimDabell 2y ago

That’s fair. I agree with other replies though that parsing and evaluating imperative code is a lot tougher and less flexible than adhering to the principle of least power and making it declarative data. It’s also worth noting that using comments is exactly how the shebang line works in the first place. It’s just so well-ingrained after 45 years that people don’t notice that it’s a shell comment.

Svoka 2y ago

I generally agree but it literally uses shebang

wavemode 2y ago

> if you remove all comments from your code, it should still execute identically It still -does- execute identically. Provided you install the same dependencies. I don't see this as changing the semantics of the code itself, rather just changing the environment in which the code runs. In that respect it is no different from a `#!/bin/bash` comment at the top of a shell script.