[issue7846] Fnmatch cache is never cleared during usage
Andrew Clegg a...@pml.ac.uk added the comment: If you give something an _, then it is not considered part of the public API and it (the internal API, not the value) is subject to change, which means you should *not* suggest that users change it. If they find it and want to change it anyway, that's their lookout. That's the consenting adults part :) This sums it up well - it should be considered a detail of implementation, thus the _. When I said I wanted to allow the value to be modified, I was thinking of the 'consenting adult' type of usage, not everyday usage. Of course there is no reasonable way to prevent the value being modified anyway. So - _MAXCACHE can stay where it is, but should not be documented or be included in __all__. Does that seem reasonable? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7950] subprocess.Popen documentation should contain a good warning about the security implications when using shell=True
New submission from Christoph Neuroth christoph.neur...@googlemail.com: Currently, the documentation of subprocess only says Calling the program through the shell is usually not required.. IMHO there should be a real warning (like, in its own box with a couple of big exclamation marks ;)) about the security implications of using this and detailed instructions of how to avoid it. People tend to use this functionality just because they know how to use the shell and its just so convenient - and by doing so they create huge security holes in their applications. -- assignee: georg.brandl components: Documentation messages: 99465 nosy: christoph.neuroth, georg.brandl severity: normal status: open title: subprocess.Popen documentation should contain a good warning about the security implications when using shell=True type: security versions: Python 2.6, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7950 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7950] subprocess.Popen documentation should contain a good warning about the security implications when using shell=True
Eric Smith e...@trueblade.com added the comment: This was just discussed in issue 6760. -- nosy: +eric.smith resolution: - duplicate stage: - committed/rejected status: open - closed superseder: - patch to subprocess docs to better explain Popen's 'args' argument ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7950 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7942] Inconsistent error types/messages for __len__ between old and new-style classes
Paul Boddie p...@boddie.org.uk added the comment: I don't disagree that OverflowError describes what's happening, but the need to convert to an int in the first place is a detail of the machine - you'd have to know that this is a limitation of whatever internal protocol CPython implements - not a description of the cause of the error, which is what the old-style message describes quite clearly. On the subject of whether __len__ should be able to return long integers, GvR seems to like the idea (from the related bug mentioned earlier): http://bugs.python.org/issue2690#msg70525 I'll take a closer look at the mechanisms for error reporting around this situation later, but my assertion is that the new-style message isn't as helpful as the old-style one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7942] Inconsistent error types/messages for __len__ between old and new-style classes
R. David Murray rdmur...@bitdance.com added the comment: Interestingly, this (len returning something larger than ssize_t) has not been fixed in python3. On the other hand, I still think the new-style message is better. Yes, it is an implementation detail of CPython, but that is exactly the error being reported. Another implementation might successfully return the value. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Alex Willmer a...@moreati.org.uk added the comment: I've packaged this latest revision and uploaded to PyPI http://pypi.python.org/pypi/regex -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7593] Computed-goto patch for RE engine
A.M. Kuchling li...@amk.ca added the comment: I finally got around to benchmarking this change, and unfortunately the results are not good. I used the regex tests in the Unladen Swallow test suite, regex_effbot and regex_v8. The tests are written for Python 2.x, but the fixes for 3.x are straightforward (use print() in one function; replace xrange with range in the bm_regex_effbot.py and bm_regex_v8.py files; remove a few uses of u''; I'll provide a patch later.) Hardware: MacBook, Intel Core 2 Duo, 1.83GHz, 2MB L2 cache, 667 MHz bus. Tests invoked with ./perf.py -b regex_effbot -r -v ../py3k/python.exe ../threaded-3000/python.exe regex_effbot is 1.1002 times slower with the computed-goto patch, and regex_v8 is 1.0081x slower. perf.py indicates that both results are significant. I'd like to see a few people replicate these results -- maybe the effect is very platform dependent or I ran the tests incorrectly -- but on current evidence, this patch is not worth pursuing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3132] implement PEP 3118 struct changes
Mark Dickinson dicki...@gmail.com added the comment: And under what conditions would a ctype long double be used vs. a Decimal object. Well, I'm guessing that this was really just an open question for the PEP, and that the PEP authors hadn't decided which of these two options was more appropriate. If all long doubles were converted to Decimal, then we need to determine what precision is appropriate to use for the conversion: any long double *can* be represented exactly as a Decimal, but to get an exact representation can need thousands of digits in some cases, so it's probably better to always round to some fixed number of signficant digits. 36 significant digits is a reasonable choice here: it's the minimum number of digits that's guaranteed to distinguish two distinct long doubles, for the case where a long double has 113 bits of precision (i.e., IEEE 754 binary128 format); other common long double formats have smaller precision than this (usually 53 (normal double), 64 (x87 extended doubles), or 106 (double double)). There would probably also need to be some way to 'repack' the Decimal instance. The 'platform long double - Decimal' conversion itself would also be nontrivial to implement; I can lend a hand here if you want it. Using ctypes makes more sense to me, since it doesn't involve trying to mix decimal and binary, except that I don't know whether it's acceptable for other standard library modules to have dependencies on ctypes. I'm not sure whether ctypes is available on all platforms that Python runs on. It's also a bit ugly that, depending on the platform, sometimes a long double will unpack to an instance of ctypes.long_double, and sometimes (when long double == double) to a regular Python float. Anyway, this particular case (long double) isn't a big deal: it can be overcome, one way or another. I'm more worried about some of the other aspects of the changes. [About unpacking with the 'O' format.] I guess if an object associated with the packed address does not exist, then you would unpack None (?). This is especially a problem if the struct-sting is being sent over the wire to another machine. And how do you determine whether an address gives a valid object or not? I can only assume that packing and unpacking with the 'O' format is only supposed to be used in certain restricted circumstances, but it's not clear to me what those circumstances are. I also have the following questions: [...] I think a lot of this discussion needs to go back to python-dev; with luck, we can get some advice and clarifications from the PEP authors there. I'm not sure whether it's appropriate to modify the original PEP (especially since it's already accepted), or whether it would be better to produce a separate document describing the proposed changes in detail. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3132 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7593] Computed-goto patch for RE engine
A.M. Kuchling li...@amk.ca added the comment: Actually, I really want someone to verify that measurement. As a control, I tried running the call_method benchmark (after a few more xrange fixes). The Python 3.x trunk version with my patch is measured as 1.0227x slower, even though the patch only touches the re module and call_method doesn't use the module at all. I recompiled both binaries; both builds are using the same compiler arguments; both have the same version from trunk. I'm mystified about why the patched version is slower. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3132] implement PEP 3118 struct changes
Mark Dickinson dicki...@gmail.com added the comment: I'm looking for previous discussions of this PEP. There's a python-dev thread in April 2007: http://mail.python.org/pipermail/python-dev/2007-April/072537.html Are there other discussions that I'm missing? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3132 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7633] decimal.py: type conversion in context methods
Mark Dickinson dicki...@gmail.com added the comment:
The latest patch looks fine. I've attached a slightly tweaked version:
- Add conversions for number_class; without this, number_class is
inconsistent with the various is_*** methods. c.is_normal(3) should be
equivalent to c.number_class(3) in ('+Normal', '-Normal), for example.
- Remove conversions for 'canonical' and 'is_canonical'; I agree with Stefan
that these don't make a lot of sense. It's mostly academic, since I can't
imagine either of these methods gets much use.
- I've reworded the documentation slightly.
- Remove lots of trailing whitespace (mostly on otherwise empty lines).
If this looks okay to everyone, I'll check it in.
--
Added file: http://bugs.python.org/file16245/issue7633_jjconti4_metd.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7633
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7299] setup.py install doesn't honor PYTHONUSERBASE
Éric Araujo mer...@netwok.org added the comment: Hello It seems to me that your patch doesn’t fix a bug but adds a feature. PEP 370 says that “distutils.command.install (setup.py install) gets a new argument --user to install packages in the user site directory”, not that the presence of the envvar should trigger the user install scheme. Can you give a link to the original bug report? Regards -- nosy: +merwok ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7299 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7946] Convoy effect with I/O bound threads and New GIL
Antoine Pitrou pit...@free.fr added the comment: We could try not to release the GIL when socket methods are called on a non-blocking socket. Regardless, I've re-run the tests under the Linux machine, with two spinning threads: * python 2.7: 25.580 seconds (409914.612 bytes/sec) * python 3.2: 32.216 seconds (325485.029 bytes/sec) (and as someone mentioned, the priority requests mechanism which was in the original new GIL patch might improve things. It's not an ideal time for me to test, right now :-)) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7593] Computed-goto patch for RE engine
Antoine Pitrou pit...@free.fr added the comment: You should disassemble the output (or produce assembler from gcc) and check that the various indirect jumps at the end of each case block don't get merged into a single shared indirect jump. Or perhaps it's simply that regular expression matching isn't really sensitive to bytecode dispatch overhead. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Matthew Barnett pyt...@mrabarnett.plus.com added the comment: The main text at http://pypi.python.org/pypi/regex appears to have lost its backslashes, for example: The Unicode escapes u and U are supported. instead of: The Unicode escapes \u and \U are supported. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7904] urlparse.urlsplit mishandles novel schemes
mARK python.mblo...@xoxy.net added the comment: Doing a fallback test for // would look like if scheme in uses_netloc and url[:2] == '//' or url[:2] == '//': but this is equivalent to if url[:2] == '//': i.e., an authority appears if and only if there is a // after the scheme. This still allows a uses_netloc scheme to appear without //. I have attached a patch against Python 2.7, svn revision 78212. It adds s3 to netloc. -- Added file: http://bugs.python.org/file16246/fix7904-2.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7904 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Vlastimil Brom vlastimil.b...@gmail.com added the comment:
I just tested the fix for unicode tracebacks and found some possibly weird
results (not sure how/whether it should be fixed, as these inputs are indeed
rather artificial...).
(win XPp SP3 Czech, Python 2.6.4)
Using the cmd console, the output is fine (for the characters it can accept and
display)
regex.findall(ur\p{InBasicLatinĚ}, uaé)
Traceback (most recent call last):
...
File C:\Python26\lib\regex.py, line 1244, in _parse_property
raise error(undefined property name '%s' % name)
regex.error: undefined property name 'InBasicLatinĚ'
(same result for other distorted proprety names containing e.g.
ěščřžýáíéúůßäëiöüîô ...
However, in Idle the output differs depending on the characters present
regex.findall(ur\p{InBasicLatinÉ}, uab c)
yields the expected
...
File C:\Python26\lib\regex.py, line 1244, in _parse_property
raise error(undefined property name '%s' % name)
error: undefined property name 'InBasicLatinÉ'
but
regex.findall(ur\p{InBasicLatinĚ}, uab c)
Traceback (most recent call last):
...
File C:\Python26\lib\regex.py, line 1244, in _parse_property
raise error(undefined property name '%s' % name)
File C:\Python26\lib\regex.py, line 167, in __init__
message = message.encode(sys.stdout.encoding)
File C:\Python26\lib\encodings\cp1250.py, line 12, in encode
return codecs.charmap_encode(input,errors,encoding_table)
UnicodeEncodeError: 'charmap' codec can't encode character u'\xcc' in position
37: character maps to undefined
which might be surprising, as cp1250 should be able to encode Ě, maybe there
is some intermediate ascii step?
using the wxpython pyShell I get its specific encoding error:
regex.findall(ur\p{InBasicLatinÉ}, uab c)
Traceback (most recent call last):
...
File C:\Python26\lib\regex.py, line 1102, in _parse_escape
return _parse_property(source, info, in_set, ch)
File C:\Python26\lib\regex.py, line 1244, in _parse_property
raise error(undefined property name '%s' % name)
File C:\Python26\lib\regex.py, line 167, in __init__
message = message.encode(sys.stdout.encoding)
AttributeError: PseudoFileOut instance has no attribute 'encoding'
(the same for \p{InBasicLatinĚ} etc.)
In python 3.1 in Idle, all of these exceptions are displayed correctly, also in
other scripts or with special characters.
Maybe in python 2.x e.g. repr(...) of the unicode error messages could be used
in order to avoid these problems, but I don't know, what the conventions are in
these cases.
Another issue I found here (unrelated to tracebacks) are backslashes or
punctuation (except the handled -_) in the property names, which just lead to
failed mathces and no exceptions about unknown property names
regex.findall(u\p{InBasic.Latin}, uab c)
[]
I was also surprised by the added pos/endpos parameters, as I used flags as a
non-keyword third parameter for the re functions in my code (probably my fault
...)
re.findall(pattern, string, flags=0)
regex.findall(pattern, string, pos=None, endpos=None, flags=0, overlapped=False)
(is there a specific reason for this order, or could it be changed to maintain
compatibility with the current re module?)
I hope, at least some of these remarks make some sense;
thanks for the continued work on this module!
vbr
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2636
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7951] Should str.format allow negative indexes when used for __getitem__ access?
New submission from Eric Smith e...@trueblade.com:
It surprised me that this doesn't work:
{0[-1]}.format('fox')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: string indices must be integers
I was expecting it to be equivalent to:
{0[2]}.format('fox')
'x'
I don't think there's any particular reason this doesn't work. It would,
however break the following code:
{0[-1]}.format({'-1':'foo'})
'foo'
But note that this doesn't work currently:
{0[1]}.format({'1':'foo'})
Traceback (most recent call last):
File stdin, line 1, in module
KeyError: 1
--
assignee: eric.smith
components: Interpreter Core
keywords: easy
messages: 99482
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Should str.format allow negative indexes when used for __getitem__
access?
type: feature request
versions: Python 2.7, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7951
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7952] fileobject.c can switch between fread and fwrite without an intervening flush or seek, invoking undefined behaviour
New submission from David-Sarah Hopwood david-sa...@jacaranda.org:
The C standard (any version, or POSIX), says in the description of fopen that:
{{{
When a file is opened with update mode ( '+' as the second or third character
in the mode argument), both input and output may be performed on the associated
stream. However, the application shall ensure that output is not directly
followed by input without an intervening call to fflush() or to a file
positioning function ( fseek(), fsetpos(), or rewind()), and input is not
directly followed by output without an intervening call to a file positioning
function, unless the input operation encounters end-of-file.
}}}
Objects/fileobject.c makes calls to fread and fwrite without taking this into
account. So calls from Python to read or write methods of a file object opened
in any rw mode, may invoke undefined behaviour. It isn't reasonable to rely
on Python code to avoid this situation, even if were considered acceptable in
C. (Arguably this is a bug in the C standard, but it is unlikely to be fixed
there or in POSIX, because of differences in philosophy about language safety.)
To fix this, fileobject.c should keep track of whether the last I/O operation
was an input or output, and perform a call to fflush whenever an input follows
an output or vice versa. This should not significantly affect performance in
any case where the behaviour was previously defined (in cases where it wasn't,
correctness trumps performance). fflush does not affect the file position and
should have no other negative effect, because the stdio implementation is free
to flush buffered data at any time (and certainly on I/O operations).
Despite the undefined behaviour, I don't currently know of a platform where
this would lead to an exploitable security bug. I'm marking this issue as
security-relevant anyway, because it may prevent analysing whether Python
applications behave securely only on the basis of documented behaviour.
--
components: IO
messages: 99483
nosy: davidsarah
severity: normal
status: open
title: fileobject.c can switch between fread and fwrite without an intervening
flush or seek, invoking undefined behaviour
type: security
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7952
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7953] RawIOBase.read fails with an AttributeError
New submission from Andrew McNabb amcn...@mcnabbs.org: I was trying to open stdin in binary mode and ran the following: RawIOBase(sys.stdin.fileno()).read() Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'RawIOBase' object has no attribute 'readinto' I would expect read() to read data instead of crashing. -- components: IO messages: 99484 nosy: amcnabb severity: normal status: open title: RawIOBase.read fails with an AttributeError type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7953 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7953] RawIOBase.read fails with an AttributeError
Benjamin Peterson benja...@python.org added the comment: If you want the actual raw sys.stdin stream, use sys.stdin.buffer.raw. -- nosy: +benjamin.peterson resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7953 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7953] RawIOBase.read fails with an AttributeError
R. David Murray rdmur...@bitdance.com added the comment: Also note that RawIOBase is not intended to be a concrete class, it is intended to be subclassed (thus the 'Base' in the name). -- nosy: +r.david.murray priority: - normal ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7953 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7954] detach method has no docstring
Benjamin Peterson benja...@python.org added the comment: 2010/2/17 Andrew McNabb rep...@bugs.python.org: Andrew McNabb amcn...@mcnabbs.org added the comment: Oops. I had run pydoc instead of pydoc3, so I was getting the 2.6 version of the io docstrings instead of the 3.1 version. By the way, it took about an hour to find out how to get Python 3 to treat stdin as bytes instead of unicode. Now that I know what I was looking for, the documentation for the io library seems fine. However, since Python 3 uptake is still a little slow, it's really hard to search for good information out there. There's a note here: http://docs.python.org/py3k/library/sys#sys.stdin Would it be possible to some tutorial-style information to the io library documentation? Stuff like switching stdin and stdout to bytes mode seem like they will be common problems, and it's a bit overwhelming to sort through 14 pages of documentation. I think for most readers, it would be helpful to start with a brief tutorial before lunging into the hierarchy of abstract classes. Overall, the documentation is great; it's detailed and complete. If there's one weakness, it's the overview. Yes, but that's another issue. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7952] fileobject.c can switch between fread and fwrite without an intervening flush or seek, invoking undefined behaviour
David-Sarah Hopwood david-sa...@jacaranda.org added the comment: Correction: when input is followed by output, the call needed to avoid undefined behaviour has to be to a file positioning function (fseek, fsetpos, or rewind, but not fflush). Since fileobject.c does not use wide I/O operations, it should be sufficient to use _portable_fseek(fp, 0, SEEK_SET). (_portable_fseek may call some function that is not strictly defined to be a file positioning function, e.g. fseeko() or fseek64(). However, it would be insane for a stdio implementation not to treat those as being file positioning functions as far as the intent of the C or POSIX standards is concerned.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7952 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Matthew Barnett pyt...@mrabarnett.plus.com added the comment: issue2636-20100218.zip is a new version of the regex module. I've added '.' to the permitted characters when parsing the name of a property. The name itself is no longer reported in the error message. I've also corrected the positions of the 'pos' and 'endpos' arguments: regex.findall(pattern, string, flags=0, pos=None, endpos=None, overlapped=False) -- Added file: http://bugs.python.org/file16247/issue2636-20100218.zip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7955] TextIOWrapper Buffering Inconsistent Between _io and _pyio
New submission from Andrew McNabb amcn...@mcnabbs.org:
The following snippet behaves differently in the C IO implementation than in
the Python IO implementation:
import sys
sys.stdout.write('unicode ')
sys.stdout.buffer.write(b'bytes ')
To test this, I have created two scripts, testpyio.py (using _pyio) and
testio.py (using _io). The output is as follows:
% python3 testpyio.py
unicode bytes
% python3 testio.py
bytes unicode
%
In my opinion, the behavior exhibited by _pyio is more correct. It appears
that to get the C implementation to print the lines in the correct order, there
must be a flush in between the statements. This extra flush would create a lot
of overhead.
I am attaching the two test scripts.
The C implementation prints the output in the correct order if each write ends
with a newline.
--
components: IO
files: testpyio.py
messages: 99496
nosy: amcnabb
severity: normal
status: open
title: TextIOWrapper Buffering Inconsistent Between _io and _pyio
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file16248/testpyio.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7955
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
