Log file Viewer
#pypa-dev logs for Thursday the 12th of February, 2015
[18:57:08] <dstufft> ionelmc: makes it easy to fetch the metadata inside of the setup.py without resorting to crap like regexes or importing the module directly
[18:59:21] <ionelmc> dstufft: isn't setup.py supposed to be just that? (the information display options, or egg_info)
[19:00:24] <sigmavirus24> ionelmc: people use many different ways of organizing the data they shove into the setup.py
[19:01:09] <sigmavirus24> Also means you can perform introspection on a package you're using without using pkgutil some other library or shelling out to pip
[19:01:12] <dstufft> ionelmc: how do I determine, give I have a module foo that I've imported, what version and of what distribution that is?
[19:01:40] <dstufft> at the very best if you already know the distribution name, you can determine what version has installed metadata for it
[19:02:20] <dstufft> ionelmc: which is exactly what __about__ is, it's a place for that stuff to live
[19:02:37] <dstufft> except you don't want to define it in __init__, because __init__ might import things
[19:02:52] <dstufft> so you split it off into __about__.py which doesn't import anything, and just stores the data
[19:02:58] <ionelmc> i'm just saying, separating it in a __about__ module still makes the package's __init__.py execute
[19:05:40] <dstufft> you don't actually import the __about__ module in a context where you care if __init__ is executed
[19:05:41] <Alex_Gaynor> the point is setup.py doesn't import it, it's able to just exec it because it's standalone
[19:06:03] <dstufft> which you can only do because it's stand alone and has no dependencies, it's just some basic assignment
[19:07:00] <dstufft> this actually reduces duplication, you define your verison and such in one place, the __about__.py, everyone else is derrived from that, your setup.py and your docs/conf.py can open() that file and exec it, your __init__.py can import it
[19:11:53] <dstufft> Explicit is better than implicit and thus flake8 complains about unused variables/imports unless they are "exported" via __all__
[19:16:56] <sigmavirus24> Check your global flake8 config to see if you have it silenced, it should be a F-class warning
[19:17:07] <sigmavirus24> ionelmc: it won't complain /now/ because __all__ is defined. Without __all__ it will
[19:18:37] <sigmavirus24> ionelmc: pestering this channel and insisting people do exactly what you want is rude
[19:19:35] <ionelmc> sigmavirus24: i didn't insist to do anything specific, i just asked some questions about why some stuff is the way it is
[19:20:36] <sigmavirus24> ionelmc: "try it" is a command. It's an imperative sentence. You're insisting I drop what I'm currently doing to do what you say
[19:20:41] <dstufft> flake8 at least used to complain about it, if it doesn't now i dunno. but I still think explicit is better than explicit
[19:54:48] <carljm> ionelmc: flake8 definitely complains about unused vars/imports, I rely on that daily.
[19:55:22] <carljm> I have flake8 hooked up directly to my editor, that's the only way I ever notice unused vars or imports.
[20:00:31] <tomprince> pyflakes/flake8 picks up things that are imported, not used, and not in __all__. But not things that are defined but not in __all__. I think.
[20:04:48] <sigmavirus24> tomprince: pyflakes may have cut a new release where it doesn't do that any longer but I'm rather certain it used to until very recently
[20:17:03] <carljm> oh yeah, flake8 doesn't complain about module-level unused vars (at least not that I've ever seen), even without __all__
[20:17:22] <carljm> I always figured that's because it assumed they could be constants meant for import elsewhere