Re: [Python-Dev] standard libraries don't behave like standard 'libraries'
On Fri, Nov 13, 2009 at 1:08 AM, "Martin v. Löwis" wrote: > > I am not an expert, I am just another python learner. These are just my > > views on the state of the standard libraries and to > > make them state-of-the-art..! ;) > > If I understand correctly, you want the (current) standard library to be > separated from the Python implementation, and available separately. > > Interestingly enough, people are very much split over whether that would > be a good thing or not. Some like it the way Python does, some dislike > it (and some quite strongly so). > > In any case, many Python users consider it a good thing that it comes > "with batteries included", ie. with no need to add extra stuff for many > tasks. > > Some of the Python maintainers have recently started objecting to this > setup, asking that the standard library should be split into separate > packages that are released and distributed independent of Python. Others > of us feel strongly that such a change should not be made. > > So don't expect any immediate change to happen. > I think the recent postings on "CPAN for Python" in this list also stems from similar thoughts. As the size of the Python std library increases, and when it reaches a kind of implosion point (perhaps it is there already), it does make sense to split it into some thing like a "core" group of modules and add-ons which could be updated dynamically as and when required by a tool. It could be something as simple as a "require" keyword which could pull in the depdencies if not found. Perhaps at the top of your module, require (stuff, '1.27') import stuff Anyone who takes a quick look at the Python std library now is sure to feel that there is an overkill of stuff there, which could be classified and packaged better than dumping into the language build. > Regards, > Martin > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/abpillai%40gmail.com > -- --Anand ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] standard libraries don't behave like standard 'libraries'
On Fri, Nov 13, 2009 at 6:44 PM, Steven D'Aprano wrote: > On Fri, 13 Nov 2009 09:36:10 pm Anand Balachandran Pillai wrote: > > > It could be something as simple as a "require" keyword which could > > pull in the depdencies if not found. Perhaps at the top of your > > module, > > > > require (stuff, '1.27') > > import stuff > > So Python, the *language*, has to become a package management system as > well as a programming language? > > No thank you. > > At most, perhaps there could be a package management tool in the > standard library: > > try: > import stuff > except ImportError: > import packman > found = packman.requires(stuff, '1.27') > if found: >import stuff > else: >fail() > > > That was just a suggestion, don't take it literally. My intention was something similar to the stuff you have written above. It would be however useful to standardize the pkg manager "packman" to something in the standard library however. > > > Anyone who takes a quick look at the Python std library now is > > sure to feel that there is an overkill of stuff there, which could > > be classified and packaged better than dumping into the language > > build. > > I don't. > > I think the std library could possibly be organised better, but just > because something isn't useful to me right now, doesn't mean it isn't > useful to someone, and may be useful to me tomorrow. > > > Ah yes, the only problem is that for any updates/fixes to your module, you need to wait for the language release which is not very much an ideal situation IMHO. Especially now when we are in discussions about end of life of 2.x etc... W.r.t the original analogy, batteries v 1.1 are included with the torch 1.1, but if you want battery upgrade to 1.2, you need to buy torch 1.2.. > > -- > Steven D'Aprano > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/abpillai%40gmail.com > -- --Anand ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pronouncement on PEP 389: argparse?
On Sun, Dec 27, 2009 at 11:21 PM, anatoly techtonik wrote: > On Tue, Dec 15, 2009 at 12:37 AM, Steven Bethard > wrote: > > > > If you're only concerned about 2.X, then yes, optparse will *never* be > > removed from 2.X. There will be a deprecation note in the 2.X > > documentation but deprecation warnings will only be issued when the -3 > > flag is specified. Please see the "Deprecation of optparse" section of > > the PEP: > > > > http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse > > I do not think that optparse should be deprecated at. It is good at > what it does and its limitations make its starting point less > confusing for people with different backgrounds that Python. > > Ref http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse . Considering that optparse will be deprecated like 5 years from now. I think this point is moot. The deprecation strategy IMHO is perhaps way too conservative. Maybe it should be deprecated faster ;) -- --Anand ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhancing the shutil module
On Mon, Jan 18, 2010 at 1:21 AM, Tarek Ziadé wrote: > Hello, > > For 2.7/3.2, I am in the process of removing modules in Distutils that > can be replaced by calls to existing functions in stdlib. For > instance, "dir_util" and "file_util" (old modules from the Python 1.x > era) are going away in favor of calls to shutil (and os), so the > Distutils package gets lighter. > > Another module I would like to move away from Distutils is > "archive_util". It contains helpers to build archives, whether they > are zip or tar files. I propose to move those useful functions into > shutil, as this seems the most logical place. > > I also propose to maintain this "shutil" module for now on (no one is > declared as a maintainer in maintainers.rst) since Distutils will > become a heavy user of its functions. > > Any objections/opinions ? > +1 for this. Just make sure that you change the docstring of shutil which now reads as, " shutil - Utility functions for copying files and directory trees." According to this "definition", archives don't fit in there. But the functionality does fit right in, so just need to make sure that it is reflected in the __doc__ . > Regards, > Tarek > > -- > Tarek Ziadé | http://ziade.org > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/abpillai%40gmail.com > -- --Anand ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] E3 BEFEHLE
On Sun, Jan 17, 2010 at 9:42 AM, Dj Gilcrease wrote: > 2010/1/16 Jack Diederich : > > Good lord, did this make it past other people's spam filters too? I > > especially liked the reference to "REGION -2,0 ; Rlyeh". Ph'nglui > > mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn to you too sir. > > Ya made it past mine too, it looks like a debug dump of a macro for a > some German game based either LOTR or Cthulhu > I initially thought it was a Python disassembler trace of some step of operations which failed, converted to German. In fact, I was looking for a question at the end regarding REPL. How very optimistic... > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/abpillai%40gmail.com > -- --Anand ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] OS information, tags
Hi, I am surprised to see that the bug-tracker doesn't have an OS classifier or ability to add tags ? Since a number of issues reported seem to be OS specific (one can find a lot of Windows only issues upon a search), won't adding these fields help bug triaging ? I am not sure which software is being used by bug tracker so excuse me if this has been already discussed in this form. A quick search in my gmail archives yielded no such discussion. Thanks, -- --Anand ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] OS information, tags
On Tue, Apr 13, 2010 at 6:24 PM, Nick Coghlan wrote: > Senthil Kumaran wrote: > > On Mon, Apr 12, 2010 at 07:06:29PM +0530, Anand Balachandran Pillai > wrote: > >>I am surprised to see that the bug-tracker > >> doesn't have an OS classifier or ability to add > >> tags ? Since a number of issues reported seem to > > > > There is one. In the Components you can do a multiple select and it > > has Macintosh , Windows as options. > Thanks for pointing that out. I missed it. A problem seems to be that for most bugs, the filer seems to select just one component and leave the rest of it to bug description. When I searched with "Windows" component, the most recent bugs I saw was upto 1 week ago, where as a bug like http://bugs.python.org/issue8384 which is a distutils issue reported on Windows is not present, because the reporter chose to file it under "distutils" component. > > I think that setup dates from the Sourceforge days when we didn't have > keywords or the ability to add our own fields. Would it make sense to > put a request on the metatracker to convert these to keywords now that > they're available? Or even a separate OS field with "Windows, Mac OS X, > Linux, *BSD, Other" as the options? > > While there is some Windows and Mac specific code, treating them as > separate components seems fairly unintuitive. > +1. I don't understand why Windows and Mac should come under "Components". It is not very obvious to the reporters also. Separate question: Who is in charge of bug triaging in pydev ? This is something which I would like to help out with, if help is required :-) > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > --- > -- --Anand ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
