On 3 December 2015 at 02:35, Guido van Rossum wrote:
> On Wed, Dec 2, 2015 at 7:32 AM, Emanuel Barry wrote:
>>
>> Nick Coghlan made a pretty elaborated blog post about that here:
>> http://opensource.com/life/14/9/why-python-4-wont-be-python-3
>
> I wholeheartedly agree with what Nick writes ther
On 3/12/2015 5:41 a.m., Random832 wrote:
Why bother with the dot? Why not rename 3.5 to Python 5, and then go to
Python 6, etc, and then your "4.0" would be 10.
Then we could call it Python X!
Everything is better with an X in the name.
--
Greg
___
On 2015-12-02, Andrew Barnert wrote:
> Python could just go from 3.9 to 4.0, as a regular dot release, just
> to dispel the idea of an inevitable backward-incompatible "Python 4".
> (That should be around 2 years after the expiration of 2.7 support,
> py2/py3 naming, etc., right?)
Why bother with
On Wed, Dec 2, 2015 at 7:32 AM, Emanuel Barry wrote:
> Nick Coghlan made a pretty elaborated blog post about that here:
> http://opensource.com/life/14/9/why-python-4-wont-be-python-3
>
I wholeheartedly agree with what Nick writes there -- but I can't resist
noting that the title is backwards --
On Dec 2, 2015, at 07:01, Random832 wrote:
>
> On 2015-12-02, Victor Stinner wrote:
>>> Are there plans for a Python 4?
>>
>> No. Don't. Don't schedule any "removal" or *any* kind of "break
>> backward compatibility" anymore, or you will definetly kill the Python
>> community.
>
> I feel like
> From: victor.stin...@gmail.com
> Date: Wed, 2 Dec 2015 15:46:37 +0100
> To: random...@fastmail.com
> Subject: Re: [Python-Dev] Deleting with setting C API functions
> CC: python-dev@python.org
>
> 2015-12-02 15:40 GMT+01:00 Random832 :
> > Are there plans for a Pyth
On 2015-12-02, Victor Stinner wrote:
>> Are there plans for a Python 4?
>
> No. Don't. Don't schedule any "removal" or *any* kind of "break
> backward compatibility" anymore, or you will definetly kill the Python
> community.
I feel like I should note that I agree with your position here, I was
j
2015-12-02 15:40 GMT+01:00 Random832 :
> Are there plans for a Python 4?
No. Don't. Don't schedule any "removal" or *any* kind of "break
backward compatibility" anymore, or you will definetly kill the Python
community.
It will probably take 10 years or more to convert *all* Python 2 code
around t
On 2015-12-02, M.-A. Lemburg wrote:
> A first step would be to replace the macro with a proper function
> to avoid false positive warnings, even when using the correct API.
>
> Then we could add a warning to the PyObject_SetAttr() function and
> hope that not too many projects use the stable ABI a
On 2 December 2015 at 22:41, M.-A. Lemburg wrote:
> On 02.12.2015 13:29, Serhiy Storchaka wrote:
>> On 02.12.15 12:06, Victor Stinner wrote:
>>> 2015-12-02 9:42 GMT+01:00 Serhiy Storchaka :
You have enough time to update your projects, and you can update them
uniformly for all versions.
On 02.12.2015 13:29, Serhiy Storchaka wrote:
> On 02.12.15 12:06, Victor Stinner wrote:
>> 2015-12-02 9:42 GMT+01:00 Serhiy Storchaka :
>>> You have enough time to update your projects, and you can update them
>>> uniformly for all versions. And may be you will found few weird bugs related
>>> to m
On 02.12.15 12:06, Victor Stinner wrote:
2015-12-02 9:42 GMT+01:00 Serhiy Storchaka :
You have enough time to update your projects, and you can update them
uniformly for all versions. And may be you will found few weird bugs related
to misuse of Set* API.
Did you check popular projects using C
2015-12-02 9:42 GMT+01:00 Serhiy Storchaka :
> You have enough time to update your projects, and you can update them
> uniformly for all versions. And may be you will found few weird bugs related
> to misuse of Set* API.
Did you check popular projects using C extensions to check if they
call Set*(
середа, 02-гру-2015 08:30:35 ви написали:
> Le 1 déc. 2015 16:51, "Serhiy Storchaka" a écrit :
> > Wouldn't be worth to deprecate deleting with Set* functions? Neither
> > other abstract Set* APIs, not concrete Set* APIs don't support deleting.
> >Deleting with Set* API can be unintentional and hi
On 2 December 2015 at 01:50, Serhiy Storchaka wrote:
> On 25.11.15 08:39, Nick Coghlan wrote:
>> So it looks to me like replicating the NULL-handling behaviour of the
>> slots in the public Set* APIs was intentional, and it's just the
>> documentation of that detail that was missed (since most fol
On 25.11.15 08:39, Nick Coghlan wrote:
On 25 November 2015 at 07:33, Guido van Rossum wrote:
Ooooh, that's probably really old code. I guess for the slots the
reasoning is to save on slots. For the public functions, alas it will
be hard to know if anyone is depending on it, even if it's
undocum
On 25 November 2015 at 07:33, Guido van Rossum wrote:
> Ooooh, that's probably really old code. I guess for the slots the
> reasoning is to save on slots. For the public functions, alas it will
> be hard to know if anyone is depending on it, even if it's
> undocumented. Perhaps add a deprecation w
Ooooh, that's probably really old code. I guess for the slots the
reasoning is to save on slots. For the public functions, alas it will
be hard to know if anyone is depending on it, even if it's
undocumented. Perhaps add a deprecation warning to these if the value
is NULL for one release cycle?
On
18 matches
Mail list logo
