Re: [Python-Dev] Rounding Decimals
On Jan 6, 2008 10:51 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Jeffrey Yasskin] > >> > I'm not > >> > sure exactly what you're objecting to. Could you be more precise? > >> > >> You note said: "I'll implement Context.round() in a separate patch. > >> Comment away." > > > > Oh, sorry for not being clear then. I don't intend to write or discuss > > that separate patch until this one's approved and submitted. I think > > it's worth discussing eventually, but this change is more important. I > > mentioned this sentiment at http://bugs.python.org/msg59417 too, but > > clearly wasn't explicit enough in either case. > > It's hard to keep up with all of these patches and I'm growing concerned > that some will sneak by. You're certainly right to be concerned. The most significant patch, the original backport of 3141, _did_ sneak through. The only email I've gotten about it has been in response to my question about a detail. I don't know how I could have made it more obvious though: nobody who suggested the backport (http://bugs.python.org/issue1623) seemed to think it would be contentious enough to suggest emailing this list first. Since then, I've tried to keep things transparent by suggesting that you add yourself to the nosy list of http://bugs.python.org/issue1623, which is where I'll post any patches before thinking about committing them. > In the case of complex proposals, it is often > helpful to have a patch that we can discuss concretely, but in the case of > simple ones like this, they just clutter to patch tracker. There's no need > to create the patch until the idea has been discussed. I always like to have a patch around because abstract discussions, even (especially?) on simple topics, have a tendency to run off into the weeds. A patch keeps things focused and moving forward. > In the case of Context.round(), I've already advised against it. > So, I'm not sure why you still intend write a separate patch > and bring it back up for discussion. Ideally, it should die right now. You advised against it. Tim, Mark, and glyph advised for something like it. I think it's consistent with the fact that most operations on Decimal instances are mirrored on Context instances, and __round__ will be an operation on Decimal instances. That doesn't sound like enough agreement to simply drop the discussion. > The sentiment is unchanged -- please do not build-out the API for the > decimal module. It is intended to be minimal and needs to stay that > way. Further additions will only make it harder to use, harder to > maintain, and will complicate efforts to rewrite the module in C. I am not building out the decimal API. I am adding enough methods to maintain the comment that "Decimal floating point objects share many properties with the other builtin numeric types such as float and int. All of the usual math operations and special methods apply." in both 2.6 and 3.0. After that's done, I am interested in talking about adding one method that 3 people on this list have been interested in. I understand that you need to be vigilant against extraneous methods, but I'm really not just adding these on a whim. On Jan 6, 2008 11:28 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Jeffrey Yasskin] > > Given Guido's agreement, expect another version of this patch with > > only __trunc__. > > Why is __trunc__ being backported? Is a trunc() builtin being backported? > What is the point for a synonym for int() and __int__ in > Py2.6. > > Unless I'm missing something, this doesn't improve Py2.6 in the least. The trunc() builtin was backported in http://svn.python.org/view?rev=59671&view=rev and hasn't been rolled back. All of the reasons to include trunc() in 3.0 apply to 2.6. A couple that I like are: if trunc had been around in the beginning, __index__ would have been unnecessary; and the name says what it's doing, unlike int(). I don't know what Guido's reasoning was for accepting it into the PEP. -- Namasté, Jeffrey Yasskin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rounding Decimals
[Jeffrey Yasskin] > I always like to have a patch around because abstract discussions, > even (especially?) on simple topics, have a tendency to run off into > the weeds. A patch keeps things focused and moving forward. Please recognize that our little system of patches and newsgroup discussions is easily overwhelmed by someone who is so prolific. Your work will not receive quality review and discussion if the volume blows beyond the bandwidth of the other participants. >> The sentiment is unchanged -- please do not build-out the API for the >> decimal module. It is intended to be minimal and needs to stay that >> way. Further additions will only make it harder to use, harder to >> maintain, and will complicate efforts to rewrite the module in C. > > I am not building out the decimal API. I am adding enough methods to > maintain the comment that "Decimal floating point objects share many > properties with the other builtin numeric types such as float and int. > All of the usual math operations and special methods apply." in both > 2.6 and 3.0. After that's done, I am interested in talking about > adding one method that 3 people on this list have been interested in. > I understand that you need to be vigilant against extraneous methods, > but I'm really not just adding these on a whim. Arghh! You seem hell-bent on jamming this in. Please leave the decimal module alone. It does *not* need both a round() method and a quantize() method. I read Glyph's note and agree that it wasn't obvious how to round with the existing API. That is a documentation problem, not a call to add duplicate methods. When one of the module authors asks you to refrain for expanding the API, please pay special attention. In this case, you are working directly against a core philosophy for the design and maintenance of the module. I admire your enthusiasm, but please hold it in check. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 07/01/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote: > There seems to be a misunderstanding. This is *not* going to happen > for standard library package names. I'm fine with inventing mechanisms > to allow 3rd party packages to beo cobbled together from multiple > contributions (it would seem to make sense for e.g. Twisted or Zope). > But I am absolutely squarely against 3rd party installs adding to (or > worse, overriding) standard library package names. This is (to me) > simple common sense, the reason being "knowing who to blame". We get > enough bug reports in the Python tracker about 3rd party software as > it is. OK, that seems pretty clear. In which case, I'm -1 on having a "databases" package in the stdlib (this discussion should probably move back to the stdlib reorg list now). Keeping things like sqlite at the top level seems fine to me. I don't have a general rule I'm applying here - I think each suggestion should be considered on its own merits. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Sun, Jan 06, 2008 at 04:23:59PM -0800, Guido van Rossum wrote: > I don't want "py" or "python" to be > part of the stdlib package namespace. *If* (part of) the stdlib has to > live under a single distinguished name, pick something like "std" or > "core". When I'm using Python I already know I'm using Python, I don't > want to be reminded of that fact on every import line. When I'm using Jython - am I using Python of Java? After from java.lang import Class should it be from py import exceptions or from core import exceptions ? Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 2008-01-06 16:33, Christian Heimes wrote: > Hello! > > We are discussing name space packages on the stdlib reorg list. For > Python 3.0 we plan to organize the packages by purpose, e.g. put all > database related packages like sqlite and shelve in a 'databases' name > space. Regardless of whether this would really be helpful or not (I used to be in favor of this some time ago, but then realized that this doesn't really buy you anything much), please be aware that by using new generic top-level names you are likely going to get into conflict with existing applications. 'databases' will likely work since most apps will use 'database' as module or package name. > Of course we want to have the name spaces extensible by 3rd party > software. This is not a good idea. The standard lib should not be extensible by 3rd party packages, instead they should use their own top-level package and deal with whatever namespace extension mechanism is used in that package. > The Python world as currently two ways to create extensible > name space packages: pkgutil and pkg_resource. I don't think pkg_resources should go into Python 2.6 as is - for the reasons I've stated last year when this question came up. I also don't like the import mechanism hackery that's being used in setuptools to get namespace packages working. IMHO, it would be a lot cleaner to extend the existing import mechanism to support search continuation, ie. have the import find mechanism continue the search for a sub-package if it doesn't find the module in the first instance of a top-level package directory. E.g. say you want to import 'a.c' and you have directories on you sys.path: libs1/a/ libs1/a/__init__.py libs1/a/b.py libs2/a/ libs2/a/__init__.py libs2/a/c.py the import mechanism would look in libs1/a/, see that c.py is not available, then continue the search and find libs2/a/c.py. This is a sketch, but I think you get the idea. Next, we add a per-user site-packages directory to the standard sys.path, and then we could get rid of most of the setuptools import and sys.path hackery, making it a lot cleaner. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 07 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 2008-01-07 14:57, Fred Drake wrote: > On Jan 7, 2008, at 7:48 AM, M.-A. Lemburg wrote: >> Next, we add a per-user site-packages directory to the standard >> sys.path, and then we could get rid of most of the setuptools >> import and sys.path hackery, making it a lot cleaner. > > > PYTHONPATH already provides this functionality. I see no need to > duplicate that. Agreed, but one of the main arguments for all the .pth file hackery in setuptools is that having to change PYTHONPATH in order to enable user installations of packages is too hard for the typical user. We could easily resolve that issue, if we add a per-user site-packages dir to sys.path in site.py (this is already done for Macs). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 07 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 7, 2008, at 7:48 AM, M.-A. Lemburg wrote: > Next, we add a per-user site-packages directory to the standard > sys.path, and then we could get rid of most of the setuptools > import and sys.path hackery, making it a lot cleaner. PYTHONPATH already provides this functionality. I see no need to duplicate that. -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote: > We could easily resolve that issue, if we add a per-user site-packages > dir to sys.path in site.py (this is already done for Macs). +1. I've advocated that for years. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR4I4EHEjvBPtnXfVAQLpPwQAizIj/FBCc9tTNVoPRTghv37WVL0wAk8Z WtmDVpag8H/j7uNKKwMd7Ld0HdVMAwpDetdGPklDnhMDqD/jY5Da2551uKgawFnZ 57WfY5C/VvYbI8jofDEJxb2bEJyG2QILnqut+D8/9zU+z/G1ubL+jgTY03F7a71O JQAaGa6DxNU= =S5C/ -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Rounding Decimals
2008/1/7, Raymond Hettinger <[EMAIL PROTECTED]>: > Arghh! You seem hell-bent on jamming this in. Please leave the > decimal module alone. It does *not* need both a round() method > and a quantize() method. Question. I'm so used to quantize that I don't care. And I'm, in general, -0 to adding new methods to Decimal and/or Context. But in Py3, when you make round(x), x.__round__ will be executed. Same with trunc, ceil and floor. And I think that Decimal should grow these __xxx__ methods. Having said that, the only thing that is not clear to me is if we should: - Diverge 2.6 and 3.0 decimal.py code - Add these __xxx__ to 2.6, and have still one code of decimal. Guido voted for this last one, in the issue 1623: """ If there aren't too many differences between the 2.6 and 3.0 version of decimal.py and your patch, do 2.6 first, then the next time we merge stuff into 3.0 from the trunk it'll be forward-ported automatically. """ But, in the light of this thread, and the new PEP that you will be writing, I think that now it's time to decide this. Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Pydotorg] Do we need both Trac and Roundup?
[EMAIL PROTECTED] wrote: > Do people think it would be worthwhile to merge the Trac tracker content > (the issue tracker that holds tickets related to the python.org website) > into the Roundup tracker (the issue tracker that holds tickets related to > Python the language)? While they are nominally distinct activities, it > seems to me that we must waste some precious resources (mostly people) > maintaining two mostly disjoint trackers. There is also some functionality > overlap, mostly in the documentation area. It would be great to merge into Roundup. The Trac instance is ancient and I've not had the time to try to upgrade it, which would indeed now be a waste of effort. When Roundup is ready, please let me know and I can at least make a pass through the pydotorg tickets to close those that aren't worth moving over to Roundup. There are quite a few stale and questionable items. In fact, it wouldn't be the end of the world to discard almost all of them, but still worth a review. - Stephan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 7, 2008 6:32 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote: > > We could easily resolve that issue, if we add a per-user site-packages > > dir to sys.path in site.py (this is already done for Macs). > > +1. I've advocated that for years. I'm not sure what this buys given that you can do this using PYTHONPATH anyway, but because of that I also can't be against it. +0 from me. Patches for 2.6 gratefully accepted. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Rounding Decimals
On Mon, Jan 07, 2008, Raymond Hettinger wrote: > [Jeffrey Yasskin] >> >> I am not building out the decimal API. I am adding enough methods to >> maintain the comment that "Decimal floating point objects share many >> properties with the other builtin numeric types such as float and int. >> All of the usual math operations and special methods apply." in both >> 2.6 and 3.0. After that's done, I am interested in talking about >> adding one method that 3 people on this list have been interested in. >> I understand that you need to be vigilant against extraneous methods, >> but I'm really not just adding these on a whim. > > Arghh! You seem hell-bent on jamming this in. Please leave the > decimal module alone. It does *not* need both a round() method > and a quantize() method. > > I read Glyph's note and agree that it wasn't obvious how to round > with the existing API. That is a documentation problem, not a call > to add duplicate methods. Excuse me. I have always thought that "quantize()" makes Decimal confusing in the context of the other mechanisms that Python makes available for other kinds of numbers. I have refrained from making an issue of it because I understand and (mostly) support the idea of keeping Decimal restricted to matching the decimal standard, but at this point, it seems that Tim Peters likes the idea, too. While I have a lot of respect for you, I think Uncle Timmy deserves some special respect, too. > When one of the module authors asks you to refrain for expanding > the API, please pay special attention. In this case, you are working > directly against a core philosophy for the design and maintenance > of the module. I'm not a current maintainer, but I was one of the instigators for the existence of Decimal. I understand that you're feeling frustrated about changes getting shoved in, but I don't think that discussion should be shut down because you have a particular point of view: the decimal module does not represent only your work. I suggest that the patches get dropped for the moment and the discussion rebooted. I haven't been following closely, but it seems that the main issue is that Python 3.0 is introducing a __round__() method. How do you think the decimal module should handle that? (Although I still like the idea of a .round() method for decimals, I think that round(Decimal()) is probably sufficient enough that I won't insist on it.) -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 7, 2008, at 10:12 AM, Guido van Rossum wrote: > On Jan 7, 2008 6:32 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: >> On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote: >>> We could easily resolve that issue, if we add a per-user site- >>> packages >>> dir to sys.path in site.py (this is already done for Macs). >> >> +1. I've advocated that for years. > > I'm not sure what this buys given that you can do this using > PYTHONPATH anyway, but because of that I also can't be against it. +0 > from me. Patches for 2.6 gratefully accepted. I think it's PEP-worthy too, just so that the semantics get nailed down. Here's a strawman proto-quasi-pre-PEP. Python automatically adds ~/.python/site-packages to sys.path; this is added /before/ the system site-packages file. An open question is whether it needs to go at the front of the list. It should definitely be searched before the system site-packages. Python treats ~/.python/site-packages the same as the system site- packages, w.r.t. .pth files, etc. Open question: should we add yet another environment variable to control this? It's pretty typical for apps to expose such a thing so that the base directory (e.g. ~/.python) can be moved. I think that's all that's needed. It would make playing with easy_install/setuptools nicer to have this. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR4JSJ3EjvBPtnXfVAQIXfgP9HCi8PNwUbPTbeaf7JPHLTkguYwUAyLH2 vD31w76fnh3pChIZSY9CtP51qRmB22DChSQxaagLmnl9FXjdS1dmXOu7oT7lfj2z avTptyJ2MB8kFuGLK2In/mjbWxPUgAd19sbm4jtE5b3nauOBVyZh23TxFvH5uRdD bUaqRNib3vE= =P3p4 -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 2008-01-07 17:24, Barry Warsaw wrote: > On Jan 7, 2008, at 10:12 AM, Guido van Rossum wrote: > >> On Jan 7, 2008 6:32 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: >>> On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote: We could easily resolve that issue, if we add a per-user site-packages dir to sys.path in site.py (this is already done for Macs). >>> >>> +1. I've advocated that for years. > >> I'm not sure what this buys given that you can do this using >> PYTHONPATH anyway, but because of that I also can't be against it. +0 >> from me. Patches for 2.6 gratefully accepted. > > I think it's PEP-worthy too, just so that the semantics get nailed > down. Here's a strawman proto-quasi-pre-PEP. > > Python automatically adds ~/.python/site-packages to sys.path; this is > added /before/ the system site-packages file. An open question is > whether it needs to go at the front of the list. It should definitely > be searched before the system site-packages. > > Python treats ~/.python/site-packages the same as the system > site-packages, w.r.t. .pth files, etc. > > Open question: should we add yet another environment variable to control > this? It's pretty typical for apps to expose such a thing so that the > base directory (e.g. ~/.python) can be moved. I'd suggest to make the "~/.python" part configurable by an env var, e.g. PYTHONRESOURCES. Perhaps we could use that directory for other Python-related resources as well, e.g. an optional sys.path lookup cache (pickled dictionary of known package/module file locations to reduces Python startup time). > I think that's all that's needed. It would make playing with > easy_install/setuptools nicer to have this. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 07 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
At 01:48 PM 1/7/2008 +0100, M.-A. Lemburg wrote: >I also don't like the import mechanism hackery that's being >used in setuptools to get namespace packages working. I believe you're mistaken: there is no import mechanism "hackery" in pkg_resources. (__path__ is a documented *hook*, not a hack, and it's the only import-related hook that pkg_resources uses). And, if you don't like namespace packages, perhaps you should be campaigning for this to be removed: http://python.org/doc/2.4.1/lib/module-pkgutil.html pkg_resources only updates the routine provided in pkgutil to be a bit more automatic, and to better support PEP 302 and zipfile importing. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
At 03:01 PM 1/7/2008 +0100, M.-A. Lemburg wrote: >On 2008-01-07 14:57, Fred Drake wrote: > > On Jan 7, 2008, at 7:48 AM, M.-A. Lemburg wrote: > >> Next, we add a per-user site-packages directory to the standard > >> sys.path, and then we could get rid of most of the setuptools > >> import and sys.path hackery, making it a lot cleaner. > > > > > > PYTHONPATH already provides this functionality. I see no need to > > duplicate that. > >Agreed, but one of the main arguments for all the .pth file hackery in >setuptools is that having to change PYTHONPATH in order to enable >user installations of packages is too hard for the typical user. > >We could easily resolve that issue, if we add a per-user site-packages >dir to sys.path in site.py (this is already done for Macs). Actually, neither PYTHONPATH nor your proposal solve all of the problems that .pth files do. To date, nobody has proposed any real substitute for them. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
At 11:24 AM 1/7/2008 -0500, Barry Warsaw wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >On Jan 7, 2008, at 10:12 AM, Guido van Rossum wrote: > > > On Jan 7, 2008 6:32 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > >> On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote: > >>> We could easily resolve that issue, if we add a per-user site- > >>> packages > >>> dir to sys.path in site.py (this is already done for Macs). > >> > >> +1. I've advocated that for years. > > > > I'm not sure what this buys given that you can do this using > > PYTHONPATH anyway, but because of that I also can't be against it. +0 > > from me. Patches for 2.6 gratefully accepted. > >I think it's PEP-worthy too, just so that the semantics get nailed >down. Here's a strawman proto-quasi-pre-PEP. > >Python automatically adds ~/.python/site-packages to sys.path; this is >added /before/ the system site-packages file. An open question is >whether it needs to go at the front of the list. It should definitely >be searched before the system site-packages. What about including the Python version in the directory name? C Extensions may not work correctly across versions, and bytecode will get recompiled a lot if you're using multiple versions. Also, if this is a 2.6/3.0 change, it's likely that the *source* won't be compatible across versions either. :) >Python treats ~/.python/site-packages the same as the system site- >packages, w.r.t. .pth files, etc. > >Open question: should we add yet another environment variable to >control this? It's pretty typical for apps to expose such a thing so >that the base directory (e.g. ~/.python) can be moved. > >I think that's all that's needed. It would make playing with >easy_install/setuptools nicer to have this. Assuming that this is a true "site" directory (i.e., .pth files are recognized), then yes. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Rounding Decimals
[Aahz] > I have always thought that "quantize()" makes Decimal > confusing in the context of the other mechanisms that Python makes > available for other kinds of numbers. No doubt, the spec made a number of choices that are obvious only if you work at IBM. And, there is no doubt, the module has a high level of complexity. Jeffrey is proposing to add a Context.round() method with the purpose of making the module easier to use. I contend that this is self-defeating on the face of it. Please count the number of existing Context methods ( http://docs.python.org/dev/library/decimal.html#context-objects ) and tell me that adding yet another method will reduce complexity or shorten the learning curve. In fact, it will just further confuse which method should be used. Also, I thought we were committed to a minimal implementation of the spec. One reason for this was that programs could be ported back and forth with other implementations of the spec. Another reason is that the core spec has extensive test cases while build-outs have none. And another reason is that we are trying to make life easier for someone (perhaps me) to rewrite the module in C. There is also the principle of having only one way to do it. However, we already have Decimal.quantize and Context.quantize and are about to introduce a number of magic methods callable from builtin functions. Do we really need even more ways to round? The rounding operation is so fundamental to the module that user must grapple with it at some point. Having multiple ways to do it will only make that task more difficult. I spent about a month of my life cleaning, documenting, and testing the decimal module to get it ready for prime time. I'm not at all pleased at the current proposal to add a duplicate method. If someone really cared about making the module easier to use, I would fully support efforts to write a tutorial on the fundamentals or an effort to write a client module implementing only a subset of the spec. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008 8:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Jan 6, 2008 7:23 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > At 04:23 PM 1/6/2008 -0800, Guido van Rossum wrote: > > >Regarding using common words, either the stdlib grabs these, or > > >*nobody* gets to use them (for fear of conflicting with some other 3rd > > >party package grabbing the same). > > > > This isn't quite true; a standalone Python application that isn't > > extensible doesn't need to worry about this. And it's standalone > > apps that are most likely to claim these common words. (For example, > > until recently, Chandler's database library packages were in > > 'repository.*'.) > > > > But of course this is still a pretty minor point overall. If the > > stdlib does go for deeper nestings, I have a slight preference for > > seeing them under std.* or some such rather than top level. But I > > don't really see a whole lot of point to doing a major re-org of the > > stdlib space to begin with, for the simple reason that package names > > are not really categories -- they're *names*. IMO 'from databases > > import sqlite' doesn't add any value over 'import pysqlite3' to begin with. > > > > Worse, it will likely be an attractive nuisance for people saying > > "why don't we have databases.Oracle?" and suchlike. And you still > > have to remember the names, only now they're longer. And was it > > database or databases? Greater uniqueness of names is just another > > reason flat is better than nested. :) > > Right. Packages are useful if it helps make the sub-names shorter. The > email package is a good example: it uses lots of generic names like > errors, charset, encoders, message, parser, utils, iterators. So only do the 'databases' package if we can change the modules names to make it worth it? So whichdb becomes databases.which, dumbdbm becomes databases.dumb, etc.? And then extend this to any other package that we consider creating? Otherwise leave it out? How would that follow for sqlite since that is not going to get any shorter thanks to a package? Should it still go into the package for organizational purposes? In other words, should the stdlib reorg only introduce new packages if the majority of modules that go into the package end up with a shorter name? -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 7, 2008 12:19 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > On Jan 6, 2008 8:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On Jan 6, 2008 7:23 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > > At 04:23 PM 1/6/2008 -0800, Guido van Rossum wrote: > > > >Regarding using common words, either the stdlib grabs these, or > > > >*nobody* gets to use them (for fear of conflicting with some other 3rd > > > >party package grabbing the same). > > > > > > This isn't quite true; a standalone Python application that isn't > > > extensible doesn't need to worry about this. And it's standalone > > > apps that are most likely to claim these common words. (For example, > > > until recently, Chandler's database library packages were in > > > 'repository.*'.) > > > > > > But of course this is still a pretty minor point overall. If the > > > stdlib does go for deeper nestings, I have a slight preference for > > > seeing them under std.* or some such rather than top level. But I > > > don't really see a whole lot of point to doing a major re-org of the > > > stdlib space to begin with, for the simple reason that package names > > > are not really categories -- they're *names*. IMO 'from databases > > > import sqlite' doesn't add any value over 'import pysqlite3' to begin > > > with. > > > > > > Worse, it will likely be an attractive nuisance for people saying > > > "why don't we have databases.Oracle?" and suchlike. And you still > > > have to remember the names, only now they're longer. And was it > > > database or databases? Greater uniqueness of names is just another > > > reason flat is better than nested. :) > > > > Right. Packages are useful if it helps make the sub-names shorter. The > > email package is a good example: it uses lots of generic names like > > errors, charset, encoders, message, parser, utils, iterators. > > So only do the 'databases' package if we can change the modules names > to make it worth it? So whichdb becomes databases.which, dumbdbm > becomes databases.dumb, etc.? Bad example IMO; these are all about relatively simple "dict-on-disk" APIs, not about (relational) databases. I'd be +0 things like dbm.gnu, dbm.any, dbm.dumb, dbm.which. > And then extend this to any other > package that we consider creating? Otherwise leave it out? How would > that follow for sqlite since that is not going to get any shorter > thanks to a package? Should it still go into the package for > organizational purposes? If you're asking me, the "organizational purpose" is 100% misguided. > In other words, should the stdlib reorg only introduce new packages if > the majority of modules that go into the package end up with a shorter > name? See what others say. Another reason to have a top-level package would be if there are a lot of subpackages/submodules. This applies to the xml package for example. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 7, 2008 12:40 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On Jan 7, 2008 12:19 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > > On Jan 6, 2008 8:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > On Jan 6, 2008 7:23 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > > > At 04:23 PM 1/6/2008 -0800, Guido van Rossum wrote: > > > > >Regarding using common words, either the stdlib grabs these, or > > > > >*nobody* gets to use them (for fear of conflicting with some other 3rd > > > > >party package grabbing the same). > > > > > > > > This isn't quite true; a standalone Python application that isn't > > > > extensible doesn't need to worry about this. And it's standalone > > > > apps that are most likely to claim these common words. (For example, > > > > until recently, Chandler's database library packages were in > > > > 'repository.*'.) > > > > > > > > But of course this is still a pretty minor point overall. If the > > > > stdlib does go for deeper nestings, I have a slight preference for > > > > seeing them under std.* or some such rather than top level. But I > > > > don't really see a whole lot of point to doing a major re-org of the > > > > stdlib space to begin with, for the simple reason that package names > > > > are not really categories -- they're *names*. IMO 'from databases > > > > import sqlite' doesn't add any value over 'import pysqlite3' to begin > > > > with. > > > > > > > > Worse, it will likely be an attractive nuisance for people saying > > > > "why don't we have databases.Oracle?" and suchlike. And you still > > > > have to remember the names, only now they're longer. And was it > > > > database or databases? Greater uniqueness of names is just another > > > > reason flat is better than nested. :) > > > > > > Right. Packages are useful if it helps make the sub-names shorter. The > > > email package is a good example: it uses lots of generic names like > > > errors, charset, encoders, message, parser, utils, iterators. > > > > So only do the 'databases' package if we can change the modules names > > to make it worth it? So whichdb becomes databases.which, dumbdbm > > becomes databases.dumb, etc.? > > Bad example IMO; these are all about relatively simple "dict-on-disk" > APIs, not about (relational) databases. I'd be +0 things like dbm.gnu, > dbm.any, dbm.dumb, dbm.which. > OK. So an html package could have htmllib for its __init__ (or html.lib), and then have html.entities and html.parser for htmlentitydefs and HTMLParser, respectively. Another example is http: http.lib, http.server.cgi, http.server.base, http.server.simple. Both examples are grouped because they make sense, but primarily to make the tail module name simpler. > > And then extend this to any other > > package that we consider creating? Otherwise leave it out? How would > > that follow for sqlite since that is not going to get any shorter > > thanks to a package? Should it still go into the package for > > organizational purposes? > > If you're asking me, the "organizational purpose" is 100% misguided. > Well that will make the reorg simpler. =) > > In other words, should the stdlib reorg only introduce new packages if > > the majority of modules that go into the package end up with a shorter > > name? > > See what others say. This will be interesting. > > Another reason to have a top-level package would be if there are a lot > of subpackages/submodules. This applies to the xml package for > example. The only place I can see that coming into play is if there is any desire to group OS-specific modules together. Otherwise I think Tk-specific stuff is the only place where this has not been done before. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 7, 2008, at 11:37 AM, Phillip J. Eby wrote: >> Python automatically adds ~/.python/site-packages to sys.path; this >> is >> added /before/ the system site-packages file. An open question is >> whether it needs to go at the front of the list. It should >> definitely >> be searched before the system site-packages. > > What about including the Python version in the directory name? C > Extensions may not work correctly across versions, and bytecode will > get recompiled a lot if you're using multiple versions. Also, if > this is a 2.6/3.0 change, it's likely that the *source* won't be > compatible across versions either. :) D'oh, yes of course. So make that: ~/.python/lib/pythonX.Y/site-packages >> Python treats ~/.python/site-packages the same as the system site- >> packages, w.r.t. .pth files, etc. >> >> Open question: should we add yet another environment variable to >> control this? It's pretty typical for apps to expose such a thing so >> that the base directory (e.g. ~/.python) can be moved. >> >> I think that's all that's needed. It would make playing with >> easy_install/setuptools nicer to have this. > > Assuming that this is a true "site" directory (i.e., .pth files are > recognized), then yes. IMO, it should be a true site directory. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR4KTN3EjvBPtnXfVAQI6twP9HUQ23I0KCGZy4CC9sA6vvM5xYfmEgKQb 7H9AP84nSqaaX0iyONmRqlPahzHaEkjkoMW68EA3AIkXagf72sNbyBMO1p7I7ZQ6 5X6dR78o8w+NywO6sgdgxqQq3ikXNEEAy2EICLamT94Um1QxR7OV7SlihdpDs20w MujSDYAr9CQ= =el6S -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 7, 2008, at 11:30 AM, M.-A. Lemburg wrote: >> Open question: should we add yet another environment variable to >> control >> this? It's pretty typical for apps to expose such a thing so that >> the >> base directory (e.g. ~/.python) can be moved. > > I'd suggest to make the "~/.python" part configurable by an > env var, e.g. PYTHONRESOURCES. Since we can't use PYTHONOHOME, this works for me. > Perhaps we could use that directory for other Python-related > resources as well, e.g. an optional sys.path lookup cache (pickled > dictionary of known package/module file locations to reduces Python > startup time). Sure, why not? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR4KTn3EjvBPtnXfVAQLQlAP/R887WX0k3VNPoiyVs3qerYBj0XQyP4DT leyFWInEamtgk1+5hL+Vu180k+EFcjEQ8d2yet3sMMVUZ4piFHEd6SdNJantVKrl YBVTHkhEBNX2qMFxYmyTwzvjaMttbIn5w9TuEG4PnNiYQv4E4HlZ9HOkRY9YuNDh UMr4e4DCZtw= =PI+B -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 7, 2008, at 3:56 PM, Brett Cannon wrote: > OK. So an html package could have htmllib for its __init__ (or > html.lib), and then have html.entities and html.parser for > htmlentitydefs and HTMLParser, respectively. Actually, I'd be inclined not to have both HTMLParser and htmllib (regardless of names); a single capable interface should be provided. But that's a separate discussion. -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
>> And then extend this to any other >> package that we consider creating? Otherwise leave it out? How would >> that follow for sqlite since that is not going to get any shorter >> thanks to a package? Should it still go into the package for >> organizational purposes? > If you're asking me, the "organizational purpose" is 100% misguided. It is my hope that there will be a great deal of restraint in the effort to group modules into packages in Py3.0. For the most part, putting modules in packages only makes them more difficult to access and introduces an additional burden of remembering which package to invoke. The best existing indicator we have is the organization of the docs for the standard library. I, for one, have a hell of a difficult time finding modules via the "organized" table of contents in the Library Reference. Instead, I always go the the Global Module Index where the somewhat flat namespace makes it easy to go directly to the module of interest. I'm curious whether the other developers have had the same experience -- if so, then it is a bad omen for over-organizing the standard library. Another indicator of what lies ahead is the current organization of os vs os.path. While that split-out was well done and necessary, I routinely have difficulty remembering which one contains a function of interest. There are handful of groupings that are obvious (i.e. html and socket modules going into an internet package). Outside of those, I think it best to leave the rest of the modules in a flat namespace (I don't want to have to quess where to find queue, random, pickle, pprint, decimal, and collections. I think most of the concerns with the standard library revolve around module quality, duplication, and obsolence. In contrast, I do not think that introducing a hierarchy of namespaces is of interest to most users. That exercise may well make the language harder to use/learn, not easier. my-two-cents-ly, Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 07/01/2008, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > It is my hope that there will be a great deal of restraint in the effort to > group modules into > packages in Py3.0. +1 > The best existing indicator we have is the organization of the docs for the > standard library. > I, for one, have a hell of a difficult time finding modules via the > "organized" table of > contents in the Library Reference. Instead, I always go the the Global Module > Index > where the somewhat flat namespace makes it easy to go directly to the module > of > interest. I'm curious whether the other developers have had the same > experience -- if so, > then it is a bad omen for over-organizing the standard library. Yes, I have the same problem. I had not considered this, but I agree that it's the best indication available of how a hierarchical organisation might end up, and what issues there might be. >From the Zen of Python: "Flat is better than nested". > There are handful of groupings that are obvious (i.e. html and socket modules > going into > an internet package). One man's obvious is another man's confusing. I'd stick to Guido's principle, that packages should only be used where they simplify sub-names. And even there, use restraint. I know I was earlier tending more towards the side of having more packages. I've been convinced otherwise. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
At 05:24 PM 1/7/2008 -0500, Raymond Hettinger wrote: >The best existing indicator we have is the organization of the docs >for the standard library. I, for one, have a hell of a difficult >time finding modules via the "organized" table of contents in the >Library Reference. Instead, I always go the the Global Module Index >where the somewhat flat namespace makes it easy to go directly to >the module of interest. I'm curious whether the other developers >have had the same experience -- if so, then it is a bad omen for >over-organizing the standard library. I do this too. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
* Barry Warsaw <[EMAIL PROTECTED]> [2008-01-07 16:01:42 -0500]: > On Jan 7, 2008, at 11:37 AM, Phillip J. Eby wrote: > > >> Python automatically adds ~/.python/site-packages to sys.path; this > >> is > >> added /before/ the system site-packages file. An open question is > >> whether it needs to go at the front of the list. It should > >> definitely > >> be searched before the system site-packages. > > > > What about including the Python version in the directory name? C > > Extensions may not work correctly across versions, and bytecode will > > get recompiled a lot if you're using multiple versions. Also, if > > this is a 2.6/3.0 change, it's likely that the *source* won't be > > compatible across versions either. :) > > D'oh, yes of course. So make that: > > ~/.python/lib/pythonX.Y/site-packages In that case how about: ~/.local/lib/pythonX.Y/site-packages or: ~/local/lib/pythonX.Y/site-packages I believe both of these locations are already in use by various systems / people, so it would fit in better with existing practice. > IMO, it should be a true site directory. This would be ideal. -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 07/01/2008, Tristan Seligmann <[EMAIL PROTECTED]> wrote: > > D'oh, yes of course. So make that: > > > > ~/.python/lib/pythonX.Y/site-packages > > In that case how about: > > ~/.local/lib/pythonX.Y/site-packages > > or: > > ~/local/lib/pythonX.Y/site-packages What would be used on Windows? It's likely to be of marginal use on Windows, but an appropriate equivalent should be defined. Possibly just replace ~ with %USERPROFILE%. I'd argue against anything under %APPDATA% as that directory is hidden. Also, should bdist_wininst/bdist_msi installers be updated to offer the option of installing to this directory? What about python setup.py install (add a --user flag, for example)? Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
>The best existing indicator we have is the organization of the docs for >the standard library. I, for one, have a hell of a difficult time finding >modules via the "organized" table of contents in the Library Reference. >Instead, I always go the the Global Module Index where the somewhat flat >namespace makes it easy to go directly to the module of interest. I'm >curious whether the other developers have had the same experience -- if >so, then it is a bad omen for over-organizing the standard library. I nearly always use my browser's search function to find the module of interest, so yes, I'm effectively using a flat namespace. >Another indicator of what lies ahead is the current organization of os vs >os.path. While that split-out was well done and necessary, I routinely >have difficulty remembering which one contains a function of interest. I mostly remember, but there are some notable exceptions: exists (posix system call, expect to find it in os), walk (which is the old deprecated one? have to check doc). -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 7, 2008 12:56 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > OK. So an html package could have htmllib for its __init__ (or > html.lib), and then have html.entities and html.parser for > htmlentitydefs and HTMLParser, respectively. I'd be very reluctant to have more "asymmetric" packages like os where the package contains functionality at the top level as well as submodules, because it means that anyone using one of the submodules will pay the price of importing the top-level package. In this example, I can easily see someone using htmlentitydefs without needing htmllib. > Another example is http: > http.lib, http.server.cgi, http.server.base, http.server.simple. That sounds like a good one. > Both examples are grouped because they make sense, but primarily to > make the tail module name simpler. [...] > > Another reason to have a top-level package would be if there are a lot > > of subpackages/submodules. This applies to the xml package for > > example. > > The only place I can see that coming into play is if there is any > desire to group OS-specific modules together. Otherwise I think > Tk-specific stuff is the only place where this has not been done > before. Well, that's a little different -- plat-* and lib-tk are not subpackages but subdirectories. For the plat-* subdirs, this is done so that the same logical module name can have different implementations per platform. For lib-tk it was done to make it easier to create a distribution that didn't include any Tk stuff. But the test package structure doesn't follow this lead, and I'm not sure if it still makes sense for lib-tk. OTOH maybe lib-tk could be promoted to being a real package (named tkinter?), with the core tkinter functionality in __init__ and the rest in submodules with names conforming to PEP 8; this is one example where that type of organization actually makes sense. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python] Re: pkgutil, pkg_resource and Python 3.0 name space packages
Paul Moore wrote: > On 07/01/2008, Tristan Seligmann <[EMAIL PROTECTED]> wrote: > >>> D'oh, yes of course. So make that: >>> >>> ~/.python/lib/pythonX.Y/site-packages >>> >> In that case how about: >> >> ~/.local/lib/pythonX.Y/site-packages >> >> or: >> >> ~/local/lib/pythonX.Y/site-packages >> > > What would be used on Windows? It's likely to be of marginal use on > Windows, Could be very useful. A lot of machines are used with multiple users. > but an appropriate equivalent should be defined. Possibly > just replace ~ with %USERPROFILE%. I'd argue against anything under > %APPDATA% as that directory is hidden. > Replacing ~ with %USERPROFILE% sounds like the right thing to do. > Also, should bdist_wininst/bdist_msi installers be updated to offer > the option of installing to this directory? What about python setup.py > install (add a --user flag, for example)? > The installers should give the user the choice at install time (preferably). A '--user' flag would also be useful (IMHO). Michael Foord > Paul. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Backport PEP 3129: Class Decorators
This seems like something that could reasonably be added to Py2.6. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backport PEP 3129: Class Decorators
Raymond Hettinger wrote: > This seems like something that could reasonably be added to Py2.6. +1 from me PEP 3107 (function annotation), PEP 3104 (nonlocal) and PEP 3132 (extended iterable unpacking: a, *b = 1,2,3) are IMHO other useful feature for 2.6. nonlocal would require a __future__ import. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
Paul Moore wrote: > What would be used on Windows? It's likely to be of marginal use on > Windows, but an appropriate equivalent should be defined. Possibly > just replace ~ with %USERPROFILE%. I'd argue against anything under > %APPDATA% as that directory is hidden. No, we shouldn't mess with the profile root directory on Windows. The data should either be installed under "Application Data" or under "My Documents". You are right, the appdata directory is hidden by the installer could add a link to Application Data\Python\python2.x\ to the start menu. I also don't like the idea to replace ~ with another string. Every OS is probably using a different path (~/.python/ on Linux, ~/Library/Python on Mac and APPDATA\Python on Windows). The distutils package should gain two methods: global_sitedir() and local_sitedir([username]). > Also, should bdist_wininst/bdist_msi installers be updated to offer > the option of installing to this directory? What about python setup.py > install (add a --user flag, for example)? Sounds good to me. Apropos My Documents and other special directories on Windows. Python doesn't have an API to get the directories from the registry. Is somebody interested in having a module for the task? I've some code for the job on disk. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 7, 2008 3:47 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Jan 7, 2008 12:56 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > > OK. So an html package could have htmllib for its __init__ (or > > html.lib), and then have html.entities and html.parser for > > htmlentitydefs and HTMLParser, respectively. > > I'd be very reluctant to have more "asymmetric" packages like os where > the package contains functionality at the top level as well as > submodules, because it means that anyone using one of the submodules > will pay the price of importing the top-level package. In this > example, I can easily see someone using htmlentitydefs without needing > htmllib. > Fair enough. Then something like html.lib or html.tools could be had for miscellaneous code. > > Another example is http: > > http.lib, http.server.cgi, http.server.base, http.server.simple. > > That sounds like a good one. Great! I think I get what you are after then for the reorg in terms of any new packages coming about. > > > Both examples are grouped because they make sense, but primarily to > > make the tail module name simpler. > > [...] > > > > Another reason to have a top-level package would be if there are a lot > > > of subpackages/submodules. This applies to the xml package for > > > example. > > > > The only place I can see that coming into play is if there is any > > desire to group OS-specific modules together. Otherwise I think > > Tk-specific stuff is the only place where this has not been done > > before. > > Well, that's a little different -- plat-* and lib-tk are not > subpackages but subdirectories. For the plat-* subdirs, this is done > so that the same logical module name can have different > implementations per platform. For lib-tk it was done to make it easier > to create a distribution that didn't include any Tk stuff. But the > test package structure doesn't follow this lead, and I'm not sure if > it still makes sense for lib-tk. OTOH maybe lib-tk could be promoted > to being a real package (named tkinter?), with the core tkinter > functionality in __init__ and the rest in submodules with names > conforming to PEP 8; this is one example where that type of > organization actually makes sense. If the platform-specific stuff is made into their own packages (e.g., unix, mac, win, tkinter, etc.) then this can apply generically across the stdlib (sans Modules, of course, unless we eventually change how we handle building extension modules such that they are kept in /Lib as well). I think that would be nice in terms of organization of the code and the documentation as it makes it more obvious which modules are platform-specific. Is applying this to OS-specific modules work for you like it does for tkinter stuff? -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 7, 2008 2:24 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > >> And then extend this to any other > >> package that we consider creating? Otherwise leave it out? How would > >> that follow for sqlite since that is not going to get any shorter > >> thanks to a package? Should it still go into the package for > >> organizational purposes? > > > If you're asking me, the "organizational purpose" is 100% misguided. > > It is my hope that there will be a great deal of restraint in the effort to > group modules into packages in Py3.0. > There will be. There is a reason why I am willing to let a committee get involved with this as that will make almost any added package difficult to pull off. > For the most part, putting modules in packages only makes them more difficult > to access and introduces an additional burden of remembering which package to > invoke. > > The best existing indicator we have is the organization of the docs for the > standard library. I, for one, have a hell of a difficult time finding modules > via the "organized" table of contents in the Library Reference. Instead, I > always go the the Global Module Index where the somewhat flat namespace makes > it easy to go directly to the module of interest. I'm curious whether the > other developers have had the same experience -- if so, then it is a bad omen > for over-organizing the standard library. > > Another indicator of what lies ahead is the current organization of os vs > os.path. While that split-out was well done and necessary, I routinely have > difficulty remembering which one contains a function of interest. > Yeah, 'os' could stand a reorganization, but I am not touching that one. > There are handful of groupings that are obvious (i.e. html and socket modules > going into an internet package). Outside of those, I think it best to leave > the rest of the modules in a flat namespace (I don't want to have to quess > where to find queue, random, pickle, pprint, decimal, and collections. > > I think most of the concerns with the standard library revolve around module > quality, duplication, and obsolence. That is definitely a concern of mine and the removal of obsolete code is still the primary motivation for me for this reorg. But I also realize that if we can group reasonable modules together (as you and Guido have now both suggested based more on similarity and coming up with shorter names) then I think we should take the chance now. > In contrast, I do not think that introducing a hierarchy of namespaces is of > interest to most users. That exercise may well make the language harder to > use/learn, not easier. I was never planning on organizing the entire stdlib into a complete, one-level deep hierarchy. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New Developer
Hello all, I've recently been granted commit privileges; so, following the usual protocol, here's a quick introduction. I'm a mathematician by day; my degree is in number theory, but five summers of Fortran 77 programming and two semesters of teaching numerical analysis have given me a taste for numerics as well. I discovered Python around twelve years ago and found that it fit my brain nicely (even more so after nested namespaces were introduced) and now use it almost daily for a wide variety of tasks. I've been lurking on python-dev for longer than I care to admit to. I also dabble in Haskell and O'Caml. I'd like to say a huge thank you to Facundo Batista: I've been helping him update Decimal to the most recent specification over the last few months, and without his support and encouragement I certainly wouldn't be writing this now---he's been a fantastic guide and mentor. Please don't hesitate to let me know if there's anything I can help out with; I'm primarily interested in mathematical, numerical, and algorithmic aspects of Python at the moment, but am looking to broaden my knowledge of the internals. I've got so much out of Python over the years, and I hope I can now give something back. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_sys failures
On Dec 21, 2007 12:05 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > When I build from scratch and run most tests (regrtest.py -uall) I get > > some strange failures with test_sys.py: > > > > test test_sys failed -- Traceback (most recent call last): > > File "/usr/local/google/home/guido/python/py3kd/Lib/test/test_sys.py", > > line 302, in test_43581 > > self.assertEqual(sys.__stdout__.encoding, sys.__stderr__.encoding) > > AssertionError: 'ascii' != 'ISO-8859-1' > > > > The same test doesn't fail when run in isolation. > > > > Interestingly, I saw this with 2.5 as well as 3.0, but not with 2.6! > > > > Any ideas? > > It looks like the chunk of code in TextIOWrapper might be getting > different answers when trying to work out the encoding for stdin and > stderr (not that I can see how that would happen...). Or maybe there is > some way that test_sys could be seeing the temporary '__stderr__' entry > that is put in place until the io module is available? > > What do you get for stdin/stdout/stderr.encoding at the interactive > prompt? On Ubuntu, I get UTF-8 for all of them in both 3.0a2 and 2.5.1, > but I'm not seeing the problem, either. > > Other values of possible interest: >os.device_encoding(1) >os.device_encoding(2) >locale.getpreferredencoding() > > Another possibility would be to throw some debugging code into io.py to > print out the encoding name to stderr when file is 1 or 2. No answers yet, but a clue, and anyone on OSX should now be able to reproduce this (with 2.5, 2.6 or 3.0) as follows: ./python ./Lib/test/test_sys.py | cat That is, the problem happens when stdout is redirected to a pipe (or a file). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
