Re: [Python-Dev] PEP 257 and __init__
On Mon, Jan 4, 2016 at 4:49 AM, Nick Coghlan wrote: > When some of the default settings for the pep8 utility became a > problem, I was able to talk to the developers and persuade them to > tune their defaults to be more in line with the actual PEP text, and > keep their extensions to optional settings. In that spirit, I opened an issue [0] in the pep257 project to be able to configure that and bypass the default behaviour, so the tool can be used in a wider set of projects. Thanks everybody for all the info. Regards, [0] https://github.com/GreenSteam/pep257/issues/171 -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ Twitter: @facundobatista ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] zipimport.c broken with implicit namespace packages
On 3 Jan 2016, at 5:33 pm, Brett Cannon wrote: > > > > On Sun, 3 Jan 2016 at 02:55 Phil Thompson wrote: > On 3 Jan 2016, at 3:41 am, Guido van Rossum wrote: > > > > On Sat, Jan 2, 2016 at 3:26 PM, wrote: > > > > -- > > > "Brett" == Brett Cannon writes: > > > > > I opened > > > https://bugs.python.org/issue25711 to specifically try to > > > fix this issue once and for all and along the way modernize > > > zipimport by rewriting it from scratch to be more > > > maintainable > > > > Every time I read about impementing a custom loader: > > > > https://docs.python.org/3/library/importlib.html > > > > I've wondered why python does not have some sort of virtual > > filesystem layer to deal with locating modules/packages/support > > files. Virtual file systems seem like a good way to store data on a > > wide range of storage devices. > > > > Yeah, but most devices already implement a *real* filesystem, so the only > > time the VFS would come in handy would be for zipfiles, where we already > > have a solution. > > Just to point out that it would be nice to have an easier way to use > something other that zipfiles. I have a need to exploit a different solution > and have to patch the bootstrap code (because the zipfile support is handled > as a special case). BTW the need is to create iOS and Android executables > from frozen Python code. > > Not quite sure about how zip files are a special-case beyond just being put > in sys.meta_path automatically. You can get the same results with a .pth file > or a sitecustomize.py depending on how pervasive your need is. Otherwise feel > free to file an issue at bugs.python.org and we can talk over there about > what you specifically need and if it's reasonable to try and support. I've created http://bugs.python.org/issue26007 and hope it's clear enough what the issue is. Thanks, Phil ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 257 and __init__
On Sun, Jan 3, 2016 at 11:49 PM, Nick Coghlan wrote: > On 4 January 2016 at 17:01, Terry Reedy wrote: > > Ask the PSF/pypi people to either prohibit such names or require a > > disclaimer of some sort. They are inherently confusing: "I took a look > at > > pep008" does not mean that one even looked at the PEP. Even when the > > context makes clear that the referent is the module, there is confusion > as > > to its authoritativeness. That Facudo would post here about the module's > > output illustrates that. To me, the name copying violates our informal > > trademark within Pythonland on 'PEP'. > > I don't think that's the right answer, as opinionated tools do serve a > useful purpose in preventing bikeshedding during code review (people > *expect* computers to be annoyingly pedantic, which frees up the human > reviewers to focus on higher level concerns). As projects evolve over > time, they may develop their own tweaks and customisations in their > style guide and switch to a more configurable tool, or they may not. > > When some of the default settings for the pep8 utility became a > problem, I was able to talk to the developers and persuade them to > tune their defaults to be more in line with the actual PEP text, and > keep their extensions to optional settings. > > A similar approach may work for PEP 257, by clarifying which aspects > tools should be leaving to human judgement (beyond the question of > whether or not to opt in to following PEP 257 at all - it's far less > universal than PEP 8). > Hm. I don't want the PSF to flex its muscles about trademarks, but I still don't like that there are tools named after PEPs (especially since the tools are not written by the same people that wrote the PEPs). I still recall the first time someone emailed me about a "pep8" issue (I had never heard of the tool by that name) and I was thoroughly confused for a long time. That said I expect it's too late to try and get the pep8 authors to rename it; but I filed an issue with the pep257 project and they are going to change the name: https://github.com/GreenSteam/pep257/issues/172 . FWIW I am happy that the tools exist! They can be very useful and I use pep8 myself. But I always let it know who's boss. :-) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] zipimport.c broken with implicit namespace packages
> " " == Brett Cannon writes: ... > It's a reasonable thing to consider, but it would be better to > get zipimport fixed for you, then rewritten To that end, I've added a patch to the issue tracker: https://bugs.python.org/issue17633 My patch is issue17633-3.diff which builds upon issue17633-2.diff in that it fixes an issue with the enumerated value used by find_loader (find_loader was returning -1 which was not even a valid enumerated value). I also expanded the test cases for zipimport to cover namespace packages spread between multiple zip archives and zip archives and real filesystems. Please let me know if there is anything else I can do. Thanks, Mike ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
