3 ms·

Getting started in python I quickly ran into the "name shadowing trap" and saw this was the exact same problem as this poor guy had way back in 2004!: https://b

Getting started in python I quickly ran into the "name shadowing trap" and saw this was the exact same problem as this poor guy had way back in 2004!: https://bugs.python.org/issue946373 https://bugs.python.org/issue946373 There are hundreds of "reserved" names that must be avoided when naming scripts, many of them are exactly the sort of names someone might use playing around in a new language, and every update/new module installed can add any number of new ones breaking your existing programs. There really should be a flag or environment variable to specify that the current directory should be ignored (or considered to be at the end of sys.path) for all scripts across the whole system. For something with such an easy fix I'm surprised this foot gun has been left out for 20 years. I mean, the bug report even had a patch included to fix the problem! Wherever you are now wrobell, know that I have shared in your pain and that I thank you for trying to fix this mess.

Spivak 4y ago
I don't know if there's a good solution to this because ignoring the current directory would only solve the first order problem but all those package names would still be essentially reserved, you'll just get bit less often, and you'll have to add your own code into the path explicitly. I think forcing relative imports and adding a new syntax for "project absolute" imports is the real way forward but is totally infeasible because it break everyone's code.
- autoexec 4y ago
  It'd also be much improved if the names of scripts could never be confused for the names of packages... maybe a new file extension like packagename.pm (to steal from perl)? It'd require an update to package names, but nobody would have to update their code.
deleted 4y ago
[deleted]
gorgoiler 4y ago
What are some good strategies for naming things that don’t trigger name shadowing? If I’m writing a library of, say, github functions for our team’s Wibble project I want to put it in wibble.github but that then precludes importing the global github package. wibble.githubutils? wibble.githubhelpers? wibble.githubwrapper? It’s such a silly thing but I’ve never really settled on a best practice for this and wonder what others do.
- autoexec 4y ago
  As long as Wibble was unique I think you'd be okay, but personally I've just been going with option #2 and at the start of every script I modify sys.path to move sys.path[0] to the end. I agree with wrobell that it's hacky and far from the ideal, but it works and it should keep me from running into nasty surprises later. Another idea I saw suggested someplace was to just keep every script or module you create in its own directory to limit the potential for conflicts.
- friendzis 4y ago
  Name shadowing is not unique to python, it exists in every language with semantics allowing to access ancestor scope without fully qualifying the name. A lot of us have been bitten in C++ style languages where introduction of method-local identifier shadows object-local identifier not prefixed with `this`. Python name shadowing is a side of the same coin. I have limited experience with python so take my words with a grain of salt. A working strategy is to go sort of Java style and have local modules/packages/scripts in their own directory beside main script. This way any shadowing you do becomes explicit in code
alrs 4y ago
So great to look at a thread from 2004 and see Josiah Carlson, one of my favorite guys ever.

Spivak 4y ago

I don't know if there's a good solution to this because ignoring the current directory would only solve the first order problem but all those package names would still be essentially reserved, you'll just get bit less often, and you'll have to add your own code into the path explicitly. I think forcing relative imports and adding a new syntax for "project absolute" imports is the real way forward but is totally infeasible because it break everyone's code.

autoexec 4y ago
It'd also be much improved if the names of scripts could never be confused for the names of packages... maybe a new file extension like packagename.pm (to steal from perl)? It'd require an update to package names, but nobody would have to update their code.

deleted 4y ago

[deleted]

gorgoiler 4y ago

What are some good strategies for naming things that don’t trigger name shadowing? If I’m writing a library of, say, github functions for our team’s Wibble project I want to put it in wibble.github but that then precludes importing the global github package. wibble.githubutils? wibble.githubhelpers? wibble.githubwrapper? It’s such a silly thing but I’ve never really settled on a best practice for this and wonder what others do.

autoexec 4y ago
As long as Wibble was unique I think you'd be okay, but personally I've just been going with option #2 and at the start of every script I modify sys.path to move sys.path[0] to the end. I agree with wrobell that it's hacky and far from the ideal, but it works and it should keep me from running into nasty surprises later. Another idea I saw suggested someplace was to just keep every script or module you create in its own directory to limit the potential for conflicts.
friendzis 4y ago
Name shadowing is not unique to python, it exists in every language with semantics allowing to access ancestor scope without fully qualifying the name. A lot of us have been bitten in C++ style languages where introduction of method-local identifier shadows object-local identifier not prefixed with `this`. Python name shadowing is a side of the same coin. I have limited experience with python so take my words with a grain of salt. A working strategy is to go sort of Java style and have local modules/packages/scripts in their own directory beside main script. This way any shadowing you do becomes explicit in code

alrs 4y ago

So great to look at a thread from 2004 and see Josiah Carlson, one of my favorite guys ever.