> to be list_of_string_like_instances or similar :) > Well, this is Python, and we use duck-typing, so everything would need instead of naming a variable "seq" or "list_", I'd have the name while these ones are protected (indeed, I don't mean they shouldn't). Strangely enough, I cannot imagine a use case for 'for' or 'in' or 'while' as names. I have (painfully) learnt a reflex to use 'ranj' for range, 'Seq' for list, 'typ' for type, etc.īut maybe its me and I'm the only one -) I cannot even figure out a debugging process that would point to the real source of the problem - except for a sudden "eureka".Īctually, the issue is that precisely the non-protected build-in words are those so obvious variable names for data or funcs. I consider the _possibility_ of using 'list', 'range' or 'type' as a name for totally custom thing, without even a warning, an issue, not a wishable feature. > it "painful" contrasted with the pain of being unable to use a keywordĭepends on your pov. > Your issue is a valid one, but I have seen no cases where I would call not just effort from the core devs, but the porting effort fromĪll the affected third part developers as well). Keywords purely from the point of view of aggregate development effort
That last point is enough of a reason to dislike the idea of new Python version where the new keyword is enabled by default. Will have to expend additional effort to port their application to the
Any users whose code triggers those warnings Order to warn people about the introduction of the new keyword withoutīreaking existing code. Means going through the whole _future_ and DeprecationWarning dance in In addition to the above and to what Ben said, every new keyword also 'cls', 'class_' or 'klass' instead) and 'assert' (generally replaced You can see the ugly workarounds that are needed in the case ofĪ couple of existing keywords like 'class' (where people have to use You can't do that with keywords - those areĭisallowed everywhere other than in the syntactic constructs that rely However, using builtin names as attribute or method names is often quite > names, but this reason does not seem to hold. > possible? (I thought at not preventing users to use the same words as > expose the reasoning behind keeping the keyword set as small as I have noticed a rather strong and nearly systematic opposition to