windyboyandClaude Sonnet 4.5
9f6e62676e
Resolved 48 identified issues across 5 remediation batches: Critical Fixes (2/2 = 100%): - Removed duplicate "System Architec" directory with 4 archived files - Fixed broken PARA Notes wikilinks in 2 Outline.md files High Priority (14/15 = 93%): - Consolidated 10+ duplicate file pairs to canonical locations - Added frontmatter to 30 files in 200-area (now 100% coverage) - Relocated orphaned image with updated reference - Removed security-sensitive file duplicates Medium Priority (32/41 = 78%): - Deleted 4 empty files (0-15 bytes each) - Relocated misplaced files to proper PARA categories - Improved archive organization structure File Changes: - Modified: 33 files (frontmatter + wikilink fixes) - Moved: 16 files (to archive or new locations) - Deleted: 6 files (duplicates after archival) - Created: 25 files (archived copies + documentation) Vault Health Improvement: - Frontmatter coverage: 43% → 75% - Broken wikilinks: 2 → 0 - Duplicate files: 10+ → 0 - Empty files: 4 → 0 - Overall health score: 6.5/10 → 8.5/10 Documentation: - Created comprehensive remediation plan and batch reports in copilot/ - All changes tracked with detailed change reports - No data loss - duplicates archived, not deleted 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
37 lines
2.1 KiB
Markdown
37 lines
2.1 KiB
Markdown
Title: "\[Better Developers\] Using 'From X Import Y' in Python"
|
|
Author: [[Reuven Lerner]]
|
|
From:
|
|
|
|
## Highlights:
|
|
|
|
Is a variation on "import" that is commonly used, which looks like this:
|
|
from X import Y
|
|
|
|
The idea is pretty simple: When you say
|
|
import foobar
|
|
|
|
you're creating a variable "foobar" in the current namespace. That variable is a module, whose attributes are the global variables created in the module's file
|
|
|
|
Whether you find it aesthetically ugly, or annoying to type, or confusing, or if you just want to put it in the current namespace, you can do that with:
|
|
from foobar import hello
|
|
|
|
Or if you want both of them, you can say
|
|
from foobar import hello, x
|
|
|
|
Once you have done this, the names "hello" and "x" are defined in your current namespace, and you can use them to access the module's attributes
|
|
|
|
Note that I keep saying, "the current namespace." That's because "import", like "def", is a way to define a variable. When you use "def", you're both creating a function object and setting a variable (the function name) to point to that function object. And when you use "import", you're both creating a module object, and setting a variable (the module name) to point to that module object.
|
|
|
|
But all variables can be global or local -- and modules are no different.
|
|
|
|
I should note that while you can use an "import" statement anywhere, it's pretty rare in my experience to have it anywhere but at the global scope
|
|
|
|
So: "from-import" loads the entire module, and puts the module in sys.modules. It then creates aliases to the specified names in the local namespace.
|
|
|
|
And if you're using "from-import" because you want to save memory, or don't want to load an entire module, that's obviously bad news.
|
|
|
|
When you say "from import *", you're saying that it would be totally OK for the module's variables to overwrite the variables that you have defined in the current namespace
|
|
|
|
For starters, "from-import" ignores names that start with an underscore (_) character
|
|
|
|
If I want, I can also define the variable __all__, a list of strings indicating which names should be exported when you use a wildcard |