On Sun, 17 Jul 2011 19:19:59 -0700
Brett Cannon br...@python.org 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.
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
now
On Jul 20, 2011, at 3:16 PM, Brett Cannon wrote:
On Wed, Jul 20, 2011 at 11:48, Terry Reedy tjre...@udel.edu 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
On 7/20/2011 8:22 PM, Nick Coghlan wrote:
On Thu, Jul 21, 2011 at 12:52 PM, R. David Murrayrdmur...@bitdance.com 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 7/20/2011 5:34 PM, Mark Hammond wrote:
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
On 7/20/2011 11:35 PM, Mark Hammond wrote:
* If the command starts with the definition of a customized command
followed by a space character, the customized command will be used.
See below for a description of customized commands.
Then a shebang line of '#! vpython' in
On Thu, Jul 21, 2011 at 6:06 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
Interesting, David, that you feel it that Python usability on Windows should
be limited to its usability on Unix, rather than to exceed it. I don't see
that as a necessary or appropriate limit. Windows and Unix are
On 21/07/2011 6:32 PM, Glenn Linderman wrote:
On 7/20/2011 11:35 PM, Mark Hammond wrote:
* If the command starts with the definition of a customized command
followed by a space character, the customized command will be used.
See below for a description of customized commands.
On 21/07/2011 00:07, Vinay Sajip wrote:
Victor Stinnervictor.stinnerat 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
On Thu, 21 Jul 2011 01:06:57 -0700, Glenn Linderman v+pyt...@g.nevcal.com
wrote:
Interesting, David, that you feel it that Python usability on Windows
should be limited to its usability on Unix, rather than to exceed it. I
don't see that as a necessary or appropriate limit. Windows and Unix
If you're going to include this into standard Python distribution, it
needs more attention from _users_. As a user, I can not find any
references to any user stories in this PEP article. Abstract chapter
is totally useless
This PEP (named 'Python launcher for Windows') describes a Python
launcher
On Jul 21, 2011 7:15 AM, anatoly techtonik techto...@gmail.com wrote:
If you're going to include this into standard Python distribution, it
needs more attention from _users_. As a user, I can not find any
references to any user stories in this PEP article. Abstract chapter
is totally useless
On 21/07/2011 10:13 PM, anatoly techtonik wrote:
If you're going to include this into standard Python distribution, it
needs more attention from _users_. As a user, I can not find any
references to any user stories in this PEP article. Abstract chapter
is totally useless
Could you please be a
At 11:52 AM 7/21/2011 +1000, Nick Coghlan wrote:
Trying to change how packages are identified at the Python level makes
PEP 382 sound positively appealing. __path__ needs to stay :)
In which case, it should be a list, not a sentinel. ;-)
Even better would be for these (and sys.path) to be
On 21 July 2011 09:13, Glenn Linderman v+pyt...@g.nevcal.com wrote:
Certainly when the launcher is invoked via an association, this would
be the case. However, when the launcher is invoked via the command
line, then the unqualified name is passed through. To be useful from
the command line,
On 21/07/2011 15:43, Paul Moore wrote:
On 21 July 2011 09:13, Glenn Lindermanv+pyt...@g.nevcal.com wrote:
Certainly when the launcher is invoked via an association, this would
be the case. However, when the launcher is invoked via the command
line, then the unqualified name is passed through.
On Wed, Jul 20, 2011 at 23:05, lekmalek lekma...@gmail.com wrote:
On Sun, 17 Jul 2011 19:19:59 -0700
Brett Cannon br...@python.org 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
On 7/21/2011 2:15 PM, Brett Cannon wrote:
It won't break any _existing_ code, but it could cause compatibility for
_future_ code. Imagine I wrote some code for 3.2.2 where this change was
backported and worked *only* with this fix. That would mean my code
would fail in any Python 3.2.1 or
On 7/21/2011 2:58 AM, Raymond Hettinger wrote:
I concur with Brett. Nothing good will come from backporting tests that
aren't aimed at a specific bugfix.
They could catch reversions that otherwise would not be caught. This
would mainly apply to 2.7. It would not be an issue for 3.2 if all
On 7/20/2011 7:55 PM, Mark Hammond wrote:
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
On 7/21/2011 8:20 AM, Michael Foord wrote:
On 21/07/2011 15:43, Paul Moore wrote:
On 21 July 2011 09:13, Glenn Lindermanv+pyt...@g.nevcal.com wrote:
Certainly when the launcher is invoked via an association, this would
be the case. However, when the launcher is invoked via the command
line,
At 12:59 PM 7/21/2011 -0700, Reliable Domains wrote:
I assume that the implicit extend_virtual_paths() would be smart
enough to only do real work if there are virtual packages to do it
in, so much of the performance costs (bunch of stats) are bounded by
the existence of and number of virtual
On Fri, Jul 22, 2011 at 5:20 AM, Terry Reedy tjre...@udel.edu wrote:
On 7/21/2011 2:58 AM, Raymond Hettinger wrote:
I concur with Brett. Nothing good will come from backporting tests that
aren't aimed at a specific bugfix.
They could catch reversions that otherwise would not be caught. This
On Fri, Jul 22, 2011 at 6:05 AM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
On 7/21/2011 8:20 AM, Michael Foord wrote:
py launcher and python binaries behaving differently in this regard would be
a recipe for confusion and hard to debug problems.
I see the point. Although the incremental
On Thu, Jul 21, 2011 at 11:20 PM, P.J. Eby p...@telecommunity.com wrote:
This seems to lean in favor of making a simple reiterable wrapper type for
the __path__, that only allows you to take the length and iterate over it.
With an appropriate design, it could actually update itself
Please don't add the IRC link to the devguide.
Based on conversations with Guido, he is against it being part of the core
development process.
Raymond
On Jul 21, 2011, at 4:08 AM, Nick Coghlan wrote:
On Thu, Jul 21, 2011 at 7:16 PM, Ezio Melotti ezio.melo...@gmail.com wrote:
FWIW you
On Thu, 21 Jul 2011 15:37:01 -0700
Raymond Hettinger raymond.hettin...@gmail.com wrote:
Please don't add the IRC link to the devguide.
Based on conversations with Guido, he is against it being part of the core
development process.
IRC is very much outside of the core development process, but
Anyone care to take a look at this?
Thank you,
Vlad
On Mon, Jul 11, 2011 at 8:59 AM, Vlad Riscutia riscutiav...@gmail.comwrote:
Actually I already attached patch implementing everything to the issue (not
too much time spent :)). I'm hoping someone can review.
Thank you,
Vlad
On Mon, Jul
On 7/20/2011 5:11 PM, Mark Hammond wrote:
It may be that your copy of the launcher is a little old - some
changes were pushed just yesterday (but I'm not sure if Vinay made a
new installer yet). It has slightly better debug output (although
generally not what you are asking for yet) and
On 7/20/2011 11:35 PM, Mark Hammond wrote:
Customized Commands:
The launcher will support the ability to define Customized Commands in a
Windows .ini file (ie, a file which can be parsed by the Windows function
GetPrivateProfileString). A section called '[commands]' can be
On 7/20/2011 11:35 PM, Mark Hammond wrote:
Virtual commands in shebang lines:
Virtual Commands are shebang lines which start with strings which would
be expected to work on Unix platforms - examples include
'/usr/bin/python', '/usr/bin/env python' and 'python'. Optionally, the
On Tue, 19 Jul 2011 23:58:55 -0400
P.J. Eby p...@telecommunity.com wrote:
Anyway, to make a long story short, we came up with an alternative
implementation plan that actually solves some other problems besides
the one that PEP 382 sets out to solve, and whose implementation a
bit is
Le 21/07/2011 01:54, Nick Coghlan a écrit :
[...]
So slightly more relaxed than Brett's view:
- definitely apply bug fixes and their tests to affected maintenance branches
- *optionally* apply coverage enhancements to maintenance branches,
but don't feel obliged to do so
I see it as a
Le 21/07/2011 03:31, Ben Finney a écrit :
Éric Araujo mer...@netwok.org 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
On Fri, Jul 22, 2011 at 9:35 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 19 Jul 2011 23:58:55 -0400
P.J. Eby p...@telecommunity.com wrote:
Anyway, to make a long story short, we came up with an alternative
implementation plan that actually solves some other problems besides
the one
Le vendredi 22 juillet 2011 à 09:53 +1000, Nick Coghlan a écrit :
On Fri, Jul 22, 2011 at 9:35 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 19 Jul 2011 23:58:55 -0400
P.J. Eby p...@telecommunity.com wrote:
Anyway, to make a long story short, we came up with an alternative
On 7/21/2011 5:00 PM, Antoine Pitrou wrote:
Le vendredi 22 juillet 2011 à 09:53 +1000, Nick Coghlan a écrit :
On Fri, Jul 22, 2011 at 9:35 AM, Antoine Pitrousolip...@pitrou.net wrote:
On Tue, 19 Jul 2011 23:58:55 -0400
P.J. Ebyp...@telecommunity.com wrote:
Anyway, to make a long story
On Thu, 21 Jul 2011 17:31:04 -0700
Glenn Linderman v+pyt...@g.nevcal.com wrote:
If I have (on sys.path), a directory x containing a y.py module, and
later (on sys.path), another directory x containing a y.py module,
what is from x import y supposed to do?
OR
If I have (on sys.path), a
On 22/07/2011 9:02 AM, Glenn Linderman wrote:
Bad logic is get_configured_value! get_configured_value only looks in
the global configuration file if there is a local configuration file
that doesn't have the setting. It should look in the global
configuration file if there is no local
On 7/21/2011 5:38 PM, Antoine Pitrou wrote:
However, you can have a x.py file and a x directory *in the same
base directory which is present in sys.path*, meaning sys.path can't
help disambiguate in this case.
Ah yes. It means there has to be one more rule for disambiguation,
which Nick
On Fri, Jul 22, 2011 at 10:00 AM, Antoine Pitrou solip...@pitrou.net wrote:
Wouldn't it produce confusing situations like the above example?
I don't see how it is any more confusing than any other form of module
shadowing.
For backwards compatibility reasons, the precedence model will be:
1.
I'm kind of -1 on changing Python executable name. It would make sense for
different major versions, where there are known incompatibilities, so
python2-python3 would make sense but python31 python32 not that much...
If my team is using Python and it gets pre-installed with other dev-tools,
do I
On Fri, Jul 22, 2011 at 10:53 AM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
Ah yes. It means there has to be one more rule for disambiguation, which
Nick supplied. Your case wasn't clear to me from your first description,
however. As long as there is an ordering, and it is documented, it
Le vendredi 22 juillet 2011 à 10:58 +1000, Nick Coghlan a écrit :
On Fri, Jul 22, 2011 at 10:00 AM, Antoine Pitrou solip...@pitrou.net wrote:
Wouldn't it produce confusing situations like the above example?
I don't see how it is any more confusing than any other form of module
shadowing.
Hi,
Le 22/07/2011 03:03, Vlad Riscutia a écrit :
I'm kind of -1 on changing Python executable name. It would make sense for
different major versions, where there are known incompatibilities, so
python2-python3 would make sense but python31 python32 not that much...
If my team is using
If versioned filenames are added in addition to python.exe, it still might
look confusing for most users: Why do I have python and python3.2
executables? What's the difference? I'd rather go with -v argument either
way, for people that *know* they want to call Python 3.2 instead of Python
3.1...
At 03:04 AM 7/22/2011 +0200, Antoine Pitrou wrote:
The additional confusion lies in the fact that a module can be
shadowed by something which is not a module (a mere global
variable). I find it rather baffling.
If you move x.py to x/__init__.py, it does *exactly the same thing*
in current
On Fri, Jul 22, 2011 at 11:04 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le vendredi 22 juillet 2011 à 10:58 +1000, Nick Coghlan a écrit :
On Fri, Jul 22, 2011 at 10:00 AM, Antoine Pitrou solip...@pitrou.net wrote:
Wouldn't it produce confusing situations like the above example?
I don't
Glenn Linderman writes:
I note in passing that '/usr/bin/env python' is hard-coded in the
launcher, which conforms to the above documentation.
A single character (space or tab) is also hard-coded in Emacs's
python-mode.
But there is no hard requirement in Unix, if I correctly understand
49 matches
Mail list logo
