uname and other os functions should return a struct sequence instead of a tuple

[storchaka]

http://bugs.python.org/review/15118/diff/5171/Modules/posixmodule.c
File Modules/posixmodule.c (right):

http://bugs.python.org/review/15118/diff/5171/Modules/posixmodule.c#newcode3603
Modules/posixmodule.c:3603: PyObject *o = PyUnicode_DecodeASCII(field,
strlen(field), NULL); \
PyUnicode_FromString(field)

[larry]

http://bugs.python.org/review/15118/diff/5171/Modules/posixmodule.c
File Modules/posixmodule.c (right):

http://bugs.python.org/review/15118/diff/5171/Modules/posixmodule.c#newcode3603
Modules/posixmodule.c:3603: PyObject *o = PyUnicode_DecodeASCII(field,
strlen(field), NULL); \
On 2012/06/21 14:10:35, storchaka wrote:
> PyUnicode_FromString(field)

Why is that better?  The string isn't UTF-8, it's ASCII.

[storchaka]

On 2012/06/21 19:13:54, larry wrote:
> http://bugs.python.org/review/15118/diff/5171/Modules/posixmodule.c
> File Modules/posixmodule.c (right):
> 
>
http://bugs.python.org/review/15118/diff/5171/Modules/posixmodule.c#newcode3603
> Modules/posixmodule.c:3603: PyObject *o = PyUnicode_DecodeASCII(field,
> strlen(field), NULL); \
> On 2012/06/21 14:10:35, storchaka wrote:
> > PyUnicode_FromString(field)
> Why is that better?  The string isn't UTF-8, it's ASCII.

It is shorter and special designed for such cases. Py_BuildValue("(sssss)"...)
uses UTF-8 decoder. For long ASCII strings UTF-8 and ASCII encoders are almost
equal fast (both use same code). For short string there are no differences
between different decoders.

[storchaka]

http://bugs.python.org/review/15118/diff/5217/Lib/test/test_sysconfig.py
File Lib/test/test_sysconfig.py (right):

http://bugs.python.org/review/15118/diff/5217/Lib/test/test_sysconfig.py#newc...
Lib/test/test_sysconfig.py:28: self._set_uname(('',)*5)
What is the reason for this change?

http://bugs.python.org/review/15118/diff/5217/Lib/test/test_sysconfig.py#newc...
Lib/test/test_sysconfig.py:70: def _set_uname(self, uname):
This function is only used in one place. I think that would be clearer if get
rid of it and inline body.

[larry]

http://bugs.python.org/review/15118/diff/5217/Lib/test/test_sysconfig.py
File Lib/test/test_sysconfig.py (right):

http://bugs.python.org/review/15118/diff/5217/Lib/test/test_sysconfig.py#newc...
Lib/test/test_sysconfig.py:28: self._set_uname(('',)*5)
On 2012/06/24 08:52:07, storchaka wrote:
> What is the reason for this change?

It allows the test to actually run if "uname" is unavailable.  It depends on
uname returning a valid object.

Y'see, I actually tested that branch--I changed the "if hasattr" above to "if
0"--and the test immediately crashed.  Bit rot, I guess.  (Maybe uname is always
available and it didn't used to be.)

http://bugs.python.org/review/15118/diff/5217/Lib/test/test_sysconfig.py#newc...
Lib/test/test_sysconfig.py:70: def _set_uname(self, uname):
On 2012/06/24 08:52:07, storchaka wrote:
> This function is only used in one place.
> I think that would be clearer if get
> rid of it and inline body.

Done.

[larry]

Let me retract that last statement.

http://bugs.python.org/review/15118/diff/5217/Lib/test/test_sysconfig.py
File Lib/test/test_sysconfig.py (right):

http://bugs.python.org/review/15118/diff/5217/Lib/test/test_sysconfig.py#newc...
Lib/test/test_sysconfig.py:70: def _set_uname(self, uname):
Wait, not done.  The function is used in four places.  Anti-done.

[hynek]

I've added some bikesheds, the more interesting ones were from Georg though.
LGTM otherwise!

http://bugs.python.org/review/15118/diff/5217/Doc/library/os.rst
File Doc/library/os.rst (right):

http://bugs.python.org/review/15118/diff/5217/Doc/library/os.rst#newcode578
Doc/library/os.rst:578: For backwards compatibility, this object is also
iterable, behaving
it's even indexable and that's what you meant here I guess :)

http://bugs.python.org/review/15118/diff/5217/Doc/library/os.rst#newcode590
Doc/library/os.rst:590: .. versionadded:: 3.3
this should be a :versionchanged:

http://bugs.python.org/review/15118/diff/5217/Doc/library/os.rst#newcode2943
Doc/library/os.rst:2943: For backwards compatibility, this object is also
iterable, behaving
as above

http://bugs.python.org/review/15118/diff/5217/Doc/library/os.rst#newcode2956
Doc/library/os.rst:2956: .. versionadded:: 3.3
as above

http://bugs.python.org/review/15118/diff/5217/Modules/posixmodule.c
File Modules/posixmodule.c (right):

http://bugs.python.org/review/15118/diff/5217/Modules/posixmodule.c#newcode4309
Modules/posixmodule.c:4309: {"sysname",    "operating system name"},
I (and Georg, FWIW) prefer osname here (and everywhere it's referenced :)).

http://bugs.python.org/review/15118/diff/5217/Modules/posixmodule.c#newcode4341
Modules/posixmodule.c:4341: PyObject *value;
"value"? really? ;)

http://bugs.python.org/review/15118/diff/5217/Modules/posixmodule.c#newcode7556
Modules/posixmodule.c:7556: 
superfluous empty line!!1!

[larry]

Comments inline, sirrah.

http://bugs.python.org/review/15118/diff/5217/Doc/library/os.rst
File Doc/library/os.rst (right):

http://bugs.python.org/review/15118/diff/5217/Doc/library/os.rst#newcode578
Doc/library/os.rst:578: For backwards compatibility, this object is also
iterable, behaving
On 2012/06/24 10:33:55, hynek wrote:
> it's even indexable and that's what you meant here I guess :)

I think it's better to drop all that and just say "this object behaves like a
five-tuple containing".

http://bugs.python.org/review/15118/diff/5217/Doc/library/os.rst#newcode590
Doc/library/os.rst:590: .. versionadded:: 3.3
On 2012/06/24 10:33:55, hynek wrote:
> this should be a :versionchanged:

Done.

http://bugs.python.org/review/15118/diff/5217/Doc/library/os.rst#newcode2943
Doc/library/os.rst:2943: For backwards compatibility, this object is also
iterable, behaving
On 2012/06/24 10:33:55, hynek wrote:
> as above
As above.

http://bugs.python.org/review/15118/diff/5217/Doc/library/os.rst#newcode2956
Doc/library/os.rst:2956: .. versionadded:: 3.3
On 2012/06/24 10:33:55, hynek wrote:
> as above
As above, as above.

http://bugs.python.org/review/15118/diff/5217/Modules/posixmodule.c
File Modules/posixmodule.c (right):

http://bugs.python.org/review/15118/diff/5217/Modules/posixmodule.c#newcode4309
Modules/posixmodule.c:4309: {"sysname",    "operating system name"},
On 2012/06/24 10:33:55, hynek wrote:
> I (and Georg, FWIW) prefer osname here (and everywhere
> it's referenced :)).

POSIX prefers "sysname".

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/utsname.h.html

http://bugs.python.org/review/15118/diff/5217/Modules/posixmodule.c#newcode4341
Modules/posixmodule.c:4341: PyObject *value;
On 2012/06/24 10:33:55, hynek wrote:
> "value"? really? ;)

I considered "hynek_is_the_most_fabulous_genius_the_world_has_ever_known", but I
believe C limits identifiers to 32 unique characters and I worried it would be
ambiguous with some of my other variable names.

http://bugs.python.org/review/15118/diff/5217/Modules/posixmodule.c#newcode7556
Modules/posixmodule.c:7556: 
On 2012/06/24 10:33:55, hynek wrote:
> superfluous empty line!!1!

Done!!1!

[storchaka]

http://bugs.python.org/review/15118/diff/5217/Lib/test/test_sysconfig.py
File Lib/test/test_sysconfig.py (right):

http://bugs.python.org/review/15118/diff/5217/Lib/test/test_sysconfig.py#newc...
Lib/test/test_sysconfig.py:70: def _set_uname(self, uname):
On 2012/06/24 09:20:56, larry wrote:
> Wait, not done.  The function is used in four places.  Anti-done.

Sorry, I didn't saw that it had existed prior to your changes.