[Python-Dev] docs.python.org
Will docs.python.org be redirected to www.python.org/doc? I think I am not the only person on the planet that had been using docs.python.org for a long time now to get to the documentation. (And some links are now broken @ docs.python.org, so it seems all the more logical to make such a redirect. docs.python.org is the 3rd result from Google too by the way.) -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Want ik kan niet leven zonder alles of niets... ___ 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] PEP: per user site-packages directory
Christian Heimes wrote: > [...] > PEP: XXX > Title: Per user site-packages directory > Version: $Revision$ > Last-Modified: $Date$ > Author: Christian Heimes > Status: Draft > Type: Standards Track > Content-Type: text/x-rst > Created: 11-Jan-2008 > Python-Version: 2.6, 3.0 > Post-History: > [...] > user site directory > >A site directory inside the users' home directory. An user site >directory is specific to a Python version. The path contains >the version number (major and minor only). > >Windows: %APPDATA%/Python/Python26/site-packages >Mac: ~/Library/Python/2.6/site-packages >Unix: ~/.local/lib/python2.6/site-packages > > > user configuration directory > >Usually the parent directory of the user site directory. It's meant >for Python version specific data like config files. > >Windows: %APPDATA%/Python/Python26 >Mac: ~/Library/Python/2.6 >Unix: ~/.local/lib/python2.6 So if I'm using the --user option, where would scripts be installed? Would this be: Windows: %APPDATA%/Python/Python26/bin Mac: ~/Library/Python/2.6/bin Unix: ~/.local/lib/python2.6/bin I'd like to be able to switch between several versions of my user installation simply by changing a link. (On the Mac I'm doing this by relinking ~/Library/Python to different directories.) Servus, Walter ___ 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] docs.python.org
On Mon, Jan 14, 2008 at 10:20:05AM +0100, Jeroen Ruigrok van der Werven wrote: > Will docs.python.org be redirected to www.python.org/doc? > > I think I am not the only person on the planet that had been using > docs.python.org for a long time now to get to the documentation. (And some > links are now broken @ docs.python.org, so it seems all the more logical to > make such a redirect. docs.python.org is the 3rd result from Google too by the I doubt it; instead I think that, once Python 2.6 is released, the new documentation system that's now at http://docs.python.org/dev/ will move up to become the top page of docs.python.org, and /dev/ will remain the trunk version, updated daily. Various links on the top page of docs.python.org have become outdated, though; I've gone through the page and updated or removed them. --amk ___ 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 1/12/08, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> > During the discussion about the new Rational implementation
> > (http://bugs.python.org/issue1682), Guido and Raymond decided that
> > Decimal should not implement the new Real ABC from PEP 3141. So I've
> > closed http://bugs.python.org/issue1623 and won't be pursuing any of
> > the extra rounding methods mentioned on this thread.
> Well, I didn't really decide anything. I suggested that if the
> developers of Decimal preferred it, it might be better if Decimal did
> not implement the Real ABC, and Raymond said he indeed preferred it.
I read his objections slightly differently.
He is very clear that Decimal itself should be restricted to the
standard, and therefore should not natively implement the extensions.
But he also said that it might be reasonable for another package to
subset or superset it in a friendlier way.
numbers.py is a different module, which must be explicitly imported.
If the objection is that
>>> decimal.Decimal("43.2").imag
would work (instead of throwing an exception) only when numbers.py has
already been imported, then ... well, that confusion is inherent in
the abstract classes.
Or is the problem that it *still* wouldn't work, without help from the
decimal module itself? In that case, 3rd party registration is fairly
limited, and this might be a good candidate for trying to figure out
ABCs and adapters *should* work together.
-jJ
___
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] docs.python.org
-On [20080114 14:54], A.M. Kuchling ([EMAIL PROTECTED]) wrote: >I doubt it; instead I think that, once Python 2.6 is released, the new >documentation system that's now at http://docs.python.org/dev/ will >move up to become the top page of docs.python.org, and /dev/ will remain >the trunk version, updated daily. The thing is: http://www.python.org/ has a link Documentation, which links to http://www.python.org/doc/ and from there has a link with Browse Current Documentation to http://docs.python.org/ - it's kind of confusing with the Quick Links content at the bottom. You have two choices in the left-hand side menu that both read Documentation. That's ambiguous. Add to that that the stylesheet between www.python.org and docs.python.org are different and the menu structure is also different and it makes for a bad user experience. And to make matters even more confusing docs.python.org/dev/ has its own stylesheet as well. Great work, all in all, but this is bad style (pun intended). I wonder if a mix between www.python.org's stylesheet and docs.python.org/dev/'s can be made. The colours of www.python.org's headers and the links are too similar in colour, plus the dotted line beneath the URL disappears against the white background. In that aspect docs.python.org/dev/ is a step up. >Various links on the top page of docs.python.org have become outdated, >though; I've gone through the page and updated or removed them. Thanks, much appreciated. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ What is the short meaning of this long speech..? ___ 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] PEP: per user site-packages directory
On 12:08 pm, [EMAIL PROTECTED] wrote: >So if I'm using the --user option, where would scripts be installed? >Would this be: > >Windows: %APPDATA%/Python/Python26/bin >Mac: ~/Library/Python/2.6/bin >Unix: ~/.local/lib/python2.6/bin > >I'd like to be able to switch between several versions of my user >installation simply by changing a link. (On the Mac I'm doing this by >relinking ~/Library/Python to different directories.) I think the relevant link to change here would be ~/.local. I have personally been using the ~/.local convention for a while, and I believe ~/.local/bin is where scripts should go. Python is not the only thing that can be locally installed, and the fact that it's ~/.local/lib/python2.6/site-packages suggests that ~/.local has the same layout as /usr (or /usr/local, for those who use that convention). ___ 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-checkins] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS
On Jan 13, 2008 11:22 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Hmm, is that really necessary? structseq has been in use for quite a > > while and this need hasn't come up -- it's been designed to be quite > > compatible with tuple *except* for isinstance checks, and that has > > worked well. > > In addition, I would like to suggest that the current structseq usage > is changed to regular classes (perhaps with slots) in Python 3. > structseq was a compatibility mechanism for existing code that assumes > the things returned are tuples, when they are really objects with named > fields. > > So for struct stat and struct tm in particular, I think the indexed > access should be removed in Python 3. Whether then structseq needs > to be preserved at all, I don't know. There seems to be a use case for it still, otherwise collections.namedtuple wouldn't be added to 2.6, right? I agree that it's time to clean up the tuple-ness of the stat and tm structures (especially since they both may have "hidden" fields that are not accessible via the tuple structure). And I see no need for the new sys.flags object to be a tuple at all. -- --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
[Python-Dev] test module availability on different Python implementations
Hi, Today I received a report from a guy who tried to run the test suite of a module of mine. The test suite uses the test module for running tests, for temporary files support and for doing a bunch of other things. He tested it on CentOS 5 and looks like python 2.5.1 includes the test module but python 2.4.3 does not: [EMAIL PROTECTED] test]# python2.4 test_ftpd.py Traceback (most recent call last): File "test_ftpd.py", line 37, in ? from test import test_support ImportError: No module named test Another guy reported the same thing by having tried to run the test suite against a Windows mobile OS equipped with PythonCE 2.4 where the test module seems to be not available too. I was wondering if there was someone aware of this problem. ___ 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] inst_persistent_id
Hi, On Sat, Jan 12, 2008 at 07:33:38PM -0500, Alexandre Vassalotti wrote: > Well, in Python 3K, inst_persistent_id() won't be usable, since > PyInstance_Type was removed. Looking at the code, inst_persistent_id() is just a confusing name. It has got nothing to do with PyInstance_Type; it's called for any object type that cPickle.c doesn't know how to handle. In fact, it seems that cPickle.c never calls inst_persistent_id() for objects of type PyInstance_Type... A bientot, Armin. ___ 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-checkins] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS
On Jan 14, 2008 10:41 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > And I see no need for the new sys.flags object to be a tuple at all. > > Correct. We don't need item access anymore. However the struct seq > should still be slice-able for functions like time.mktime(). Oh, that's a good point. I think it actually doesn't make sense for it to be sliceable without behaving like a sequence in all (or most) aspects. I don't think this applies to struct stat though; I can never remember the order of the values there, unlike the first 6 of a time tuple, which have an obvious order. -- --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-checkins] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS
Guido van Rossum wrote: > And I see no need for the new sys.flags object to be a tuple at all. Correct. We don't need item access anymore. However the struct seq should still be slice-able for functions like time.mktime(). 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] [Python-3000] Rounding Decimals
On Jan 14, 2008 5:48 AM, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 1/12/08, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> > > During the discussion about the new Rational implementation
> > > (http://bugs.python.org/issue1682), Guido and Raymond decided that
> > > Decimal should not implement the new Real ABC from PEP 3141. So I've
> > > closed http://bugs.python.org/issue1623 and won't be pursuing any of
> > > the extra rounding methods mentioned on this thread.
>
> > Well, I didn't really decide anything. I suggested that if the
> > developers of Decimal preferred it, it might be better if Decimal did
> > not implement the Real ABC, and Raymond said he indeed preferred it.
>
> I read his objections slightly differently.
>
> He is very clear that Decimal itself should be restricted to the
> standard, and therefore should not natively implement the extensions.
Well, to me that sounds like idolizing the standard. The standard
exists so as to ensure that decimal numbers have well-understood
semantics that are implemented correctly. I don't think the standard
was ever meant to exclude optimal interaction with the rest of a
language. I'd like to see if ReXX implements numeric features over and
above the standard.
> But he also said that it might be reasonable for another package to
> subset or superset it in a friendlier way.
>From a user's perspective, it might make more sense to move the
strictly standard-conforming code into a module "decimal_standard" and
make the friendlier-named "decimal" module be that friendly superset.
> numbers.py is a different module, which must be explicitly imported.
>
> If the objection is that
>
> >>> decimal.Decimal("43.2").imag
>
> would work (instead of throwing an exception) only when numbers.py has
> already been imported, then ... well, that confusion is inherent in
> the abstract classes.
Fortunately, the confusion is in your mind only, because that's not
how ABCs work according to PEP 3119. While as a side effect of
importing the numbers module, the Decimal class might become a virtual
subclass of numbers.Real, that doesn't mean that implementation
features are automatically added. The registration that might take
place inside numbers.py *only* affects the outcome of isinstance() and
issubclass() checks -- it doesn't magically add missing attributes or
methods to the class.
> Or is the problem that it *still* wouldn't work, without help from the
> decimal module itself?
Right.
> In that case, 3rd party registration is fairly
> limited, and this might be a good candidate for trying to figure out
> ABCs and adapters *should* work together.
Of course 3rd party registration is limited -- there's no way that you
could automatically define the right semantics, since the ABCs don't
have a way to express semantics.
PEP 3119 is meant as a *first step* towards adopting ABCs as a core
feature. The changes added to collections.py and numbers.py are best
considered as minimal examples. The main achievement of the PEP is
probably the hooks that allow you to override isinstance() and
issubclass(), plus the decision (which was discussed at length) to use
ABCs (with virtual inheritance), not interfaces, to model similarities
between class APIs.
--
--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] PEP: per user site-packages directory
[EMAIL PROTECTED] wrote: > I think the relevant link to change here would be ~/.local. > > I have personally been using the ~/.local convention for a while, and I > believe ~/.local/bin is where scripts should go. Python is not the only > thing that can be locally installed, and the fact that it's > ~/.local/lib/python2.6/site-packages suggests that ~/.local has the > same layout as /usr (or /usr/local, for those who use that convention). ~/.local/bin or ~/bin ? ~/bin is the standard directory for user binaries. I can see how ~/.local/bin follows the idea of other directories. But ~/bin is more convenient than ~/.local/bin. I don't want to teach users how to change their .bashrc or .profile file for ~/.local/bin. A line like if [ -d ~/bin ]; then PATH=~/bin:$PATH fi is in most .profile files (often commented out). I'm proposing ~/bin for Unix (including Mac) and %APPDATA%/Python/Scripts for Windows. The Windows installer could then add the directory to the PATH environment and install a minimal bat file "@C:\Python26\python.exe %*" as python26.bat, too. 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] test module availability on different Python implementations
The test *package* is much older than Python 2.4, but many Python distros exclude it from their default configuration. Perhaps there is a way to add it back; on many Linux-based systems running apt-get or yum with the appropriate arguments is all it takes. Sorry, I can't help you with the appropriate parameters, since every distro does it differently. --Guido On Jan 14, 2008 10:00 AM, Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: > Hi, > Today I received a report from a guy who tried to run the test suite > of a module of mine. > The test suite uses the test module for running tests, for temporary > files support and for doing a bunch of other things. > He tested it on CentOS 5 and looks like python 2.5.1 includes the test > module but python 2.4.3 does not: > > [EMAIL PROTECTED] test]# python2.4 test_ftpd.py > Traceback (most recent call last): > File "test_ftpd.py", line 37, in ? > from test import test_support > ImportError: No module named test > > Another guy reported the same thing by having tried to run the test > suite against a Windows mobile OS equipped with PythonCE 2.4 where the > test module seems to be not available too. > > I was wondering if there was someone aware of this problem. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --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] PEP: per user site-packages directory
On 06:37 pm, [EMAIL PROTECTED] wrote: >[EMAIL PROTECTED] wrote: >>I think the relevant link to change here would be ~/.local. >> >>I have personally been using the ~/.local convention for a while, and >>I >>believe ~/.local/bin is where scripts should go. Python is not the >>only >>thing that can be locally installed, and the fact that it's >>~/.local/lib/python2.6/site-packages suggests that ~/.local has the >>same layout as /usr (or /usr/local, for those who use that >>convention). > >~/.local/bin or ~/bin ? > >~/bin is the standard directory for user binaries. "the" standard directory? according to what? commented-out examples in some linux distribution? >I can see how ~/.local/bin follows the idea of other directories. I think consistency is important here. Python is not the only tool that could follow this convention, and it would be nice to have a consistent convention that it would be easy for other tools and environments to adopt. >But ~/bin is more >convenient than ~/.local/bin. I don't want to teach users how to change >their .bashrc or .profile file for ~/.local/bin. A line like as you say, it is often commented out. You have to teach users this anyway, even if sometimes it will work by accident. ~/bin comes from the convention of "./configure --prefix=$HOME", as autoconf suggests. This means users must have visible directories in their home folder named (among other things) "bin", "share", "lib", "src", "sbin", "man", and "include". I find this ugly. I only find it slightly less ugly that Python will now hide its locally-installed library files from me but not its locally-installed executable scripts. "./configure --prefix=$HOME/.local" will instead put things into ~/.local/bin, ~/.local/lib, etc. Now, I am aware that setup.py already has a special "--home" option, and it can be incompatibly changed, but I don't see a reason for this. Note that --home $HOME will currently put files into ~/lib, not ~/.local/lib. (and --home $HOME/local will put scripts into ~/.local/bin, not ~/bin). But, now that I've told you what I think in more detail, unless you like my ideas and have specific questions, I will try to refrain from commenting further, lest I dig my own bike shed here :). ___ 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 module availability on different Python implementations
On 14 Gen, 19:46, "Guido van Rossum" <[EMAIL PROTECTED]> wrote: > The test *package* is much older than Python 2.4, but many Python > distros exclude it from their default configuration. Perhaps there is > a way to add it back; on many Linux-based systems running apt-get or > yum with the appropriate arguments is all it takes. Sorry, I can't > help you with the appropriate parameters, since every distro does it > differently. > > --Guido Good to know, thanks for the information. I didn't know that python-tests were treated as a separate package on certain platforms. As replacement I'll use unittest.main() for running tests and a static string defined by me instead of test.test_support.TESTFN. ___ 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] PEP: per user site-packages directory
[EMAIL PROTECTED] wrote: > "the" standard directory? according to what? commented-out examples in > some linux distribution? Yes ... :/ I should be more carefully when I use the word "standard". > But, now that I've told you what I think in more detail, unless you like > my ideas and have specific questions, I will try to refrain from > commenting further, lest I dig my own bike shed here :). I have no strong opinion on ~/bin or ~/.local/bin. I understand your point of view and I concur with some of your arguments. I'm making this discussion point easy for me. I let the others decide! :) I don't feel like wasting my time on a bike shed discussion unless it's painted in a different color than blue. I like blue ... *g* 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] PEP: per user site-packages directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 14, 2008, at 2:13 PM, [EMAIL PROTECTED] wrote: > ~/bin comes from the convention of "./configure --prefix=$HOME", as > autoconf suggests. This means users must have visible directories in > their home folder named (among other things) "bin", "share", "lib", > "src", "sbin", "man", and "include". I find this ugly. I only find > it > slightly less ugly that Python will now hide its locally-installed > library files from me but not its locally-installed executable > scripts. > > "./configure --prefix=$HOME/.local" will instead put things into > ~/.local/bin, ~/.local/lib, etc. > > Now, I am aware that setup.py already has a special "--home" option, > and > it can be incompatibly changed, but I don't see a reason for this. > Note > that --home $HOME will currently put files into ~/lib, not ~/.local/ > lib. > (and --home $HOME/local will put scripts into ~/.local/bin, not ~/ > bin). > > But, now that I've told you what I think in more detail, unless you > like > my ideas and have specific questions, I will try to refrain from > commenting further, lest I dig my own bike shed here :). I feel pretty strongly that ~/bin should *not* be used. It makes sense to me that ~/.local would mirror /usr/local. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR4vA+XEjvBPtnXfVAQICEgP8CAuFVzZld1769uQKDWj2h4Y7x+besq5o 9bujNYJ6SayNac4u1jWLWmCIdBSuQU6/xNF6+ljpn5Pz4H/yRBl/HK2ibF2ksZwg quv23PHLvMnLju77FNKE5VclVJk3rBKpkpjmS/yXMcyfBwAccIDEJY+QUshtQzql 8mRZ4cEUP0I= =gepD -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] PEP: per user site-packages directory
Barry Warsaw wrote: > I feel pretty strongly that ~/bin should *not* be used. It makes > sense to me that ~/.local would mirror /usr/local. Two votes for ~/.local/bin and one undecided PEP author ... I'm changing the code to ~/.local/bin and I'm adding a new section to the PEP. Can I just submit the PEP or do I have to follow a procedure before I can add it to the PEP list? 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] PEP: per user site-packages directory
On Jan 14, 2008 12:27 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Barry Warsaw wrote: > > I feel pretty strongly that ~/bin should *not* be used. It makes > > sense to me that ~/.local would mirror /usr/local. > > Two votes for ~/.local/bin and one undecided PEP author ... I'm changing > the code to ~/.local/bin and I'm adding a new section to the PEP. > > Can I just submit the PEP or do I have to follow a procedure before I > can add it to the PEP list? You can submit the PEP and update PEP 0 (note that each PEP occurs twice!) but you can't mark it "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] PEP: per user site-packages directory
The PEP is now available at http://www.python.org/dev/peps/pep-0370/. The reference implementation is in svn, too: svn+ssh://[EMAIL PROTECTED]/sandbox/trunk/pep370 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] [Python-checkins] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS
> There seems to be a use case for it still, otherwise > collections.namedtuple wouldn't be added to 2.6, right? Perhaps; I'm not strongly opposed to keeping structseq. I'll work on making stat_result and struct_time regular fixed-size types, for 3.0. Regards, Martin ___ 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] PEP: per user site-packages directory
On 2008-01-14 22:23, Christian Heimes wrote: > The PEP is now available at http://www.python.org/dev/peps/pep-0370/. > The reference implementation is in svn, too: > svn+ssh://[EMAIL PROTECTED]/sandbox/trunk/pep370 Thanks for the effort, Christian. Much appreciated. Regarding the recent ~/bin vs. ~/.local/bin discussion: I usually maintain my ~/bin directories by hand and wouldn't want any application to install things in there automatically (and so far I haven't been using any application that does), so I'd be in favor of the ~/.local/bin dir. Note that users typically don't know which scripts are made available by a Python application and it's not always clear what functionality they provide, whether they can be trusted, include bugs, need to be run with extra care, etc, so IMHO making it a little harder to run them by accident is well warranted. Thanks again, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 14 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] [Python-checkins] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS
> Correct. We don't need item access anymore. However the struct seq > should still be slice-able for functions like time.mktime(). Can you please explain that? What application do you have in mind? Regards, Martin ___ 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-checkins] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS
On Jan 14, 2008 2:19 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Correct. We don't need item access anymore. However the struct seq > > should still be slice-able for functions like time.mktime(). > > Can you please explain that? What application do you have in mind? Well, mktime() assumes its argument to be a tuple, and there are plenty of places that either emulate its API (like calendar.timegm()) or provide a tuple for it. I wouldn't want to lose the ability to manually construct a tuple to go into mktime() and friends. -- --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] inst_persistent_id
Oh, you are right. I thought that save_inst() used inst_persistent_id,
but that isn't the case. Now, I have checked more thoroughly and found
the relevant piece of code:
if (!pers_save && self->inst_pers_func) {
if ((tmp = save_pers(self, args, self->inst_pers_func)) != 0) {
res = tmp;
goto finally;
}
}
which is indeed called only when the object is not "supported" by pickle.
I guess my original argument doesn't hold anymore, thus I don't have
anything against supporting this feature officially.
Thanks for correcting me!
-- Alexandre
On Jan 14, 2008 12:59 PM, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Sat, Jan 12, 2008 at 07:33:38PM -0500, Alexandre Vassalotti wrote:
> > Well, in Python 3K, inst_persistent_id() won't be usable, since
> > PyInstance_Type was removed.
>
> Looking at the code, inst_persistent_id() is just a confusing name. It
> has got nothing to do with PyInstance_Type; it's called for any object
> type that cPickle.c doesn't know how to handle. In fact, it seems that
> cPickle.c never calls inst_persistent_id() for objects of type
> PyInstance_Type...
>
>
> A bientot,
>
> Armin.
>
___
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-checkins] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS
Guido van Rossum wrote: > On Jan 14, 2008 2:19 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >>> Correct. We don't need item access anymore. However the struct seq >>> should still be slice-able for functions like time.mktime(). >> Can you please explain that? What application do you have in mind? > > Well, mktime() assumes its argument to be a tuple, and there are > plenty of places that either emulate its API (like calendar.timegm()) > or provide a tuple for it. I wouldn't want to lose the ability to > manually construct a tuple to go into mktime() and friends. But what about the slicing? AFAICT, mktime doesn't support "short" tuples. mktime could continue to support tuples (including manually created ones), yet struct_time could still be a proper class, as long as mktime accepts that as well. Regards, Martin ___ 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-checkins] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS
A use case for slicing was just found in zipfile.py: date = "%d-%02d-%02d %02d:%02d:%02d" % zinfo.date_time[:6] On Jan 14, 2008 3:28 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > On Jan 14, 2008 2:19 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > >>> Correct. We don't need item access anymore. However the struct seq > >>> should still be slice-able for functions like time.mktime(). > >> Can you please explain that? What application do you have in mind? > > > > Well, mktime() assumes its argument to be a tuple, and there are > > plenty of places that either emulate its API (like calendar.timegm()) > > or provide a tuple for it. I wouldn't want to lose the ability to > > manually construct a tuple to go into mktime() and friends. > > But what about the slicing? AFAICT, mktime doesn't support "short" > tuples. > > mktime could continue to support tuples (including manually created > ones), yet struct_time could still be a proper class, as long as mktime > accepts that as well. > > Regards, > Martin > -- --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] PEP: per user site-packages directory
On Mon, Jan 14, 2008 at 03:07:20PM -0500, Barry Warsaw wrote: > I feel pretty strongly that ~/bin should *not* be used. It makes > sense to me that ~/.local would mirror /usr/local. It makes sense, but personally I have never heard before of ~/.local. Whereas ~/bin is something I am quite familiar with. ___ 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] PEP: per user site-packages directory
On Jan 14, 2008 6:41 PM, Jon Ribbens <[EMAIL PROTECTED]> wrote: > It makes sense, but personally I have never heard before of ~/.local. > Whereas ~/bin is something I am quite familiar with. *raises hand* I have one, fwiw. -- Cheers, Leif ___ 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] PEP: per user site-packages directory
One thing I miss in this PEP and discussion is the point of view from a webhosting company and webhosting user. If the webhoster upgrades his hosting software and Python get updated by a revision (say 2.5 to 2.6) this would in the current case mean that the webhosting user using per-user site-packages is out of luck due to the hard-wired (and apparently needed) version identifier. Or is that a wrong assumption on my side? Right now Python faces a lot of problems in the webhosting world because it's tedious to set up and maintain for the webhosting user since they often have to compile and install their own Python in their home directory. The per-user site-packages will help in that aspect a lot, I think, but we do need to detail some more use-cases and scenarios (patterns if you like) on how such deployments would work. I think this is extremely important due to the proliferation of Python now more and more as a choice for webapp development. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ The greatest of faults, I should say, is to be conscious of none... ___ 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
