I'm pleased to announce the immediate availability of Python 2.7.16 release
candidate 1. This is a prerelease for yet another bug fix release in the Python
2.7.x series. It includes over 100 fixes over Python 2.7.15. See the changelog
at
On Fri, Feb 15, 2019 at 10:02 AM Zachary Ware
wrote:
> On Fri, Feb 15, 2019 at 11:44 AM Steve Dower
> wrote:
> > That said, I'd love to have a context manager that we can use to make
> > this easier. Really, none of us should be having to decide "how am I
> > going to use a temporary location
On 16Feb.2019 1332, Antoine Pitrou wrote:
> On Sat, 16 Feb 2019 11:15:44 +0100
> Jeroen Demeyer wrote:
>> On 2019-02-16 00:37, Eric Snow wrote:
>>> One thing that would help simplify changes
>>> in this area is if PyInterpreterState were defined in
>>> Include/internal.
>>
>> How would that
On Sat, 16 Feb 2019 11:15:44 +0100
Jeroen Demeyer wrote:
> On 2019-02-16 00:37, Eric Snow wrote:
> > One thing that would help simplify changes
> > in this area is if PyInterpreterState were defined in
> > Include/internal.
>
> How would that help anything? I don't like the idea (in general,
On Feb 16, 2019, at 09:25, Nick Coghlan wrote:
> While Matthias is still personally reluctant to add the alias for
> Debian/Ubuntu, the *only* thing preventing aliasing /usr/bin/python to
> /usr/bin/python3 right now on the Fedora & RHEL side of things is PEP
> 394, and Guido objected strongly
+1 on the improved docs solution: no new code to maintain and big return on
investment in preventing future bugs / confusion :)
On Sat, Feb 16, 2019 at 9:40 AM Nick Coghlan wrote:
> On Sun, 17 Feb 2019 at 03:20, Paul Ganssle wrote:
> > I think if we add such a function, it will essentially be
On Sun, 17 Feb 2019 at 03:20, Paul Ganssle wrote:
> I think if we add such a function, it will essentially be just a slower
> version of something that already exists. I suspect the main reason the
> "divide the timedelta by the interval" thing isn't a common enough idiom that
> people see it
On 16Feb.2019 0831, Nick Coghlan wrote:
> On Sat, 16 Feb 2019 at 08:06, Steve Dower wrote:
>> I'm inclined to say that nobody but us uses this API :) Does that make
>> it seem more okay to "clarify" that it's returning target platform?
>
> I've always treated the situation as "Cross-compilation
On Sat, 16 Feb 2019 at 09:19, Gregory P. Smith wrote:
> Not our problem? Well, actually, it is. Matthias speaking for Debian
> suggesting they don't want to have "python" at all if it isn't a synonym for
> "python2" because it'll break software is... wrong. If software is not 3
> compatible
I am definitely sympathetic to the idea of it being more readable, but I
feel like this adds some unnecessary bloat to the interface when "divide
the value by the units" is not at all uncommon. Plus, if you add a
total_duration that by default does the same thing as total_seconds, you
now have
On Fri, 15 Feb 2019 at 04:15, Alexander Belopolsky
wrote:
>
>
>
> On Thu, Feb 14, 2019 at 9:07 AM Paul Ganssle wrote:
>>
>> I don't think it's totally unreasonable to have other total_X() methods,
>> where X would be days, hours, minutes and microseconds
>
> I do. I was against adding the
On Sat, 16 Feb 2019 at 08:06, Steve Dower wrote:
> I'm inclined to say that nobody but us uses this API :) Does that make
> it seem more okay to "clarify" that it's returning target platform?
I've always treated the situation as "Cross-compilation doesn't work,
build on the target platform,
On 2019-02-16 00:37, Eric Snow wrote:
One thing that would help simplify changes
in this area is if PyInterpreterState were defined in
Include/internal.
How would that help anything? I don't like the idea (in general, I'm not
talking about PyInterpreterState specifically) that external
13 matches
Mail list logo
