String interpolation doesn't work with sys.version_info

[Arfrever]

BPO	8413
Nosy	@rhettinger, @abalkin, @pitrou, @ericvsmith, @benjaminp, @ezio-melotti, @briancurtin
Files	structseq-inheritance.patch structseq-inheritance2.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/benjaminp'
closed_at = <Date 2010-07-07.20:54:27.486>
created_at = <Date 2010-04-16.01:28:08.841>
labels = ['interpreter-core', 'type-bug']
title = "String interpolation doesn't work with sys.version_info"
updated_at = <Date 2010-07-08.19:33:03.669>
user = 'https://bugs.python.org/Arfrever'

bugs.python.org fields:

activity = <Date 2010-07-08.19:33:03.669>
actor = 'belopolsky'
assignee = 'benjamin.peterson'
closed = True
closed_date = <Date 2010-07-07.20:54:27.486>
closer = 'benjamin.peterson'
components = ['Interpreter Core']
creation = <Date 2010-04-16.01:28:08.841>
creator = 'Arfrever'
dependencies = []
files = ['17890', '17896']
hgrepos = []
issue_num = 8413
keywords = ['patch']
message_count = 23.0
messages = ['103282', '103305', '103797', '104519', '104521', '104523', '104524', '104525', '104529', '104530', '104531', '108497', '109445', '109495', '109496', '109497', '109498', '109499', '109500', '109501', '109502', '109556', '109577']
nosy_count = 8.0
nosy_names = ['rhettinger', 'belopolsky', 'pitrou', 'eric.smith', 'benjamin.peterson', 'ezio.melotti', 'Arfrever', 'brian.curtin']
pr_nums = []
priority = 'high'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue8413'
versions = ['Python 3.1', 'Python 2.7', 'Python 3.2']

[Arfrever]

String interpolation doesn't work with sys.version_info in Python versions in which sys.version_info is a named tuple. It's a regression in Python 2.7 and 3.1. This problem doesn't concern named tuples created using collections.namedtuple().

This problem might also concern sys.getwindowsversion(), but I don't have access to Windows system, so I can't check it.

$ python2.6 -c 'import sys; print("%s.%s.%s-%s-%s" % sys.version_info)'
2.6.5-final-0
$ python2.7 -c 'import sys; print("%s.%s.%s-%s-%s" % sys.version_info)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: not enough arguments for format string
$ python3.0 -c 'import sys; print("%s.%s.%s-%s-%s" % sys.version_info)'
3.0.1-final-0
$ python3.1 -c 'import sys; print("%s.%s.%s-%s-%s" % sys.version_info)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: not enough arguments for format string

[ericvsmith]

This affects any type implemented as PyStructSequence. For example, sys.flags has the same behavior.

[ericvsmith]

I think the right way to handle this is to modify the test:

if (Py_TYPE(args)->tp_as_mapping && !PyTuple_Check(args) &&
!PyObject_TypeCheck(args, &PyBaseString_Type))

to also exclude PyStructSequence's, but since they're all distinct types I don't see how to do that. I don't really think listing all of the PyStructSequence types would be acceptable.

This is the test that's trying to figure out if %-formatting should use mapping or tuple expansion.

[AlexanderBelopolsky]

I am not sure fixing this quirk of %-formatting is worth the trouble given that one simply use new style {}-formatting:

$ python-c 'import sys; print("{}.{}.{}-{}-{}".format(*sys.version_info))'
3.2.0-alpha-0

or a work-around

$ python -c 'import sys; print("%s.%s.%s-%s-%s" % tuple(sys.version_info))'
3.2.0-alpha-0

[pitrou]

Well, the problem is that it's a regression from 2.6.
It also shows why these "fancy" structs aren't necessarily a good idea.
I agree fixing in py3k is less important, though it would be nice too.

[ericvsmith]

The other thing to do would be to convince PyTuple_Check that PyStructSequences are tuples, but that would no doubt come with its own set of regressions.

Since this problem is 1) hard to fix and 2) probably of minimal impact, I think the best course is to do nothing.

[AlexanderBelopolsky]

The recommended way to check that an object is an instance of a namedtuple is to check for the _fields attribute. See bpo-7796, msg99869.

[ericvsmith]

Yes, but sys.version_info isn't a namedtuple (which are in fact tuples), it's the (sort-of) C equivalent, which isn't a real tuple.

>>> from collections import namedtuple
>>> x = namedtuple('x', 'a b c')
>>> '%s %s %s' % x(1, 2, 3)
'1 2 3'

Hmm, but sys.version_info is a tuple:
>>> isinstance(sys.version_info, tuple)
True

I'll have to check if PyTuple_Check returns true or not. Maybe the problem is in the mapping check.

I'll investigate more.

[rhettinger]

IIRC, there is an open ticket to make structseq inherit from tuple to avoid just this kind of problem.

[ericvsmith]

Looks like that's bpo-1820.