Hello, On Mon, 29 Jun 2015 09:15:57 +0100 Paul Moore <[email protected]> wrote:
> On 29 June 2015 at 07:56, Paul Sokolovsky <[email protected]> wrote: > >> If you want to avoid a dependency on pkg_resources, you can use > >> pkgutil.get_data (from the stdlib). It doesn't have as many > >> features as pkg_resources, but it does the job in straightforward > >> cases. > > > > Which makes everyone in the audience wonder: how it happens that > > it's 2015, Python is at 3.5, but pkgutil.get_data() is in stdlib, > > while pkg_resources.resource_stream() isn't? An implementation of > > pkgutil.get_data() would be based on > > pkg_resources.resource_stream(), or would contain just the same > > code as the latter, so it could easily be exposed, and yet it isn't. > > In addition to Nick's response, which are the main reasons, there is > also a more fundamental issue behind this. > > The PEP 302 definition of a loader only provides a get_data method, > which corresponds directly to pkgutil.get_data. Thanks for this clarification, I expected it to be not just purely logistical reason ("nobody yet got to it"), but also technical/API limitation ("Python core/stdlib doesn't have required prerequisites"). But then it's another level of the same question: we have distutils-sig group with people who oversee Python packaging needs (and related questions), they lately told us (Python community) that e.g. we should stop using Eggs and start using Wheels, so there's lot of active work happens in the area, and yet we're stuck at the old base PEPs which overlooked providing stream access protocol for package resources access. Let that be rhetoric question then, and let everyone assume that so far trading eggs for wheels was more important than closing a visible accidental gap in the stdlib/loader API. > Any additional > features provided by pkg_resources are not supported directly by the > loader protocol, and so could not be guaranteed to be present for an > arbitrary loader. pkg_resources provides the extended features (I > believe) by special-casing filesystem and zip loaders, and providing > an extension mechanism for other loaders to participate in the > functionality, but that extension mechanism is not in the stdlib > either. > > So adding more resource loading features means extending the PEP 302 > protocols, etc. That's the work that no-one is currently doing that > blocks the process. > > Having said all this, PEP 302 is pretty old now, and importlib makes > all of this *much* easier, so (as long as you're only targeting recent > Python versions, which stdlib support would be) it's a lot simpler to > do this now than it was when we wrote PEP 302. And of course, in > practical terms filesystem and zip loaders are the only significant > ones that exist anyway... There was recent discussion on python-dev how other languages are cooler because they allow to create self-contained executables. Python has all parts of the equation already - e.g. the standard way to put Python source inside an executable is using frozen modules. So, that's another usecase for accessing package resources - was support for frozen modules was implemented at all? Granted, frozen modules may be not the easiest way for users to achieve self-contained executables, but the whole point is that Python already has it. I'm worked on another small under-popular scripting language before, and felt that I had all opportunities to make the most perfect language ever - except that it yet needs to be done. As soon as opportunity allowed, I switched to MicroPython, to reuse wealth of APIs and schemas devised by smart people, 90% of which are close to perfect. Well, there's gaps and warts still. So, per the above logic, I don't try to invent something new, but use (at least for starters) frozen modules in MicroPython. But then there's interesting situation - frozen modules are core Python feature, while accessing arbitrary files in them as stream is not. So, even if the core interface doesn't require me to provide stream access to files in frozen modules, I still need to provide it, otherwise I simply won't be able to freeze real-world Python packages. > > Paul -- Best regards, Paul mailto:[email protected] _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
