[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Paul Moore]

On Sun, 27 Mar 2022 at 00:52, Ethan Furman  wrote:
>
> [apologies for the late post, just found this in my drafts folder]
>
> On 2/7/22 12:49 AM, Stéfane Fermigier wrote:
>
> > 3. Overall, I think the days where "battery included" was a positive 
> > argument are over
>
> I strongly disagree.  Being able to download something and immediately get 
> something to work and see results is hugely
> rewarding; on the other hand, having to research, find, compare & contrast 
> available third-party modules (especially for
> new-comers) can be extremely discouraging.

100% agreed.

I think people massively underestimate how frustrating it can be to
have to hunt out some piece of functionality that *doesn't* come with
the base download. Or worse, to find 5 different implementations, and
have no idea which one you "should" use.

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

[Python-Dev] Re: Changing unittest verbose output.

[Jelle Zijlstra]

El sáb, 26 mar 2022 a las 17:51, Itay Yeshaya ()
escribió:

>
> Any thoughts on the mentioned solutions?
>

This is a bit more out there, but can anyone explain why we show the
docstring at all? As far as I can tell it causes a bunch of confusion and
helps little. If there's a failing test, I want the test name so I can
quickly find it in the code; I don't want the docstring which may not even
be unique.


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

[Python-Dev] Re: Changing unittest verbose output.

[Eric V. Smith]

On 3/27/2022 10:51 AM, Jelle Zijlstra wrote:



El sáb, 26 mar 2022 a las 17:51, Itay Yeshaya 
() escribió:



Any thoughts on the mentioned solutions?


This is a bit more out there, but can anyone explain why we show the 
docstring at all? As far as I can tell it causes a bunch of confusion 
and helps little. If there's a failing test, I want the test name so I 
can quickly find it in the code; I don't want the docstring which may 
not even be unique.


I think this is a good idea. The target audience for a docstring isn't 
the people trying to track down failing tests.


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

[Python-Dev] Re: Changing unittest verbose output.

[Guido van Rossum]

I recall actually really liking the docstring. I think there are situations
where the test name just can't be sufficiently explanatory. IIRC in the
past we didn't print the docstring at all and it felt right when it was
added.

ATM I'm not using unittest for anything so I don't have a strong opinion.

On Sun, Mar 27, 2022 at 8:21 AM Eric V. Smith  wrote:

> On 3/27/2022 10:51 AM, Jelle Zijlstra wrote:
>
>
>
> El sáb, 26 mar 2022 a las 17:51, Itay Yeshaya ()
> escribió:
>
>>
>> Any thoughts on the mentioned solutions?
>>
>
> This is a bit more out there, but can anyone explain why we show the
> docstring at all? As far as I can tell it causes a bunch of confusion and
> helps little. If there's a failing test, I want the test name so I can
> quickly find it in the code; I don't want the docstring which may not even
> be unique.
>
>
> I think this is a good idea. The target audience for a docstring isn't the
> people trying to track down failing tests.
>
> Eric
> ___
> 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/BTF4LZWVTHNHBJVNHXNWSPB2WS4324TO/
> 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/LIZB53G6YT4NXEIWTPVP5BIPDWUC4S26/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Christopher Barker]

On Sun, Mar 27, 2022 at 3:08 AM Paul Moore  wrote:

> > > 3. Overall, I think the days where "battery included" was a positive
> argument are over
> >
> > I strongly disagree.  Being able to download something and immediately
> get something to work and see results is hugely
> > rewarding; on the other hand, having to research, find, compare &
> contrast available third-party modules (especially for
> > new-comers) can be extremely discouraging.
>

exactly - let's say someone needs to write some JSON for the first time.

With the json package included, all they need to do is `import json`. If
that wasn't there, they's look in PyPi for a JSON implementation, and find
an absolutely astonishing number of options. I just did a search for "JSON"
 on PYPI, and it's HUGE -- most of them are for specialized JSON-using
protocols of some sort. I was actually really surprised that couple I know
about of the top of my head (ujson, orjson) are actually hard to find.

"You can just pip install it" is really not a good solution.

In fact, this is an example, I think, of where we should put some effort
into making the included batteries better -- it's great to have a JSON lib
built in, but it's too bad that it's not best-of-bread by pretty much any
definition (speed, memory performance, flexibility) -- there are quite a
few feature requests open for it -- it would be nice to
actually implement some of those. (but yes, that's a lot of work that
someone(s) would have to do)

Back to the topic at hand, rather than remove urllib, maybe it could be
made better -- an as-easy-to-use-as-requests package in the stdlib would be
really great.

-CHB

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/SK67KYZN7PG6PN7JNU74SX2INC3FGKOZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[lincoln auster [they/them]]

> Back to the topic at hand, rather than remove urllib, maybe it could
> be made better -- an as-easy-to-use-as-requests package in the stdlib
> would be really great.

Agreed. I think one thing that's easy to forget is that Python is useful
not just for very large applications but also for your standard tiny
one-off scripts (i.e., cron jobs and the like). The big standard library
is indispensible for writing clean code in those somewhat inherently
hacky situations. Note that this isn't really unique to Python. If we
look across the landscape for scripting lanugages useful in the same
areas, Bash stands out as being a bit of an odd language on its own, but
one that pairs well with all your traditional UNIX tools. These tools
make for a decently capable 'standard library', and Bash a surprisingly
versatile tool. My point obviously isn't that Python is or should be
Bash, but that Python gets a tangible benefit from its batteries in much
the same way as Bash gets a benefit from sed, awk, &c. Namely, these
languages are both made so much more /versatile/ by their respective
included tools. Being able to count on some common problems *just being
solved already* is a highly appreciated language feature, and something
I'd love to see stable and supported going forward.

So, let's not remove urllib. The fact that we're having this discussion
indicates that the scope of urllib is somewhat undefined, so perhaps it
would benefit from a firm and semi-formal (re)definition of scope
(hopefully in a manner motivated by real code). After that, it would
probably benefit from patching up all the rough spots in the
implementation side of things. To keep the metaphor going, let's
recharge our dead batteries.

-- 
lincoln auster
they/them


As an aside, I've opened PR#30520 on the CPython repo, which makes
urllib.urlparse less dependent on the hard-coded list of schemes it uses
to determine parsing behavior. In the interest of recharging batteries,
would anyone be willing to review that? @orsenthil volunteered a while
back, but with all of my first-PR issues, it's sort of stalled.
___
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/FR4AGGHFUQ3XUHUG3Q3QF7PAO6HJ3CJI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Changing unittest verbose output.

[Eric V. Smith]

> On Mar 27, 2022, at 11:20 AM, Eric V. Smith  wrote:
> 
> 
> On 3/27/2022 10:51 AM, Jelle Zijlstra wrote:
>> 
>> 
>> El sáb, 26 mar 2022 a las 17:51, Itay Yeshaya () 
>> escribió:
>>> 
>>> Any thoughts on the mentioned solutions?
>> 
>> This is a bit more out there, but can anyone explain why we show the 
>> docstring at all? As far as I can tell it causes a bunch of confusion and 
>> helps little. If there's a failing test, I want the test name so I can 
>> quickly find it in the code; I don't want the docstring which may not even 
>> be unique.
>>  
> I think this is a good idea. The target audience for a docstring isn't the 
> people trying to track down failing tests.
> 
I’m wrong about the docstrings having a different audience. So I’m going to 
retract my support here. 

Eric

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

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Paul Moore]

On Sun, 27 Mar 2022 at 17:11, Christopher Barker  wrote:
>
> With the json package included, all they need to do is `import json`. If that 
> wasn't there, they's look in PyPi for a JSON implementation, and find an 
> absolutely astonishing number of options. I just did a search for "JSON"
>  on PYPI, and it's HUGE -- most of them are for specialized JSON-using 
> protocols of some sort. I was actually really surprised that couple I know 
> about of the top of my head (ujson, orjson) are actually hard to find.
>
> "You can just pip install it" is really not a good solution.
>
> In fact, this is an example, I think, of where we should put some effort into 
> making the included batteries better -- it's great to have a JSON lib built 
> in, but it's too bad that it's not best-of-bread by pretty much any 
> definition (speed, memory performance, flexibility) -- there are quite a few 
> feature requests open for it -- it would be nice to actually implement some 
> of those. (but yes, that's a lot of work that someone(s) would have to do)
>
> Back to the topic at hand, rather than remove urllib, maybe it could be made 
> better -- an as-easy-to-use-as-requests package in the stdlib would be really 
> great.

I think that's where the mistake happens, though. Someone who needs
"best of breed" is motivated (and likely knowledgeable enough) to make
informed decisions about what's on PyPI. But someone who just wants to
get the job done probably doesn't - and that's the audience for the
stdlib. A stdlib module needs to be a good, reliable set of basic
functionality that non-experts can use successfully. There can be
better libraries on PyPI, but that doesn't mean the stdlib module is
unnecessary, nor does it mean that the stdlib has to match the PyPI
library feature for feature.

So here, specifically, I'd rather see urlllib be the best urlllib it
can be, and not demand that it turn into requests. Requests is there
if people need/want it (as is httpx, and urllib3, and aiohttp). But
urllib is for people who want to get a file from the web, and *not*
have to deal with dependencies, 3rd party libraries, etc.

The "batteries included" standard library and PyPI complement each
other. Neither is redundant, and neither implies the other is
unnecessary.

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

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Steve Holden]

Time for a __legacy__ package?

Kind regards,
Steve


On Sun, Mar 27, 2022 at 7:06 PM Paul Moore  wrote:

> On Sun, 27 Mar 2022 at 17:11, Christopher Barker 
> wrote:
> >
> > With the json package included, all they need to do is `import json`. If
> that wasn't there, they's look in PyPi for a JSON implementation, and find
> an absolutely astonishing number of options. I just did a search for "JSON"
> >  on PYPI, and it's HUGE -- most of them are for specialized JSON-using
> protocols of some sort. I was actually really surprised that couple I know
> about of the top of my head (ujson, orjson) are actually hard to find.
> >
> > "You can just pip install it" is really not a good solution.
> >
> > In fact, this is an example, I think, of where we should put some effort
> into making the included batteries better -- it's great to have a JSON lib
> built in, but it's too bad that it's not best-of-bread by pretty much any
> definition (speed, memory performance, flexibility) -- there are quite a
> few feature requests open for it -- it would be nice to actually implement
> some of those. (but yes, that's a lot of work that someone(s) would have to
> do)
> >
> > Back to the topic at hand, rather than remove urllib, maybe it could be
> made better -- an as-easy-to-use-as-requests package in the stdlib would be
> really great.
>
> I think that's where the mistake happens, though. Someone who needs
> "best of breed" is motivated (and likely knowledgeable enough) to make
> informed decisions about what's on PyPI. But someone who just wants to
> get the job done probably doesn't - and that's the audience for the
> stdlib. A stdlib module needs to be a good, reliable set of basic
> functionality that non-experts can use successfully. There can be
> better libraries on PyPI, but that doesn't mean the stdlib module is
> unnecessary, nor does it mean that the stdlib has to match the PyPI
> library feature for feature.
>
> So here, specifically, I'd rather see urlllib be the best urlllib it
> can be, and not demand that it turn into requests. Requests is there
> if people need/want it (as is httpx, and urllib3, and aiohttp). But
> urllib is for people who want to get a file from the web, and *not*
> have to deal with dependencies, 3rd party libraries, etc.
>
> The "batteries included" standard library and PyPI complement each
> other. Neither is redundant, and neither implies the other is
> unnecessary.
>
> Paul
> ___
> 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/E2FGXTYOEYLC6GSJGMWBQKHOO62LZPHQ/
> 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/XGHKV3G5PJO3U4B6QTZRZSXIPNC4XDCL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Dan Stromberg]

On Sat, Mar 26, 2022 at 5:58 PM Ethan Furman  wrote:

> [apologies for the late post, just found this in my drafts folder]
>
> On 2/7/22 12:49 AM, Stéfane Fermigier wrote:
>
> > 3. Overall, I think the days where "battery included" was a positive
> argument are over
>
> I strongly disagree.  Being able to download something and immediately get
> something to work and see results is hugely
> rewarding; on the other hand, having to research, find, compare & contrast
> available third-party modules (especially for
> new-comers) can be extremely discouraging.
>

It might make sense to have CPython's release cadence decoupled from the
Standard Library's release cadence.  That is, maybe they should be separate
downloads.
___
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/Y2FXUA643E7DJPKHPFGMI3IVC2PWTVKN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[MRAB]

On 2022-03-27 19:52, Dan Stromberg wrote:


On Sat, Mar 26, 2022 at 5:58 PM Ethan Furman > wrote:


[apologies for the late post, just found this in my drafts folder]

On 2/7/22 12:49 AM, Stéfane Fermigier wrote:

 > 3. Overall, I think the days where "battery included" was a
positive argument are over

I strongly disagree.  Being able to download something and
immediately get something to work and see results is hugely
rewarding; on the other hand, having to research, find, compare &
contrast available third-party modules (especially for
new-comers) can be extremely discouraging.


It might make sense to have CPython's release cadence decoupled from the 
Standard Library's release cadence.  That is, maybe they should be 
separate downloads.


On the other hand, it's nice to get it all in one go. Perhaps the 
installer could gain controls to download optional parts of the standard 
library or update those parts that have been installed.

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

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[lincoln auster [they/them]]

> On the other hand, it's nice to get it all in one go. Perhaps the
> installer could gain controls to download optional parts of the
> standard library or update those parts that have been installed.

I'm not sure the proposed is really a standard library if it's
distributed like that. If a given script cannot rely on the presence of
some given module --- one which may need to be installed as though it
were just another 3rd-party component --- then it's not really all that
standard, is it?

-- 
Lincoln Auster
they/them
___
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/OZSDKTLIGHSNQY32ZIX3B2ALSB4CARAM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Barry Warsaw]

On Mar 27, 2022, at 11:52, Dan Stromberg  wrote:
> 
> It might make sense to have CPython's release cadence decoupled from the 
> Standard Library's release cadence.  That is, maybe they should be separate 
> downloads.

While I don’t underestimate the work and complexity, we can do both.  I.e. 
separate the stdlib development cycle from the interpreter (for all but a 
handful of required packages perhaps).  We could still distribute “sumo” 
releases which include all the batteries, but develop and maintain them outside 
the cpython repo, and even release them separately on PyPI.  It’s *possible* 
but I don’t know if it’s *practical*.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/YSOF6Z66W5P7C5A6PPLOLFV4WH72YA3S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Changing unittest verbose output.

[Barry Warsaw]

On Mar 26, 2022, at 17:48, Itay Yeshaya  wrote:
> 
> When running unittest with the -v flag, if a test has errors, and has a 
> docstring, the test name is shown on one line, and the docstring is shown on 
> the next line with the `ERROR` word.

This has been a long-standing nuisance, but I’m like Guido.  I pretty much use 
pytest for everything these days, except for maybe unittest.mock.patch.

-Barry




signature.asc
Description: Message signed with OpenPGP
___
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/ZIMXSRQMWFOE4U3C3MBK6SG5TH26PDRL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Changing unittest verbose output.

[Gregory P. Smith]

For many of us, this isn't a nuisance. It is a desirable feature.

test_xxx functions and methods typically don't have docstrings at all as
the majority of tests tend to be concise and obvious with the function name
itself describes what its purpose is.  When we added printing the
docstring, it was useful, as you can expand upon the purpose of the test
more than you can in a reasonable name within the docstring.  We do this
all the many times in our own test suite.  When running the tests, you see
the docstring and are given more context as to what the test is about.
This can be useful when triaging a failure before you've even loaded the
source.

I don't doubt that someone writes thesis defenses and stores them in their
TestCase.test_method docstrings. I'm just saying that is not the norm.

I'd accept a PR adding another command line switch for unittest to disable
docstring printing in verbose mode.

-gps


On Sun, Mar 27, 2022 at 12:59 PM Barry Warsaw  wrote:

> On Mar 26, 2022, at 17:48, Itay Yeshaya  wrote:
> >
> > When running unittest with the -v flag, if a test has errors, and has a
> docstring, the test name is shown on one line, and the docstring is shown
> on the next line with the `ERROR` word.
>
> This has been a long-standing nuisance, but I’m like Guido.  I pretty much
> use pytest for everything these days, except for maybe unittest.mock.patch.
>
> -Barry
>
>
> ___
> 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/ZIMXSRQMWFOE4U3C3MBK6SG5TH26PDRL/
> 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/RJOWQWMMUMBJAZZTWXWEAJSRDVARA2XL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Changing unittest verbose output.

[Guido van Rossum]

Hopefully it only prints the first line of the docstring?

On Sun, Mar 27, 2022 at 2:42 PM Gregory P. Smith  wrote:

> For many of us, this isn't a nuisance. It is a desirable feature.
>
> test_xxx functions and methods typically don't have docstrings at all as
> the majority of tests tend to be concise and obvious with the function name
> itself describes what its purpose is.  When we added printing the
> docstring, it was useful, as you can expand upon the purpose of the test
> more than you can in a reasonable name within the docstring.  We do this
> all the many times in our own test suite.  When running the tests, you see
> the docstring and are given more context as to what the test is about.
> This can be useful when triaging a failure before you've even loaded the
> source.
>
> I don't doubt that someone writes thesis defenses and stores them in their
> TestCase.test_method docstrings. I'm just saying that is not the norm.
>
> I'd accept a PR adding another command line switch for unittest to disable
> docstring printing in verbose mode.
>
> -gps
>
>
> On Sun, Mar 27, 2022 at 12:59 PM Barry Warsaw  wrote:
>
>> On Mar 26, 2022, at 17:48, Itay Yeshaya  wrote:
>> >
>> > When running unittest with the -v flag, if a test has errors, and has a
>> docstring, the test name is shown on one line, and the docstring is shown
>> on the next line with the `ERROR` word.
>>
>> This has been a long-standing nuisance, but I’m like Guido.  I pretty
>> much use pytest for everything these days, except for maybe
>> unittest.mock.patch.
>>
>> -Barry
>>
>>
>> ___
>> 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/ZIMXSRQMWFOE4U3C3MBK6SG5TH26PDRL/
>> 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/RJOWQWMMUMBJAZZTWXWEAJSRDVARA2XL/
> 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/6GKOOGDXGHND57VTM2FNVTXOS2H4PCUF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Changing unittest verbose output.

[Gregory P. Smith]

On Sun, Mar 27, 2022 at 2:50 PM Guido van Rossum  wrote:

> Hopefully it only prints the first line of the docstring?
>

Indeed, it's just the first line (traditionally a one line summary per
style).

https://github.com/python/cpython/blob/f6b3a07b7df60dc04d0260169ffef6e9796a2124/Lib/unittest/runner.py#L46


>
> On Sun, Mar 27, 2022 at 2:42 PM Gregory P. Smith  wrote:
>
>> For many of us, this isn't a nuisance. It is a desirable feature.
>>
>> test_xxx functions and methods typically don't have docstrings at all as
>> the majority of tests tend to be concise and obvious with the function name
>> itself describes what its purpose is.  When we added printing the
>> docstring, it was useful, as you can expand upon the purpose of the test
>> more than you can in a reasonable name within the docstring.  We do this
>> all the many times in our own test suite.  When running the tests, you see
>> the docstring and are given more context as to what the test is about.
>> This can be useful when triaging a failure before you've even loaded the
>> source.
>>
>> I don't doubt that someone writes thesis defenses and stores them in
>> their TestCase.test_method docstrings. I'm just saying that is not the norm.
>>
>> I'd accept a PR adding another command line switch for unittest to
>> disable docstring printing in verbose mode.
>>
>> -gps
>>
>>
>> On Sun, Mar 27, 2022 at 12:59 PM Barry Warsaw  wrote:
>>
>>> On Mar 26, 2022, at 17:48, Itay Yeshaya  wrote:
>>> >
>>> > When running unittest with the -v flag, if a test has errors, and has
>>> a docstring, the test name is shown on one line, and the docstring is shown
>>> on the next line with the `ERROR` word.
>>>
>>> This has been a long-standing nuisance, but I’m like Guido.  I pretty
>>> much use pytest for everything these days, except for maybe
>>> unittest.mock.patch.
>>>
>>> -Barry
>>>
>>>
>>> ___
>>> 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/ZIMXSRQMWFOE4U3C3MBK6SG5TH26PDRL/
>>> 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/RJOWQWMMUMBJAZZTWXWEAJSRDVARA2XL/
>> 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/YULIAATNZVWHHJEASJY3P5UMC4G7ZIPC/
Code of Conduct: http://python.org/psf/codeofconduct/