Am 29.05.2012 01:15, schrieb mar...@v.loewis.de:
>> Comments welcome, especially on whether Windows users agree that
>> something like this is needed in the absence of PEP 397 in Python 3.3.
>
> AFAICT, there is no need to check in the binary into revision control.
> Instead, the Windows build p
On 5/28/2012 10:31 PM, Nick Coghlan wrote:
Given an exchange on the tracker, I feel I should expand on this point.
Historically, our Setup& Usage documentation has *only* covered the
main Python executable, even though we actually install additional
tools, including pydoc, idle, 2to3 and now p
On Tue, May 29, 2012 at 1:03 PM, eli.bendersky
wrote:
> http://hg.python.org/cpython/rev/7d252dbfbee3
> changeset: 77217:7d252dbfbee3
> user: Eli Bendersky
> date: Tue May 29 06:02:56 2012 +0300
> summary:
> Issue 14814: Add namespaces keyword arg to find(*) methods in _elementtr
On 5/28/2012 9:48 PM, Brian Curtin wrote:
> On Mon, May 28, 2012 at 8:44 PM, Terry Reedy wrote:
snipped context: return eval(user_entered_expression, namespace)
+except:
return None
>>>
>>>
>>> "except Exception" may be better here.
>>
>>
>> Idle's S
On Sat, May 26, 2012 at 2:07 AM, Larry Hastings wrote:
>
> On 05/25/2012 10:14 AM, Antoine Pitrou wrote:
>
> On Fri, 25 May 2012 18:57:57 +0200
> Georg Brandl wrote:
>
> This is probably minor, but wouldn't it make more sense to have those
> constants uppercased? At least that's the general styl
Le 28/05/2012 22:31, Nick Coghlan a écrit :
> Historically, our Setup & Usage documentation has *only* covered the
> main Python executable, even though we actually install additional
> tools, including pydoc, idle, 2to3 and now pysetup and pyvenv, and
> provide additional documented and supported
On Tue, May 29, 2012 at 9:20 AM, Nick Coghlan wrote:
> As the standard library comes to include more directly executed tools,
> we really need to focus on keeping the Setup & Usage docs up to date.
> The fact we've been historically lax on that front is no excuse for
> perpetuating the problem for
On Mon, May 28, 2012 at 8:44 PM, Terry Reedy wrote:
>>> + except:
>>> return None
>>
>>
>> "except Exception" may be better here.
>
>
> Idle's Shell catches all exceptions. I think the attempt to provide an
> optional help (a function signature) should too.
Can you exp
On 5/28/2012 2:53 AM, Georg Brandl wrote:
Am 28.05.2012 03:55, schrieb terry.reedy:
namespace.update(__main__.__dict__)
try:
return eval(name, namespace)
-except (NameError, AttributeError):
+# any exception is possible
On Tue, May 29, 2012 at 10:07 AM, Carl Meyer wrote:
> On 05/28/2012 04:24 PM, Nick Coghlan wrote:
>> It would have been better if the issue of script management on Windows
>> had been raised in PEP 405 itself - I likely would have declared PEP
>> 397 a dependency *before* accepting it (even if tha
On 05/28/2012 04:24 PM, Nick Coghlan wrote:
> It would have been better if the issue of script management on Windows
> had been raised in PEP 405 itself - I likely would have declared PEP
> 397 a dependency *before* accepting it (even if that meant the feature
> missed the alpha 4 deadline and firs
Vinay originally wrote:
PEP 397 (Python launcher for Windows) has not yet been accepted, so there still
needs to be some way of natively launching scripts in Windows which is
equivalent to /path/to/venv/bin/foo. The way setuptools (and hence Distribute)
does this is to shadow each script with an
On Tue, May 29, 2012 at 5:37 AM, Vinay Sajip wrote:
> Antoine Pitrou pitrou.net> writes:
>
>> Regardless of what the executable is or does, its source code must be
>> included somewhere in the Python source tree (and, preferably, there
>> should be a simple procedure to build the binaries).
>
> I
The documentation does not currently provide end user guides for
pysetup or pyvenv under http://docs.python.org/dev/using/index.html
This needs to be fixed before 3.3 is released. I've created the
following issues as deferred blockers (since they don't need to be
addressed before the alpha this we
Comments welcome, especially on whether Windows users agree that
something like this is needed in the absence of PEP 397 in Python 3.3.
AFAICT, there is no need to check in the binary into revision control.
Instead, the Windows build process should create, package, and deploy
them, and venv sho
On Mon, 28 May 2012 21:23:50 + (UTC)
Vinay Sajip wrote:
> Antoine Pitrou pitrou.net> writes:
>
> > Not necessarily, but OTOH, it is not really standard procedure to
> > commit half-finished patches.
>
> I didn't want to miss the window for the upcoming alpha, and and I'm not sure
> exactly
Antoine Pitrou pitrou.net> writes:
> Not necessarily, but OTOH, it is not really standard procedure to
> commit half-finished patches.
I didn't want to miss the window for the upcoming alpha, and and I'm not sure
exactly how things will pan out with respect to PEP 397 and packaging. If people
On Mon, 28 May 2012 19:37:55 + (UTC)
Vinay Sajip wrote:
> Antoine Pitrou pitrou.net> writes:
>
> > Regardless of what the executable is or does, its source code must be
> > included somewhere in the Python source tree (and, preferably, there
> > should be a simple procedure to build the bina
Antoine Pitrou pitrou.net> writes:
> Regardless of what the executable is or does, its source code must be
> included somewhere in the Python source tree (and, preferably, there
> should be a simple procedure to build the binaries).
I understand that. Does it need to be checked in right now? It
On Mon, 28 May 2012 17:25:10 + (UTC)
Vinay Sajip wrote:
>
> The foo.exe file is just a copy of a stock launcher executable which finds its
> name from the C argv[0], and based in that name (foo in this case), invokes
> foo-script.py or foo-script.pyw with the appropriate Python interpreter.
In the recent check-in I made of the PEP 405 functionality, there is a Windows
executable. Antoine asked what this was in his comment on the checkin, but I
couldn't respond via Gmane (my usual method) as for some reason his post
doesn't appear there.
PEP 397 (Python launcher for Windows) has not y
21 matches
Mail list logo
