[13:07:12] <ronny> thats significantly less painfull
[13:16:43] <ionelmc> ah yes, the joys of rewriting old software
[13:17:28] <ionelmc> you can tell how better the new code will be by measuring swearing per minute
[14:11:34] <ionelmc> nanonyme: it's actually pretty easy to drop random stuff in site-packages, just dump the stuff in self.build_lib in a custom build command
[14:12:32] <ionelmc> then you only need to override the easy_install and develop commands to get that stuff in site-packages for those too
[14:17:10] <nanonyme> Well, sky is the limit to what I can do given what I did was I dropped a vanilla Python2.7.9 in Git, then use that Python to install more stuff to itself, then ship that Python forward as a ready environment to another machine
[14:17:48] <nanonyme> I just scratched the surface of the setup with trying to make legacy stuff work as expected
[14:18:42] <nanonyme> Pretty much all of the Python build system is written in Python and running in the Python that is being built :)
[14:20:59] <ionelmc> that reminds me, gotta stop using that old python provided by ubuntu
[15:23:53] <nicksloan> Does anyone know why this might happen: https://gist.github.com/nicksloan/3f7bb082c7594b4115c8? I figure this crowd might understand import mechanics a bit better than #python.
[16:23:58] <doismellburning> nicksloan: that is the behaviour I pretty much expect; what surprises you?
[16:24:39] <doismellburning> nicksloan: oh that it's not `.json` or something?
[16:25:01] <nicksloan> doismellburning: no, I would assume the parser couldn't handle .json
[16:25:25] <doismellburning> nicksloan: then what surprises you?
[16:25:29] <nicksloan> It's that I'm asking to import the name JSONEncoder, but I'm also getting the name json, which I did not ask to import
[17:14:47] <nicksloan> here's a full test case: https://github.com/nicksloan/import-issue
[17:15:33] <nicksloan> cd into the directory, run python -m importtest.b and it works as expected (you get an error on print a) run python -m importtest.__init__ and weird behavior occurs.
[17:20:35] <nicksloan> I suspect that it has nothing to do with the occurrence of .json in the import line. I think that any time a submodule of a package is loaded, the submodule is automatically added to the package's namespace.
[17:21:00] <nicksloan> even if the submodule itself isn't imported into the package
[17:57:51] <ionelmc> nicksloan: looks very odd, did you try to report it on http://bugs.python.org/ ?
[18:06:02] <nicksloan> Here's a better example: https://github.com/nicksloan/import-issue
[18:06:19] <nicksloan> I'm trying to verify that this isn't the expected behavior before reporting
[18:06:51] <nicksloan> it seems like it could possibly be a necessary side effect of how submodules are imported.
[18:26:55] <nicksloan> for anyone who is interested, I've updated the example. and provided a python3 branch.
[19:00:02] <ionelmc> nicksloan: looks like a bug to me, it doesn't happen when the `from` import is absolute
[19:11:15] <nicksloan> ionelmc: are you sure? I thought I tested for that with the second example?
[19:11:30] <nicksloan> if my test was insufficient, could you do a quick pull request?
[19:12:02] <ionelmc> nicksloan: doesn't happen on `from json import JSONEncoder`
[19:12:54] <nicksloan> ionelmc: ah. That's because JSONEncoder is not a submodule.
[19:14:46] <nicksloan> this issue only presents when you are in __init__.py of some package, and the name happens to be that of a submodule of the package
[19:35:13] <nicksloan> the reason this has to happen is because when you do "import logging.config", you get both the logging.config module AND the logging module
[19:37:02] <nicksloan> logging.config has to be an attribute of the logging module in that case. The workaround would be for python to make you only import leaf modules, ie "from logging import config"
[19:37:16] <ionelmc> this reminds me of an issue that made me angry a while ago: if, say, you have a module `main`, with a function `main` in it, and in the `main`'s package you do something like `from main import main` then you shadow the main module
[19:37:31] <ionelmc> and certain kinds of imports cease to function
[19:38:15] <ionelmc> well, i think the meaningless `main` name also contributed to me being very angry
[19:44:08] <ionelmc> if there's something already defined for that name then maybe it shouldn't be overriden
[19:44:20] <nicksloan> I think I'm doing too much in __init__.py
[19:44:29] <nicksloan> that's the root of the problem, really
[19:45:44] <nicksloan> the takeaway is that you shouldn't import or define anything in an __init__.py that is the same name as that package's submodules
[19:45:57] <nicksloan> easy enough to solve by aliasing the import
[21:01:50] <nedbat> nicksloan: just catching up: when you do "import logging.config" you don't have logging defined, though you have imported the logging module.
[21:05:00] <nicksloan> nedbat: so what's happening here: https://gist.github.com/nicksloan/2500462ac215339ee05c?
[21:06:29] <nedbat> nicksloan: oh, I am wrong, sorry
[21:06:49] <nedbat> derp. of course logging is defined, because you can do "logging.config.foo"
[21:06:55] <nicksloan> you have to define logging, because you can't have a name like "logging.config"