Python is quickly turning into a crowded keyword junkyard

notatallshaw 3 days ago | parent | next [-]

Python has about 40 keywords, I say I would regularly use about 30, and irregularly use about another 5. Hardly seems like a "junkyard".

Further, this lack of first class support for lazy importing has spawned multiple CPython forks that implement their own lazy importing or a modified version of the prior rejected PEP 690. Reducing the real world need for forks seems worth the price of one keyword.

▲

lairv 3 days ago | parent [-]

For those curious here are the actual keywords (from https://docs.python.org/3/reference/lexical_analysis.html?ut... )

Hard Keywords:

False await else import pass None break except in raise True class finally is return and continue for lambda try as def from nonlocal while assert del global not with async elif if or yield

Soft Keywords:

match case _ type

I think nonlocal/global are the only hard keywords I now barely use, for the soft ones I rarely use pattern matching, so 5 seems like a good estimate

	▲	silverwind 3 days ago \| parent \| next [-]
		I recall when they added "async" and it broken a whole lot of libraries. I hope they never again introduce new "hard" keywords.
	▲	GauntletWizard 3 days ago \| parent \| prev [-]
		Removing "print" in 3.0 helped their case significantly, as well.

▲

striking 3 days ago | parent | prev | next [-]

From the PEP (https://peps.python.org/pep-0810/):

> The choice to introduce a new `lazy` keyword reflects the need for explicit syntax. Lazy imports have different semantics from normal imports: errors and side effects occur at first use rather than at the import statement. This semantic difference makes it critical that laziness is visible at the import site itself, not hidden in global configuration or distant module-level declarations. The lazy keyword provides local reasoning about import behavior, avoiding the need to search elsewhere in the code to understand whether an import is deferred. The rest of the import semantics remain unchanged: the same import machinery, module finding, and loading mechanisms are used.

This functionality is highly desired, and it does appear to actually need a new (soft) keyword. Sorry you don't like it.

▲

onedognight 3 days ago | parent | prev | next [-]

The pep didn’t mention considering reusing `async` instead of `lazy`. That would’ve conveyed the same thing to me without a new keyword, and would haven’t been similar to html’s usage `async`.

▲

belval 3 days ago | parent [-]

I personally would have preferred "defer import os" instead of "lazy import os". It might be the non-native showing but lazy import feels unserious.

	▲	_moof 3 days ago \| parent \| next [-]
		"Lazy" is standard language for this kind of behavior.
	▲	bloppe 3 days ago \| parent \| prev [-]
		Lazy is more canonical: https://en.wikipedia.org/wiki/Lazy_evaluation

▲

riedel 3 days ago | parent | prev | next [-]

It is a 'soft keyword' as the PEP explains. I would not think that this has any major impact on anyone who just chooses to ignore this feature. Assuming that you want this behavior, I wonder how this could have been done in a better fashion without now having 'lazy' in the specific context of an import statement.

	▲	rrauenza 3 days ago \| parent [-]
		soft keyword for anyone not familiar like I was ... "A new soft keyword lazy is added. A soft keyword is a context-sensitive keyword that only has special meaning in specific grammatical contexts; elsewhere it can be used as a regular identifier (e.g., as a variable name). The lazy keyword only has special meaning when it appears before import statements..."

▲

aroberge 3 days ago | parent | prev [-]

> Python is quickly turning into a crowded keyword junkyard

* Javascript (ECMAScript) has 63 keywords. * Rust has 50 keywords. * Java has 51 keywords + 17 contextually reserved words, for a total of 68. * Python has now 36 keywords + 4 'soft' keywords, for a total of 40. * Go has 25 keywords.