> If we simply allowed string objects to support higher character
> numbers I *cannot see* how that could break existing code.
To take a specific example: What would you change about imp and
py_compile.py? What is the type of imp.get_magic()? If character
string, what about this fragment?
import imp
MAGIC = imp.get_magic()
def wr_long(f, x):
"""Internal; write a 32-bit int to a file in little-endian order."""
f.write(chr( x & 0xff))
f.write(chr((x >> 8) & 0xff))
f.write(chr((x >> 16) & 0xff))
f.write(chr((x >> 24) & 0xff))
...
fc = open(cfile, 'wb')
fc.write('\0\0\0\0')
wr_long(fc, timestamp)
fc.write(MAGIC)
Would that continue to write the same file that the current version
writes?
> We are just making life harder for ourselves by walking further and
> further down one path when "everyone agrees" that we are eventually
> going to end up on another path.
I think a problem of discussing on a theoretical level is that the
impact of changes is not clear. You seem to claim that you want
changes that have zero impact on existing programs. Can you provide a
patch implementing these changes, so that others can experiment and
find out whether their application would break?
Regards,
Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4