Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

[Philipp A.]

Hi! Just this minute I ran across a case where I’d want DeprecationWarnings
on by default

(We want to rename a property in an API I’m co-developing. I has mainly
scientists as target audience, so end users, not developers)

Gustavo Carneiro  schrieb am Mo., 6. Nov. 2017 um
15:19 Uhr:

> Big +1 to turning warnings on by default again.
>
> When this behaviour first started, first I was surprised, then annoyed
> that warnings were being suppressed.  For a few years I learned to have
> `export PYTHONWARNINGS=default` in my .bashrc.
>
> But eventually, the warnings in 3rd-party Python modules gradually
> increased because, since warnings are disabled by default, authors of
> command-line tools, or even python modules,  don't even realise they are
> triggering the warning.
>
> So developers stop fixing warnings because they are hidden.  Things get
> worse and worse over the years.  Eventually I got fed up and removed the
> PYTHONWARNINGS env var.
>
> Showing warnings by default is good:
>  1. End users who don't understand what those warnings are are unlikely to
> see them since they don't command-line tools at all;
>  2. The users that do see them are sufficiently proficient to be able to
> submit a bug report;
>  3. If you file a bug report in tool that uses a 3rd party module, the
> author of that tool should open a corresponding bug report on the 3rd party
> module that actually caused the warning;
>  4. Given time, all the bug reports trickle down and create pressure on
> module maintainers to fix warnings;
>  5. If a module is being used and has no maintainer, it's a good
> indication it is time to fork it or find an alternative.
>
> Not fixing warnings is a form of technical debt that we should not
> encourage.  It is not the Python way.
>
>
> On 6 November 2017 at 02:05, Nick Coghlan  wrote:
>
>> On the 12-weeks-to-3.7-feature-freeze thread, Jose Bueno & I both
>> mistakenly though the async/await deprecation warnings were missing
>> from 3.6.
>>
>> They weren't missing, we'd just both forgotten those warnings were off
>> by default (7 years after the change to the default settings in 2.7 &
>> 3.2).
>>
>> So my proposal is simple (and not really new): let's revert back to
>> the way things were in 2.6 and earlier, with DeprecationWarning being
>> visible by default, and app devs having to silence it explicitly
>> during application startup (before they start importing third party
>> modules) if they don't want their users seeing it when running on the
>> latest Python version (e.g. this would be suitable for open source
>> apps that get integrated into Linux distros and use the system Python
>> there).
>>
>> This will also restore the previously clear semantic and behavioural
>> different between PendingDeprecationWarning (hidden by default) and
>> DeprecationWarning (visible by default).
>>
>> As part of this though, I'd suggest amending the documentation for
>> DeprecationWarning [1] to specifically cover how to turn it off
>> programmatically (`warnings.simplefilter("ignore",
>> DeprecationWarning)`), at the command line (`python -W
>> ignore::DeprecationWarning ...`), and via the environment
>> (`PYTHONWARNINGS=ignore::DeprecationWarning`).
>>
>> (Structurally, I'd probably put that at the end of the warnings
>> listing as a short introduction to warnings management, with links out
>> to the relevant sections of the documentation, and just use
>> DeprecationWarning as the specific example)
>>
>> Cheers,
>> Nick.
>>
>> [1] https://docs.python.org/3/library/exceptions.html#DeprecationWarning
>>
>
>> --
>> 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/gjcarneiro%40gmail.com
>>
>
>
>
> --
> Gustavo J. A. M. Carneiro
> Gambit Research
> "The universe is always one step beyond logic." -- Frank Herbert
> ___
> 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/flying-sheep%40web.de
>
___
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] Proposal: go back to enabling DeprecationWarning by default

[Philipp A.]

Sorry, I still don’t understand how any of this is a problem.

   1. If you’re an application developer, google “python disable
   DeprecationWarning” and paste the code you found, so your users don’t see
   the warnings.
   2. If you’re a library developer, and a library you depend on raises
   DeprecationWarnings without it being your fault, file an issue/bug there.

For super-increased convenience in case 2., we could also add a convenience
API that blocks deprecation warnings raised from certain module or its
submodules.
Best, Philipp

Nick Coghlan  schrieb am Di., 7. Nov. 2017 um 13:25 Uhr:

> On 7 November 2017 at 19:30, Paul Moore  wrote:
> > On 7 November 2017 at 04:09, Nick Coghlan  wrote:
> >> Given the status quo, how do educators learn that the examples they're
> >> teaching to their students are using deprecated APIs?
> >
> > By reading the documentation on what they are teaching, and by testing
> > their examples with new versions with deprecation warnings turned on?
> > Better than having warnings appear the first time they run a course
> > with a new version of Python, surely?
> >
> > I understand the "but no-one actually does this" argument. And I
> > understand that breakage as a result is worse than a few warnings. But
> > enabling deprecation warnings by default feels to me like favouring
> > the developer over the end user. I remember before the current
> > behaviour was enabled and it was *immensely* frustrating to try to use
> > 3rd party code and get a load of warnings. The only options were:
> >
> > 1. Report the bug - usually not much help, as I want to run the
> > program *now*, not when a new release is made.
> > 2. Fix the code (and ideally submit a PR upstream) - I want to *use*
> > the program, not debug it.
> > 3. Find the right setting/environment variable, and tweak how I call
> > the program to apply it - which doesn't fix the root cause, it's just
> > a workaround.
>
> Yes, this is why I've come around to the view that we need to come up
> with a viable definition of "third party code" and leave deprecation
> warnings triggered by that code disabled by default.
>
> My suggestion for that definition is to have the *default* meaning of
> "third party code" be "everything that isn't __main__".
>
> That way, if you get a deprecation warning at the REPL, it's
> necessarily because of something *you* did, not because of something a
> library you called did. Ditto for single file scripts.
>
> We'd then offer some straightforward interfaces for people to say
> "Please also report legacy calls from 'module' as warnings".
>
> You'd still get less-than-helpful warnings if you were running a
> single file script that someone *else* wrote (rather than one you
> wrote yourself), but that's an inherent flaw in that distribution
> model: as soon as you ask people to supply their own Python runtime,
> you're putting them in the position of acting as an application
> integrator (finding a combination of Python language runtime and your
> script that actually work together), rather than as a regular software
> user.
>
> 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/flying-sheep%40web.de
>
___
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] Proposal: go back to enabling DeprecationWarning by default

[Philipp A.]

Nick Coghlan  schrieb am Di., 7. Nov. 2017 um 14:57 Uhr:

> Users of applications written in Python are not python-dev's users:
> they're the users of those applications, and hence the quality of that
> experience is up to the developers of those applications. […]
>

Thank you, that’s exactly what I’m talking about. Besides: Nobody is
“hosed”… There will be one occurrence of every DeprecationWarning in the
stderr of the application. Hardly the end of the world for CLI applications
and even invisible for GUI applications.

If the devs care about the user not seeing any warnings in their CLI
application, they’ll have a test set up for that, which will tell them that
the newest python-dev would raise a new warning, once they turn on testing
for that release. That’s completely fine!

Explicit is better than implicit! If I know lib X raises
DeprecationWarnings I don’t care about, I want to explicitly silence them,
instead of missing out on all the valuable information in other
DeprecationWarnings.

Best, Philipp
___
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] Proposal: go back to enabling DeprecationWarning by default

[Philipp A.]

Hi Guido,

As far as I can see, the general consensus seems to be to turn them back on
in general: The last person to argue against it was Paul Moore, and he
since said:

“OK, I overstated [that you’re ‘hosed’ by DeprecationWarnings appearing].
Apologies. My recollection is of a lot more end user complaints when
deprecation warnings were previously switched on than others seem to
remember, but I can't find hard facts, so I'll assume I'm misremembering.”

Besides, quite some of the problems people mention would only be fixed by
turning them on in general, not with the compromise.

So I don’t think we need a compromise, right?

Best, Philipp

Guido van Rossum  schrieb am Mi., 8. Nov. 2017 um
03:46 Uhr:

> To cut this thread short, I say we should use Nick's proposal to turn
> these warnings on for __main__ but off elsewhere. (See
> https://mail.python.org/pipermail/python-dev/2017-November/150364.html.)
>
>
> --
> --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/flying-sheep%40web.de
>
___
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] {RELEASE] Python 3.6.0a4 is now available

[Philipp A.]

hi, i already posted in python-ideas, but i got no replies, so i’ll post
here:

in essence i think interpreting escape sequences in f-literals is a *very*
bad idea, mainly because i think it’s fundamental that syntax highlighters
can highlight code as code.

so they should highlight the code parts of f-literals as code to avoid bugs
and misunderstandings (parts highlighted as string aren’t expected to
execute). for many syntax highlighters, it’s *impossible* to properly
highlight python code after this change makes python’s grammar recursive
(escaped code in f-literals, doubly-escaped code in escaped f-literals in
f-literals, …).

i want this changed because i think it’s only done this way to reuse the
string tokenization code (i.e. convenience), not for some deeper reason.
the RFC even says so. however, f-literals aren’t strings, but expressions,
so string tokenization rules shouldn’t apply to the non-string parts.

how am i going about changing f-literal grammar before the beta hits?

i consider this important enough to defer f-literals to 3.7 if it can’t get
in in time.

best, philipp

Ned Deily  schrieb am Di., 16. Aug. 2016 um 05:02 Uhr:

> On behalf of the Python development community and the Python 3.6 release
> team, I'm happy to announce the availability of Python 3.6.0a4. 3.6.0a4
> is the last of four planned alpha releases of Python 3.6, the next major
> release of Python. During the alpha phase, Python 3.6 remains under
> heavy development: additional features will be added and existing
> features may be modified or deleted. Please keep in mind that this is a
> preview release and its use is not recommended for production environments.
>
> You can find Python 3.6.0a4 here:
>
> https://www.python.org/downloads/release/python-360a4/
>
> The next planned release of Python 3.6 will be 3.6.0b1, currently
> scheduled for 2016-09-12. 3.6.0b1 will mark the beginning of the beta
> phase of Python 3.6; at that time, feature development for 3.6 will be
> complete and the emphasis will change to fixing bugs and regressions.
> More information about the release schedule can be found here:
>
> https://www.python.org/dev/peps/pep-0494/
>
> --Ned
>
> --
>   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/flying-sheep%40web.de
>
___
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] {RELEASE] Python 3.6.0a4 is now available

[Philipp A.]

Brett Cannon  schrieb am Mi., 17. Aug. 2016 um 19:15 Uhr:

> Please don't cross-post as it means anyone replying to your email will now
> split the conversation as not everyone will be subscribed to all of the
> mailing lists you sent this to. I have stripped out all but python-dev for
> my reply.
>

sorry, i’ll remember that! i just hit reply on the post and didn’t realize
it was posted to more than python-dev.

I don't remember specifically seeing any email on this. Do you have a link
> to your post from the python-ideas archive showing your email actually made
> it to the list?
>

i posted here
…

I believe you're referring to
> https://www.python.org/dev/peps/pep-0498/#escape-sequences ?
>

yes!

how am i going about changing f-literal grammar before the beta hits?
>>
>
> You can post to python-ideas and start a discussion there as the PEP has
> already been accepted and implemented with the current semantics or ask for
> clarification for the reasoning behind the decision here on python-dev.
>

thanks. i’d like to hereby do the latter. i think the PEP’s wording is
pretty clear:

Due to Python's string tokenizing rules, the f-string f'abc {a['x']} def' is
> invalid. The tokenizer parses this as 3 tokens: f'abc {a[' , x , and ']}
> def' . Just like regular strings, this cannot be fixed by using raw
> strings. There are a number of correct ways to write this f-string
>

i guess that means that python’s string tokenization rules are reused for
f-literals, even though they aren’t actually strings. could someone please
explain if this is right and if so, why it was chosen to do this instead of
writing more fitting tokenization code?

naively i’d assume f'abc {a['x']} def' to tokenize as something like:

F_BEGIN
  F_STRING_BEGIN "a" "b" "c" " " F_STRING_END
  F_EXPR_START
NAME_START "a" NAME_END
GETITEM_BEGIN STRING_BEGIN "x" STRING_END GETITEM_END
  F_EXPR_END
  F_STRING_BEGIN " " "d" "e" "f" F_STRING_END
F_END

where f-literals are defined as F_START + F_STRING + (F_EXPR + F_STRING)* +
F_END

all of this of course accounting for different delimiters and so on

i consider this important enough to defer f-literals to 3.7 if it can’t get
>> in in time.
>>
>
> I just wanted to let you know, Philipp, that your email comes off as
> somewhat demanding, e.g. "I want this changed". Had you asked why the
> decision was made then your email would not come off as "I'm right and
> you're wrong" and more about you asking for clarification to understand
> why, and then if you still disagreed with the thought process then bring up
> that you think it may have been a mistake.
>

sorry. i just wanted to make my feelings clear since i think this is an
overlooked issue and the time is tight, in hope that maybe someone is
inspired to listen. i thought the PEP’s wording was hint enough to explain
the rationale (convenient reuse of tokenization code)

i’ll patiently await clarification about this, and again: sorry for
sounding demanding :(

-Brett
>

Cheers, Philipp
___
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] Someons's put a "Python 2.8" on GitHub

[Philipp A.]

Paul Moore  schrieb am Sa., 10. Dez. 2016 um 11:38 Uhr:

> Someone has raised an issue against the project at
> https://github.com/naftaliharris/python2.8/issues/47 We should
> probably see what the project owner's response to that is.
>

That would be me, hi.

I really hope this is resolved in a constructive way, without resorting to
lawyers sending cease-and-desist letters. So yeah, please let’s wait!

Also interesting what cropped up as first comment. People seem to be really
emotional about this. But no matter how the transition experience could
have been improved: 8 years are a long time to transition your stuff if you
accept the fact that a transition is necessary. Sorry for bringing this up,
that’s not the right place to discuss this.

Best, Philipp
___
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

[Philipp A.]

I think this particular mess was caused by the hiding of
“DeprecationWarning”s by default: If you don’t see any warnings cropping up
in your production code, you don’t know you have to fix something.

Some languages handle it like this:

   1. Silent deprecation warning (deprecated in docs and/or hidden like in
   Python, the most eagle-eyed maintainers will see it and fix it)
   2. Visible deprecation warning (people start seeing it and bug you in
   issues)
   3. Hide things behind a flag: You’ll have breakage but you get a grace
   perior by enabling some scary looking environment variable or so (nobody
   can deny that things are getting serious)
   4. Removal

Going from 1 to 4 is of course pretty harsh, and this is what we’re doing.

I propose that at least in the future, we have a schedule for every single
deprecation to go to a gradual process like above.

Best, Phil

Am Fr., 31. Jan. 2020 um 05:21 Uhr schrieb Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp>:

> Dima Tisnek writes:
>
>  > I thought that collections compatibility was kept up to 3.8
>  > specifically because py2 was alive.
>  > No that that requirement is gone, so should the shim, right?
>
> Python 2 is still very much alive (even in a Python 3 venv :-þ):
>
> (analysis.venv) 01 16:56$ /usr/bin/python
> Python 2.7.10 (default, Feb 22 2019, 21:55:15)
> [GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> ^D
>
> We have stopped supporting Python 2 in the sense that we are no longer
> going to release source updates to Python 2.  That doesn't necessarily
> mean we don't consider the needs of users who continue to depend on
> Python 2 for one reason or another, excellent or totally (in our
> oh-so-ever-'umble opinion) mistaken though that reason may be.
>
>  > Ofc., my assumption could be just wrong...
>
> It might be, it might not be, it might be situation-dependent (ie,
> decisions should be made case by case on a cost to Python core
> developers versus benefits to Python 2 users and those who support
> them in their libraries etc basis).
>
> I think it would certainly be reasonable to make the decision that
> we're going to go full speed ahead with Python 3 and start stripping
> out Python 2-only features in the stdlib code.  I don't support that,
> but I'm not a core developer, so that's a +1.0e-17 for keeping the
> code.  I get the feeling that Guido is also not in favor of a
> Procrustean[1] approach to Python 2 support in the Python 3 stdlib,
> but I could be wrong.  Since he's not BDFL, that's merely indicative,
> but IMO it's a pretty strong indicator.
>
> What would really distress me however, is if we forget that we're not
> supporting *code*, we're supporting *users* by creating and
> maintaining code.  Of course we can choose that user base, and may
> have to make painful decisions.  But this community is about people
> supporting people, just like any community.
>
> Footnotes:
> [1]  Look up "Procrustes" in Wikipedia.  It's not a story to tell in
> this family setting. ;-)
> ___
> 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/WX4LA55VR35LEAM46WWMQHS2T5DZOZII/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/N5XWYZJEZRSMLG43BAL65YGLXDSVKS6C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] re.findall() should return named tuple

[Philipp A.]

hi devs,

just an idea that popped up in my mind: re.findall() returns a list of
tuples, where every entry of each tuple represents a match group.
since match groups can be named, we are able to use named tuples instead of
plain tuples here, in the same fashion as namedtuple’s rename works:
misssing group names get renamed to _1 and so on. i suggest to add the
rename keyword option, to findall, defaulting to True, since mixed
positional and named tuples are more common than in usual use cases of
namedtuple.

do you think it’s a good idea?

finally: should i join the mailing list to see answers? should i file a
PEP? i have no idea how the inner workings of python development are, but i
wanted to share this idea with you :)

thanks for keeping python great,
philipp
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com