Well, I finally ran into a Python Unicode problem, sort of

[Ned Batchelder]

On Monday, July 4, 2016 at 6:05:20 AM UTC-4, BartC wrote:
> On 04/07/2016 03:30, Steven D'Aprano wrote:
> > On Mon, 4 Jul 2016 10:17 am, BartC wrote:
> >
> >> On 04/07/2016 01:00, Lawrence D’Oliveiro wrote:
> >>> On Monday, July 4, 2016 at 11:47:26 AM UTC+12, eryk sun wrote:
> >>>> Python lacks a mechanism to add user-defined operators. (R has this
> >>>> capability.) Maybe this feature could be added.
> >>>
> >>> That would be neat. But remember, you would have to define the operator
> >>> precedence as well. So you could no longer use a recursive-descent
> >>> parser.
> >>
> >> That wouldn't be a problem provided the new operator symbol and its
> >> precedence is known at a compile time, and defined before use.
> >
> > You're still having problems with the whole Python-as-a-dynamic-language
> > thing, aren't you? :-)
> 
> Well it isn't completely dynamic, not unless code only exists as a eval 
> or exec argument string (and even there, any changes will only be seen 
> on calling eval or exec again on the same string).
> 
> Most Pythons seem to pre-compile code before executing the result. That 
> pre-compilation requires that operators and precedences are known in 
> advance and the resulting instructions are then hard-coded before execution.

This is the key but subtle point that all the discussion of parser mechanics
are missing: Python today needs no information from imported modules in
order to compile a file.  When the compiler encounters "import xyzzy" in
a file, it doesn't have to do anything to find or read xyzzy.py at compile
time.

If operators can be invented, they will only be useful if they can be
created in modules which you then import and use.  But that would mean that
imported files would have to be found and read during compilation, not
during execution as they are now.

This is a huge change.

--Ned.