Re: [Python-Dev] Process to remove a Python feature

[Steve Dower]

To be fair, if they hadn’t already been deprecated we would have had to 
deprecate the old behaviour for a couple of releases before changing it. It 
just so happened that we did the deprecation first without knowing what the fix 
would be :)

Top-posted from my Windows phone

From: Victor Stinner
Sent: Friday, May 4, 2018 15:24
To: Serhiy Storchaka
Cc: python-dev
Subject: Re: [Python-Dev] Process to remove a Python feature

2018-05-04 20:48 GMT+02:00 Serhiy Storchaka :
> I think the information about since which version number it will be removed
> is more useful.

About deprecation, there is the funny story of bytes filenames on
Windows. I deprecated this feature in Windows 3.3 since it was broken.
I really wanted hard to remove support for bytes filenames on Windows.

One day, Steve Dower showed up with the PEP 529 "Change Windows
filesystem encoding to UTF-8" and he just *removed the deprecation
warning* from Python 3.6, since bytes filenames are now working as
intended :-)

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/steve.dower%40python.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] Process to remove a Python feature

[Terry Reedy]

On 5/4/2018 6:18 PM, Victor Stinner wrote:

2018-05-04 23:59 GMT+02:00 Terry Reedy :

Would it be possible (and sensible) to use the 2to3 machinery to produce
36to37.py, etc., to do mechanical replacements when possible and flag other
things when necessary?


I suggest you to watch Daniele Esposti's talk "Evolution or stagnation
programming languages". He explains that Javascript is more successful
than Python to introduce *language* evolutions thanks to transpiling
(things like babel and polyfill):
https://www.pycon.it/conference/talks/evolution-or-stagnation-programming-languages


I ran through the slides and found the babelsite.  What I found: Babel 
translates new code back to a sufficiently powerful and presumably 
ubiquitous older version.  It does so on a selectable feature basis 
rather than a language version basis.  (In other words, define your own 
'new' version.) Polyfill supplies the backported new objects needed to 
make the back translations run with new semantics.


This would be equivalent of defining, for instance, 2.7 as a base 
version and having 3xbytesto27, 35asyncto27, etc for every new 3.x 
feature.  Some people wanted this, but, of course, 2.7 is *not* 
installed everywhere.  If Microsoft were to treat Python like it once 
did Basic, and install it on all Windows machines, it would start with 
recent 3.x.


Neither the slides nor site said anything about bug fixes and about the 
need to have multiple versions of every function touched.


Because of the unique features of how Javascript is distributed and 
used, I don't see how the Babel example would apply very well to Python.


--
Terry Jan Reedy

___
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] Dealing with tone in an email

[Terry Reedy]

On 5/4/2018 10:07 PM, Steven D'Aprano wrote:


Terry, please, to persist in attacking Ivan's past behaviour when he has
not repeated it is not open, considerate or respectful.


I did not do that.  My first sentence was background for a *discussion* 
about a partial disagreement with what you said.  I won't repeat any of it.



At this point,
*our reaction* to Ivan's transgression has been much worse and more
disruptive than anything he has done.


I partially agree with this and said so in my last summary line.  And I 
agree that these threads should die.


--
Terry Jan Reedy

___
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] Dealing with tone in an email

[Steven D'Aprano]

On Fri, May 04, 2018 at 03:21:28PM -0400, Terry Reedy wrote:
> On 5/4/2018 11:43 AM, Steven D'Aprano wrote:
> 
> >I'm not defending Ivan's initial email. His tantrum *was* annoying,
> >unreasonable, and unfair to those who do care about tkinter.
> 
> Ivan's email was a disinformation troll intended to jump the attention 
> queue of core developers.  He is proud of its apparent success, and 
> seemingly unconcerned about equally apparent side-effects.

Terry, please, to persist in attacking Ivan's past behaviour when he has 
not repeated it is not open, considerate or respectful. At this point, 
*our reaction* to Ivan's transgression has been much worse and more 
disruptive than anything he has done.

People had already jumped down Ivan's throat long before he rationalised 
the tone of his initial email as necessary to get people's attention. 
Whether that rationalisation was an excuse he came up with afterwards, 
or a deliberate plan he started with, is impossible to tell. I wouldn't 
even expect Ivan to be 100% in his own mind which it was. Psychology 
isn't that cut and dried.

But it doesn't matter. *One* impolite email, even if deliberate, 
should not be enough to condemn a newbie. If he persists with this 
pattern of behaviour, that is a different story.

I understand your concern about deliberate disinformation, but even if 
your worst fears come true and "someone somewhere, in a blog, talk, or 
SO answer, quotes Ivan as a reason to not use tkinter", that hardly 
makes giving the opinion "tkinter is broken" an unforgiveable sin. As 
you point out yourself, that opinion is hardly new or rare.

And frankly, people are allowed to be wrong. Let's not have thought 
police here, please.

Everyone, can we *PLEASE* stop attacking this newbie now, and give him a 
chance to show by his future actions that he either has or hasn't 
changed his ways? Wrongly suggesting that nobody uses a software package 
should not be a Zero Tolerance offense.


-- 
Steve
___
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] A fast startup patch (was: Python startup time)

[Nathaniel Smith]

What are the obstacles to including "preloaded" objects in regular .pyc
files, so that everyone can take advantage of this without rebuilding the
interpreter?

Off the top of my head:

We'd be making the in-memory layout of those objects part of the .pyc
format, so we couldn't change that within a minor release. I suspect this
wouldn't be a big change though, since we already commit to ABI
compatibility for C extensions within a minor release? In principle there
are some cases where this would be different (e.g. adding new fields at the
end of an object is generally ABI compatible), but this might not be an
issue for the types of objects we're talking about.

There's some memory management concern, since these are, y'know, heap
objects, and we wouldn't be heap allocating them. The main constraint would
be that you couldn't free them one at a time, but would have to free the
whole block at once. But I think it at least wouldn't be too hard to track
whether any of the objects in the block are still alive, and free the whole
block if there aren't any. E.g., we could have an object flag that means
"when this object is freed, don't call free(), instead find the containing
block and decrement its live-object count. You probably need this flag even
in the current version, right? (And the flag could also be an escape hatch
if we did need to change object size: check for the flag before accessing
the new fields.) Or maybe you could get clever tracking object liveness on
an page by page basis; not sure it's worth it though. Unloading
module-level objects is pretty rare.

I'm assuming these objects can have pointers to each other, and to well
known constants like None, so you need some kind of relocation engine to
fix those up. Right now I guess you're probably using the one built into
the dynamic loader? In theory it shouldn't be too hard to write our own –
basically just a list of offsets in the block where we need to add the base
address or write the address of a well known constant, I think?

Anything else I'm missing?

On Fri, May 4, 2018, 16:06 Carl Shapiro  wrote:

> On Fri, May 4, 2018 at 5:14 AM, Nick Coghlan  wrote:
>
>> This definitely seems interesting, but is it something you'd be seeing us
>> being able to take advantage of for conventional Python installations, or
>> is it more something you'd expect to be useful for purpose-built
>> interpreter instances? (e.g. if Mercurial were running their own Python,
>> they could precache the heap objects for their commonly imported modules in
>> their custom interpreter binary, regardless of whether those were standard
>> library modules or not).
>>
>
> Yes, this would be a win for a conventional Python installation as well.
> Specifically, users and their scripts would enjoy a reduction in
> cold-startup time.
>
> In the numbers I showed yesterday, the version of the interpreter with our
> patch applied included unmarshaled data for the modules that always appear
> on the sys.modules list after an ordinary interpreter cold-start.  I
> believe it is worthwhile to including that set of modules in the standard
> CPython interpreter build.  Expanding that set to include the commonly
> imported modules might be an additional win, especially for short-running
> scripts.
>
> ___
> 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/njs%40pobox.com
>

On May 4, 2018 16:06, "Carl Shapiro"  wrote:

On Fri, May 4, 2018 at 5:14 AM, Nick Coghlan  wrote:

> This definitely seems interesting, but is it something you'd be seeing us
> being able to take advantage of for conventional Python installations, or
> is it more something you'd expect to be useful for purpose-built
> interpreter instances? (e.g. if Mercurial were running their own Python,
> they could precache the heap objects for their commonly imported modules in
> their custom interpreter binary, regardless of whether those were standard
> library modules or not).
>

Yes, this would be a win for a conventional Python installation as well.
Specifically, users and their scripts would enjoy a reduction in
cold-startup time.

In the numbers I showed yesterday, the version of the interpreter with our
patch applied included unmarshaled data for the modules that always appear
on the sys.modules list after an ordinary interpreter cold-start.  I
believe it is worthwhile to including that set of modules in the standard
CPython interpreter build.  Expanding that set to include the commonly
imported modules might be an additional win, especially for short-running
scripts.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:

Re: [Python-Dev] A fast startup patch (was: Python startup time)

[Carl Shapiro]

On Fri, May 4, 2018 at 5:14 AM, Nick Coghlan  wrote:

> This definitely seems interesting, but is it something you'd be seeing us
> being able to take advantage of for conventional Python installations, or
> is it more something you'd expect to be useful for purpose-built
> interpreter instances? (e.g. if Mercurial were running their own Python,
> they could precache the heap objects for their commonly imported modules in
> their custom interpreter binary, regardless of whether those were standard
> library modules or not).
>

Yes, this would be a win for a conventional Python installation as well.
Specifically, users and their scripts would enjoy a reduction in
cold-startup time.

In the numbers I showed yesterday, the version of the interpreter with our
patch applied included unmarshaled data for the modules that always appear
on the sys.modules list after an ordinary interpreter cold-start.  I
believe it is worthwhile to including that set of modules in the standard
CPython interpreter build.  Expanding that set to include the commonly
imported modules might be an additional win, especially for short-running
scripts.
___
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] Process to remove a Python feature

[Victor Stinner]

2018-05-04 20:48 GMT+02:00 Serhiy Storchaka :
> I think the information about since which version number it will be removed
> is more useful.

About deprecation, there is the funny story of bytes filenames on
Windows. I deprecated this feature in Windows 3.3 since it was broken.
I really wanted hard to remove support for bytes filenames on Windows.

One day, Steve Dower showed up with the PEP 529 "Change Windows
filesystem encoding to UTF-8" and he just *removed the deprecation
warning* from Python 3.6, since bytes filenames are now working as
intended :-)

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] Process to remove a Python feature

[Victor Stinner]

2018-05-04 23:59 GMT+02:00 Terry Reedy :
> Would it be possible (and sensible) to use the 2to3 machinery to produce
> 36to37.py, etc., to do mechanical replacements when possible and flag other
> things when necessary?

I suggest you to watch Daniele Esposti's talk "Evolution or stagnation
programming languages". He explains that Javascript is more successful
than Python to introduce *language* evolutions thanks to transpiling
(things like babel and polyfill):
https://www.pycon.it/conference/talks/evolution-or-stagnation-programming-languages

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] Process to remove a Python feature

[Terry Reedy]

On 5/2/2018 5:11 AM, Victor Stinner wrote:


As a follow-up to the "[Python-Dev] (Looking for) A Retrospective on
the Move to Python 3" thread, I will like to clarify how a feature
should be removed from Python.


Would it be possible (and sensible) to use the 2to3 machinery to produce 
36to37.py, etc., to do mechanical replacements when possible and flag 
other things when necessary?


--
Terry Jan Reedy

___
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] Dealing with tone in an email (was: Drop/deprecate Tkinter?)

[Alexander Belopolsky]

On Fri, May 4, 2018 at 11:43 AM, Steven D'Aprano  wrote:
> On Thu, May 03, 2018 at 06:31:03PM +, Brett Cannon wrote:
> ..
> I'm not defending Ivan's initial email. His tantrum *was* annoying,
> unreasonable, and unfair to those who do care about tkinter. He could
> have done better.
>
> But *we* should be better too. Our response to Ivan has not been
> welcoming, and as a community we haven't lived up to our own standards,
> as we have piled onto him to express our rightous indignation:

+1

It may be a reflection of me sharing the cultural roots with Ivan, but
his original post did not sound particularly offensive to me. I've
seen worse.

When it comes to communication on public fora, I am a strong believer
in Postel's principle of robustness: "be conservative in what you do,
be liberal in what you accept from others."
___
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] Dealing with tone in an email (was: Drop/deprecate Tkinter?)

[Brett Cannon]

On Fri, 4 May 2018 at 09:07 Guido van Rossum  wrote:

> Thank you Steven! I assume that Brian hadn't seen my response (such
> crossed messages due to delivery delays are very common in this mailing
> list).
>
> I'd like to use your email (nearly) verbatim to start off the discussion
> about civility we're going to have at the Language Summit.
>

And I will also want to say thanks for the email, Steven! I agree with
everything you said and that any expectations we have of others should
apply equally to anyone on this list in any interaction. And I think it's
especially true in our responses as we should try to keep the moral high
ground by being examples of what we expect and want from others.


>
> On Fri, May 4, 2018 at 8:43 AM, Steven D'Aprano 
> wrote:
>
>> On Thu, May 03, 2018 at 06:31:03PM +, Brett Cannon wrote:
>>
>> > No one is saying people can't be upset and if you are ever upset there's
>> > something wrong; we're human beings after all. But those of us speaking
>> up
>> > about the tone are saying that you can also wait until you're not so
>> upset
>> > to write an email. This was never going to be resolved in an hour, so
>> > waiting an hour until you're in a better place to write an email that
>> > wasn't quite so inflammatory seems like a reasonable thing to ask.
>>
>> Certainly!
>>
>> I'm not defending Ivan's initial email. His tantrum *was* annoying,
>> unreasonable, and unfair to those who do care about tkinter. He could
>> have done better.
>>
>> But *we* should be better too. Our response to Ivan has not been
>> welcoming, and as a community we haven't lived up to our own standards,
>> as we have piled onto him to express our rightous indignation:
>>
>> 1. Guido responded telling Ivan to calm down and work off his
>>frustration elsewhere. And that's where things should have
>>stopped, unless Ivan had persisted in his impoliteness.
>>
>> 2. Brian upped the ante by bringing the CoC into discussion.
>>
>> 3. Paul raised it again by describing Ivan's post as "offensive".
>>
>> 4. And now, Steve H has claimed that Ivan's initial post was
>>bordering on "abusive".
>>
>> We've gone from rightly treating Ivan's post as intemperate and
>> impolite, and telling him to chill, to calling his post "offensive", to
>> "abusive". (Next, I presume, someone will claim to be traumatised by
>> Ivan's email.)
>>
>> Just as Ivan should have waited until he had calmed down before firing
>> off his rant, so we ought to resist the temptation to strike back with
>> hostility at trivial social transgressions, especially from newcomers.
>> This is what Ivan actually said:
>>
>> - Tkinter is broken and partly functional (an opinion with only the
>>   most tenuous connection with fact, but hardly abusive);
>>
>> - that nobody cares (factually wrong, but not abusive);
>>
>> - that possibly nobody is using it (factually wrong, but not abusive);
>>
>> - that if that's the case (it isn't), then it should be removed
>>   from the std lib (a reasonable suggestion if only the premise had
>>   been correct).
>>
>> Intemperate and impolite it certainly was, as well as full of factual
>> inaccuracies, but to call it "close to abusive" is a hostile over-
>> reaction. We ought to be kinder than that. Our response to Ivan has been
>> more hostile, and less open and respectful, than his email that
>> triggered the response.
>>
>> Brett is right to say people can afford to wait a little while before
>> firing off an angry email. But the same applies to us: we too can afford
>> to wait a little while before raising the threat of the CoC over a minor
>> social faux pas. This community isn't so fragile that we have to jump
>> down the throat of a newcomer lest the community immediately collapses
>> into Call Of Duty gamer culture.
>>
>
>>
>> --
>> Steve
>> ___
>> 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/guido%40python.org
>>
>
>
>
> --
> --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/brett%40python.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] Process to remove a Python feature

[Brett Cannon]

On Fri, 4 May 2018 at 12:09 Matthias Bussonnier <
bussonniermatth...@gmail.com> wrote:

> On Fri, 4 May 2018 at 11:49, Serhiy Storchaka  wrote:
>
>> 04.05.18 20:57, Matthias Bussonnier пише:
>> > But when I hit a DeprecationWarning message there is one crucial piece
>> of
>> > information missing most of the time: Since which version number it's
>> > deprecated
>> > (and sometime since when the replacement is available could be good if
>> > overlap
>> > between functionality there was).
>>
>> I think the information about since which version number it will be
>> removed is more useful. Different cases need different deprecation
>> periods. The more common the case, the longer deprecation period should
>> be. Some recently added warnings contain this information.
>>
>
> Maybe to push people forward, but from experience it is hard to predict
> future, so saying when
> it _will_ be remove is hard.  When you _want_ to remove it probably.
> Victor's first mail in
> this thread is a good example. The functionality was marked to be removed
> from 3.7, but I think
> it is likely too late now. You can always update, but I hate giving
> differing information between software version.
>

So there is actually an opportunity here to programmatically help prevent
missing a removal. If we attach a version number for when a
DeprecationWarning is expected to go away due to removal we can then have
the warning itself raise a warning that while the DeprecationWarning was
supposed to be gone by e.g. 3.7, it's still being raised. The drawback to
this is it will make the first cut-over to a newer version of Python a bit
more painful, but as long as warnings don't raise exceptions it should just
be a noisy.


>
> I'm curious about your use case for the version of removal,
> I usually don't care when it's going to be removed, I prefer since
> when the functionality is deprecated.
>
> if pyversion < deprecated_version:
>   old_stuff
> else:
>   new_stuff
>
> And I soon as my project drop deprecated_version, I remove the
> conditional.
> I do not try/except on purpose to be able to grep for when to remove the
> code.
>

The other way to look at that is:

if pyversion < replacement:
  old_stuff
else:
  new_stuff

In which case you don't care about when the deprecation happened, just when
it's replacement was introduced (which Serhiy suggested being a version
before the deprecation is added).


> Could you share you use case ? Of be ore detailed ?
>
> We can also be more generic and say that if DeprecationWarning messages
> could contain
> timeline informations it would likely encourage the migration.
>
> One related question is how much are DeprecationWarning messages stables
> between versions ?
>

Same as any other exception; typically left alone unless there's a better
way to phrase things (IOW don't parse the message ;) .

So at this point there are basically two threads going on here.

One is an official deprecation policy. E.g. X.Y something happens, X.Y+1
something else happens, etc.

The other one is how to make what gets deprecated more discoverable. E.g.
an informational PEP that tracks what's planned, warnings having more
metadata, etc.

Both of these things seem independent, although one of them will require a
PEP while the other just takes some work (I leave it as an exercise for the
reader to figure out which one is which ;) .

-Brett


> Would any update to many of these be accepted of refused because users
> might be filtering them ?
> --
> Matthias
>
>
>>
>> Ideally any deprecated feature should have a replacement, and this
>> replacement should be available in at least one version before adding
>> the deprecation warning.
>>
>> X.Y: added a replacement
>>
>> X.Y+1: added a deprecation warning. Many users need to support only two
>> recent versions and can move to using the replacement now.
>>
>> X.Y+3 (or X.Y+2): removed the deprecated feature. Versions older than
>> X.Y should grew out of use at that moment.
>>
>> ___
>> 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/bussonniermatthias%40gmail.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/brett%40python.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] Dealing with tone in an email

[Terry Reedy]

On 5/4/2018 12:04 PM, Guido van Rossum wrote:

Thank you Steven!
I'd like to use your email (nearly) verbatim to start off the discussion 
about civility we're going to have at the Language Summit.


I won't be there but sounds like a good idea.  I hope you consider that 
bad content as well as bad tone can be uncivil and negatively impact 
Python development.


--
Terry Jan Reedy

___
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] Dealing with tone in an email

[Terry Reedy]

On 5/4/2018 11:43 AM, Steven D'Aprano wrote:


I'm not defending Ivan's initial email. His tantrum *was* annoying,
unreasonable, and unfair to those who do care about tkinter.


Ivan's email was a disinformation troll intended to jump the attention 
queue of core developers.  He is proud of its apparent success, and 
seemingly unconcerned about equally apparent side-effects.


In form, it reminds me of Ranting Rick Johnson's performances on 
python-list, where such things are more acceptable.  At least Rick knows 
to not do the same on pydev.


>  He could have done better.

I tried to persuade him of this by explaining how others have had the 
same success with respectful and factual emails.  In either case, any 
success is because some of us care deeply about the quality of the 
CPython distribution and want to encourage others to join in the enterprise.



We've gone from rightly treating Ivan's post as intemperate and
impolite, and telling him to chill, to calling his post "offensive", to
"abusive".


Discursive writing has two components: content and tone.  I agree with 
you that the tone was not that bad.  But I am more concerned with 
content.  To me, posting disinformation to pydev *is* abusive of its 
'authoritativeness'.  This forum is read and mirrored around the world. 
People tend to believe what they read here.  Based on past events, I 
will not be surprised if someone somewhere, in a blog, talk, or SO 
answer, quotes Ivan as a reason to not use tkinter.



(Next, I presume, someone will claim to be traumatised by
Ivan's email.)


Yep, but not my concern here.


Just as Ivan should have waited until he had calmed down before firing
off his rant, so we ought to resist the temptation to strike back with
hostility at trivial social transgressions, especially from newcomers.


Is disinformation and FUD really trivial?


This is what Ivan actually said:

- Tkinter is broken and partly functional (an opinion with only the
   most tenuous connection with fact, but hardly abusive);

- that nobody cares (factually wrong, but not abusive);

- that possibly nobody is using it (factually wrong, but not abusive);


I previously responded to the first and second points above. As to the 
third, not only do many people use the tkinter-based IDLE and turtle 
frameworks (and many others), but as evidenced by Stackoverflow 
questions, some Python beginners dive into writing GUIs with tkinter 
after as little as 2 weeks exposure to Python.  Given that I ignored 
tkinter for over a decade, I am impressed at their boldness.


The following is a paraphrase of a combination of multiple things I have 
read and heard .  "Don't use IDLE.  Its buggy, not used much, and not 
maintained.  Someone said so on pydev."  Ivan saying the same about 
tkinter will possibly prompt others to imitate him.



- that if that's the case (it isn't), then it should be removed
   from the std lib (a reasonable suggestion if only the premise had
   been correct).


I am dubious that Ivan actually believed what he wrote.  It looks more 
like rhetorical devices rather than factual claims. Yet many people 
responding here treated 'the case' as plausible.  This supports my 
contention that people tend to treat claims posted here as plausible and 
made in good faith.



Intemperate and impolite it certainly was, as well as full of factual
inaccuracies, but to call it "close to abusive" is a hostile over-
reaction.


Dismissing as non-existent the hard work of volunteers tends to result 
in less volunteer work.  Given that 'factual inaccuracies' can have 
negative consequences for the future of CPython, I think a bit of 
hostility is appropriate.



We ought to be kinder than that. Our response to Ivan has been
more hostile, and less open and respectful, than his email that
triggered the response.


I agree that too much attention was give to 'tone'.  I think too little 
was given to the validity of the claims.


--
Terry Jan Reedy

___
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] Process to remove a Python feature

[Matthias Bussonnier]

On Fri, 4 May 2018 at 11:49, Serhiy Storchaka  wrote:

> 04.05.18 20:57, Matthias Bussonnier пише:
> > But when I hit a DeprecationWarning message there is one crucial piece of
> > information missing most of the time: Since which version number it's
> > deprecated
> > (and sometime since when the replacement is available could be good if
> > overlap
> > between functionality there was).
>
> I think the information about since which version number it will be
> removed is more useful. Different cases need different deprecation
> periods. The more common the case, the longer deprecation period should
> be. Some recently added warnings contain this information.
>

Maybe to push people forward, but from experience it is hard to predict
future, so saying when
it _will_ be remove is hard.  When you _want_ to remove it probably.
Victor's first mail in
this thread is a good example. The functionality was marked to be removed
from 3.7, but I think
it is likely too late now. You can always update, but I hate giving
differing information between software version.

I'm curious about your use case for the version of removal,
I usually don't care when it's going to be removed, I prefer since
when the functionality is deprecated.

if pyversion < deprecated_version:
  old_stuff
else:
  new_stuff

And I soon as my project drop deprecated_version, I remove the conditional.
I do not try/except on purpose to be able to grep for when to remove the
code.

Could you share you use case ? Of be ore detailed ?

We can also be more generic and say that if DeprecationWarning messages
could contain
timeline informations it would likely encourage the migration.

One related question is how much are DeprecationWarning messages stables
between versions ?
Would any update to many of these be accepted of refused because users
might be filtering them ?
-- 
Matthias


>
> Ideally any deprecated feature should have a replacement, and this
> replacement should be available in at least one version before adding
> the deprecation warning.
>
> X.Y: added a replacement
>
> X.Y+1: added a deprecation warning. Many users need to support only two
> recent versions and can move to using the replacement now.
>
> X.Y+3 (or X.Y+2): removed the deprecated feature. Versions older than
> X.Y should grew out of use at that moment.
>
> ___
> 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/bussonniermatthias%40gmail.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] Process to remove a Python feature

[Guido van Rossum]

No, the reason they're hidden by default is that for most users they're not
actionable most of the time.

On Fri, May 4, 2018 at 11:55 AM, Nathaniel Smith  wrote:

> On Fri, May 4, 2018, 11:50 Serhiy Storchaka  wrote:
>
>>
>> Ideally any deprecated feature should have a replacement, and this
>> replacement should be available in at least one version before adding
>> the deprecation warning.
>>
>> X.Y: added a replacement
>>
>> X.Y+1: added a deprecation warning. Many users need to support only two
>> recent versions and can move to using the replacement now.
>>
>
> Isn't the whole point of making DeprecationWarnings hidden by default that
> it lets us add the new thing and deprecate the old thing in the same
> release, without creating too much disruption?
>
> -n
>
> ___
> 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/
> guido%40python.org
>
>


-- 
--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] Process to remove a Python feature

[Nathaniel Smith]

On Fri, May 4, 2018, 11:50 Serhiy Storchaka  wrote:

>
> Ideally any deprecated feature should have a replacement, and this
> replacement should be available in at least one version before adding
> the deprecation warning.
>
> X.Y: added a replacement
>
> X.Y+1: added a deprecation warning. Many users need to support only two
> recent versions and can move to using the replacement now.
>

Isn't the whole point of making DeprecationWarnings hidden by default that
it lets us add the new thing and deprecate the old thing in the same
release, without creating too much disruption?

-n
___
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] Process to remove a Python feature

[Serhiy Storchaka]

04.05.18 20:57, Matthias Bussonnier пише:

But when I hit a DeprecationWarning message there is one crucial piece of
information missing most of the time: Since which version number it's 
deprecated
(and sometime since when the replacement is available could be good if 
overlap

between functionality there was).


I think the information about since which version number it will be 
removed is more useful. Different cases need different deprecation 
periods. The more common the case, the longer deprecation period should 
be. Some recently added warnings contain this information.


Ideally any deprecated feature should have a replacement, and this 
replacement should be available in at least one version before adding 
the deprecation warning.


X.Y: added a replacement

X.Y+1: added a deprecation warning. Many users need to support only two 
recent versions and can move to using the replacement now.


X.Y+3 (or X.Y+2): removed the deprecated feature. Versions older than 
X.Y should grew out of use at that moment.


___
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] Process to remove a Python feature

[Matthias Bussonnier]

I would like to take a step back,

I think that for removal of feature you need to make sure that the "old
way" is
not common enough. I think that in many context, users of Python see
DeprecationWarnings as a stick. A deprecation warning means you'll have to
do
some work. A pep or a document that list all the removal may be useful, but
I'm
unsure if in reading what's knew you'll catch all the removal of
functionality
you use and convince yourself (or your management) to thouroughly go through
your code base and fix these things. Maybe to help transition you need to
soften
the stick by being more explicit as since when things are deprecated and
what can
be done.

Personally I find deprecations when I run test-suites and use libraries
interactively, not by reading ahead of time documents. Python has made huge
progress in the deprecation messages. And the usage of "X Is is deprecated,
use
Y" has become common, this is already tremendously more helpful than just
"X is
deprecated".

But when I hit a DeprecationWarning message there is one crucial piece of
information missing most of the time: Since which version number it's
deprecated
(and sometime since when the replacement is available could be good if
overlap
between functionality there was). Yes it is available in the docs (or in the
docstring), but if I have to switch context to search in the documentation I
might not bother. In particular when the version is in the deprecation
message,
as I know the python requirement of my project, I can immediately know if
it's a
search and replace away, or if I need to have conditional branches.

That is at least to me the biggest change that would push me to update the
deprecated features in my own project, and make me do drive by
contributions on
Open-Source project I use where I spotted one of those.

There are other improvement possible to deprecation messages, but I think
this
one would have the largest impact for many developers who do not closely
follow
python development, and for whom DeprecationWarnings are just an extra
hassle.

Also if there is a standard, or conventional way _in warnings_ to say since
when
something is deprecated, then it's relatively easy to search for it when
version N+p is
released and remove what you believe is old enough.

Thanks,
-- 
Matthias


On Fri, 4 May 2018 at 09:03, Serhiy Storchaka  wrote:

> 04.05.18 16:14, Steven D'Aprano пише:
> > Have there been many features removed since 3.1? I know there were some
> > features removed in 3.0, like callable(), which were later put back in,
> > but I can't think of anythin removed since then. If there were, the pace
> > of it is pretty slow.
>
> Read "What's New" documents, sections "Removed" and "Porting to Python
> X.Y". There is a long list in every release.
>
> ___
> 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/bussonniermatthias%40gmail.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] Dealing with tone in an email (was: Drop/deprecate Tkinter?)

[Steve Holden]

On Fri, May 4, 2018 at 4:43 PM, Steven D'Aprano  wrote:

> On Thu, May 03, 2018 at 06:31:03PM +, Brett Cannon wrote:
>
> > No one is saying people can't be upset and if you are ever upset there's
> > something wrong; we're human beings after all. But those of us speaking
> up
> > about the tone are saying that you can also wait until you're not so
> upset
> > to write an email. This was never going to be resolved in an hour, so
> > waiting an hour until you're in a better place to write an email that
> > wasn't quite so inflammatory seems like a reasonable thing to ask.
>
> Certainly!
>
> I'm not defending Ivan's initial email. His tantrum *was* annoying,
> unreasonable, and unfair to those who do care about tkinter. He could
> have done better.
>
> But *we* should be better too. Our response to Ivan has not been
> welcoming, and as a community we haven't lived up to our own standards,
> as we have piled onto him to express our rightous indignation:
>
> 1. Guido responded telling Ivan to calm down and work off his
>frustration elsewhere. And that's where things should have
>stopped, unless Ivan had persisted in his impoliteness.
>
> 2. Brian upped the ante by bringing the CoC into discussion.
>
> 3. Paul raised it again by describing Ivan's post as "offensive".
>
> 4. And now, Steve H has claimed that Ivan's initial post was
>bordering on "abusive".
>
> We've gone from rightly treating Ivan's post as intemperate and
> impolite, and telling him to chill, to calling his post "offensive", to
> "abusive". (Next, I presume, someone will claim to be traumatised by
> Ivan's email.)
>
> ​I for one hold my hand up, and will simply not respond the next time I am
tempted to respond in this way. I do not wish to enter into discussion on
the semantics of abuse, neither do I want to sidetrack the list from its
intended purpose.

regards
 Steve​
___
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] Dealing with tone in an email (was: Drop/deprecate Tkinter?)

[Steven D'Aprano]

On Fri, May 04, 2018 at 09:04:20AM -0700, Guido van Rossum wrote:
> Thank you Steven! I assume that Brian hadn't seen my response (such crossed
> messages due to delivery delays are very common in this mailing list).
> 
> I'd like to use your email (nearly) verbatim to start off the discussion
> about civility we're going to have at the Language Summit.

Please do. I would be honoured!



-- 
Steve
___
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] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2018-04-27 - 2018-05-04)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open6629 (+14)
  closed 38547 (+37)
  total  45176 (+51)

Open issues with patches: 2593 


Issues opened (34)
==

#33375: warnings: get filename from frame.f_code.co_filename
https://bugs.python.org/issue33375  opened by takluyver

#33376: [pysqlite] Duplicate rows can be returned after rolling back a
https://bugs.python.org/issue33376  opened by cary

#33379: PyImport_Cleanup is called with builtins_copy == NULL in test_
https://bugs.python.org/issue33379  opened by serhiy.storchaka

#33381: Incorrect documentation for strftime()/strptime() format code 
https://bugs.python.org/issue33381  opened by jujuwoman

#33384: Build does not work with closed stdin
https://bugs.python.org/issue33384  opened by MartinHusemann

#33385: setdefault() with a single argument doesn't work for dbm.gnu a
https://bugs.python.org/issue33385  opened by serhiy.storchaka

#33387: Simplify bytecodes for try-finally, try-except and with blocks
https://bugs.python.org/issue33387  opened by Mark.Shannon

#33388: Support PEP 566 metadata in dist.py
https://bugs.python.org/issue33388  opened by rbricheno

#33389: argparse redundant help string
https://bugs.python.org/issue33389  opened by stefan

#33392: pathlib .glob('*/') returns files as well as directories
https://bugs.python.org/issue33392  opened by robbuckley

#33393: update config.guess and config.sub
https://bugs.python.org/issue33393  opened by doko

#33394: the build of the shared modules is quiet/non-visible when GNU 
https://bugs.python.org/issue33394  opened by doko

#33396: IDLE: Improve and document help doc viewer
https://bugs.python.org/issue33396  opened by terry.reedy

#33397: IDLE help viewer: let users control font size
https://bugs.python.org/issue33397  opened by terry.reedy

#33398: From, To, Cc lines break when calling send_message()
https://bugs.python.org/issue33398  opened by _savage

#33399: site.abs_paths should handle None __cached__ type
https://bugs.python.org/issue33399  opened by demian.brecht

#33400: logging.Formatter does not default to ISO8601 date format
https://bugs.python.org/issue33400  opened by paulc

#33403: asyncio.tasks.wait does not allow to set custom exception when
https://bugs.python.org/issue33403  opened by pyneda

#33406: [ctypes] increase the refcount of a callback function
https://bugs.python.org/issue33406  opened by Zuzu_Typ

#33407: Implement Py_DEPRECATED() macro for Visual Studio
https://bugs.python.org/issue33407  opened by vstinner

#33408: AF_UNIX is now supported in Windows
https://bugs.python.org/issue33408  opened by filips123

#33409: Clarify the interaction between locale coercion & UTF-8 mode
https://bugs.python.org/issue33409  opened by ncoghlan

#33411: All console message are in the error output in bash interpreto
https://bugs.python.org/issue33411  opened by Quentin Millardet

#33413: asyncio.gather should not use special Future
https://bugs.python.org/issue33413  opened by Martin.Teichmann

#33414: Make shutil.copytree use os.scandir to take advantage of cache
https://bugs.python.org/issue33414  opened by adelfino

#33415: When add_mutually_exclusive_group is built without argument, t
https://bugs.python.org/issue33415  opened by ariel-anieli

#33416: Add endline and endcolumn to every AST node
https://bugs.python.org/issue33416  opened by levkivskyi

#33417: Isinstance() behavior is not consistent with the document
https://bugs.python.org/issue33417  opened by hongweipeng

#33418: Memory leaks in functions
https://bugs.python.org/issue33418  opened by jdemeyer

#33419: Add functools.partialclass
https://bugs.python.org/issue33419  opened by NeilGirdhar

#33420: __origin__ invariant broken
https://bugs.python.org/issue33420  opened by apaszke

#33421: Missing documentation for typing.AsyncContextManager
https://bugs.python.org/issue33421  opened by Travis DePrato

#33422: Fix and update string/byte literals in help()
https://bugs.python.org/issue33422  opened by adelfino

#33423: [logging] Improve consistency of logger mechanism.
https://bugs.python.org/issue33423  opened by Daehee Kim



Most recent 15 issues with no replies (15)
==

#33421: Missing documentation for typing.AsyncContextManager
https://bugs.python.org/issue33421

#33418: Memory leaks in functions
https://bugs.python.org/issue33418

#33417: Isinstance() behavior is not consistent with the document
https://bugs.python.org/issue33417

#33416: Add endline and endcolumn to every AST node
https://bugs.python.org/issue33416

#33415: When add_mutually_exclusive_group is built without argument, t
https://bugs.python.org/issue33415

#33413: asyncio.gather should not use special Future
https://bugs.python.org/issue33413

#33409: Clarify the interaction between locale 

Re: [Python-Dev] Dealing with tone in an email (was: Drop/deprecate Tkinter?)

[Guido van Rossum]

Thank you Steven! I assume that Brian hadn't seen my response (such crossed
messages due to delivery delays are very common in this mailing list).

I'd like to use your email (nearly) verbatim to start off the discussion
about civility we're going to have at the Language Summit.

On Fri, May 4, 2018 at 8:43 AM, Steven D'Aprano  wrote:

> On Thu, May 03, 2018 at 06:31:03PM +, Brett Cannon wrote:
>
> > No one is saying people can't be upset and if you are ever upset there's
> > something wrong; we're human beings after all. But those of us speaking
> up
> > about the tone are saying that you can also wait until you're not so
> upset
> > to write an email. This was never going to be resolved in an hour, so
> > waiting an hour until you're in a better place to write an email that
> > wasn't quite so inflammatory seems like a reasonable thing to ask.
>
> Certainly!
>
> I'm not defending Ivan's initial email. His tantrum *was* annoying,
> unreasonable, and unfair to those who do care about tkinter. He could
> have done better.
>
> But *we* should be better too. Our response to Ivan has not been
> welcoming, and as a community we haven't lived up to our own standards,
> as we have piled onto him to express our rightous indignation:
>
> 1. Guido responded telling Ivan to calm down and work off his
>frustration elsewhere. And that's where things should have
>stopped, unless Ivan had persisted in his impoliteness.
>
> 2. Brian upped the ante by bringing the CoC into discussion.
>
> 3. Paul raised it again by describing Ivan's post as "offensive".
>
> 4. And now, Steve H has claimed that Ivan's initial post was
>bordering on "abusive".
>
> We've gone from rightly treating Ivan's post as intemperate and
> impolite, and telling him to chill, to calling his post "offensive", to
> "abusive". (Next, I presume, someone will claim to be traumatised by
> Ivan's email.)
>
> Just as Ivan should have waited until he had calmed down before firing
> off his rant, so we ought to resist the temptation to strike back with
> hostility at trivial social transgressions, especially from newcomers.
> This is what Ivan actually said:
>
> - Tkinter is broken and partly functional (an opinion with only the
>   most tenuous connection with fact, but hardly abusive);
>
> - that nobody cares (factually wrong, but not abusive);
>
> - that possibly nobody is using it (factually wrong, but not abusive);
>
> - that if that's the case (it isn't), then it should be removed
>   from the std lib (a reasonable suggestion if only the premise had
>   been correct).
>
> Intemperate and impolite it certainly was, as well as full of factual
> inaccuracies, but to call it "close to abusive" is a hostile over-
> reaction. We ought to be kinder than that. Our response to Ivan has been
> more hostile, and less open and respectful, than his email that
> triggered the response.
>
> Brett is right to say people can afford to wait a little while before
> firing off an angry email. But the same applies to us: we too can afford
> to wait a little while before raising the threat of the CoC over a minor
> social faux pas. This community isn't so fragile that we have to jump
> down the throat of a newcomer lest the community immediately collapses
> into Call Of Duty gamer culture.
>
>
> --
> Steve
> ___
> 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/
> guido%40python.org
>



-- 
--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] Process to remove a Python feature

[Serhiy Storchaka]

04.05.18 16:14, Steven D'Aprano пише:

Have there been many features removed since 3.1? I know there were some
features removed in 3.0, like callable(), which were later put back in,
but I can't think of anythin removed since then. If there were, the pace
of it is pretty slow.


Read "What's New" documents, sections "Removed" and "Porting to Python 
X.Y". There is a long list in every release.


___
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] Dealing with tone in an email (was: Drop/deprecate Tkinter?)

[Steven D'Aprano]

On Thu, May 03, 2018 at 06:31:03PM +, Brett Cannon wrote:

> No one is saying people can't be upset and if you are ever upset there's
> something wrong; we're human beings after all. But those of us speaking up
> about the tone are saying that you can also wait until you're not so upset
> to write an email. This was never going to be resolved in an hour, so
> waiting an hour until you're in a better place to write an email that
> wasn't quite so inflammatory seems like a reasonable thing to ask.

Certainly!

I'm not defending Ivan's initial email. His tantrum *was* annoying, 
unreasonable, and unfair to those who do care about tkinter. He could 
have done better.

But *we* should be better too. Our response to Ivan has not been 
welcoming, and as a community we haven't lived up to our own standards, 
as we have piled onto him to express our rightous indignation:

1. Guido responded telling Ivan to calm down and work off his 
   frustration elsewhere. And that's where things should have
   stopped, unless Ivan had persisted in his impoliteness.

2. Brian upped the ante by bringing the CoC into discussion.

3. Paul raised it again by describing Ivan's post as "offensive".

4. And now, Steve H has claimed that Ivan's initial post was
   bordering on "abusive".

We've gone from rightly treating Ivan's post as intemperate and 
impolite, and telling him to chill, to calling his post "offensive", to 
"abusive". (Next, I presume, someone will claim to be traumatised by 
Ivan's email.)

Just as Ivan should have waited until he had calmed down before firing 
off his rant, so we ought to resist the temptation to strike back with 
hostility at trivial social transgressions, especially from newcomers. 
This is what Ivan actually said:

- Tkinter is broken and partly functional (an opinion with only the 
  most tenuous connection with fact, but hardly abusive);

- that nobody cares (factually wrong, but not abusive);

- that possibly nobody is using it (factually wrong, but not abusive);

- that if that's the case (it isn't), then it should be removed
  from the std lib (a reasonable suggestion if only the premise had
  been correct).

Intemperate and impolite it certainly was, as well as full of factual 
inaccuracies, but to call it "close to abusive" is a hostile over- 
reaction. We ought to be kinder than that. Our response to Ivan has been 
more hostile, and less open and respectful, than his email that 
triggered the response.

Brett is right to say people can afford to wait a little while before 
firing off an angry email. But the same applies to us: we too can afford 
to wait a little while before raising the threat of the CoC over a minor 
social faux pas. This community isn't so fragile that we have to jump 
down the throat of a newcomer lest the community immediately collapses 
into Call Of Duty gamer culture.


-- 
Steve
___
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 linkage on macOS

[Ned Deily]

On May 4, 2018, at 08:10, Ray Donnelly  wrote:
> On Fri, May 4, 2018 at 11:00 AM, Antoine Pitrou  wrote:
>> On Fri, 04 May 2018 00:21:54 +
>> Ray Donnelly  wrote:
>>> Anyway, it is obviously safer for us to do what upstream does and I will
>>> try to post some benchmarks of static vs shared to the list so we can
>>> discuss it.
>> I have no idea what our default builds do on macOS, I'll let Ned Deily
>> or another mac expert answer (changing the topic in the hope he notices
>> this subthread :-)).
> And thanks for doing this. For the benchmarks I think I should build
> Python 3.6.5 (or would 3.7.0b4 be better?) from pyperformance built
> each way using the AD scripts and reply here with the results. If I do
> not get it done today then I hope to get them ready by Monday.

The macOS python interpreters provided by python.org binary installers have 
always (for a very long time of always) been built as shared, in particular the 
special macOS framework build configuration.  It would be very interesting to 
do Apple to Apple comparisons of shared vs static builds on macOS.  I would 
look forward to seeing any results you have, Ray, and your methodology.  Static 
builds is on my list of things to look at for 3.8.
 
--
  Ned Deily
  n...@python.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] Process to remove a Python feature

[Steven D'Aprano]

On Fri, May 04, 2018 at 12:56:57PM +0200, Victor Stinner wrote:

> Sorry, when I wrote "Python 4" I mean "the new Python release which
> introduces a lot of backward incompatible changes and will annoy
> everyone". It can be Python 3.9 or 3.10, or whatever version
> (including 4.3 if you want) :-)

I call that "Python 4000", in analogy with Python 3000 which became 
Python 3, and to further emphasise how far away it is, I've started 
calling it "Python 5000".

As I understand it, Guido has said that we won't be doing a repeat of 
the 2 to 3 break-a-lot-of-stuff-at-once transition unless there is some 
unforeseen necessity.


> My point is that deprecating a feature is one thing, removing it is
> something else.
> 
> We should slow down feature removal, or more generally reduce the
> number of backward incompatible changes per release.

Have there been many features removed since 3.1? I know there were some 
features removed in 3.0, like callable(), which were later put back in, 
but I can't think of anythin removed since then. If there were, the pace 
of it is pretty slow.


> Maybe keep a deprecating warning for 10 years is just fine.
> 
> Extract of the Zen of Python: "Although practicality beats purity." ;-)

Aside from things that need to be removed for security reasons, this 
seems good to me.


-- 
Steve
___
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] Dealing with tone in an email

[Steve Holden]

Me neither, but I do want people to accept that there are norms, which
should usually be observed.  S

Steve Holden

On Fri, May 4, 2018 at 11:14 AM, Antoine Pitrou  wrote:

> On Fri, 4 May 2018 08:23:19 +0100
> Steve Holden  wrote:
> >
> > ​Yup. Tolerance has to have its limits, and this came close to abusive
> > behaviour. ​
> >
> > ​I suspect others among us might have been guilty of similar behaviours
> in
> > the past I certainly couldn't cast the first stone), but times change as
> do
> > standards, and it's certainly not the tone the majority of the readers of
> > this list would want, I believe.
> >
> > Let's hope this message continues to come across loud and clear.
>
> Since Terry Reedy (the IDLE maintainer) responded and refuted (some
> of?) the OP's assertions, I guess the case is settled.
>
> But that's not the same thing as threatening a poster with some
> accusations of CoC violation, just because the poster happened to use a
> familiar expression.
>
> Personally, I don't want people to be intimidated away from contributing
> because their English expression differs from that of the dominant (or,
> rather, most vocal and/or better organized) fraction.
>
> Regards
>
> Antoine.
>
>
> ___
> 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/
> steve%40holdenweb.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] A fast startup patch (was: Python startup time)

[Nick Coghlan]

On 4 May 2018 at 06:13, Carl Shapiro  wrote:

> Hello,
>
> Yesterday Neil Schemenauer mentioned some work that a colleague of mine
> (CCed) and I have done to improve CPython start-up time.  Given the recent
> discussion, it seems timely to discuss what we are doing and whether it is
> of interest to other people hacking on the CPython runtime.
>
> There are many ways to reduce the start-up time overhead.  For this
> experiment, we are specifically targeting the cost of unmarshaling heap
> objects from compiled Python bytecode.  Our measurements show this specific
> cost to represent 10% to 25% of the start-up time among the applications we
> have examined.
>
> Our approach to eliminating this overhead is to store unmarshaled objects
> into the data segment of the python executable.  We do this by processing
> the compiled python bytecode for a module, creating native object code with
> the unmarshaled objects in their in-memory representation, and linking this
> into the python executable.
>
> When a module is imported, we simply return a pointer to the top-level
> code object in the data segment directly without invoking the unmarshaling
> code or touching the file system.  What we are doing is conceptually
> similar to the existing capability to freeze a module, but we avoid
> non-trivial unmarshaling costs.
>

This definitely seems interesting, but is it something you'd be seeing us
being able to take advantage of for conventional Python installations, or
is it more something you'd expect to be useful for purpose-built
interpreter instances? (e.g. if Mercurial were running their own Python,
they could precache the heap objects for their commonly imported modules in
their custom interpreter binary, regardless of whether those were standard
library modules or not).

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

Re: [Python-Dev] Python linkage on macOS

[Ray Donnelly]

On Fri, May 4, 2018 at 11:00 AM, Antoine Pitrou  wrote:
> On Fri, 04 May 2018 00:21:54 +
> Ray Donnelly  wrote:
>>
>> Yes, on Windows there's always a python?.dll.
>>
>> macOS is an interesting one. For Anaconda 5.0 I read somewhere (how's that
>> for a useless reference - and perhaps I got the wrong end of the stick)
>> that Python for all Unixen should use a statically linked interpreter so I
>> happily went ahead and did that.
>
> A statically linked Python can also be significantly faster (10 to 20%
> IIRC, more perhaps on ARM).  I think you already know about that :-)
>

Indeed, and it worked out well on Intel too. Thanks for the recommendation.

>> Anyway, it is obviously safer for us to do what upstream does and I will
>> try to post some benchmarks of static vs shared to the list so we can
>> discuss it.
>
> I have no idea what our default builds do on macOS, I'll let Ned Deily
> or another mac expert answer (changing the topic in the hope he notices
> this subthread :-)).
>

And thanks for doing this. For the benchmarks I think I should build
Python 3.6.5 (or would 3.7.0b4 be better?) from pyperformance built
each way using the AD scripts and reply here with the results. If I do
not get it done today then I hope to get them ready by Monday.

> Regards
>
> Antoine.
>
>
> ___
> 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/mingw.android%40gmail.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] Process to remove a Python feature

[Victor Stinner]

2018-05-02 19:24 GMT+02:00 Brett Cannon :
> On Wed, 2 May 2018 at 02:12 Victor Stinner  wrote:
>> Does it mean that the Python 3 release following Python 2 end-of-life
>> (2020) will be our next feared "Python 4"? Are we going to remove all
>> deprecated features at once, to maximize incompatibilities and make
>> users unhappy?
>
> I don't see why removing features that already raise a DeprecationWarning
> would require bumping the major version number. Personally, I assumed either
> Python 3.9 or 3.10 would be the version where we were okay clearing out the
> stuff that had been raising DeprecationWarning for years.

Sorry, when I wrote "Python 4" I mean "the new Python release which
introduces a lot of backward incompatible changes and will annoy
everyone". It can be Python 3.9 or 3.10, or whatever version
(including 4.3 if you want) :-)

My point is that deprecating a feature is one thing, removing it is
something else.

We should slow down feature removal, or more generally reduce the
number of backward incompatible changes per release.

Maybe keep a deprecating warning for 10 years is just fine.

Extract of the Zen of Python: "Although practicality beats purity." ;-)

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] Dealing with tone in an email

[Antoine Pitrou]

On Fri, 4 May 2018 08:23:19 +0100
Steve Holden  wrote:
> 
> ​Yup. Tolerance has to have its limits, and this came close to abusive
> behaviour. ​
> 
> ​I suspect others among us might have been guilty of similar behaviours in
> the past I certainly couldn't cast the first stone), but times change as do
> standards, and it's certainly not the tone the majority of the readers of
> this list would want, I believe.
> 
> Let's hope this message continues to come across loud and clear.

Since Terry Reedy (the IDLE maintainer) responded and refuted (some
of?) the OP's assertions, I guess the case is settled.

But that's not the same thing as threatening a poster with some
accusations of CoC violation, just because the poster happened to use a
familiar expression.

Personally, I don't want people to be intimidated away from contributing
because their English expression differs from that of the dominant (or,
rather, most vocal and/or better organized) fraction.

Regards

Antoine.


___
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 linkage on macOS

[Antoine Pitrou]

On Fri, 04 May 2018 00:21:54 +
Ray Donnelly  wrote:
> 
> Yes, on Windows there's always a python?.dll.
> 
> macOS is an interesting one. For Anaconda 5.0 I read somewhere (how's that
> for a useless reference - and perhaps I got the wrong end of the stick)
> that Python for all Unixen should use a statically linked interpreter so I
> happily went ahead and did that.

A statically linked Python can also be significantly faster (10 to 20%
IIRC, more perhaps on ARM).  I think you already know about that :-)

> Anyway, it is obviously safer for us to do what upstream does and I will
> try to post some benchmarks of static vs shared to the list so we can
> discuss it.

I have no idea what our default builds do on macOS, I'll let Ned Deily
or another mac expert answer (changing the topic in the hope he notices
this subthread :-)).

Regards

Antoine.


___
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] Dealing with tone in an email

[Steve Holden]

On Thu, May 3, 2018 at 9:13 PM, Brett Cannon  wrote:

>
>
> On Thu, 3 May 2018 at 12:29 Guido van Rossum  wrote:
>
>> EVENTUALLY WE'LL ALL BE SHOUTING ALL THE TIME. Sad.
>>
>
> Yep. And that leads to burn-out. So while Ivan may have lucked out in
> getting the attention of people who are helped him (and given the wrong
> kind of positive reinforcement that this approach is reasonable), this can
> lead to people quitting open source and not being available to help you
> next time (e.g. notice how it drove Paul Moore over the edge to pull back
> for a week or so and he may have been the expert you needed for packaging
> or me for imports; IOW I would say Ivan was lucky this time and may not be
> so lucky next time).
>
> -Brett
>
>

​Yup. Tolerance has to have its limits, and this came close to abusive
behaviour. ​

​I suspect others among us might have been guilty of similar behaviours in
the past I certainly couldn't cast the first stone), but times change as do
standards, and it's certainly not the tone the majority of the readers of
this list would want, I believe.

Let's hope this message continues to come across loud and clear.

​regards
 Steve

​
___
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] Dealing with tone in an email

[Paddy McCarthy]

> > Whatever anyone may think of this, it worked.


I help on other forums and have two practises that I work at:

When asking a question I try to be polite. It may be more challenging to be
ultra polite but sometimes it's worthwhile. Being told I am polite online
is a much rarer accolade and can lift my day :-)

On those being brusk/abusive in asking for help then I don't like to reward
that behaviour and someone will tell them it's not necessary. If repeated
then the best one can do is ignore them leaving them knowing why.

Hopefully it leads to a better community. People have to understand **"Help
on the helpers terms".**
___
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