Currently, what's the best way to implement a function
f(OrderedDict([(1,2),(3,4)])) == '{1: 2, 3: 4}', works for all possible types,
and also availaible for pprint with nice indent?
If I could set a parameter in ipython or python repl that would print that,
that would already be very useful.
Le ven. 27 juil. 2018 à 07:23, Steven D'Aprano
<st...@pearwood.info<mailto:st...@pearwood.info>> a écrit :
On Thu, Jul 26, 2018 at 06:50:20PM -0400, David Mertz wrote:
> I often use doctests to verify APIs and behaviors when I update code. I
> know I'm in a minority and most developers slightly disparage doctests.
I don't know why you think that "most developers" disparage doctests.
Perhaps they're the same ones who think that "read the source" is all
the documentation anyone needs.
I know I don't. I love them. Tim Peters loves them (he should, he wrote
the module) and if its good enough for Uncle Timmy then anyone who
disparages them better have a damn good reason.
Doc tests aren't perfect, but they fill a very important niche which is
otherwise badly neglected by developers.
I think we'd need to ask on Python-Dev to be sure, but my understanding
is that backwards compatibility guarantees for reprs are weaker than
those for regular APIs but stronger than those for error messages.
Earlier, Michael Selik <m...@selik.org<mailto:m...@selik.org>> wrote:
> > Given the way different Python prompts feel free to change reprs, I always
> > understood the repr to have no compatibility guarantees.
That doesn't follow. The Python language makes no guarantees about
how applications can display objects to the user, and a REPL is just
another application. I suppose there might be an implied expectation
that the official REPL that comes with the standard interpreter probably
shouldn't make too many changes to the way things are displayed, but
that's as far as it goes.
[Michael (I think)]
> > Breaking doctests is somewhat annoying, but I understand that to be more
> > about verifying the accuracy of documentation than verifying the
> > correctness of code.
Breaking doctests is more than "somewhat annoying", and you seem to have
missed the point that the way we verify the accuracy of documentation is
by verifying the correctness of code.
> > It's handy for following TDD, but that's during the
> > initial development and a changed repr won't interfere.
I don't understand the reasoning here. Surely doctests are *less*
valuable during initial development, when function APIs are in rapid
change. (On the other hand, I use doctests to nail down what API I
want, before I have an implementation.)
Unless you delete all your documentation or stop running doctests when
the project reaches the first stable version, I don't understand why you
think that changing reprs won't interfere.
--
Steve
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org<mailto:Python-ideas@python.org>
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
