On Tue, Aug 27, 2019 at 05:13:41PM -0000, [email protected] wrote:
> The difference between `x'...'` and `x('...')`, other than visual noise, is
> the
> following:
>
> - The first "x" is in its own namespace of string prefixes. The second "x"
> exists in the global namespace of all other symbols.
Ouch! That's adding a lot of additional complexity to the language.
Python's scoping rules are usually described as LEGB:
- Local
- Enclosing (non-local)
- Global (module)
- Builtins
but that's an over-simplification, dating back to something like Python
1.5 days. Python scope also includes:
- class bodies can be the local scope, but they don't work quite
the same as function locals);
- parts of the body of comprehensions behave as if they were a
seperate scope.
This proposal adds a completely seperate, parallel set of scoping rules
for these string prefixes. How many layers in this parallel scope?
The simplest design is to have a single, interpreter wide namespace for
prefixes. Then we will have name clashes, especially since you seem to
want to encourage single character prefixes like "v" (verbose, version)
or "d" (date, datetime, decimal). Worse, defining a new prefix will
affect all other modules using the same prefix.
So we need a more complex parallel scope. How much more complex?
* if I define a string prefix inside a comprehension, function or
class body, will that apply across the entire module or just inside
that comp/func/class?
* how do nested functions interact with prefixes?
* do we need a set of parallel keywords equivalent to global and
nonlocal for prefixes?
If different modules have different registries, then not only do we need
to build a parallel set of scoping rules for prefixes into the
interpreter, but we need a parallel way to import them from other
modules, otherwise they can't be re-used.
Does "from module import x" import the regular object x from the module
namespace, or the prefix x from the prefix-namespace? So it seems we'll
need a parallel import system as well.
All this adds more complexity to the language, more things to be coded
and tested and documented, more for users to learn, more for other
implementations to re-implement, and the benefit is marginal: the
ability to drop parentheses from some but not all function calls.
Now consider another problem: introspection, or the lack thereof.
One of the weaknesses of string prefixes is that it's hard to get help
for them. In the REPL, we can easily get help on any class or function:
help(function)
and that's really, really great. We can use the inspect module or dir()
to introspect functions, classes and instances, but we can't do the same
for string prefixes.
What's the difference between r-strings and u-strings? help() is no help
(pun intended), since help sees only the string instance, not the syntax
you used to create it. All of these will give precisely the same output:
help(str())
help('')
help(u'')
help(r"")
etc. This is a real weakness of the prefix system, and will apply
equally to custom prefixes. It is *super easy* to introspect a class or
function like Version; it is *really hard* to do the same for a prefix.
You want this seperate namespace for prefixes so that you can have an v
prefix without "polluting" the module namespace with a v function (or
class). But v doesn't write itself! You still have to write a function
or class, athough you might give it a better name and then register it
with the single letter prefix:
@register_prefix('v')
class Version:
...
(say). This still leaves Version lying around in your global namespace,
unless you explicitly delete it:
del Version
but you probably won't want to do that, since Version will probably be
useful for those who want to create Version objects from expressions or
variables, not just string literals.
So the "pollution" isn't really pollution at all, at least not if you
use reasonable names, and the main justification for parallel namespaces
seems much weaker.
Let me put it another way: parallel namespaces is not a feature of this
proposal. It is a point against it.
> - Python style discourages too short variable names, especially in libraries,
> because they have increased chance of clashing with other symbols, and
> generally may be hard to understand. At the same time, short names for
> string prefixes could be perfectly fine: there won't be too many of them
> anyways.
That's an interesting position for the proponent of a new feature to
take. "Don't worry about this being confusing, because hardly anyone
will use it."
> The standard prefixes "b", "r", "u", "f" are all short, and nobody
> gets confused about them.
Plenty of people get confused about raw strings.
There's only four, plus uppercase and combinations, and they are
standard across the entire language. If there were dozens of them,
coming from lots of different modules and third-party libraries, with
lots of conflicts ('v' for version in foolib, but 'v' for verbose in
barlib), the situation would be very different.
We can't extrapolate from four built-in prefixes being manageable to
concluding that dozens of clashing user-defined prefixes will be too.
> - Barrier of entry. Today you can write `from re import compile as x` and then
> write `x('...')` to denote a regular expression (if you don't mind having
> `x` as
> a global variable). But this is not the way people usually write code.
I doubt that is true. "from module import foo as bar" is a standard,
commonly used Python language feature:
https://stackoverflow.com/questions/22245711/from-import-or-import-as-for-modules
in particular this answer here:
https://stackoverflow.com/a/29010729
Besides, we don't design the language for the least knowledgable, most
ignorant, copy-and-paste coders.
> People
> write the code the way they are taught from examples, and the examples
> don't speak about regular expression objects. The examples only show
> regular expressions-as-strings
That's simply wrong. The *very first* example of a regular expression here:
https://scotch.io/tutorials/an-introduction-to-regex-in-python
uses the compile function.
More examples talking about regex objects:
https://docs.python.org/3/library/re.html#re.compile
https://pymotw.com/2/re/#compiling-expressions
https://docs.python.org/3/howto/regex.html#compiling-regular-expressions
https://stackoverflow.com/questions/20386207/what-does-pythons-re-compile-do
These weren't hard to find. You don't have to dig deep into obscure
parts of the WWW to find people talking about regex objects. I think you
underestimate the knowledge of the average Python programmer.
--
Steven
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/NS45GVLBWCGINYQYXZMYPCOGSDFAQC7K/
Code of Conduct: http://python.org/psf/codeofconduct/
