Change by Mark Tolonen :
--
assignee: -> docs@python
components: +Documentation, ctypes
nosy: +docs@python
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Tolonen :
At the following documentation link:
https://docs.python.org/3/library/ctypes.html#incomplete-types
The last example should have byte strings:
>>> c1 = cell()
>>> c1.name = b"foo"
>>> c2 = cell()
>>> c2.n
New submission from Mark Tolonen:
I built a C extension using SWIG for both Python 3.2 and Python 3.3. The
Python file supplying class proxies uses imp.load_module and fails with the
following traceback on 3.3.0rc1, but works on 3.2.3:
Traceback (most recent call last):
File "&q
New submission from Mark Tolonen :
This is on Windows 7 SP1. Run 'chcp 65001' then Python from a console. Note
the extra characters when non-ASCII characters are in the string. At a guess
it appears to be using the UTF-8 byte length of the internal representation
instead of the
Mark Tolonen added the comment:
Sorry, msg.replace('Issue ','Issue 4571').
--
___
Python tracker
<http://bugs.python.org/issue6345>
___
__
New submission from Mark Tolonen :
According to Issue , sys.stdout.buffer is the binary stream
underlying stdout. I see the following behavior on 3.0.1 and 3.1rc2
when writing to a console window:
Python 3.1rc2 (r31rc2:73414, Jun 13 2009, 16:43:15) [MSC v.1500 32 bit
(Intel)]
on win32
Mark Tolonen <[EMAIL PROTECTED]> added the comment:
I see it as primarily useful in this transition period between 2.x and
3.0, since py3 scripts aren't backward compatible and I see both being
installed for the few years. It could be a front-end launcher
suitable for "f
Mark Tolonen <[EMAIL PROTECTED]> added the comment:
An extension to this idea: Support parsing #! lines in Windows and
select the version of Python used. python.exe could examine:
#!/usr/bin/python30
pattern match "python##", look in the registry to see if that versi
