I don’t want to discourage the author, but this seems like a misguided use of decorators. Maybe there’s some scenario where it’s practical to do version checks only at function boundaries, but why limit yourself that? It’s already easy (and clear, and non-magical) to check sys.version yourself in an if-statement. You can do that inside a def block to modify a function slightly, or outside a def block if you truly need the function definition to change by version. Given that, I don’t see how this library adds enough value to justify it as a dependency.
The project should also maybe note that it doesn’t help at all with Python 2 compatibility. A newer Python user might assume it enables freely mixing Python 2 and Python 3 in the same file, but even without reading the code I’m pretty sure the library doesn’t (and couldn’t) support this.
I wish Python had come with some equivalent to the "BEGIN {}" blocks that Perl and Awk have.
Lacking that, there's no way to write a (single file) script where a Python 2 interpreter would just get a "You need Python 3" error instead of a syntax error. Because testing for the interpreter version happens too late...after the syntax error already happened.
Perl's "BEGIN {}" block lets you easily test for versions or language features before the script itself is parsed.
You couldn't be more mistaken, most libraries supported both python 2 and 3 for years. Doing what you describe is extremely trivial. If you thought it was a good idea you could write a script that would exec trampoline itself into a different interpreter version entirely.
You can also catch a SyntaxError like any other exception.
Put an f-string into a script and get python2 not to choke on it, or try catching that SyntaxError as you describe...without using eval, futures, or similar. You can't catch something that already happened.
Yes, people are able to write backwards compatible scripts... by avoiding some features, or by using more than a single file.
What I'm describing was just a desire for a very simple "this script requires python version >= X" error, with the ability to write unfettered python version X code below it, in a single file script.
Sure, a variation on eval. I still think some sort of BEGIN equivalent would have been nice. But, the optimal time for that has passed, so I'm just complaining anyway :)
What I'm describing was just a desire for a very simple "this script requires python version >= X" error, with the ability to write unfettered python version X code below it, in a single file script.
import sys
if sys.version_info.major < 3:
raise Exception("this script requires python version >= 3")
plus an extra line or two if you're worried about minor versions.
from __future__ import absolute_import, division, print_function, unicode_literals
This will give you syntax much closer to Python 3 in Python 2.7. The remaining differences can be papered over with function and class helpers. Well, except for metaclasses, but I doubt you'd have need for those in a single-file script.
My way to work around this is to make a zipapp that contains several files, hence the entry point can do the checking and import another file that contains the code. But since its a zipapp, it behaves like a single file script: https://docs.python.org/3/library/zipapp.html
There's an interesting extensibility point in Python in form of codecs and the encoding comment:
# -*- coding: ... -*-
The trick is that encoding names come from an extensible registry of codecs (https://docs.python.org/3/library/codecs.html#codecs.registe...), so you can register your own. And when you look at codec API, you get the raw byte stream as input, and spit out strings - so it's basically as powerful as reader macros.
The problem is getting that registration code to run before your script starts. Easy if you have multiple scripts, but it requires .pth hacks if you go for single-file.
Awk's BEGIN blocks are not parsed separately from the rest of the program. Awk's Yacc-based implementations (like the original One True Awk and GNU Awk) parse the entire input in a single call to yyparse() before executing anything.
Therefore, I suspect it is not possible to write a test in the BEGIN block which avoids a version-dependent syntax error elsewhere in favor of terminating with a graceful error.
I wasn't proposing adding yet another change at the time. I'm saying if the capability were already in place, dealing with breaking changes would have been easier.
The whole reason this thought popped in my head is that I still have people asking today: "Tried to run your script, and I got a syntax error...is it broken?". When the issue is that the default python on their box is 2.x.
It doesn’t seem common to write single file libraries in Python; and it doesn’t seem to be too unreasonable to add an entrypoint script for version checks.
If Python had macros this library would have a very different implementation indeed.
I think 200LOC and a complex registration/namespace/cache system is a bit much to avoid an if statement around a def for a handful of functions. This is especially true since this just turns the if into a decorator, and imports will still need to be done the old way for compatibility. The cognitive overhead of this is not a good tradeoff.
You're absolutely right! I built this mainly to see if it could be done. I noticed uvicorn's main function uses an if-statement like you described, and I wondered what it would look like as a decorator.
My next goal is to see if I can make the resolution "static", i.e. Once all the functions are loaded, avoid the dictionary lookup at runtime, and just assign the appropriate function version as the bare module attribute.
It's fun to do things like this in python, simply because you can. But it's also important to point out that there's a lot of things you _shouldn't_ (this may be one of them!). I'm glad to see this sparked some discussion!
If Python simply parsed and evaluated top-level expressions one by one, you could test the value of some version variable and act accordingly. Like for this range of versions, load this file, otherwise load that one.
If I think of this problem in a Lisp frame, it does not scream "use macros" at me.
That looks great, maybe some libraries can leverage this to offer a wider range of compatibility -- even if "recent" syntax changes, such like the walrus operator or the match/case statements cannot be covered by this.
I'm not sure I get the point of this. If you already have to write the code using the equivalent old syntax, and keep maintaining it, why write the code a second time with the new syntax?
Old versions get deprecated in libraries, you don’t just cut over to a new way and break your callers on upgrade.
If you own all the callers of your api in the same repo, you probably don’t want this, you just replace all the old callers along with the implementation.
What I mean is (looking at the example in the README): when `asyncio.run()` was added, `asyncio.get_event_loop().run_until_complete()` didn't stop working.
What is the point of making two versions of the functions, when one of them already supports every Python you target?
The project should also maybe note that it doesn’t help at all with Python 2 compatibility. A newer Python user might assume it enables freely mixing Python 2 and Python 3 in the same file, but even without reading the code I’m pretty sure the library doesn’t (and couldn’t) support this.