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 understan
On Fri, Jul 22, 2011 at 11:04 AM, Antoine Pitrou wrote:
>
> Le vendredi 22 juillet 2011 à 10:58 +1000, Nick Coghlan a écrit :
>> On Fri, Jul 22, 2011 at 10:00 AM, Antoine Pitrou wrote:
>> > Wouldn't it produce confusing situations like the above example?
>>
>> I don't see how it is any more confu
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 ver
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...
T
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 P
Le vendredi 22 juillet 2011 à 10:58 +1000, Nick Coghlan a écrit :
> On Fri, Jul 22, 2011 at 10:00 AM, Antoine Pitrou 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.
The additional
On Fri, Jul 22, 2011 at 10:53 AM, Glenn Linderman 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 is not
> particular
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 n
On Fri, Jul 22, 2011 at 10:00 AM, Antoine Pitrou 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. Modules and self-con
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 s
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 configurat
On Thu, 21 Jul 2011 17:31:04 -0700
Glenn Linderman 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 mod
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 Pitrou wrote:
On Tue, 19 Jul 2011 23:58:55 -0400
"P.J. Eby" wrote:
Anyway, to make a long story short, we came up with an alternative
impleme
Le vendredi 22 juillet 2011 à 09:53 +1000, Nick Coghlan a écrit :
> On Fri, Jul 22, 2011 at 9:35 AM, Antoine Pitrou wrote:
> > On Tue, 19 Jul 2011 23:58:55 -0400
> > "P.J. Eby" wrote:
> >>
> >> Anyway, to make a long story short, we came up with an alternative
> >> implementation plan that actual
On Fri, Jul 22, 2011 at 9:35 AM, Antoine Pitrou wrote:
> On Tue, 19 Jul 2011 23:58:55 -0400
> "P.J. Eby" 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 solv
Le 21/07/2011 03:31, Ben Finney a écrit :
> É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.
My
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
On Tue, 19 Jul 2011 23:58:55 -0400
"P.J. Eby" 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 easier to explain. (
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 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 crea
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 better
Anyone care to take a look at this?
Thank you,
Vlad
On Mon, Jul 11, 2011 at 8:59 AM, Vlad Riscutia wrote:
> 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 11, 2011 at 12
On Thu, 21 Jul 2011 15:37:01 -0700
Raymond Hettinger 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 it's
still a reasonable
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 wrote:
>>
>> FWIW you can make #python a
On Thu, Jul 21, 2011 at 11:20 PM, P.J. Eby 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 automatically,
> given a subnam
On Fri, Jul 22, 2011 at 6:05 AM, Glenn Linderman 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 benefit is highe
On Fri, Jul 22, 2011 at 5:20 AM, Terry Reedy 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 would
> m
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 pa
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 Linderman 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 n
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 multiple
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 fix
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 older
On Wed, Jul 20, 2011 at 23:05, lekmalek wrote:
> 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.
>
It won't break an
On 21/07/2011 15:43, Paul Moore wrote:
On 21 July 2011 09:13, Glenn Linderman 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
th
On 21 July 2011 09:13, Glenn Linderman 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, the launcher shoul
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 l
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 l
On Jul 21, 2011 7:15 AM, "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
>
> "This PEP
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 Thu, 21 Jul 2011 01:06:57 -0700, Glenn Linderman
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
That wasn't how
On 21/07/2011 00:07, Vinay Sajip wrote:
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 loggin
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 Thu, Jul 21, 2011 at 6:06 PM, Glenn Linderman 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 different.
> Unix pe
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 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 c
On 7/20/2011 8:22 PM, Nick Coghlan wrote:
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
On Jul 20, 2011, at 3:16 PM, Brett Cannon wrote:
>
>
> 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
47 matches
Mail list logo
