The Python stdlib allows override of sys.ps1/ps2 (to make IPython-like dynamic prompts and so on).  I believe it would be a good idea to
support this in doctest too, to cover cases when given application
uses different from defaults settings for the interpreter.

Probably, we could add ps1/2 optional arguments for DoctestParser.__init__().

Some projects already patch doctest module for this, e.g. IPython:
https://github.com/ipython/ipython/blob/master/IPython/testing/plugin/ipdoctest.py
It shouldn't be too hard to port this feature.

Tim, what do you say, feature or feature creep, straightforward patch or can of worms?

doctest was intended to deal with the standard CPython terminal shell.  I'd like to keep it that way, but recognize that everyone wants to change everything into "a framework" ;-)

How many other shells are there?  As Sergey linked to, IPython already dealt with its shell conventions, and PS1/PS2 differences account for a relatively tiny amount of the 600+ lines of IPython-customization code they'd need anyway.  That is, I don't see that this would be of much value to IPython.

So people who "need" this already figured out how to do this - and there aren't many of them anyway.  I'd leave it alone.

> doctest was intended to deal with the standard CPython terminal shell.  I'd like to keep it that way

The point is: ps1/ps2 customization could be considered as part of the standard shell.  If stdlib allow such changes - doctest module should take this into account.

Sergey, I understand that, but I don't care.  The only people I've ever seen _use_ this are people writing an entirely different shell interface.  They're rare.  There's no value in complicating doctest to cater to theoretical use cases that don't exist - to the contrary, that's counterproductive complication.

As your IPython example showed, their job is harder than _just_ replacing PS1/PS2.  See their `parse()` function.  They want to cater both to IPython's PS1/PS2 conventions _and_ to the standard CPython terminal shell PS1/PS2 conventions.

But they don't cater to _more_ than just those either.  Why should they?  Same thing here:  extra complication for no good reason.

> are people writing an entirely different shell interface.  They're rare.

Or just using a different shell interface.  Or even different defaults for the standard shell...

And they are not rare.  Almost nobody in reality use CPython shell - that's definitely true for scientific applications of Python, data scientists, etc.

> As your IPython example showed, their job is harder than _just_ replacing PS1/PS2.

Yes, custom shells have much more stuff (In/Out arrays, etc), but changing PS1/PS2 - require very tiny modifications for doctest.  And such changes - almost all that usually prevent using standard doctest for testing examples, written for applications, which assume "a different shell interface" (which, I remind, may be just a plain CPython shell with customized ps1/ps2).

You missed my point about IPython:  forget "In/Out arrays, etc".  What you suggest is inadequate for _just_ changing PS1/PS2 for IPython.  Again, read their `parse()` function.  They support _more than one_ set of PS1/PS2 conventions.  So the code changes you suggest wouldn't help them.  So long as they want to support more than one set, they'd still have to write their own `parse()` function just to deal with multiple PS1/PS2 conventions.

For the rest, it's not the number of people using non-CPython shells that's rare, but the number _of_ non-CPython shells.  IPython is popular, they already solved their problem, and the patch wouldn't help them anyway.  Who would it help?

I don't take "a plain CPython shell with customized ps1/ps2" seriously because, as I said, after some decades now I still don't know of anyone who does that (granting that newbies sometimes try it, go 'ha! ha! - cool!", and never try it again).  If any such people exist, I would oppose changing doctest just for them, because the _point_ of doctest is to help write easily understood tests.  Catering to changing shell syntax in random ways opposes that goal - programming is a social activity.

So, sorry, but I remain opposed.  Something that might change my mind:  find an author of a widely used alternative Python shell who says this change would allow them to _remove_ their own doctest-PS1/PS2 customization code.  That would be a real use case.

> They support _more than one_ set of PS1/PS2 conventions.

I saw this, not sure if that's required.  IMHO, same effect should be possible by running doctest several times with different conventions.

> Who would it help?

In principle, any project, that uses some custom shell (i.e. IPython) per default.  I believe, "easily understood tests" should start with prompts that users could easily recognise.

> Something that might change my mind:  find an author of a widely used alternative Python shell who says this change would allow them to _remove_ their own doctest-PS1/PS2 customization code.  That would be a real use case.

I admit, exactly this use case I can't provide right now.

Thank you for the suggestion, but per the discussion with Tim, I am closing as rejected.

nosy: + cheryl.sabella
messages: + msg342281

resolution: rejected
stage: patch review -> resolved

messages: + msg317801

assignee: tim.peters
type: enhancement