PMXBOT Log file Viewer

Help | Karma | Search:

#pypa logs for Sunday the 5th of April, 2015

(Back to #pypa overview) (Back to channel listing) (Animate logs)
[11:11:52] <nanonyme> Hmm, any way to update setuptools as --user in Debian 7?
[11:12:09] <nanonyme> Basically I'd need to tell pip to forget the uninstall setp on upgrade
[11:40:46] <ronny> wats the correct way to obtain the folder of site-packages?
[12:52:47] <ionelmc> ronny: distutils.sysconfig.get_python_lib()
[12:52:52] <ionelmc> i think :-)
[12:52:58] <ronny> hmm, i see
[12:53:22] <ionelmc> that works in virtualenvs too
[12:55:02] <ronny> ionelmc: im workin on a develop command for the guby elf again
[12:55:24] <ronny> the idea is to write a python script and dist into into site-packages in a way pip can uninstall it
[12:56:03] <ionelmc> worth checking what the develop command does
[12:56:13] <ionelmc> nothing reusable (conceptually) there?
[12:56:52] <ronny> its utterly broken, messy and fucked up
[12:57:04] <ronny> i already worked on it once
[13:00:39] <doismellburning> aaa
[13:00:40] <doismellburning> ~.
[13:00:46] <doismellburning> sorry
[13:02:29] <ronny> did you take a look at the develop command? i think thats a common reaction :P
[13:06:45] <doismellburning> no, autossh failed on me :P
[13:07:05] <ronny> i see
[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:16:15] <nanonyme> Right
[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
[16:25:59] <doismellburning> nicksloan: ah
[16:26:00] <nicksloan> apparently this only happens if the file that looks like my gist is an __init__.py file
[16:35:12] <dstufft> I'm not nearly awake enough to figure out python import semantics ;)
[16:36:43] <tdsmith> oh, that is odd
[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:15:37] <nicksloan> not sure if this is a bug
[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:13:09] <ionelmc> nicksloan: a what?
[19:13:15] <ionelmc> it's a class no?
[19:13:45] <nicksloan> ionelmc: sorry, I mispoke
[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:16:12] <ionelmc> aaah
[19:16:15] <ionelmc> got it
[19:16:29] <ionelmc> sounds convenient if you put it like that
[19:17:02] <nicksloan> convenient, but weirdly not explicit
[19:17:27] <ionelmc> i think there's gonna be lots of breakage if this is changed
[19:17:41] <nicksloan> yeah. Doubt it can ever be changed
[19:17:48] <nicksloan> definitely not before version 4
[19:17:51] <ionelmc> still, i'd still want to see what the cpython devs say about it
[19:22:01] <nicksloan> I'm definitely curious
[19:34:19] <nicksloan> nedbat: moving the conversation here for ionelmc's benefit
[19:34:25] <nicksloan> I get it now
[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:38:21] <nicksloan> haha
[19:39:17] <ionelmc> i was asking around 'why would anyone do this'
[19:39:25] <nicksloan> so I think I'm convinced now that this is not a bug, and is in fact necessary
[19:40:08] <ionelmc> but then i don't think getting the answer to that question would had appeased my anger
[19:40:29] <ionelmc> thankfully whoever did that left the company before i joined
[19:43:38] <ionelmc> nicksloan: your initial example is interesting because of the shadowing
[19:43:51] <ionelmc> i think that's not desirable
[19:44:00] <nicksloan> ionelmc: yeah, agreed
[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"
[21:07:57] <nedbat> nicksloan: yup, my bad