gmane.comp.python.devel

What if we didn't have repr?

Guido van Rossum — 2013-05-20T01:46:40

I have pondered it many times, although usually in the form "Why do we
need both str and repr?"

Unfortunately I always come back to the same issue: I really want
print() of a string to write just the characters of the string
(without quotes), but I also really want the >>> prompt to write the
string with quotes (and escapes). Moreover, these are just two
examples of the different use cases -- repr() is more useful whenever
you are writing a value for a debugging purpose (e.g. when logging),
and str() is more useful when writing a value as "output" of a
program.

One could argume that the only type for which it makes sense to
distinguish between the two is str itself -- indeed I rarely define
different __repr__ and __str__ functions for new classes I create (but
I do note that PEP 435 does define them differently for enum members).
But for the str type, it's pretty important to have str(s) equal to s,
and it's also pretty important to have a way to produce a string
literal from a string value. And it would

Re: Ordering keyword dicts

Greg Ewing — 2013-05-20T01:35:49

No, because the callee is the only one that knows whether it
requires its keyword args to be ordered.

In fact, not even the callee might know at the time of the
call. Consider a function that takes **kwds and passes them
on to another function that requires ordered keywords.

Re: Why is documentation not inline?

Demian Brecht — 2013-05-20T01:19:08

< at >nick: Yes, I realize what docstrings are for (I should have used that
term rather than "inline" docs, my bad there :)). I think the problem
that I've run into is simply inconsistencies in methods of documenting
code (and the few times that it would have been helpful, what I was
looking at had not been authored using docstrings).

Is the usage of docstrings a requirement (or a strong suggestion) for
new commits (I didn't see anything while reading the submission
guidelines)? If not, would it perhaps be a worthy addition?

On Sun, May 19, 2013 at 4:51 PM, Nick Coghlan <ncoghlan< at >gmail.com> wrote:

Re: Purpose of Doctests [Was: Best practices for Enum]

Tim Peters — 2013-05-20T00:28:42

[Raymond Hettinger]

I disagree.



That's representative of how doctest was developed:  to help me in
keeping some well-defined mathematical functions working as intended.
It still excels in that particular area (a few examples to illustrate
normal cases, and a few more to illustrate well-defined end and error
cases - and that's all there _is_ to be tested).



But more than just one ;-)  Another great use has nothing to do with
docstrings:  using an entire file as "a doctest".   This encourages
writing lots of text explaining what you're doing,. with snippets of
code interspersed to illustrate that the code really does behave in
the ways you've claimed.



I'd rather encourage users to turn their brains on when writing
doctest files - and when writing unit tests.  I've lost count of how
many times I've seen a unit test fail, then stared helplessly at the
unit test code just trying to figure out what the author thought they
were doing.  A lot of comments in the test code could have helped
that, but - outsid

Re: Purpose of Doctests [Was: Best practices for Enum]

Nick Coghlan — 2013-05-20T00:24:08

This is the point I was trying to make: once you use IntEnum (as you
would in any case where you need bitwise operators), Enum gets out of
the way for everything other than __str__, __repr__, and one other
slot (that escapes me for the moment...).

The metaclass does extra work at definition time so there shouldn't be
any runtime overhead - the slots should be inherited directly from the
non-Enum parent.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan< at >gmail.com   |   Brisbane, Australia

Re: Purpose of Doctests [Was: Best practices for Enum]

Antoine Pitrou — 2013-05-20T00:14:25

On Sun, 19 May 2013 20:04:03 -0400
Ned Batchelder <ned< at >nedbatchelder.com> wrote:

Then it's up to the library writer to not use enums in that case.
(assuming the performance of bitwise operations is critical here, which
I doubt)

Regards

Antoine.

Re: Purpose of Doctests [Was: Best practices for Enum]

Ned Batchelder — 2013-05-20T00:04:03

It makes sense if the enums represent bit-oriented values that will be 
used close to the machine.  Python is used in many disciplines.

--Ned.

Re: [RELEASED] Python 2.7.5

Richard Oudkerk — 2013-05-20T00:04:31

Even in Python 2, if the result of arithmetic on ints which would 
overflow, the result automatically gets promoted to a long integer which 
is variable-length.

     >>> 2**128
     340282366920938463463374607431768211456L
     >>> type(2), type(2**128)
     (<type 'int'>, <type 'long'>)

So the size of an int is pretty much irrelevant.

Re: Purpose of Doctests [Was: Best practices for Enum]

Gregory P. Smith — 2013-05-19T23:51:21

applies

Oh cool. I didn't realize that already existed!

Re: Why is documentation not inline?

Nick Coghlan — 2013-05-19T23:51:07

That's what docstrings are for - abbreviated docs for use when reading the
code and at the interactive prompt.

The prose docs are designed to be a more discursive introduction to the
full details of each operation, whereas docstrings are usually written more
to provide someone that already knows what the function does with a
reminder of the details.

Cheers,
Nick.

wrote:
http://mail.python.org/mailman/options/python-dev/demianbrecht%40gmail.com
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com

Re: [RELEASED] Python 2.7.5

Pierre Rouleau — 2013-05-19T23:47:20


Fair


Good to know.  Too bad there still are libraries not supporting Python 3.
 Thanks.

Re: [RELEASED] Python 2.7.5

Antoine Pitrou — 2013-05-19T23:41:28

On Sun, 19 May 2013 19:37:46 -0400
Pierre Rouleau <prouleau001< at >gmail.com> wrote:


Well, it's Microsoft's choice. But from a Python point of view, which C
type a Python int maps to is of little relevance.

Moreover, the development version is 3.4, and in Python 3 the int
type is a variable-length integer type (sys.maxint doesn't exist
anymore). So this discussion is largely moot now.

Regards

Antoine.

Re: [RELEASED] Python 2.7.5

Pierre Rouleau — 2013-05-19T23:37:46

On that topic of bitness for 64-bit platforms, would it not be better for
CPython to be written such that it uses the same 64-bit strategy on all
64-bit platforms, regardless of the OS?

As it is now, Python running on 64-bit Windows behaves differently (in
terms of bits for the Python's integer) than it is behaving in other
platforms.  I assume that the Python C code is using the type 'long'
instead of something like the C99 int64_t.  Since Microsoft is using the
LLP64 model and everyone else is using the LP64, code using the C 'long'
type would mean something different on Windows than Unix-like platforms.
 Isn't that unfortunate?

Would it not be better to hide the difference at Python level?

Or is it done this way to allow existing C extension modules to work the
way they were and request Python code that depends on integer sizes to
check sys.maxint?

Also, I would imagine that the performance delta between a Windows 32-bit
Python versus 64-bit Python is not as big as it would be on a Unix
computer.  As

Re: Purpose of Doctests [Was: Best practices for Enum]

Benjamin Peterson — 2013-05-19T23:31:33

2013/5/19 Gregory P. Smith <greg< at >krypto.org>:

2to3 can operate on doctests, though it doesn't do anything different
to them than it does to normal sourcecode.


--
Regards,
Benjamin

Re: Purpose of Doctests [Was: Best practices for Enum]

Gregory P. Smith — 2013-05-19T23:27:33

On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger <
raymond.hettinger< at >gmail.com> wrote:


So long as doctests insist on comparing the repr of things being the number
one practice that people use when writing them there is no other position I
can hold on the matter.  reprs are not stable and never have been.
 ordering changes, hashes change, ids change, pointer values change,
wording and presentation of things change.  none of those side effect
behaviors were ever part of the public API to be depended on.

That one can write doctests that don't depend on such things as the repr
doesn't ultimately matter because the easiest thing to do, as encouraged by
examples that are pasted from an interactive interpreter session into docs,
is to have the interactive interpreter show the repr and not add code to
check things in a accurate-for-testing manner that would otherwise make the
documentation harder for a human to read.

Instead, we should be clear about their primary purpose which is to test

I really do applaud

Re: [RELEASED] Python 2.7.5

Pierre Rouleau — 2013-05-19T23:23:23

OK thanks, Benjamin,

you are correct sys.maxsize is 2*63-1 on it.

I was under the impression that Python was using int_64_t for the
implementation of Win64 based integers.  Most probably because I've sen
discussion on Python 64 bits and those post were most probably were in the
scope of some Unix-type platform.


Regards,


On Sun, May 19, 2013 at 6:56 PM, Benjamin Peterson <benjamin< at >python.org>wrote:

Re: Purpose of Doctests [Was: Best practices for Enum]

Mark Janssen — 2013-05-19T23:22:22

I think it's rather pointless to do bitwise operations on python
enums.  We're not that close to the machine.

MarkJ
Tacoma, Washington

Re: [RELEASED] Python 2.7.5

Benjamin Peterson — 2013-05-19T22:56:51

2013/5/19 Pierre Rouleau <prouleau001< at >gmail.com>:

This is correct. sizeof(long) != sizeof(void *) on Win64, and size
Python int's are platform longs, you get the maxsize of a 32-bit int.
Check sys.maxsize for comparison.



--
Regards,
Benjamin

Re: [RELEASED] Python 2.7.5

Pierre Rouleau — 2013-05-19T22:48:06

Hi all,

I just installed Python 2.7.5 64-bit () on a Windows 7 64-bit OS computer.
 When I evaluate sys.maxint I don't get what I was expected.  I get this:

Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)]
on win32
Type "copyright", "credits" or "license()" for more information.
2147483647
'AMD64'
'AMD64'


 Should I not get a 64-bit integer maxint (9223372036854775807) for
sys.maxint ?

Or is there something I am missing here?

Thanks!

/ Pierre Rouleau


On Thu, May 16, 2013 at 6:23 AM, "Martin v. Löwis" <martin< at >v.loewis.de>wrote:

Re: Why is documentation not inline?

Demian Brecht — 2013-05-19T22:47:18

< at >benjamin: Ah, i see. I wasn't around pre-Sphinx. However, unless
there's some custom build steps that I'm unaware of that may prevent
it, it should still be relatively easy to maintain the desired
narrative structure as long as the inline API docs are kept terse.

< at >antoine: Sorry, I may not have been clear. I wasn't advocating the
inclusion of the /entire/ doc pages inline. I'm advocating terse
documentation for the stdlib APIs and parameters. Narrative
documentation can (and should be) maintained externally, but could use
autodoc to include the terse references when desired. This would
ensure that the same docs are available (and consistent) when reading
the documentation as well as when neck-deep in code.

On Sun, May 19, 2013 at 3:32 PM, Antoine Pitrou <solipsis< at >pitrou.net> wrote:

Re: Purpose of Doctests [Was: Best practices for Enum]

Nick Coghlan — 2013-05-19T22:46:53

can do each with the other is beside the point.)

I consider those to be binary arithmetic, but it's a fair point. The word I
really wanted was "comparison" anyway, since the main intended uses of
enums are as flags, lookup keys and marker values.

Cheers,
Nick.

http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com