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-pack
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-De
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 famil
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.
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 min
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)
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() assume
> 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
Python-Dev
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.
> 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
_
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
Python-Dev@python.org
http://mail.python.org/mailma
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
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 subm
-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", "
[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 spe
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 ca
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 appropria
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
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 appropria
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 maili
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)
[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 i
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 p
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 calle
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
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
-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
>
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 n
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
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:
> [..
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.
31 matches
Mail list logo
