On 3 September 2016 at 14:32, Nick Coghlan wrote:
> On 2 September 2016 at 02:29, Avram Lubkin wrote:
>> On Thu, Sep 1, 2016 at 10:22 AM, Petr Viktorin wrote:
>>>
>>>
>>> Whatever we do, I'd like it to be coordinated across multiple
>>> distrubutions, and blesed by a PEP like [PEP 394]. We don't
On Sat, Sep 3, 2016 at 2:32 PM, Nick Coghlan wrote:
>
> * Tier 0: "the default Python" is determined at the distribution
> level. For the majority of current distributions, that means Python 2,
> but on a select few it means Python 3.
>
> * Tier 1: "the default Python" is configurable on a per-sy
On 2 September 2016 at 02:29, Avram Lubkin wrote:
> On Thu, Sep 1, 2016 at 10:22 AM, Petr Viktorin wrote:
>>
>>
>> Whatever we do, I'd like it to be coordinated across multiple
>> distrubutions, and blesed by a PEP like [PEP 394]. We don't want a solution
>> specific to Fedora.
We do need to fig
On 1 September 2016 at 22:04, Avram Lubkin wrote:
>
> On Thu, Sep 1, 2016 at 7:44 AM, Nick Coghlan wrote:
>>
>>
>> The ideal point we'd like to get to is one where all distro provided
>> scripts actually have the appropriate major version in their shebang
>> lines, and the unqualifed "python" is
On Thu, Sep 1, 2016 at 10:22 AM, Petr Viktorin wrote:
>
> Whatever we do, I'd like it to be coordinated across multiple
> distrubutions, and blesed by a PEP like [PEP 394]. We don't want a solution
> specific to Fedora.
>
Completely agree. Based on the suggestions offered in PEP 394, we would
ne
On 09/01/2016 01:44 PM, Nick Coghlan wrote:
For /usr/bin/python, we had an upstream discussion about that at the
2015 language summit: https://lwn.net/Articles/640296/
Whatever we do, I'd like it to be coordinated across multiple
distrubutions, and blesed by a PEP like [PEP 394]. We don't want
On Thu, Sep 1, 2016 at 8:40 AM, Neal Gompa wrote:
> Sure, but those scripts may not actually work because modules that are
> supposed to be there, aren't. For example, if you depend on a
> non-standard lib module, then that means it needs to be installed for
> each python version supported. How d
On Thu, Sep 1, 2016 at 8:33 AM, Avram Lubkin wrote:
> On Thu, Sep 1, 2016 at 8:14 AM, Neal Gompa wrote:
>>
>> Alternatives doesn't work in this case because Python 2.x and Python
>> 3.x versions don't share resources, even with minor versions of the
>> same series. Enabling alternatives for it is
On Thu, Sep 1, 2016 at 8:14 AM, Neal Gompa wrote:
> Alternatives doesn't work in this case because Python 2.x and Python
> 3.x versions don't share resources, even with minor versions of the
> same series. Enabling alternatives for it is a recipe for disaster.
>
Could you elaborate? The use case
On Thu, Sep 1, 2016 at 8:04 AM, Avram Lubkin wrote:
>
> On Thu, Sep 1, 2016 at 7:44 AM, Nick Coghlan wrote:
>>
>>
>> The ideal point we'd like to get to is one where all distro provided
>> scripts actually have the appropriate major version in their shebang
>> lines, and the unqualifed "python" i
On Thu, Sep 1, 2016 at 7:44 AM, Nick Coghlan wrote:
>
> The ideal point we'd like to get to is one where all distro provided
> scripts actually have the appropriate major version in their shebang
> lines, and the unqualifed "python" is something along the lines of a
> user-configurable launcher,
On 31 August 2016 at 23:54, Charalampos Stratakis wrote:
> Hello Python-SIG,
>
> Currently I am working on some ideas regarding the python package.
>
> Nothing is too concrete yet, however the technical side should be fairly
> simple.
>
> The first thing is renaming python to python2.
Moving "py
12 matches
Mail list logo
