On 20 July 2011 03:21, Terry Reedy wrote:
> Suppose for Windows there were one '.../python' directory wherever the user
> first asks it to be put and that all pythons, not just cpython, are
> installed in directories below that and that the small startup file is
> copied into or linked from the py
In article
,
Kerrick Staley wrote:
> On Mon, Jul 18, 2011 at 3:03 AM, Ned Deily wrote:
> > I think adding the requirement to mandate hard link vs soft link usage
> > is an unnecessary and unwarranted attempt at optimization. For
> > instance, IIRC, the OS X installers don't use any hard links:
On Wed, Jul 20, 2011 at 4:53 PM, Kerrick Staley wrote:
> Nick, can you please apply the patch (will be sent in the following
> email) to the PEP SVN as soon as we get the hard-link issue is figured
> out? Alternatively, could you provide me write access to just the
> pep-0394.txt file so I can upd
On Wed, Jul 20, 2011 at 1:58 PM, P.J. Eby wrote:
> So, without further ado, here it is:
I pushed this version up to the PEPs repo, so it now has a number
(402) and can be read in prettier HTML format:
http://www.python.org/dev/peps/pep-0402/
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.c
+1 (and yay!)
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
___
Python-Dev mailing list
Python-D
On 7/19/2011 8:58 PM, P.J. Eby wrote:
Standard Library Changes/Additions
--
The ``pkgutil`` module should be updated to handle this
specification appropriately, including any necessary changes to
``extend_path()``, ``iter_modules()``, etc.
Specifically the propos
On 7/18/2011 6:41 PM, Vinay Sajip wrote:
> So I can fix my machine, now that I understand what went wrong
> (delete py.exe entries from HCU, and put them in HLM instead).
> Then the other problem I have, is why py.exe launched py 2.6.4
> instead of py 3.2.1 when 3.2.1 is ne
On 20 July 2011 10:17, Glenn Linderman wrote:
> However, the following fails: py foo.py
> It fails, because foo.py is not found. Instead, I have to specify: py
> d:\path\to\foo.py
> This is annoying, py should walk the PATH for unqualified files (the Windows
> PATH implicitly includes the curren
At 06:46 PM 7/20/2011 +1000, Nick Coghlan wrote:
On Wed, Jul 20, 2011 at 1:58 PM, P.J. Eby wrote:
> So, without further ado, here it is:
I pushed this version up to the PEPs repo, so it now has a number
(402) and can be read in prettier HTML format:
http://www.python.org/dev/peps/pep-0402/
Te
At 02:24 AM 7/20/2011 -0700, Glenn Linderman wrote:
When I read about creating __path__ from sys.path, I immediately
thought of the issue of programs that extend sys.path, and the above
is the "workaround" for such programs. but it requires such
programs to do work, and there are a lot of suc
On 07/20/2011 08:57 AM, P.J. Eby wrote:
> At 06:46 PM 7/20/2011 +1000, Nick Coghlan wrote:
>> On Wed, Jul 20, 2011 at 1:58 PM, P.J. Eby wrote:
>> > So, without further ado, here it is:
>>
>> I pushed this version up to the PEPs repo, so it now has a number
>> (402) and can be read in prettier HTML
On Tue, 19 Jul 2011 23:58:55 -0400, "P.J. Eby" wrote:
> Worse, this is not just a problem for new users: it prevents *anyone*
> from easily splitting a package into separately-installable
> components. In Perl terms, it would be as if every possible ``Net::``
> module on CPAN had to be bundled u
Glenn Linderman g.nevcal.com> writes:
> Since I don't yet have associations set up that point at the
> launcher, I thought I'd play with saying "py" in front of the
> command.
Why don't you have any associations pointing to the launcher? Did you delete
them? If you uninstall and ins
Hi,
> changeset: 3903:728660b53208
> user:pje
> date:Wed Jul 20 09:56:48 2011 -0400
> summary:
> Restore whitespace characters lost via email transmission.
> [...]
> diff --git a/pep-0402.txt b/pep-0402.txt
> --- a/pep-0402.txt
> +++ b/pep-0402.txt
> @@ -38,13 +38,13 @@
>
>
I wonder if this fixes the long-standing issue in OS vendor's distributions.
In
Fedora, for example, there is both arch-specific and non-arch directories:
/usr/lib/python2.7 + /usr/lib64/python2.7, for example. Pure python goes into
/usr/lib/python2.7, and code including binaries goes into /u
At 10:40 AM 7/20/2011 -0400, Neal Becker wrote:
I wonder if this fixes the long-standing issue in OS vendor's
distributions. In
Fedora, for example, there is both arch-specific and non-arch directories:
/usr/lib/python2.7 + /usr/lib64/python2.7, for example. Pure python
goes into
/usr/lib/pyt
At 04:21 PM 7/20/2011 +0200, Ãric Araujo wrote:
FYI, reST uses three-space indents, not four (so that blocks align
nicely under the leading two dots + one space), so I think the change
was intentional. The âDocumenting Pythonâ guide tells this (in the
standard docs), and I think it applies
Le 20/07/2011 16:40, P.J. Eby a écrit :
> PEP 12 prescribes four-space indents for PEPs, actually, wherever it
> mentions an specific indentation depth.
Ah, thanks. I see in my docutils docs that David Goodger used three and
four-space indents (three for indenting the body of a directive, four
fo
On Tue, Jul 19, 2011 at 8:58 PM, P.J. Eby wrote:
> The biggest likely exception to the above would be when a piece of
> code tries to check whether some package is installed by importing
> it. If this is done *only* by importing a top-level module (i.e., not
> checking for a ``__version__`` or so
Hello everyone,
I’ve seen recent commits in the default branch (3.3) that improve test
coverage (for example logging) or add new test files (cgitb, committed
by Brian). Do we have a policy of not adding new test files to stable
branches? For existing test files that get more tests, is the commit
On Wed, Jul 20, 2011 at 11:56 AM, Jeff Hardy wrote:
> On Tue, Jul 19, 2011 at 8:58 PM, P.J. Eby wrote:
>> The biggest likely exception to the above would be when a piece of
>> code tries to check whether some package is installed by importing
>> it. If this is done *only* by importing a top-leve
Le 20/07/2011 17:58, Éric Araujo a écrit :
Do we have a policy of not adding new test files to stable branches?
New logging tests failed during some weeks. If we add new tests, we may
also break some stable buildbots. I don't think that we need to add
these new tests to a stable version.
Vict
At 08:56 AM 7/20/2011 -0700, Jeff Hardy wrote:
On Tue, Jul 19, 2011 at 8:58 PM, P.J. Eby wrote:
> The biggest likely exception to the above would be when a piece of
> code tries to check whether some package is installed by importing
> it. If this is done *only* by importing a top-level module
At 12:37 PM 7/20/2011 -0400, Erik wrote:
The best solution I can think of would be to have a way for a module
to mark itself as "finalized" (I'm not sure if that's the best
term--just the first that popped into my head). This would prevent
its __path__ from being created or extended in any way.
On Wed, Jul 20, 2011 at 3:28 AM, Nick Coghlan wrote:
> Done: http://www.python.org/dev/peps/pep-0394/
Quick question: When I do "svn up", it doesn't show any changes. Has
it been switched over to Mercurial recently?
Thanks,
Kerrick Staley
___
Python-De
On Wed, Jul 20, 2011 at 12:03 PM, Kerrick Staley wrote:
> On Wed, Jul 20, 2011 at 3:28 AM, Nick Coghlan wrote:
>> Done: http://www.python.org/dev/peps/pep-0394/
>
> Quick question: When I do "svn up", it doesn't show any changes. Has
> it been switched over to Mercurial recently?
http://hg.pytho
On 7/20/2011 3:22 AM, Paul Moore wrote:
On 20 July 2011 03:21, Terry Reedy wrote:
Suppose for Windows there were one '.../python' directory wherever the user
first asks it to be put and that all pythons, not just cpython, are
installed in directories below that and that the small startup file i
On 7/20/2011 12:25 PM, Victor Stinner wrote:
Le 20/07/2011 17:58, Éric Araujo a écrit :
Do we have a policy of not adding new test files to stable branches?
New logging tests failed during some weeks. If we add new tests, we may
also break some stable buildbots. I don't think that we need to ad
On 07/20/11 17:05, Éric Araujo wrote:
> Le 20/07/2011 16:40, P.J. Eby a écrit :
>> PEP 12 prescribes four-space indents for PEPs, actually, wherever it
>> mentions an specific indentation depth.
>
> Ah, thanks. I see in my docutils docs that David Goodger used three and
> four-space indents (thre
On 7/20/2011 11:41 AM, r.david.murray wrote:
diff --git a/Lib/email/utils.py b/Lib/email/utils.py
# We need wormarounds for bugs in these methods in older Pythons (see below)
Is 'wormaround' (variation of workaround) an intentional play on the
fact that some worms prey on other 'bugs' ;-
On Wed, Jul 20, 2011 at 11:04 AM, P.J. Eby wrote:
> Hm. Here's another variant that might be easier to implement (even in C),
> and could offer some other advantages as well.
>
> Suppose we replace the sys.virtual_packages set() with a sys.virtual_paths
> dict(): a dictionary that maps from modul
On 7/20/2011 1:04 PM, P.J. Eby wrote:
This part worries me slightly. Imagine a program as such:
datagen.py
json/foo.js
json/bar.js
datagen.py uses the files in json/ to generate sample data for a
database. In datagen.py is the following code:
try:
import json
except ImportError:
import simple
On Wed, 20 Jul 2011 14:12:42 -0400
Terry Reedy wrote:
> On 7/20/2011 11:41 AM, r.david.murray wrote:
>
> > diff --git a/Lib/email/utils.py b/Lib/email/utils.py
>
> > # We need wormarounds for bugs in these methods in older Pythons (see
> > below)
>
> Is 'wormaround' (variation of workaround)
At 01:35 PM 7/20/2011 -0600, Eric Snow wrote:
This is a really nice solution. So a virtual package is not imported
until a submodule of the virtual package is successfully imported
Correct...
(except for direct import of pure virtual packages).
Not correct. ;-) What we do is avoid creati
On Wed, Jul 20, 2011 at 2:44 PM, P.J. Eby wrote:
> At 01:35 PM 7/20/2011 -0600, Eric Snow wrote:
>>
>> This is a really nice solution. So a virtual package is not imported
>> until a submodule of the virtual package is successfully imported
>
> Correct...
>
>> (except for direct import of pure vi
On 7/20/2011 7:19 AM, Vinay Sajip wrote:
Glenn Linderman g.nevcal.com> writes:
Since I don't yet have associations set up that point at the
launcher, I thought I'd play with saying "py" in front of the
command.
Why don't you have any associations pointing to the launcher? Did
On Wed, 20 Jul 2011 22:40:17 +0200, Antoine Pitrou wrote:
> On Wed, 20 Jul 2011 14:12:42 -0400
> Terry Reedy wrote:
> > On 7/20/2011 11:41 AM, r.david.murray wrote:
> >
> > > diff --git a/Lib/email/utils.py b/Lib/email/utils.py
> >
> > > # We need wormarounds for bugs in these methods in olde
Victor Stinner haypocalc.com> writes:
> New logging tests failed during some weeks. If we add new tests, we may
> also break some stable buildbots. I don't think that we need to add
> these new tests to a stable version.
Just for my information, which logging test failures are you referring to
On 7/20/2011 6:05 AM, P.J. Eby wrote:
At 02:24 AM 7/20/2011 -0700, Glenn Linderman wrote:
When I read about creating __path__ from sys.path, I immediately
thought of the issue of programs that extend sys.path, and the above
is the "workaround" for such programs. but it requires such
programs
On Wed, Jul 20, 2011 at 11:48, Terry Reedy wrote:
> On 7/20/2011 12:25 PM, Victor Stinner wrote:
>
>> Le 20/07/2011 17:58, Éric Araujo a écrit :
>>
>>> Do we have a policy of not adding new test files to stable branches?
>>>
>> New logging tests failed during some weeks. If we add new tests, we m
Glenn Linderman wrote:
On 7/20/2011 7:19 AM, Vinay Sajip wrote:
It's not py's job to walk the path: the shell does that when you just type
"foo". It locates foo.py, and then invokes py because of file association - py
then checks the file for a shebang to decide which Python to dispatch it to.
At 03:22 PM 7/20/2011 -0600, Eric Snow wrote:
On Wed, Jul 20, 2011 at 2:44 PM, P.J. Eby wrote:
>
> So, yeah, actually, that's looking pretty sweet. Basically, we
just have to
> throw a virtual_package_paths dict into the sys module, and do the above
> along with the get_virtual_path() functio
At 03:09 PM 7/20/2011 -0700, Glenn Linderman wrote:
On 7/20/2011 6:05 AM, P.J. Eby wrote:
At 02:24 AM 7/20/2011 -0700, Glenn Linderman wrote:
When I read about creating __path__ from sys.path, I immediately
thought of the issue of programs that extend sys.path, and the
above is the "workaround
On 7/20/2011 4:03 PM, P.J. Eby wrote:
I'd recommend *always* using it, outside of simple startup code.
So that is a burden on every program. Documentation would help, but it
certainly makes updating sys.path much more complex -- 3 lines (counting
import of pkgutil) instead of one, and the co
On 21/07/2011 7:43 AM, Glenn Linderman wrote:
...
I still get the same behavior. Is there any debugging output produced
by py.exe that would tell what py.ini it looks in, and what the content
is? What diagnostic steps might I take to produce additional
information that would help you (or me, a
On Thu, Jul 21, 2011 at 8:16 AM, Brett Cannon wrote:
> I say don't add new tests for the sake of coverage or adding new tests to
> stable branches. Tests for bugfixes are practically required.
I don't *object* to enhanced tests going into maintenance branches,
but the workflow of committing direc
On 21/07/2011 4:38 AM, Terry Reedy wrote:
Many installers first make an organization directory and then an app
directory within that. This annoys me sometimes when they only have one
app to ever install, but is useful when there might really be multiple
directories, as in our case. (Ditto for st
On 7/20/2011 4:41 PM, Mark Hammond wrote:
On 21/07/2011 7:43 AM, Glenn Linderman wrote:
...
I still get the same behavior. Is there any debugging output produced
by py.exe that would tell what py.ini it looks in, and what the content
is? What diagnostic steps might I take to produce additiona
On Thu, Jul 21, 2011 at 8:51 AM, Ethan Furman wrote:
> I would say that would be a cool enhancement, as it could save a bit of
> typing, but I think the launcher is quite useful even without path
> traversal.
Two related points:
1. Walking PATH isn't necessary, but the cwd of the py process shou
On Thu, 21 Jul 2011 09:55:28 +1000
Mark Hammond wrote:
>
> > The two proposals
> > overlap but are not mutually exclusive. For future pythons, 'python33'
> > is easier to remember and type than 'py -v 3.3' or whatever the proposed
> > encantation is.
>
> 'py -3.3' - less chars to type than 'pyt
On 21/07/2011 10:02 AM, Glenn Linderman wrote:
So this tells me that it didn't find a local py.ini (no surprise, I
don't have one) but doesn't tell me that it did find or read
c:\Windows\system32\py.ini much less whether I have the syntax correct
for my [defaults] section. It doesn't tell me tha
On 21/07/2011 10:08 AM, Antoine Pitrou wrote:
On Thu, 21 Jul 2011 09:55:28 +1000
Mark Hammond wrote:
> The two proposals
overlap but are not mutually exclusive. For future pythons, 'python33'
is easier to remember and type than 'py -v 3.3' or whatever the proposed
encantation is.
'py -3.
On 7/20/2011 2:43 PM, Glenn Linderman wrote:
It's not py's job to walk the path: the shell does that when you just type
"foo". It locates foo.py, and then invokes py because of file association - py
then checks the file for a shebang to decide which Python to dispatch it to.
Certainly when the
On 7/20/2011 5:07 PM, Nick Coghlan wrote:
On Thu, Jul 21, 2011 at 8:51 AM, Ethan Furman wrote:
I would say that would be a cool enhancement, as it could save a bit of
typing, but I think the launcher is quite useful even without path
traversal.
Two related points:
1. Walking PATH isn't necess
On 7/20/2011 5:11 PM, Mark Hammond wrote:
On 21/07/2011 10:02 AM, Glenn Linderman wrote:
So this tells me that it didn't find a local py.ini (no surprise, I
don't have one) but doesn't tell me that it did find or read
c:\Windows\system32\py.ini much less whether I have the syntax correct
for my
On 21/07/2011 10:13 AM, Glenn Linderman wrote:
On 7/20/2011 2:43 PM, Glenn Linderman wrote:
It's not py's job to walk the path: the shell does that when you just type
"foo". It locates foo.py, and then invokes py because of file association - py
then checks the file for a shebang to decide which
On 21/07/2011 10:18 AM, Glenn Linderman wrote:
On 7/20/2011 5:07 PM, Nick Coghlan wrote:
On Thu, Jul 21, 2011 at 8:51 AM, Ethan Furman wrote:
I would say that would be a cool enhancement, as it could save a bit of
typing, but I think the launcher is quite useful even without path
traversal.
T
Éric Araujo writes:
> FYI, reST uses three-space indents, not four (so that blocks align
> nicely under the leading two dots + one space), so I think the change
> was intentional.
No, reST doesn't specify any particular level of indentation. Like most
Python programmers I prefer four-space inden
On Thu, Jul 21, 2011 at 9:03 AM, P.J. Eby wrote:
> Hm. Yes, there is a way to do something like that, but it would complicate
> things a bit. We'd need to:
>
> 1. Leave __path__ off of the modules, and always pull them from
> sys.virtual_package_paths, and
Setting __path__ to a sentinel value (
On Wed, Jul 20, 2011 at 20:31, Ben Finney wrote:
> Éric Araujo writes:
>
> > FYI, reST uses three-space indents, not four (so that blocks align
> > nicely under the leading two dots + one space), so I think the change
> > was intentional.
>
> No, reST doesn't specify any particular level of inden
On Wed, Jul 20, 2011 at 7:52 PM, Nick Coghlan wrote:
> Even better would be for these (and sys.path) to be list subclasses
> that did the right thing under the hood as Glenn suggested. Code that
> *replaces* rather than modifies these attributes would still
> potentially break virtual packages, bu
R. David Murray writes:
> Hexlify, wormaround...our Barry is just full of interesting words :)
Not "full" at all---there's no there there to put them in.
He's a generator!
The FLUFL-always-uses-efficient-idioms-ly y'rs,
___
Python-Dev mailing list
Py
On Thu, 21 Jul 2011 10:27:31 +1000, Mark Hammond
wrote:
> On 21/07/2011 10:18 AM, Glenn Linderman wrote:
> > On 7/20/2011 5:07 PM, Nick Coghlan wrote:
> >> On Thu, Jul 21, 2011 at 8:51 AM, Ethan Furman wrote:
> >>> I would say that would be a cool enhancement, as it could save a bit of
> >>> typ
On Thu, Jul 21, 2011 at 12:52 PM, R. David Murray wrote:
> Indeed. If I want to run a script with a different python version
> on a unix-like system, I need to know the path to said script.
> We're trying to make python as easy to use on Windows as it is on Unix.
> If find-script-on-path is consi
On Sun, 17 Jul 2011 19:19:59 -0700
Brett Cannon wrote:
> Just so people know, I went ahead and fixed this for 3.3 (but not for
> 3.2 since it changes the API in a subtle way).
Yeah, but that shouldn't break anything.
Anyway, thanks a lot for your help, I'm happy it's in 3.3.
lekma
>
> On Sat,
I've updated PEP 397 - "Python launcher for Windows" based on recent
discussions and Vinay's implementation.
http://www.python.org/dev/peps/pep-0397/ and a copy is attached for your
convenience.
The main changes are:
* All mentions of the Python reference implementation have been removed
no
66 matches
Mail list logo
