13 ms·

I agree with a number of these but I really don't understand #4. If you want to know what's in a module then 'import foo; help(foo)' in your interpreter will g

I agree with a number of these but I really don't understand #4. If you want to know what's in a module then 'import foo; help(foo)' in your interpreter will give you it. In C you can't just grep /usr/include because you might be importing form somewhere else. And in C everything goes directly into your main namespace, the equivalent of 'form foo import *'. And even with single letter renames you can just quickly check at the top of the file for what the rename is, 'gg<c-o>' in vim and probably similarly easy in most people's editors. And really importing common libraries as single letters should be by convention in a codebase. I really think that Python's import story is one of my favorite things about the language and it's something where I'm often comparing other languages to Python and finding that they're coming up short.

breatheoften 8y ago
There's so much incidental design exposed to the user/library author because of python's import system ... Ultimately you have to step through a large list of questions in order to understand the actual import behavior -- its not easy and adds a large (pointless?) cognitive load for every library user/author ... Are you import'ing a Module or a Package? If it is a package then maybe there's a magic file called __init__.py in a directory that might have an __all__ = [...] array or might just import some other modules but not contain an __all__ or it might import some names from some other modules. Or maybe there's a namespace package somewhere which has some behavior when there are directories that contain .py files but don't have an __init__.py (I honestly don't know the rules -- but I do know they can't be explained to me in a small number of words and that makes me insane!) ... And by the way -- every instance of 'import' used throughout your program is additionally beholden in its behavior to a global runtime magic state magic called the PYTHONPATH (that often has to get munged from the shell environment prior to invoking a python program ...) which is a list of path's that will be consulted/augmented differently depending on whether its a (module/package/namespace) import search to ultimately decide which set of files will be inspected ... As a half-assed python developer (who is firmly in the 'I hate python camp') I honestly have very little idea how you are 'supposed' to use these mechanism when defining a package. I recently tried to figure out actual best practices so I could publish a small package -- I relied on lots of boilerplate copying from what seemed like knowledgable sources. I think I got something vaguely workable (https://github.com/breathe/NotebookScripter https://github.com/breathe/NotebookScripter) but there's a lot of line noise all throughout the filesystem layout ... What is it about my Project name that python demands I should repeat it in the filesystem over and over and over again? I believe this is actually the common pattern for laying out a small library ...: Project/setup.py Project/Project/__init__.py Project/Project/SomethingToDoWithProject.py

breatheoften 8y ago

There's so much incidental design exposed to the user/library author because of python's import system ... Ultimately you have to step through a large list of questions in order to understand the actual import behavior -- its not easy and adds a large (pointless?) cognitive load for every library user/author ... Are you import'ing a Module or a Package? If it is a package then maybe there's a magic file called __init__.py in a directory that might have an __all__ = [...] array or might just import some other modules but not contain an __all__ or it might import some names from some other modules. Or maybe there's a namespace package somewhere which has some behavior when there are directories that contain .py files but don't have an __init__.py (I honestly don't know the rules -- but I do know they can't be explained to me in a small number of words and that makes me insane!) ... And by the way -- every instance of 'import' used throughout your program is additionally beholden in its behavior to a global runtime magic state magic called the PYTHONPATH (that often has to get munged from the shell environment prior to invoking a python program ...) which is a list of path's that will be consulted/augmented differently depending on whether its a (module/package/namespace) import search to ultimately decide which set of files will be inspected ... As a half-assed python developer (who is firmly in the 'I hate python camp') I honestly have very little idea how you are 'supposed' to use these mechanism when defining a package. I recently tried to figure out actual best practices so I could publish a small package -- I relied on lots of boilerplate copying from what seemed like knowledgable sources. I think I got something vaguely workable (https://github.com/breathe/NotebookScripter https://github.com/breathe/NotebookScripter) but there's a lot of line noise all throughout the filesystem layout ... What is it about my Project name that python demands I should repeat it in the filesystem over and over and over again? I believe this is actually the common pattern for laying out a small library ...: Project/setup.py Project/Project/__init__.py Project/Project/SomethingToDoWithProject.py