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] 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] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch

[Matthias Bussonnier]

> As I wrote, it became very difficult to merge any PR on 2.7 because of
> that. We all run a race to be the first one to merge a change into
> 2.7. The next one will get a "conflict" even if the merged commit is
> unrelated (as I described: two different unrelated directories).

Couldn't miss-islington be configured to automatically rebase those (when
there is no actual conflict). The "Allow edit from maintainer" would most
likely permit to push on the PRs branch.
-- 
M

On Tue, 29 May 2018 at 05:26, Nick Coghlan  wrote:

> On 29 May 2018 at 08:52, Ned Deily  wrote:
>
>> On May 28, 2018, at 17:42, Victor Stinner  wrote:
>> > Please use the same configuration for 2.7, 3.6, 3.7 and master branches!
>>
>> Sounds reasonable. I've updated the 2.7 configuration to match the others
>> and not require the PR branch be up to date before merging, meaning the CI
>> test might be against an older view of the branch.  If it proves to be a
>> problem, we can revisit it for all of the branches.  I am not going to
>> change the settings for 3.5 and 3.4 as they are in security-fix mode and
>> only their release manager can merge changes for those.
>>
>
> Turning the setting on for security-fix branches sounds like a good idea
> to me, since it's basically a "stability-of-target-branch vs
> ease-of-merging" trade-off: by setting it, you ensure that your pre-merge
> CI checks reflect the state of the post-merge branch, whereas the default
> setting means your post-merge branch state represents a never-before-tested
> combination of software.
>
> The default state works pretty well for us since we don't kick off test
> runs on the BuildBot fleet for every PR, so there's always some additional
> testing that only happens post-merge anyway.
>
> 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/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] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch

[Matthias Bussonnier]

On Tue, 29 May 2018 at 08:43, Paul G  wrote:

> This doesn't seem like the best idea, since it would kick off dozens or
> hundreds of builds for every commit to the master branch.
>

Sorry if I was unclear, I was not suggesting to do that for PRs against
master, but do that only for 2.7, 3.4 and 3.5 only. (or Branch having "Require
branches to be up to date before merging ")
For these there is likely only a couple of open PRs, and it won't kick more
jobs than if the author had to rebase and push by themselves.

If you still think it's too much or triggered too often, you can also just
have a tag "Miss-islington please rebase", which is often easier to apply
manually, than having to do that by yourself on the Command line.

-- 
M
___
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] Docstrings on builtins

[Matthias Bussonnier]

This may even be a bug/feature of IPython,

I see that inspect.signature(timedelta) fails, so if  timedelta? says
Init signature: timedelta(self, /, *args, **kwargs)
Then this may be some IPython internal logic. The timedelta class seem to
use __new__ instead of __init__ (not sure why) and __new__ have a
meaningful signature,
So maybe we should fallback on that during signature inspection.

Feel free to open an issue on the IPython repo.

Btw IPython is uppercase I, and we don't want any troupe with the fruit
giant.
-- 
M

On Mon, 4 Jun 2018 at 16:30, Chris Barker via Python-Dev <
python-dev@python.org> wrote:

> On Mon, Jun 4, 2018 at 3:27 PM, Victor Stinner 
> wrote:
>
>> For Argument Clinic, have a look at
>> https://docs.python.org/dev/howto/clinic.html
>
>
> Thanks Victor -- scanning that page, it is indeed where I needed to look.
>
> You can also try to copy/paste code from other files using Argument
>> Clinic and then run "make clinic" to regenerate the generated files.
>>
>
> good idea.
>
> Now to find some time to actually work on this...
>
> -CHB
>
>
>
>
>> Victor
>>
>> 2018-06-04 23:45 GMT+02:00 Chris Barker via Python-Dev <
>> python-dev@python.org>:
>> > Over on python-ideas, someone is/was proposing literals for timedeltas.
>> >
>> > I don't expect that will come to anything, but it did make me take a
>> look at
>> > the docstring for datetime.timedelta. I use iPython's ? a lot for a
>> quick
>> > overview of how to use a class/function.
>> >
>> > This is what I get:
>> >
>> > In [8]: timedelta?
>> > Init signature: timedelta(self, /, *args, **kwargs)
>> > Docstring:  Difference between two datetime values.
>> > File:   ~/miniconda2/envs/py3/lib/python3.6/datetime.py
>> > Type:   type
>> >
>> >
>> > That is, well, not so useful. I'd like to see at least the signature:
>> >
>> > datetime.timedelta(days=0, seconds=0, microseconds=0, milliseconds=0,
>> > minutes=0, hours=0, weeks=0
>> >
>> > And ideally much of the text in the docs.
>> >
>> > I've noticed similarly minimal docstrings on a number of builtin
>> functions
>> > and methods.
>> >
>> > If I wanted to contribute a PR to enhance these docstrings, where would
>> they
>> > go?  I've seen mention of "argument clinic", but really don't know quite
>> > what that is, or how it works, but it appears to be related.
>> >
>> > Anyway -- more comprehensive docstrings on buildins could really help
>> > Python's usability for command line usage.
>> >
>> > Thanks,
>> > -  Chris
>> >
>> >
>> >
>> >
>> > --
>> >
>> > Christopher Barker, Ph.D.
>> > Oceanographer
>> >
>> > Emergency Response Division
>> > NOAA/NOS/OR&R(206) 526-6959   voice
>> > 7600 Sand Point Way NE   (206) 526-6329   fax
>> > Seattle, WA  98115   (206) 526-6317   main reception
>> >
>> > chris.bar...@noaa.gov
>> >
>> > ___
>> > 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/vstinner%40redhat.com
>> >
>>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
> ___
> 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] Docstrings on builtins

[Matthias Bussonnier]

On Mon, 4 Jun 2018 at 17:29, Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

> On 05.06.2018 3:09, Matthias Bussonnier wrote:
>
> This may even be a bug/feature of IPython,
>
> I see that inspect.signature(timedelta) fails, so if  timedelta? says
> Init signature: timedelta(self, /, *args, **kwargs)
> Then this may be some IPython internal logic. The timedelta class seem to
> use __new__ instead of __init__ (not sure why)
>
> Because it's an immutable type.
>
Ah, yes, thanks.


> and __new__ have a meaningful signature,
> So maybe we should fallback on that during signature inspection.
>
> According to
> https://stackoverflow.com/questions/4374006/check-for-mutability-in-python
> ,
> there are no reliable tests for mutability.
>
Sure, but we can test if the signature of __init__ is (self,/, *args,
**kwargs), and if it is,  it is useless we can attempt to get the signature
from __new__ and show that instead.  We do similar things for docstrings,
if __init__ have no docstring we look at the class level docstring.
-- 
M
___
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] If you shadow a module in the standard library that IDLE depends on, bad things happen

[Matthias Bussonnier]

> On Oct 29, 2015, at 11:46, Laura Creighton  wrote:
> 
> In a message of Thu, 29 Oct 2015 18:27:59 +, Paul Moore writes:
>> The idle issues seem to me to demonstrate that shadowing the stdlib is
>> a bad idea. Of course, consenting adults, and if you override you're
>> responsible for correctly replacing the functionality, and all that,
>> but honestly, I don't think it needs to be *easy* to shadow the stdlib
>> - there's nothing wrong with it being an "advanced" technique that
>> people have to understand in order to use.
> 
> I am actually sick of the 'consenting adults' argument.
> I am dealing with '11 year old children trying to write their
> first, third and tenth python programs'.  For the life of me
> I cannot see how convenience for the sort of person who has a 
> legitimate reason to shadow the syslib should get a higher priority
> over these mites who are doing their damndest to write python
> despite natural language barriers  and the fact that their peers
> and parents think they are nuts to want to do so.
> 
> (a grumpy comment from a teacher at a Swedish 'coding for
> kids' club.  Disregard if too grumpy.)

+1 on **warning**, warning still allow people to shadow stdlib, and for people 
who have
 **legitimate** reasons to shadow, we can always find a solution to to tag 
a module as “yes I know I am shadowing, I am doing that on purpose”. 

StdlibShadowWarning and warning filter ?

Also a warning would be useful for people to discover that some Stdlib modules 
exist, 
and maybe explore them. 



-- 
M

___
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] Opcode cache in ceval loop

[Matthias Bussonnier]

> On Feb 3, 2016, at 13:22, Yury Selivanov  wrote:
> 
> 
> An ideal way would be to calculate a hit/miss ratio over time
> for each cached opcode, but that would be an expensive
> calculation.

Do you mean like a sliding windows ?
Otherwise if you just want a let's say 20% miss threshold, you increment by 1 
on hit, 
and decrement by 4 on miss. 


On Feb 3, 2016, at 13:37, Sven R. Kunze  wrote:

> On 03.02.2016 22:22, Yury Selivanov wrote:
>> One way of tackling this is to give each optimized opcode
>> a counter for hit/misses.  When we have a "hit" we increment
>> that counter, when it's a miss, we decrement it.
> 
> Within a given range, I suppose. Like:
> 
> c = min(c+1, 100)


Min might be overkill, maybe you can use a or mask, to limit the windows range
to 256 consecutive call ? 
-- 
M





> 
> Yury
> 
> ___
> 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] Opcode cache in ceval loop

[Matthias Bussonnier]

> On Feb 4, 2016, at 08:22, Sven R. Kunze  wrote:
> 
> On 04.02.2016 16:57, Matthias Bussonnier wrote:
>>> On Feb 3, 2016, at 13:22, Yury Selivanov  wrote:
>>> 
>>> 
>>> An ideal way would be to calculate a hit/miss ratio over time
>>> for each cached opcode, but that would be an expensive
>>> calculation.
>> Do you mean like a sliding windows ?
>> Otherwise if you just want a let's say 20% miss threshold, you increment by 
>> 1 on hit,
>> and decrement by 4 on miss.
> 
> Division is expensive.

I'm not speaking about division here. 
if you +M / -N the counter will decrease in average only if the hit/miss ratio 
is below N/(M+N), but you do not need to do the division. 

Then you deoptimize only if you get < 0. 

> 
>> 
>> On Feb 3, 2016, at 13:37, Sven R. Kunze  wrote:
>> 
>>> On 03.02.2016 22:22, Yury Selivanov wrote:
>>>> One way of tackling this is to give each optimized opcode
>>>> a counter for hit/misses.  When we have a "hit" we increment
>>>> that counter, when it's a miss, we decrement it.
>>> Within a given range, I suppose. Like:
>>> 
>>> c = min(c+1, 100)
>> 
>> Min might be overkill, maybe you can use a or mask, to limit the windows 
>> range
>> to 256 consecutive call ?
> 
> Sure, that is how I would have written it in Python. But I would suggest an 
> AND mask. ;-)


Sure, implementation detail I would say. Should not write emails before 
breakfast...

The other problem, with the mask, is if your increment hit 256 you wrap around 
back to 0
where it deoptimize (which is not what you want), so you might need to not mask 
the
sign bit and deoptimize only on a certain negative threshold.


Does it make sens ?

-- 
M

 

> 
> Best,
> Sven

___
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] Windows: Remove support of bytes filenames in the os module?

[Matthias Bussonnier]

> On Feb 8, 2016, at 06:40, Victor Stinner  wrote:
> 
> 2016-02-08 15:32 GMT+01:00 Victor Stinner :
>> Since 3.3, functions of the os module started to emit
>> DeprecationWarning when called with bytes filenames.
>> (...)
>> Recently, an user complained that os.walk() doesn't work with bytes on
>> Windows anymore:
>> (...)
> 
> It's also sad to see that deprecation warnings are completly ignored.
> Python 3.3 was release in 2011, 5 years ago.

> 
> I would prefer to show deprecation warnings by default. But I know
> that it's an old debate: developers vs users :-) I like to see my
> users as potential developers ;-)


This is tracked in this issue:

http://bugs.python.org/issue24294  :  
DeprecationWarnings should be visible by default in the interactive REPL

IPython have enabled them only if they come from __main__. From totally 
subjective experience, 
that has already pushed a few library to update their code to new apis[1].
-- 
M

[1] or sometime to wrap code in ignore warnings...



> 
> 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/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] Very old git mirror under github user "python-git"

[Matthias Bussonnier]

Hi all, 


> On Feb 27, 2016, at 14:21, Alexander Walters  wrote:
> 
> Can we even ask github to pull it down and reasonably expect them to comply?  
> Their entire model is built on everyone forking everyone else.

Why the model is everyone forking, some of the help page of GitHub actually 
tell you to contact GitHub support, like if you desire to "detach" a fork. 

Every reasonable requests I made to GitHub and the few interactions I had with 
the support always went well. 
This did include asking GitHub to contact user as their pages were confusing, 
and might be misleading others.

So I would suggest 

1) asking GitHub to contact author, potentially forwarding him/her a message 
from this list asking him/her to bring that down or transfer the control to you.
That should be easy to do as it will not force GitHub to provide anyone with 
the emails of the the owner of python-git.

2) in the case of no response from author ask politely GitHub that the repo is 
confusing for user, and ask what they can do about that.

3) If still nothing can be done make a DMCA request. You can likely argue that 
the logo/name are used without PSF content. 
https://help.github.com/articles/dmca-takedown-policy/ 
 

This would likely have more impact if sent from someone part of 
https://github.com/python 

-- 
M




___
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] Which version is better? Phyton 27 or Phyton 35?

[Matthias Bussonnier]

On Fri, Apr 1, 2016 at 9:21 AM, Chris Angelico  wrote:
> On Fri, Apr 1, 2016 at 9:42 PM, Roberto Martínez
>  wrote:
>> I am having a hard time trying to choose one of this two products:
>>
>> Phyton 27:
>> http://www.amazon.com/Phyton-27-Systemic-Bactericide-Fungicide/dp/B00VKPL8FU
>> Phyton 35:
>> http://www.amazon.com/Phyton-Bactericide-fungicide-Substitute-Liter/dp/B00BGE65VM
>>
>> Phyton 35 is announced as the "Substitute for Phyton 27" but I feel that
>> Phyton 27 is more tested and have a bigger user base.
>>
>> Can you help to choose?
>
> Sure! This is a fairly common question, and it comes down to what sort
> of plants you're trying to use this with. Some plants prefer Phyton
> 27, while others prefer Phyton 35. Most plants are happy with either,
> though, so unless you have a good reason to do otherwise, use Phyton
> 35.
>
> Phyton 35 has some significant improvements that make it far better at
> handling plants from different parts of the world. And even some
> American plants have special black markings on them, or cost so much
> money that they're priced in Euros, or for some similar reason need
> the advanced care of Phyton 35. As such, I strongly recommend that you
> develop a taste for Phyton 35, as it will serve you better in the long
> run. In this era of international foods in every supermarket aisle,
> you cannot simply dismiss the black marks as "funny spots" and wish
> they'd just go away; you MUST have a fungicide which can adequately
> handle them.
>


Also keep in mind that Phyton 35 improve on previous fungicide by allowing
asynchronous plant growing using  eukaryotic microorganisms also known
`yeast from`.


-- 
M
___
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] Communication channels

[Matthias Bussonnier]

On Mon, 1 Oct 2018 at 13:38, Victor Stinner  wrote:

> Le lun. 1 oct. 2018 à 22:32, Tres Seaver  a écrit :
> > I'm pretty strongly -1 on the notion that folks who subscribe python-dev,
> > BPO, and the github repositories should need to *also* follow an
> > arbitrarily-growing set of Twitter accounts:  how would one know if a new
> > one popped into being?  How likely is it that everything a given Python
> > developer tweets is relevant for the Python development community?
>
> My intent is not to ask you to subscribe to everything. I just wanted

to list all communication channels and let you make your own choices.


And too modest to add self to list of twitter accounts...
https://twitter.com/VictorStinner
Or did he deemed himself not worthy of beeing followed ?

I was tempted to do a joke based on "takes 0 positional arguments but 1 was
given"...

Much love for the time you take to list all those channels and reach out to
the community.
-- 
M
___
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] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

[Matthias Bussonnier]

Is it possible to change some of those deprecation from Warn-by-default (but 
can add a warning filter to make them error) to error-by-default (but can add a 
filter to make them only warnings). 

That way it is easy to fix large projects (even w/o modifying the source) in 
only a couple of lines of codes; and they buy themselves a year or so and 
remove in 3.10. 

That way you have a more gradual transition; and a clear signal to project with 
a last chance to fix issues.
And that way can't complained they did not know as they have to opt-in.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CMO7H5A4IHXRR52SDOBSPE25C7UW6A7T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

[Matthias Bussonnier]

Is it possible to change some of those deprecation from Warn-by-default (but 
can add a warning filter to make them error) to error-by-default (but can add a 
filter to make them only warnings). 

That way it is easy to fix large projects (even w/o modifying the source) in 
only a couple of lines of codes; and they buy themselves a year or so and 
remove in 3.10. 

That way you have a more gradual transition; and a clear signal to project with 
a last chance to fix issues.
And that way can't complained they did not know as they have to opt-in.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7BMWSTC4WUXOZ3MKQKSXWKEX6QLYHNU2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] inspect.getdoc and (Not) returning type/superclass docstrings in 3.9

[Matthias Bussonnier]

Hi All, 

# Too long didn't read:

In 3.9 inspect.getdoc(instance) behavior was changed and does not return the 
documentation of type(instance) or it's superclass(es) – I think this is a 
problematic change of for some project and interactive use to get info on 
objects that get rarely directly constructed by users. For example pandas 
dataframe obtained via `pandas.read_csv(filepath)`.

I'd like to ask for reconsideration, and that change of behavior are better 
suited in a new function; potentially deprecating the old one.

# Longer version

In https://bugs.python.org/issue40257 attempts are made to improve the output 
of `pydoc`, it particular it is difficult to have fine grained logic depending 
on where the documentation comes from (instance, class , superclass, etc..). 
Which sometime can lead to nonsensical help.

The following are given as examples:

> inspect.getdoc(1) returns the same as inspect.getdoc(int)

or 

>>> import wave
>>> help(wave.Error)
Help on class Error in module wave:

class Error(builtins.Exception)
 |  Common base class for all non-exit exceptions.
 |  
 |  Method resolution order:
...


In 3.9 the behavior of `inspect.getdoc()` has been changed to be way more 
restrictive in what it returns, often returning None where it used to return 
docstrings. 

I agree with the end goal of having more controllable way of finding where the 
documentation/docstrings is coming from and avoiding incorrect docs in pydoc 
and help, 
though I find that change of behavior of `getdocs()` might not be the right 
approach.

I'm quite worried many project rely on current behavior of `getdocs()` – at 
least IPython/Jupyter does to provide user with help/superhelp accessible via 
obj? and obj??.

I would also argue that inaccurate help is also often better than no help.
With current state on Python 3.9,  a few things like asking for help on a 
pandas dataframe instance will currently loose informations.
>>> import pandas as pd
>>> from inspect import getdoc
>>> df = pd.read_csv('mydata.csv')
>>> print(getdoc(df))
None

I'm taking the example of pandas as this is typically the kind of objects you 
don't construct directly, and get via for example `read_csv()`, or that another 
API/Package return to you. 

I haven't been able to confirm yet exactly how this affects sphinx rendering of 
docs, and how other IDEs provide help (Spyder, Pycharm...), or other projects 
that use `getdocs()`. 

I've found mentions of `getdocs()` in numpy, scipy, jedi, matplotlib ... as 
well (sphinx extension and various dynamic docs), and working on building them 
on 3.9 to check the effect.

In general though the effect of `getdoc()` rarely seem to be tested as they 
will directly be user facing is my feeling – I was lucky to catch it in 
IPython/Jupyter as the failing test was unrelated and indirectly relying on the 
exact output of a subprocess. 

From the IPython/Jupyter perspective I would prefer to keep current behavior of 
`inspect.getdocs()` potentially deprecating it if you wish to, and provide an 
alternative that have a behavior of your choosing. Dealing with functions with 
slightly chaging behavior across Python version is not the best experience, and 
this would let the ecosystem get some chance to adapt. Updated project get 
rarely released  in synchrony with new Python versions.

Your thoughts on this issue are welcome, thanks for all your work on core 
python, and I'll support any decision that get made. 
-- 
Matthias
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6QO2XI5B7RVZDW3YZV24LYD75VGRITFU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 (match statement) playground

[Matthias Bussonnier]

It's still weird user experience as if you swap case .z and case z you don't 
get the Unbound error anymore. SO it can work w/o global.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/N7JWYVR3YSO2Z6F46GBGZQVDQXDVHJYS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Hygenic macros PEP.

[Matthias Bussonnier]

Mark, 

Thanks you this is an interesting proposal. I can see how many of the "magics" 
provided by IPython/Jupyter could also be replaced by some of those macros. 

A couple of questions – which I understand could be delegated to further 
improvement to macros in a subsequent proposal. 

 - I'm not sure I see how these macros could take parameters ? For example 
`timeit` in IPython takes a number of options on the number of repetitions and 
the number of innerloop for really fast code. I'm not sure how this would be 
done with your proposal, would
stmt_macro!(options):
multi_statement_body
Be something you consider for a later iteration? I might be missing how to do 
it, apologies about this if its the case.
passing parameters also likely apply to siblings macros?

- especially for statement_macros, have you considered to relax the syntax 
inside the block, and pass the string of the dedented block to the macross 
processor (or have it as an option). That would make it quite easier to embed 
non-python syntax, and allow to convert a much larger chunk of the 
IPython/Jupyter magics to macros.

Thanks, 
-- 
Matthias
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YVCAKVEMTEL7ZHDLURORDVX4DCLUZ3ZM/
Code of Conduct: http://python.org/psf/codeofconduct/