| msg312053 - (view) |
Author: Sergey B Kirpichev (Sergey.Kirpichev) * |
Date: 2018-02-12 13:49 |
| 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. |
|
|
| msg317801 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2018-05-27 18:00 |
| Tim, what do you say, feature or feature creep, straightforward patch or can of worms? |
|
|
| msg317803 - (view) |
Author: Tim Peters (tim.peters) * |
Date: 2018-05-27 18:27 |
| 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. |
|
|
| msg317805 - (view) |
Author: Sergey B Kirpichev (Sergey.Kirpichev) * |
Date: 2018-05-27 18:37 |
| > 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. |
|
|
| msg317806 - (view) |
Author: Tim Peters (tim.peters) * |
Date: 2018-05-27 18:52 |
| 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. |
|
|
| msg317831 - (view) |
Author: Sergey B Kirpichev (Sergey.Kirpichev) * |
Date: 2018-05-28 08:46 |
| > 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). |
|
|
| msg317869 - (view) |
Author: Tim Peters (tim.peters) * |
Date: 2018-05-28 15:31 |
| 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. |
|
|
| msg317901 - (view) |
Author: Sergey B Kirpichev (Sergey.Kirpichev) * |
Date: 2018-05-28 19:11 |
| > 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. |
|
|
| msg342281 - (view) |
Author: Cheryl Sabella (cheryl.sabella) * |
Date: 2019-05-13 03:14 |
| Thank you for the suggestion, but per the discussion with Tim, I am closing as rejected. |
|
|