On 7/10/19, Brendan Barnwell wrote:
>
> I agree that it seems the real problem here is the lack of a real way
> to determine if an available version is a real release or a
> prerelease/beta. Is it not possible to change that, so that it is
> possible for the launcher to quickly and easily
> On 10 Jul 2019, at 21:13, Steve Barnes wrote:
>
> Brett,
>
> Can I suggest that it might be an idea to add the honouring of PY_PYTHON and
> PY_PYTHON2 environmental variables to the help text. This is the missing
> piece as far as I am concerned.
I knew about the py.ini but not the env
On Wed, Jul 10, 2019 at 1:58 PM Brendan Barnwell
wrote:
> On 2019-07-09 23:23, Alex Walters wrote:
> > I have made this suggestion in the past. The response then was that
> there
> > is no metadata in the windows install that includes if the release is
> > development or stable (that
I'll also mention it's covered in the official docs at
https://docs.python.org/3/using/windows.html#launcher.
On Wed, Jul 10, 2019 at 2:04 PM Brett Cannon wrote:
>
>
> On Wed, Jul 10, 2019 at 1:13 PM Steve Barnes
> wrote:
>
>> Brett,
>>
>>
>>
>> Can I suggest that it might be an idea to add
On Wed, Jul 10, 2019 at 1:13 PM Steve Barnes wrote:
> Brett,
>
>
>
> Can I suggest that it might be an idea to add the honouring of PY_PYTHON
> and PY_PYTHON2 environmental variables to the help text. This is the
> missing piece as far as I am concerned.
>
I would then open a bug report and if
On 2019-07-09 23:23, Alex Walters wrote:
I have made this suggestion in the past. The response then was that there
is no metadata in the windows install that includes if the release is
development or stable (that information is not stored in the registry). I
was advised to adjust my
Brett,
Can I suggest that it might be an idea to add the honouring of PY_PYTHON and
PY_PYTHON2 environmental variables to the help text. This is the missing piece
as far as I am concerned.
Steve
From: Brett Cannon
Sent: 10 July 2019 18:41
To: Steve Barnes
Cc: Python-Ideas
Subject: Re:
Based on the various responses I've seen, one thing I want to make very
clear is the launcher needs to be *fast*. That means no executing Python
code, minimizing stat calls, etc.
Also be aware that I'm developing a launcher for UNIX, which puts its own
twist on this whole situation as there's no
On Tue, Jul 9, 2019 at 4:15 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> On Jul 9, 2019, at 13:09, Shay Cohen wrote:
> >
> > >>> a: 3
>
> The reason this isn’t a syntax error is that Python allows any valid
> expression as an annotation. And “3” is just as valid an
On 7/9/19, Steve Barnes wrote:
>
> Currently the py[w] command will launch the latest python by default however
> I feel that this discourages the testing of pre-releases & release
> candidates as once they are installed they will become the default. What I
> would like is for the default to be
My thought is one of:
- if an explicit version is not specified the top (i.e. highest version)
candidate at the call time could be timestamp checked and compared with a
registry or ini file entry - if the entry for that version is missing or has a
different timestamp stored then it could be
I have made this suggestion in the past. The response then was that there
is no metadata in the windows install that includes if the release is
development or stable (that information is not stored in the registry). I
was advised to adjust my configuration of the py.exe launcher to set a
12 matches
Mail list logo
