It would be useful to add a syntax to encode some numbers with an ASCII character, like `a` representing 0141. Right now, there is a discrepancy between bytestring and byte syntax: b"a"[0] cannot be expressed with anything involving 'a', which was an option in all languages since 1970s.
Which syntax? Can you present a concrete proposal?
What’s wrong with builtin ord?
>>> ord('a')
97
>>> oct(_)
'0o141'
Backticks would work and should not conflict with anything.
There is no need to make a function call to obtain a constant value. It is as weird as calling eval("0x20") to obtain 32.
Well, it’s not our job for fill your proposal, but I assume it will look like
>>> `a`
97
Am I correct?
Backticks aren’t used in Python syntax, yes. But this alone is not a reason to use them.
Any integer value can be a constant. What’s wrong to return it from some function?
But you can use hexadecimal integer literals as a string input for the int constructor:
>>> int('0x20', 0)
32
Is this weird? Other languages have e.g. hexadecimal floating-point literals, like 0x1.2p3. Not Python. Sorry, calling something to be “weird” — is not a solid ground for a proposal.
You are proposing some syntax change. This will certainly require a PEP. Please take look on PEP 1 and try to fill missing parts of your proposal. E.g. (motivation) why existing language specification is not enough? Can you provide examples, where new syntax will be useful c.f. existing workarounds?
1 Like
The difference is you don’t have to use int() to be able to represent int constants as hexadecimal numbers, but for some reason it is impossible for ASCII representation.
The ability to use ASCII form for corresponding literals is a part of every major programming language in the last 50 years. It is unfortunate that Python hijacks the universally accepted syntax of '', but it does not excuse the necessity of reducing the code readability with cryptic references like 0x61 or unnecessary code invocation like ord("a") instead of clear literal 'a'.
Perhaps, it has much less use cases in practice? After all, ASCII is just an arbitrary encoding.
Again, you defend your proposal by arguments, already shown as weak above. (BTW, you must also define what’s “major programming languages” term means. Does e.g. Scheme have this feature?)
We can’t use literal 'a' for this. This syntax already have a different meaning in python. You have to invent a new syntax, e.g. with backticks. But this will also close opportunity to use backticks for something else, maybe more important. You could search discussion threads, I’m pretty sure it already was proposed for something.
Such syntax already exists, and you know it. This is b"a"[0]. In CPython it is evaluated at compile time, so there is no difference between b"a"[0], 97, 0x61, 0o141 and 0b1100001 at runtime.
10 Likes
For what? Can you show examples where you’d use it? Maybe in Python they’d better be handled a different way anyway.
You’re right, I didn’t know that:
>>> import dis
>>> dis.dis('b"a"[0]')
0 RESUME 0
1 RETURN_CONST 0 (97)
1 Like
Python used to have backticks. They were considered unreadable, since so poorly rendered in many fonts.
It comes up quite often when writing a scanner/parser. Usually though, @Carmina16, one defines a constant for each of the letters/symbols that might be individually significant. I think that’s the idiom you have to show a material advance over.
LWR_A = ord('a')
...
if c == LWR_A:
do_something()
A LOAD_NAME rather than a LOAD_CONST.
It’s not universal, it’s not necessarily ASCII (although these days it’s likely Unicode, which is not the same, and Unicode is less then 50 years old), and it’s not necessarily an integer (it might be a distinct character type).
2 Likes