[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

[Guido van Rossum]

On Tue, May 11, 2021 at 4:07 PM Gregory P. Smith  wrote:

>
>
> On Tue, May 11, 2021 at 3:33 PM Mike Miller 
> wrote:
>
>>
>> On 5/11/21 1:57 AM, Baptiste Carvello wrote:
>> > Le 11/05/2021 à 09:35, Steven D'Aprano a écrit :
>> >> On Mon, May 10, 2021 at 09:44:05PM -0400, Terry Reedy wrote:
>> >>
>> >>> The vanilla interpreter could be updated to recognize when it is
>> running
>> >>> on a similated 35-year-old terminal that implements ansi-vt100 color
>> >>> codes rather than a similated 40+-year-old black-and-white
>> teletype-like
>> >>> terminal.
>> >>
>> >> This is what is called "scope creep", although in this case
>> >> perhaps "scope gallop" is more appropriate *wink*
>> >> [...]
>> >
>> > Also: people paste tracebacks into issue reports, so all information has
>> > to survive copy-pasting.
>> >
>>
>> The first ANSI standard supported underlined text, didn't it?  The VT100
>> did.
>> That would make it part of the 40+ year old subset from the late 70's.
>>
>> While color might stand out more, underline suits the problem well, also
>> without
>> increasing the line count.
>>
>> There are a number of terminal emulators that support rich text copies,
>> but not
>> all of them.  This is added information however, so it not being
>> copy-pastable
>> everywhere shouldn't be a blocking requirement imho.
>>
>
> fancier REPL frontends have supported things like highlighting and such in
> their tracebacks, I expect they'll adopt column information and render it
> as such.
>
> There's a difference between tracebacks dumped as plain text (utf-8) by
> traceback.print_exc() appearing on stderr or directed into log files and
> what can be displayed within a terminal.  It is highly unusual to emit
> terminal control characters into log files.
>

And yet it happens all the time. :-( Let's not risk that happening.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/ZR4VCUXV4GQB2KT2MFWNLJ7I4YXLZGMN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

[Gregory P. Smith]

On Tue, May 11, 2021 at 3:33 PM Mike Miller  wrote:

>
> On 5/11/21 1:57 AM, Baptiste Carvello wrote:
> > Le 11/05/2021 à 09:35, Steven D'Aprano a écrit :
> >> On Mon, May 10, 2021 at 09:44:05PM -0400, Terry Reedy wrote:
> >>
> >>> The vanilla interpreter could be updated to recognize when it is
> running
> >>> on a similated 35-year-old terminal that implements ansi-vt100 color
> >>> codes rather than a similated 40+-year-old black-and-white
> teletype-like
> >>> terminal.
> >>
> >> This is what is called "scope creep", although in this case
> >> perhaps "scope gallop" is more appropriate *wink*
> >> [...]
> >
> > Also: people paste tracebacks into issue reports, so all information has
> > to survive copy-pasting.
> >
>
> The first ANSI standard supported underlined text, didn't it?  The VT100
> did.
> That would make it part of the 40+ year old subset from the late 70's.
>
> While color might stand out more, underline suits the problem well, also
> without
> increasing the line count.
>
> There are a number of terminal emulators that support rich text copies,
> but not
> all of them.  This is added information however, so it not being
> copy-pastable
> everywhere shouldn't be a blocking requirement imho.
>

fancier REPL frontends have supported things like highlighting and such in
their tracebacks, I expect they'll adopt column information and render it
as such.

There's a difference between tracebacks dumped as plain text (utf-8) by
traceback.print_exc() appearing on stderr or directed into log files and
what can be displayed within a terminal.  It is highly unusual to emit
terminal control characters into log files.

-G


>
> -Mike
> ___
> 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/W44D2BWWICNJTWPQOZUWVQEIJ6T3QWYM/
> 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/7AQFQOCZCN44ML3UDY5RNWJJHOEDS4JN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

[Mike Miller]

On 5/11/21 1:57 AM, Baptiste Carvello wrote:

Le 11/05/2021 à 09:35, Steven D'Aprano a écrit :

On Mon, May 10, 2021 at 09:44:05PM -0400, Terry Reedy wrote:


The vanilla interpreter could be updated to recognize when it is running
on a similated 35-year-old terminal that implements ansi-vt100 color
codes rather than a similated 40+-year-old black-and-white teletype-like
terminal.


This is what is called "scope creep", although in this case
perhaps "scope gallop" is more appropriate *wink*
[...]


Also: people paste tracebacks into issue reports, so all information has
to survive copy-pasting.



The first ANSI standard supported underlined text, didn't it?  The VT100 did. 
That would make it part of the 40+ year old subset from the late 70's.


While color might stand out more, underline suits the problem well, also without 
increasing the line count.


There are a number of terminal emulators that support rich text copies, but not 
all of them.  This is added information however, so it not being copy-pastable 
everywhere shouldn't be a blocking requirement imho.


-Mike
___
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/W44D2BWWICNJTWPQOZUWVQEIJ6T3QWYM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: python-iterators mailing list on SourceForge

[Thomas Grainger]

it might be possible to recover the account by contacting  
sfnet_...@slashdotmedia.com
___
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/QYNRUGSRE44ZJEPD7EWJHB7KMMNU32HZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: python-iterators mailing list on SourceForge

[Guido van Rossum]

I doubt that anyone has the keys to the python project on sourceforge any
more... :-( We've abandoned that platform nearly two decades ago.

On Mon, May 10, 2021 at 11:40 PM Julien Palard via Python-Dev <
python-dev@python.org> wrote:

> Hi,
>
> PEP 234 mention
> https://sourceforge.net/p/python/mailman/python-iterators/ but the
> project mailing list archives are marked as "hidden".
>
> Looks like projects admin and developers can get the "hidden link", but
> I think it would be nice to "unhide" the archives if someone is still
> admin there and if it's possible, to "unbreak" the link from the PEP.
>
> Bests,
> --
> [Julien Palard](https://mdk.fr)
>
> ___
> 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/SN5RMHWBWKRRP5ZKONKERJY3VQODRZMT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/WI47JF6UBPEMAUK5S4QTNQCPVULMZPPA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

[Baptiste Carvello]

Le 11/05/2021 à 09:35, Steven D'Aprano a écrit :
> On Mon, May 10, 2021 at 09:44:05PM -0400, Terry Reedy wrote:
> 
>> The vanilla interpreter could be updated to recognize when it is running 
>> on a similated 35-year-old terminal that implements ansi-vt100 color 
>> codes rather than a similated 40+-year-old black-and-white teletype-like 
>> terminal.
> 
> This is what is called "scope creep", although in this case 
> perhaps "scope gallop" is more appropriate *wink*
> [...]

Also: people paste tracebacks into issue reports, so all information has
to survive copy-pasting.

Cheers,
Baptiste
___
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/U2U44ZB3HFBAD3TGJ5X7Q3P6QCAIRYG2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Using FutureWarning for last version before deletion.

[Petr Viktorin]

On 11. 05. 21 11:08, Inada Naoki wrote:

On Tue, May 11, 2021 at 5:30 PM Petr Viktorin  wrote:


Test tools should treat DeprecationWarning as error by default [0][1].
So even if end users don't really see it, I don't consider it "hidden".



*should* is not *do*. For example, nosetests don't show DeprecationWarning.
And there are many scripts without tests.

So it is hidden for some people.



Sadly, there's not much we can do for users of nose. Nose itself is only 
tested with Python 3.5 and below.


I'm aware that there are scripts without tests. But maybe letting them 
suddenly break is the right balance between letting people know and 
annyoing everyone with unactionable warnings.


If DeprecationWarning is not enough, then we should be having a wider 
discussion, and PEP 387 should change. This particular issue should not 
be an exception to the process.


___
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/FWFZWMSWWV5KNM3LSU5NQCSDO7YLUARU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Using FutureWarning for last version before deletion.

[Antoine Pitrou]

On Tue, 11 May 2021 10:25:38 +0200
Petr Viktorin  wrote:
> On 10. 05. 21 10:53, Inada Naoki wrote:
> > Hi, folks.
> > 
> > Now Python 3.11 development is open and I am removing some deprecated
> > stuffs carefully.
> > 
> > I am considering `configparser.ParseError.filename` property that is
> > deprecated since Python 3.2.
> > https://github.com/python/cpython/blob/8e8307d70bb9dc18cfeeed3277c076309b27515e/Lib/configparser.py#L315-L333
> > 
> > My random thoughts about it:
> > 
> > * It has been deprecated long enough.
> > * But the maintenance burden is low enough.
> > * If we don't remove long deprecated stuff like this, Python 4.0 will
> > be a big breaking change.
> > 
> > My proposal:
> > 
> > * Change DeprecationWarning to FutureWarning and wait one more version.
> >* DeprecationWarning is suppressed by default to hide noise from end 
> > users.
> >* But sudden breaking change is more annoying to end users.
> > 
> > I am not proposing to change PEP 387 "Backwards Compatibility Policy".
> > This is just a new convention.  
> 
> Test tools should treat DeprecationWarning as error by default [0][1].
> So even if end users don't really see it, I don't consider it "hidden".

Several data science libraries emit FutureWarning rather than
DeprecationWarning for the reason that DeprecationWarning is silenced
by default.  So, yes, it is a real problem.

Regards

Antoine.


___
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/HSGO5IUNNRDXO2U26UMXXIMJJDWTCYYA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Using FutureWarning for last version before deletion.

[Inada Naoki]

On Tue, May 11, 2021 at 5:30 PM Petr Viktorin  wrote:
>
> Test tools should treat DeprecationWarning as error by default [0][1].
> So even if end users don't really see it, I don't consider it "hidden".
>

*should* is not *do*. For example, nosetests don't show DeprecationWarning.
And there are many scripts without tests.

So it is hidden for some people.

-- 
Inada Naoki  
___
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/GO7LZDHH4PEB57FRH4XHZZNZACWP5SRG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Using FutureWarning for last version before deletion.

[Petr Viktorin]

On 10. 05. 21 10:53, Inada Naoki wrote:

Hi, folks.

Now Python 3.11 development is open and I am removing some deprecated
stuffs carefully.

I am considering `configparser.ParseError.filename` property that is
deprecated since Python 3.2.
https://github.com/python/cpython/blob/8e8307d70bb9dc18cfeeed3277c076309b27515e/Lib/configparser.py#L315-L333

My random thoughts about it:

* It has been deprecated long enough.
* But the maintenance burden is low enough.
* If we don't remove long deprecated stuff like this, Python 4.0 will
be a big breaking change.

My proposal:

* Change DeprecationWarning to FutureWarning and wait one more version.
   * DeprecationWarning is suppressed by default to hide noise from end users.
   * But sudden breaking change is more annoying to end users.

I am not proposing to change PEP 387 "Backwards Compatibility Policy".
This is just a new convention.


Test tools should treat DeprecationWarning as error by default [0][1].
So even if end users don't really see it, I don't consider it "hidden".

Waiting one more release sounds reasonable to me, but for a slightly 
different reason: the warning should list the version the feature will 
be removed in: "3.12" rather than "future versions".



Another idea: would it be worth it to create "What's new" pages for 3.12 
and 3.13 already and fill them with planned removals? (Of course they'd 
need to be de-emphasized in the table of contents.)



[0]: 
https://www.python.org/dev/peps/pep-0565/#recommended-filter-settings-for-test-runners
[1]: 
https://docs.pytest.org/en/latest/how-to/capture-warnings.html#deprecationwarning-and-pendingdeprecationwarning

___
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/L73YDIYZLA5JVAP3FYWTJJH6NMBZL5OJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

[Steven D'Aprano]

On Mon, May 10, 2021 at 09:44:05PM -0400, Terry Reedy wrote:

> The vanilla interpreter could be updated to recognize when it is running 
> on a similated 35-year-old terminal that implements ansi-vt100 color 
> codes rather than a similated 40+-year-old black-and-white teletype-like 
> terminal.

This is what is called "scope creep", although in this case 
perhaps "scope gallop" is more appropriate *wink*

Supporting coloured output out of the box would be nice but if we want 
to do it properly, we would have to support at least ANSI-compatible 
terminals and Windows. And once we support it in tracebacks, you know 
people will say "if Python can print coloured text in a traceback, why 
can't I print coloured text in my own output?" and so that's going to 
rapidly end up needing something like colorama.

-- 
Steve
___
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/2N2IOBTUSCZQVZSCPSDHKBCR5UCKXGC2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] python-iterators mailing list on SourceForge

[Julien Palard via Python-Dev]

Hi,

PEP 234 mention
https://sourceforge.net/p/python/mailman/python-iterators/ but the
project mailing list archives are marked as "hidden".

Looks like projects admin and developers can get the "hidden link", but
I think it would be nice to "unhide" the archives if someone is still
admin there and if it's possible, to "unbreak" the link from the PEP.

Bests,
--
[Julien Palard](https://mdk.fr)

___
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/SN5RMHWBWKRRP5ZKONKERJY3VQODRZMT/
Code of Conduct: http://python.org/psf/codeofconduct/