Re: [Python-Dev] Deleting with setting C API functions

[Serhiy Storchaka]

середа, 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 hide a bug.
> Wow wow wow, what? No, dont break Python C API for purity. 8 years later,
> we are still porting projects to python 3 And we are not done yet.

I suggest just to deprecate this feature. I'm not suggesting to remove it in 
the foreseeable future (at least before 4.0).

> Practicability beats purity.

I don't think this argument applies here. Two things make the deprecation more 
painless than usual:

1. This feature has never been documented.

2. PyObject_DelAttr() exists from the start (from the time of adding Generic 
Abstract Object Interface).

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.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deleting with setting C API functions

[Victor Stinner]

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*() functions to delete attributes/items?

If the feature is used, I suggest to document and test it, not remove it.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deleting with setting C API functions

[Serhiy Storchaka]

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 extensions to check if they
call Set*() functions to delete attributes/items?


I have checked following projects.

regex, simplejson, Pillow, PyQt4, LibreOffice, PyGTK, PyICU, pyOpenSSL, 
libxml2, Boost, psutil, mercurial don't use PyObject_SetAttr at all.


NumPy, pgobject don't use PyObject_SetAttr for deleting.

PyYAML and lxml use PyObject_SetAttr only in code generated by Cython 
and never use it for deleting.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deleting with setting C API functions

[M.-A. Lemburg]

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 misuse of Set* API.
>>
>> Did you check popular projects using C extensions to check if they
>> call Set*() functions to delete attributes/items?
> 
> I have checked following projects.
> 
> regex, simplejson, Pillow, PyQt4, LibreOffice, PyGTK, PyICU, pyOpenSSL, 
> libxml2, Boost, psutil,
> mercurial don't use PyObject_SetAttr at all.
> 
> NumPy, pgobject don't use PyObject_SetAttr for deleting.
> 
> PyYAML and lxml use PyObject_SetAttr only in code generated by Cython and 
> never use it for deleting.

While I don't think deleting attributes is a very common thing
to do in any Python code base (unless you need to break circular
references or explicitly want to free resources), the
fact that PyObject_DelAttr() itself is implemented as macro
using the NULL attribute value clearly creates an API incompatibility
when removing this functionality or generating warnings, since
all code using the correct PyObject_DelAttr() at the moment,
would then trigger the warning as well.

As a result, the deprecation would have to be extended across
more releases than the usual cycle.

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 as basis to
have C extensions work across several releases.

Overall, I'm not sure whether it's worth the trouble. Documenting
the feature and adding a deprecation notice to just the documentation
would likely be better. We could then remove the functionality
in Python 4.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Dec 02 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deleting with setting C API functions

[Nick Coghlan]

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. 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*() functions to delete attributes/items?
>>
>> I have checked following projects.
>>
>> regex, simplejson, Pillow, PyQt4, LibreOffice, PyGTK, PyICU, pyOpenSSL, 
>> libxml2, Boost, psutil,
>> mercurial don't use PyObject_SetAttr at all.
>>
>> NumPy, pgobject don't use PyObject_SetAttr for deleting.
>>
>> PyYAML and lxml use PyObject_SetAttr only in code generated by Cython and 
>> never use it for deleting.
>
> While I don't think deleting attributes is a very common thing
> to do in any Python code base (unless you need to break circular
> references or explicitly want to free resources), the
> fact that PyObject_DelAttr() itself is implemented as macro
> using the NULL attribute value clearly creates an API incompatibility
> when removing this functionality or generating warnings, since
> all code using the correct PyObject_DelAttr() at the moment,
> would then trigger the warning as well.
>
> As a result, the deprecation would have to be extended across
> more releases than the usual cycle.
>
> 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 as basis to
> have C extensions work across several releases.

Ah, I forgot to take the stable ABI guarantee into account - you're
right, it isn't possible to introduce the deprecation without making
an addition to the stable ABI, which would mean extension modules
relying on the stable ABI would need to be rebuilt, rather defeating
the purpose of the stable ABI guarantee.

I think that puts the idea squarely in "we can't do it" territory,
since the benefit on offer through the deprecation process is only a
much easier debugging session when someone is trying to track down the
root cause of an unexpectedly missing attribute on an object.

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deleting with setting C API functions

[Random832]

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 as basis to
> have C extensions work across several releases.

How about using a versioned ABI? Make a new function that
doesn't allow NULL, called something like PyObject_SetAttr2, and
instead of declaring the old one in headers, use a #define to
the new name.

> Overall, I'm not sure whether it's worth the trouble. Documenting
> the feature and adding a deprecation notice to just the documentation
> would likely be better. We could then remove the functionality
> in Python 4.

Are there plans for a Python 4?

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deleting with setting C API functions

[Victor Stinner]

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 the world to Python 3. I don't want to have to redo the same
thing again. Never ever again.

To be clear: removing functions is fine, but if and only if you have a
smooth transition plan. Sorry, it's unclear to me what is a "smooth
transition plan". IMHO the deprecation warnings which are current
quiet by default is not a good idea. Everybody ignore them, and then
complain when the function is really removed.

Maybe I should write an informal PEP to explain my idea.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deleting with setting C API functions

[Random832]

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
just asking the question to articulate the issue that "put it off to the
indefinite future" isn't a real plan for anything.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deleting with setting C API functions

[Emanuel Barry]

> 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 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.

Nick Coghlan made a pretty elaborated blog post about that here: 
http://opensource.com/life/14/9/why-python-4-wont-be-python-3   
 ___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Avoiding CPython performance regressions

[Popa, Stefan A]

Hi Fabio,

Let me know if you have any questions related to the Python benchmarks run 
nightly in Intel’s 0-Day Lab.

Thanks,
Stefan


From: "Stewart, David C" 
mailto:david.c.stew...@intel.com>>
Date: Tuesday 1 December 2015 at 17:26
To: Fabio Zadrozny mailto:fabi...@gmail.com>>
Cc: "R. David Murray" mailto:rdmur...@bitdance.com>>, 
"python-dev@python.org" 
mailto:python-dev@python.org>>, Stefan A Popa 
mailto:stefan.a.p...@intel.com>>
Subject: Re: [Python-Dev] Avoiding CPython performance regressions



From: Fabio Zadrozny mailto:fabi...@gmail.com>>
Date: Tuesday, December 1, 2015 at 1:36 AM
To: David Stewart mailto:david.c.stew...@intel.com>>
Cc: "R. David Murray" mailto:rdmur...@bitdance.com>>, 
"python-dev@python.org" 
mailto:python-dev@python.org>>
Subject: Re: [Python-Dev] Avoiding CPython performance regressions


On Mon, Nov 30, 2015 at 3:33 PM, Stewart, David C 
mailto:david.c.stew...@intel.com>> wrote:

On 11/30/15, 5:52 AM, "Python-Dev on behalf of R. David Murray" 
mailto:intel@python.org>
 on behalf of rdmur...@bitdance.com> wrote:

>
>There's also an Intel project posted about here recently that checks
>individual benchmarks for performance regressions and posts the results
>to python-checkins.

The description of the project is at https://01.org/lp - Python results are 
indeed sent daily to python-checkins. (No results for Nov 30 and Dec 1 due to 
Romania National Day holiday!)

There is also a graphic dashboard at http://languagesperformance.intel.com/

​Hi Dave,

Interesting, but ​I'm curious on which benchmark set are you running? From the 
graphs it seems it has a really high standard deviation, so, I'm curious to 
know if that's really due to changes in the CPython codebase / issues in the 
benchmark set or in how the benchmarks are run... (it doesn't seem to be the 
benchmarks from https://hg.python.org/benchmarks/ right?).

Fabio – my advice to you is to check out the daily emails sent to 
python-checkins. An example is 
https://mail.python.org/pipermail/python-checkins/2015-November/140185.html. If 
you still have questions, Stefan can answer (he is copied).

The graphs are really just a manager-level indicator of trends, which I find 
very useful (I have it running continuously on one of the monitors in my 
office) but core developers might want to see day-to-day the effect of their 
changes. (Particular if they thought one was going to improve performance. It's 
nice to see if you get community confirmation).

We do run nightly a subset of https://hg.python.org/benchmarks/ and run the 
full set when we are evaluating our performance patches.

Some of the "benchmarks" really do have a high standard deviation, which makes 
them hardly very useful for measuring incremental performance improvements, 
IMHO. I like to see it spelled out so I can tell whether I should be worried or 
not about a particular delta.

Dave
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Avoiding CPython performance regressions

[Michael Droettboom]

You may also be interested in a project I've been working on, airspeed
velocity, which will automatically benchmark historical versions of a git
or hg repo.

http://github.com/spacetelescope/asv

astropy, scipy, numpy and dask are already using it.

Cheers,
Mike
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deleting with setting C API functions

[Andrew Barnert via Python-Dev]

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 I should note that I agree with your position here, I was
> just asking the question to articulate the issue that "put it off to the
> indefinite future" isn't a real plan for anything.

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?)

Or, of course, Python could avoid the number 4, go to 3.17 and then decide that 
the next release is big enough to be worthy of 5.0.

Or go from 3.9 to 2022, or XP, or Python Enterprise Python 1.  :)

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deleting with setting C API functions

[Guido van Rossum]

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 -- the whole point is that Python 4
*will* be like Python 3, i.e. it will *not* differ (in a
backward-incompatible way) from Python 3. What Nick probably meant is "Why
the *transition to* Python 4 won't be like the transition to Python 3." And
that is exactly right. We've learned our lesson (though we're in much
better shape than Perl :-).

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deleting with setting C API functions

[Random832]

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 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.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python 4 musings (was Re: Deleting with setting C API functions)

[Barry Warsaw]

On Dec 02, 2015, at 08:35 AM, Guido van Rossum wrote:

>I wholeheartedly agree with what Nick writes there

As do I.

One interesting point will be what *nix calls the /usr/bin thingie for Python
4.  It would seem weird to call it /usr/bin/python3 and symlink it to say
/usr/bin/python4.0 but maybe that's the most practical solution.  OTOH, by
2023, Python 2 will at worst be in source-only security release mode, if not
finally retired so maybe we can reclaim /usr/bin/python by then.  Oh well, PEP
394 will hash all that out I'm sure.

One other potentially disruptive change would be when Python's Einstein, er
David Beazley, finally cracks the nut of the GIL.  Should that require a new
backward incompatible C API, Python 4.0 would be the time to do it.

Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 4 musings (was Re: Deleting with setting C API functions)

[Guido van Rossum]

On Wed, Dec 2, 2015 at 8:57 AM, Barry Warsaw  wrote:

> On Dec 02, 2015, at 08:35 AM, Guido van Rossum wrote:
>
> >I wholeheartedly agree with what Nick writes there
>
> As do I.
>
> One interesting point will be what *nix calls the /usr/bin thingie for
> Python
> 4.  It would seem weird to call it /usr/bin/python3 and symlink it to say
> /usr/bin/python4.0 but maybe that's the most practical solution.  OTOH, by
> 2023, Python 2 will at worst be in source-only security release mode, if
> not
> finally retired so maybe we can reclaim /usr/bin/python by then.  Oh well,
> PEP
> 394 will hash all that out I'm sure.
>

Maybe the criteria for switching to 4 would be that all traces of 2 are
gone.


> One other potentially disruptive change would be when Python's Einstein, er
> David Beazley, finally cracks the nut of the GIL.  Should that require a
> new
> backward incompatible C API, Python 4.0 would be the time to do it.
>

There would still have to be a backward compatibility API for a very long
time. So I don't see why this particular change (however eagerly
anticipated! :-) should force a major version bump.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 4 musings (was Re: Deleting with setting C API functions)

[Gregory P. Smith]

Except that we should skip version 4 and go directly to 5 in homage to
http://www.montypython.net/scripts/HG-handgrenade.php.

On Wed, Dec 2, 2015 at 9:13 AM Guido van Rossum  wrote:

> On Wed, Dec 2, 2015 at 8:57 AM, Barry Warsaw  wrote:
>
>> On Dec 02, 2015, at 08:35 AM, Guido van Rossum wrote:
>>
>> >I wholeheartedly agree with what Nick writes there
>>
>> As do I.
>>
>> One interesting point will be what *nix calls the /usr/bin thingie for
>> Python
>> 4.  It would seem weird to call it /usr/bin/python3 and symlink it to say
>> /usr/bin/python4.0 but maybe that's the most practical solution.  OTOH, by
>> 2023, Python 2 will at worst be in source-only security release mode, if
>> not
>> finally retired so maybe we can reclaim /usr/bin/python by then.  Oh
>> well, PEP
>> 394 will hash all that out I'm sure.
>>
>
> Maybe the criteria for switching to 4 would be that all traces of 2 are
> gone.
>
>
>> One other potentially disruptive change would be when Python's Einstein,
>> er
>> David Beazley, finally cracks the nut of the GIL.  Should that require a
>> new
>> backward incompatible C API, Python 4.0 would be the time to do it.
>>
>
> There would still have to be a backward compatibility API for a very long
> time. So I don't see why this particular change (however eagerly
> anticipated! :-) should force a major version bump.
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 4 musings (was Re: Deleting with setting C API functions)

[Barry Warsaw]

On Dec 02, 2015, at 11:26 PM, Gregory P. Smith wrote:

>Except that we should skip version 4 and go directly to 5 in homage to
>http://www.montypython.net/scripts/HG-handgrenade.php.

Five is right out.

https://youtu.be/QM9Bynjh2Lk?t=3m35s

-Barry


pgplrHBCVtY0F.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 4 musings (was Re: Deleting with setting C API functions)

[Serhiy Storchaka]

On 03.12.15 01:26, Gregory P. Smith wrote:

Except that we should skip version 4 and go directly to 5 in homage to
http://www.montypython.net/scripts/HG-handgrenade.php.


Good point! So now we can assign version 4 as a term of un-realising any 
stupid ideas.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deleting with setting C API functions

[Greg]

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

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 4 musings (was Re: Deleting with setting C API functions)

[Mark Lawrence]

On 02/12/2015 23:36, Barry Warsaw wrote:

On Dec 02, 2015, at 11:26 PM, Gregory P. Smith wrote:


Except that we should skip version 4 and go directly to 5 in homage to
http://www.montypython.net/scripts/HG-handgrenade.php.


Five is right out.

https://youtu.be/QM9Bynjh2Lk?t=3m35s

-Barry



Can we have a PEP on this please, otherwise there's likely to be a great 
deal of confusion between hand grenade style counting, and the faculty 
rules at the University of Walamaloo.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deleting with setting C API functions

[Nick Coghlan]

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 there -- but I can't resist
> noting that the title is backwards -- the whole point is that Python 4
> *will* be like Python 3, i.e. it will *not* differ (in a
> backward-incompatible way) from Python 3. What Nick probably meant is "Why
> the *transition to* Python 4 won't be like the transition to Python 3." And
> that is exactly right.

Yeah, the full title was actually "Why Python 4.0 won't be like Python
3.0" which I think better conveys the implied "transition to" aspect,
but the zeros got left out in the opensource.com URL. The RHEL dev
blog version uses the full title in the URL as well:
https://developerblog.redhat.com/2014/09/17/why-python-4-0-wont-be-like-python-3-0/

I also wrote the article before you mentioned you might be amenable to
doing a 3.10 instead of rolling over to 4.0 (although I suspect there
are even more systems that assume XY is sufficient to identify a
Python feature release than assumed XYZ was sufficient to identify
maintenance releases prior to 2.7.10)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com