[issue17439] insufficient error message for failed unicode conversion
anatoly techtonik added the comment: Ok. Does the data (string literals) has a scope? Does Python know at runtime that a string literal stored in its memory was defined in the input stream or a file? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17439 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17439] insufficient error message for failed unicode conversion
R. David Murray added the comment: No. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17439 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17444] multiprocessing.cpu_count() should use hw.availcpu on Mac OS X
New submission from John Szakmeister: While trying to test a fix for Nose, I discovered that multiprocessing is picking up the CPU count incorrectly. It should be using hw.availcpu instead of hw.ncpu. The latter is the number of cpus installed in the system, but the former is the number that are available for processing. The processor pane let's you adjust the available CPUs, which is handy for testing and troubleshooting. -- components: Library (Lib) files: use-availcpu.patch keywords: patch messages: 184367 nosy: jszakmeister priority: normal severity: normal status: open type: behavior Added file: http://bugs.python.org/file29430/use-availcpu.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17444] multiprocessing.cpu_count() should use hw.availcpu on Mac OS X
Changes by Richard Oudkerk shibt...@gmail.com: -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Gurmeet Singh added the comment:
Please consider following before making a decision:
__
io.BufferedReader does not implement read1 (the last lines of trace
below)
It does. You made a mistake in your experiment (you called read1() on a FileIO
object, not a BufferedReader object).
Please see the following lines:
cfl = open ('c:/temp9/Capability/Analyzing Data.mp4', 'rb', buffering = -1)
type(cfl)
class '_io.BufferedReader'
According to me it is a _io.BufferedReader only and not just _io.FileIO (the
base class). Please tell me if I am wrong here.
--
status: pending - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17440
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17444] multiprocessing.cpu_count() should use hw.availcpu on Mac OS X
Changes by Antoine Pitrou pit...@free.fr: -- stage: - patch review versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Antoine Pitrou added the comment: You called read1() on fl (a FileIO object) and not cfl (a BufferedReader object). Your fault for choosing confusing variable names :-) len(fl.read1(70934549)) Traceback (most recent call last): File pyshell#44, line 1, in module len(fl.read1(70934549)) AttributeError: '_io.FileIO' object has no attribute 'read1' Please try to call cfl.read1() and see whether it works (it should). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17440 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Gurmeet Singh added the comment: Please consider following before making a decision: io.FileIO does not implements single OS system call on read() - instead reads a file until EOF i.e. ignores the arguments supplied to read() Your experiments show otherwise, the argument supplied to read() is observed: if you call read(1024), at most 1024 bytes are returned, etc. It's only if you call read() without an argument that the file is being read until EOF. I said this because I saw the following in the docs: class io.RawIOBase read(n=-1) Read up to n bytes from the object and return them. As a convenience, if n is unspecified or -1, readall() is called. Otherwise, only one system call is ever made. Fewer than n bytes may be returned if the operating system call returns fewer than n bytes. If only one system call is being made, then I think that fl.read(256) and fl.read(70934549) should take same amount of time to complete - assuming disk I/O is the time consuming factor in this operation (as compared to memory processing). I am only saying that instead of one system call being made - the whole size specified by read is being read (by multiple system calls - as it appears to me). Please tell me if I am wrong here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17440 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Gurmeet Singh added the comment: @Antoine - wait I will do it -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17440 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17443] imaplib.IMAP4_stream subprocess is opened unbuffered but ignores short reads
Antoine Pitrou added the comment: os.fdopen() in 2.x would always create a FILE*, and therefore inherit fread()'s semantics even in unbuffered mode. In 3.x, unbuffered I/O instead calls read() directly, and happily returns partial reads; this is by design. So, I guess imaplib should be fixed :-) -- components: +Library (Lib) nosy: +pitrou stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17443 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17443] imaplib.IMAP4_stream subprocess is opened unbuffered but ignores short reads
Antoine Pitrou added the comment: I don't think there's any reason to open the subprocess in unbuffered mode (you aren't sharing the stdio streams with anyone else). Just be careful to call flush() on stdin before attempting to read any response from stdout. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17443 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Gurmeet Singh added the comment: @Antoine It worked. I was wrong to say read1() was not implemented. Sorry. But please do consider other issues. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17440 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Antoine Pitrou added the comment: If only one system call is being made, then I think that fl.read(256) and fl.read(70934549) should take same amount of time to complete - assuming disk I/O is the time consuming factor in this operation (as compared to memory processing). What do you mean? Reading a large number of bytes will most certainly always be slower than reading a small number of bytes, even if it only takes one system call. You still have to copy the data from disk or filesystem buffers into userspace. A reasonable expectation is for read(N) to be O(N), but not O(1). You might want to check that by timing it with different N values. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17440 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14916] PyRun_InteractiveLoop fails to run interactively when using a Linux pty that's not tied to stdin/stdout
Changes by emmanuel garcia6.emman...@wanadoo.fr: -- nosy: +emmanuel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14916 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Gurmeet Singh added the comment:
I did the following to understand time taken for in memory copy:
1 fl = io.FileIO('c:/temp9/Capability/Analyzing Data.mp4', 'rb')
2 byt = fl.read(70934549)
3 byt2 = None
4 byt2 = byt[:]
5 fl.close()
6 fl = io.FileIO('c:/temp9/Capability/Analyzing Data.mp4', 'rb')
7 byt = fl.read(1)
I found that python interpreter blocked for negligible time on line 4 (and line
7), as compared to line 2.
I assume that line 4 is a correct syntax for an in place memory copy.
Therefore, multiple system calls could be taking place - This is how I assumed.
Please suggest if I am incorrect.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17440
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17436] pass a file object to hashlib.update
STINNER Victor added the comment: obj.update(buffer[:size]) This code does an useless memory copy: obj.update(memoryview(buffer)[:size]) can be used instead. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17436 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Gurmeet Singh added the comment: Sorry, typo in the last post - I meant in memory - memory copy not in place memory copy. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17440 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Return the type you accept
New submission from Barry A. Warsaw: This came up at the Pycon 2013 Python 3 porting clinic. There are many cases in the stdlib that claim (either explicitly or implicitly) to accept bytes or strings, but that don't return the type of the arguments they accept. An example is urllib.parse.quote() which accepts bytes or str but always returns str. A similar example brought up at the clinic was difflib, which accepts both types, and works internally on both, but crashes when joining the results for return. It should be policy for the stdlib (i.e. codified in an informational PEP and including bug reports, because they *are* bugs, not features or baked-in API) where bytes or str are accepted but the right things are not done (i.e. return the type you accept). This bug captures the principle, and probably should be closed once such a PEP is accepted, with individual bugs opened for each individual case. -- components: Library (Lib) messages: 184379 nosy: barry priority: normal severity: normal status: open title: Return the type you accept versions: Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16997] subtests
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16997 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17094] sys._current_frames() reports too many/wrong stack frames
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17094 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Antoine Pitrou added the comment: Bytes objects are immutable, so trying to copy them doesn't copy anything actually (it's an optimization): b = bx *10 id(b) 139720033059920 b2 = b[:] id(b2) 139720033059920 FileIO.read() only calls the underlying read() once, you can check the implementation: http://hg.python.org/cpython/file/8002f45377d4/Modules/_io/fileio.c#l703 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17440 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Return the type you accept
R. David Murray added the comment: There was a long thread about this on python-dev that might be worth going back over, where I had the same misconception (that functions should always return the same type as their arguments). While I think that should be the default design, it isn't always the best API. (The real rule, if I recall correctly, is that functions should never accept *mixed* argument types for input data.) -- nosy: +ncoghlan, r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Return the type you accept
Barry A. Warsaw added the comment: On Mar 17, 2013, at 03:10 PM, R. David Murray wrote: There was a long thread about this on python-dev that might be worth going back over, where I had the same misconception (that functions should always return the same type as their arguments). While I think that should be the default design, it isn't always the best API. (The real rule, if I recall correctly, is that functions should never accept *mixed* argument types for input data.) Totally agree about the mixed type rule. But this is something different, and I know it's been discussed, and is a difficult problem. It's causing real-world pain for people though, so it's worth thinking about again. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Gurmeet Singh added the comment:
Thanks for letting me know about the optimization.
I trusted you that the system call is made once, though I looked up code to see
if size of the read in buffer is being passed to the C routine. I should
apologize though for raising this issue - since it is incorrect.
But, I think you would be interested (out of CURIOSITY) in findings from the
last experiment that I did to understand this issue:
1 import io
2 fl = io.FileIO('c:/temp9/Capability/Analyzing Data.mp4', 'rb')
3 barr = bytearray(70934549)
4 barr2= bytearray(70934549)
5 id(barr)
29140440
6 id(barr2)
26433560
7 fl.readinto(barr)
70934549
8 barr2 = barr[:]
9 fl.close()
10 fl = io.FileIO('c:/temp9/Capability/Analyzing Data.mp4', 'rb')
11 barrt = bytearray(1)
12 id(barrt)
34022512
13 fl.readinto(barrt)
1
14 fl.close()
The time of line 7 was much greater than line 13. It was also greater than 8
(but not that great as of 11). But I cannot say for sure that the time for line
13 plus line 8 is equal to or lesser than 7 - it looks lesser but needs more
precise testing to say anything further.
I tried to reason the situation as follows (for this I looked up the hyperlink
that you gave). I feel that the underlying system call takes the size argument
- so I guess that large value suggests the C compiler to make ask the disk
subsystem to read up the longer data - hence it takes the time since disk
access is slower.
Thanks for your time. Sorry for the incorrect issue.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17440
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17446] doctest test finder doesnt find line numbers of properties
New submission from Ronny Pfannschmidt: examples that are found on a property dont detect the line number class example(object): @property def me(self): 1/0 pass -- messages: 184384 nosy: Ronny.Pfannschmidt priority: normal severity: normal status: open title: doctest test finder doesnt find line numbers of properties ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17446 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Antoine Pitrou added the comment: The time of line 7 was much greater than line 13. Well, yes, reading 70 MB is much longer than reading a single byte :-) I feel that the underlying system call takes the size argument Indeed it does. It would be totally inefficient if it didn't. so I guess that large value suggests the C compiler to make ask the disk subsystem to read up the longer data - hence it takes the time since disk access is slower. It's not the C compiler. It's the OS kernel which reads data from the disk when you ask to. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17440 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17440] Some IO related problems on x86 windows
Antoine Pitrou added the comment: Anyway, I'm now closing the issue as invalid. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17440 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17239] XML vulnerabilities in Python
Antoine Pitrou added the comment: Since this has dragged on for quite a while, I'm probably just going to release 2.7.4 with a pointer to defusedxml in the release notes. (docs, though, perhaps) +1 too. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17239 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17443] imaplib.IMAP4_stream subprocess is opened unbuffered but ignores short reads
Gregory P. Smith added the comment: Yes imaplib can be fixed pretty easily and should use buffered IO regardless. I'm pondering if the default behavior of subprocess needs fixing as existing python 2.x code being ported to 3 doesn't expect this changed behavior of the PIPE file objects. It probably does. Thankfully my subprocess32 backport on 2.x doesn't suffer from the problem as it still uses os.fdopen. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17443 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17447] str.identifier shouldn't accept Python keywords
New submission from Raymond Hettinger: 'def'.isidentifier() True -- components: Interpreter Core messages: 184389 nosy: rhettinger priority: normal severity: normal status: open title: str.identifier shouldn't accept Python keywords type: behavior versions: Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17447 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17444] multiprocessing.cpu_count() should use hw.availcpu on Mac OS X
Changes by Ned Deily n...@acm.org: -- nosy: +ned.deily, ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9090] Error code 10035 calling socket.recv() on a socket with a timeout (WSAEWOULDBLOCK - A non-blocking socket operation could not be completed immediately)
Kristján Valur Jónsson added the comment: I will backport this. I have recently seen this happening in 2.7 in our company and it would make sense to fix this before 2.7.4 is released. -- nosy: +kristjan.jonsson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9090 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17447] str.identifier shouldn't accept Python keywords
Florent Xicluna added the comment:
According to the documentation, the reserved words are classified as
identifiers:
http://docs.python.org/3/reference/lexical_analysis.html#keywords
There's an easy workaround:
from keyword import iskeyword
def is_valid_identifier(s):
... return s.isidentifier() and not iskeyword(s)
...
is_valid_identifier('def')
False
--
nosy: +flox
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17447
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17415] Clarify docs of os.path.normpath()
Roundup Robot added the comment: New changeset ff9636af9505 by Terry Jan Reedy in branch '3.2': Issue #17415: Clarify 'this' referent by moving containing sentence just after http://hg.python.org/cpython/rev/ff9636af9505 New changeset bceb81b0016e by Terry Jan Reedy in branch '2.7': Issue #17415: Clarify 'this' referent by moving containing sentence just after http://hg.python.org/cpython/rev/bceb81b0016e New changeset 5b5a9bceb228 by Terry Jan Reedy in branch '3.2': Issue #17415: Trim trailing whitespace http://hg.python.org/cpython/rev/5b5a9bceb228 New changeset 44b9f59c6ea7 by Terry Jan Reedy in branch '2.7': Issue #17415: Trim trailing whitespace http://hg.python.org/cpython/rev/44b9f59c6ea7 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17415 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17415] Clarify docs of os.path.normpath()
Terry J. Reedy added the comment: If foo is a symbolic link, changing A/foo/../B to A/B could change the meaning, so I am sure the rewrite is correct. I used Ezio's version with a few more changes. I particular, I changed 'This collapsing', which is slightly awkward anyway, to 'This string manipulation', which addresses Gurmeet's last comment. -- resolution: - fixed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17415 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17446] doctest test finder doesnt find line numbers of properties
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17446 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17447] str.identifier shouldn't accept Python keywords
R. David Murray added the comment: Or maybe 'is_usable_identifier' :) -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17447 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14916] PyRun_InteractiveLoop fails to run interactively when using a Linux pty that's not tied to stdin/stdout
emmanuel added the comment: run the attached shell script to observe the bug ./bug.sh 0 - shows the bug ./bug.sh 1 - shows the expected behaviour (using a workaround) tested on linux with python 2.7 -- Added file: http://bugs.python.org/file29431/bug.sh ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14916 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17415] Clarify docs of os.path.normpath()
Serhiy Storchaka added the comment: os.path.normpath() works not only with strings but with bytes objects too. -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17415 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16381] Introduce option to force the interpreter to exit upon MemoryErrors
Christian Theune added the comment: I feel unsure how to help this move along. I agree that making it possible for applications to carefully work with MemoryErrors is a good idea. I don't think heuristics to determine which situation we are in will solve this but make it more spooky. (This is a semantic issue anyways). My goal is to use the flag to make it easier for operators to deal with applications that don't get it right. This isn't to defend bad programming but to support temporary relief. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17447] str.identifier shouldn't accept Python keywords
Serhiy Storchaka added the comment: Hmm. I were going to use this method for re's named group (see issue14462). There is a possibility that some third-party code uses it for checking on general Unicode-aware identifiers. The language specifification says that keywords is a subset of identifiers. However in most places in stdlib (collections.namedtuple, unittest.mock, inspect.Parameter) is_usable_identifier() should be used instead of isidentifier(). -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17447 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14916] PyRun_InteractiveLoop fails to run interactively when using a Linux pty that's not tied to stdin/stdout
Changes by emmanuel garcia6.emman...@wanadoo.fr: Added file: http://bugs.python.org/file29432/bug.sh ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14916 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14916] PyRun_InteractiveLoop fails to run interactively when using a Linux pty that's not tied to stdin/stdout
Changes by emmanuel garcia6.emman...@wanadoo.fr: Removed file: http://bugs.python.org/file29431/bug.sh ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14916 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17299] Test cPickle with real files
Changes by Serhiy Storchaka storch...@gmail.com: -- resolution: fixed - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17299 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14916] PyRun_InteractiveLoop fails to run interactively when using a Linux pty that's not tied to stdin/stdout
Kevin Barry added the comment: emmanuel, Thanks for the suggestion. Your workaround is exactly the same as using dup2 (in C) to replace stdin/stdout/stderr with the pty, however. If you added the following lines to your C code, it would have the same effect as the command-line redirection in the workaround: dup2(fileno(file), STDIN_FILENO); dup2(fileno(file), STDOUT_FILENO); dup2(fileno(file), STDERR_FILENO); In fact, that's exactly what bash does after forking, just before executing exe. In most cases, developers who use PyRun_InteractiveLoop in a pty probably also do exactly that, which is why I'm the only one who's reported this as a bug. For applications like mine, however, where the interactive Python session needs to be an unobtrusive add-on to an otherwise-complete program, this solution won't work. The standard file descriptors aren't disposable in most of the programs I work on. Thanks again! Kevin Barry -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14916 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17299] Test cPickle with real files
Serhiy Storchaka added the comment: I'm not sure what is wrong and can't check on Windows, but it is possible that this patch fixes tests. Please check it if you can. -- Added file: http://bugs.python.org/file29433/test_cpickle_fileio.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17299 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17320] os.path.abspath in window7, return error
Amaury Forgeot d'Arc added the comment: There may be an issue with the GetFullPathName system call. Could you copy the result of these functions: import sys, locale print(locale.getdefaultlocale()) print(sys.getdefaultencoding()) -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17320 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17299] Test cPickle with real files
Antoine Pitrou added the comment: I think you want to open the files in binary mode, not text mode. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17299 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16381] Introduce option to force the interpreter to exit upon MemoryErrors
Changes by Christian Theune c...@gocept.com: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14916] PyRun_InteractiveLoop fails to run interactively when using a Linux pty that's not tied to stdin/stdout
emmanuel added the comment: Kevin, Indeed the code I submitted can be written entirely in C using pipe fork execl dup2 etc. as you suggest. The only purpose of mixing bash and C is to have a short self-contained file showing the problem. Anyway, whether in C or bash the workaround is less than satisfying in that it uses up fds 0 1 2, and I have exactly the same goal and constraints as you. Finally, thanks for identifying the limitation in the python implementation and submitting a patch. Like you I hope it will be eventually applied. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14916 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16880] Importing imp will fail if dynamic loading not supported
Roundup Robot added the comment: New changeset d5aa922f97f9 by Brett Cannon in branch '3.3': Issue #16880: _imp.load_dynamic() is not defined on a platform that http://hg.python.org/cpython/rev/d5aa922f97f9 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16880 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17415] Clarify docs of os.path.normpath()
Terry J. Reedy added the comment: The top of the os doc makes it clear that path = byte string or unicode string and I meant 'string' in that generalized sense. I think 'string' is used that way elsewhere in the 3.x docs. I though of 'text manipulation', but as the doc again makes clear, unix byte string paths may not be 'text', which is why byte string paths are needed. That was my thought, anyway. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17415 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16880] Importing imp will fail if dynamic loading not supported
Brett Cannon added the comment: And this was merged into default in http://hg.python.org/cpython/rev/3c3c9ad7c297 but for some reason it didn't show up attached to this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16880 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17416] Clarify docs of os.walk()
Terry J. Reedy added the comment: I considered your point, re-read the walk entry, and still wish to leave it as it is. First, we are not in the business of providing synonyms for everything. Second, The abbreviations BFS and DFS did not immediately register with me, even though I am quite familiar with the concepts. I expect that many would find them more confusing rather than less. So they would need to be spelled out. There is also the issue of whether the defined topdown behavior is 'exactly' what any particular person would consider 'breadth-first search'. For one thing, walk does not exactly visit leaf-nodes -- it provides a list of them so that the caller can 'visit' them. Unselecting 'Resolution' amounts to partially reopening an issue. Please don't do that. -- resolution: - works for me ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17416 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Return the type you accept
Greg Ward added the comment: The particular use case that triggered this: Mercurial's test suite. It runs hg blah blah and compares the output against known good output. But Mercurial's output is just bytes, because pretty much everything in a Mercurial repo is just bytes (file data of course, but also filenames and even changeset metadata like usernames). So attempting to run the Mercurial test suite under 3.x immediately fails hard. The boiled-down essence of the bug is this: import difflib a = bhello world b = bgoodbye world [line for line in difflib.unified_diff(a, b)] Traceback (most recent call last): File stdin, line 1, in module File stdin, line 1, in listcomp File /home/greg/src/cpython/3.2/Lib/difflib.py, line 1224, in unified_diff yield '-' + line TypeError: Can't convert 'int' object to str implicitly -- nosy: +durin42, gward ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14916] PyRun_InteractiveLoop fails to run interactively when using a Linux pty that's not tied to stdin/stdout
Kevin Barry added the comment: One additional issue, which my patch doesn't address, is that PyRun_InteractiveLoop should really take *two* FILE* arguments, with the second one being optional. This is because on Linux (and presumably on other *nixes) if a read operation is blocked on a file descriptor then write operations (from other threads) to the same file descriptor will also block. That doesn't happen in the current Python implementations because PyOS_Readline is always called with two FILE* objects, anyway (stdin and stdout.) I would, however, expect such a problem to appear if a user created a Python thread in the interactive session that periodically printed to the terminal, then read input from the terminal. In that case, I would expect to see no output from the thread while the read operations were blocked, but I haven't tested it. (I don't remember if this came up after I applied my patch locally.) I actually considered this when I created the patch; however, I didn't feel like going to all the trouble of adding a member to tok and propagating the change throughout the entire core. I had hoped this bug would get more attention and I'd be able to discuss it with a developer involved in the Python project, but ultimately that didn't happen and I ended up forgetting about it. Kevin Barry -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14916 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17409] resource.setrlimit doesn't respect -1
Kushal Das added the comment: On Fedora 17, x86_64 ./python Python 3.4.0a0 (default:fb50eb64e097, Feb 22 2013, 11:43:18) [GCC 4.7.2 20120921 (Red Hat 4.7.2-2)] on linux Type help, copyright, credits or license for more information. import resource [92450 refs, 32257 blocks] resource.setrlimit(resource.RLIMIT_NOFILE, (10, -1)) Traceback (most recent call last): File stdin, line 1, in module ValueError: not allowed to raise maximum limit -- nosy: +kushaldas ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17409 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17447] str.identifier shouldn't accept Python keywords
Matthew Barnett added the comment: I already use it in the regex module for named groups. I don't think it would ever be a problem in practice because the names are invariably handled as strings. -- nosy: +mrabarnett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17447 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16057] Subclasses of JSONEncoder should not be insturcted to call JSONEncoder.decode
Roundup Robot added the comment: New changeset 5d56e1214e95 by R David Murray in branch '3.2': #16057: Clarify why the base method default is called in custom encoders. http://hg.python.org/cpython/rev/5d56e1214e95 New changeset 5f76e7db97ac by R David Murray in branch '3.3': Merge #16057: Clarify why the base method default is called in custom encoders. http://hg.python.org/cpython/rev/5f76e7db97ac New changeset 406c6fd7e753 by R David Murray in branch 'default': Merge #16057: Clarify why the base method default is called in custom encoders. http://hg.python.org/cpython/rev/406c6fd7e753 New changeset ef8ea052bcc4 by R David Murray in branch '2.7': #16057: Clarify why the base method default is called in custom encoders. http://hg.python.org/cpython/rev/ef8ea052bcc4 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16057 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16057] Subclasses of JSONEncoder should not be insturcted to call JSONEncoder.decode
R. David Murray added the comment: Thanks Kushal. -- nosy: +r.david.murray resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16057 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15927] csv.reader() does not support escaped newline when quoting=csv.QUOTE_NONE
Kalon Mills added the comment: Serhiy, sorry I'm not sure I understand your question. But if you take a look at the script that exhibits the problem I think the bug that I'm reporting becomes more clear. Namely, using the dialect configuration shown in the script, the round trip conversion from string through writer then through the reader back to string is inconsistent. The reader should return as output the same input that was given to the corresponding writer and this is not the case. So even if CVS in not well defined I believe the writer and reader should at least be consistent. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15927 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7720] Errors in tests and C implementation of raw FileIO
R. David Murray added the comment: Looks to me like this issue is out of date. -- nosy: +r.david.murray resolution: - out of date stage: test needed - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17443] imaplib.IMAP4_stream subprocess is opened unbuffered but ignores short reads
Diane Trout added the comment: So as a first stab at fixing this. I modified imaplib to wrap the process.stdin / process.stdout from with io.BufferedWriter / io.BufferedReader. I didn't use the TextIOWrapper as the imaplib wanted to work with the raw \r\n. The change seems to have fixed the problem I was having, I also checked out 82724:ef8ea052bcc4 and tried running ./python -m test -j3 before and after the buffer wrapping and it didn't seem to trigger any test case failures. -- keywords: +patch Added file: http://bugs.python.org/file29434/imaplib-buff.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17443 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3840] if TESTFN == /tmp/@test, some tests fail
Colin Su added the comment:
TESTFN will be in format @test_{pid}_tmp instead of @test right now.
So it's not easy to have exactly the same name @test_{pid}_tmp in case if you
put @test_{X}_tmp (for X in range(1,10)) so many files into the top
folder.
does it need to keep open anymore?
--
nosy: +littleq0903
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3840
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17448] test_xml should skip when no xml parsers are found
New submission from Rafael Santos: When running test_xml, an exception is thrown if no SAXReader is available, but the test is not skipped. [1/1] test_sax test test_sax crashed -- Traceback (most recent call last): File /Users/tucif/Documents/dev/cpython/cpython/Lib/test/test_sax.py, line 7, in module make_parser() File /Users/tucif/Documents/dev/cpython/cpython/Lib/xml/sax/__init__.py, line 90, in make_parser raise SAXReaderNotAvailable(No parsers found, None) xml.sax._exceptions.SAXReaderNotAvailable: No parsers found -- components: Tests messages: 184419 nosy: tucif priority: normal severity: normal status: open title: test_xml should skip when no xml parsers are found type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17448 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17448] test_xml should skip when no xml parsers are found
Changes by Rafael Santos tuci...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file29435/skiptestsax.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17448 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17448] test_sax should skip when no xml parsers are found
Changes by Rafael Santos tuci...@gmail.com: -- title: test_xml should skip when no xml parsers are found - test_sax should skip when no xml parsers are found ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17448 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10560] Fixes for Windows sources
Martin v. Löwis added the comment: I'm rejecting the patch, on grounds of PEP 11. We only support MSVC compilers up to 3 years after the extended support by Microsoft has expired. For MSC 5, this is long past. For MSC 6, extended support was discontinued in 2005, for MSVC 2002, in 2009. For all these versions, we will not accept patches anymore. MSVC 2003 will be supported until 08/10/2013, 2005 until 12/04/2016, and 2008 until 10/04/2018, so we would continue to accept for any of these for quite some time. -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10560 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17449] dev guide appears not to cover the benchmarking suite
New submission from Dave Malcolm: Does the devguide document the benchmarking suite anywhere? I can't see it anywhere in the index on http://docs.python.org/devguide/ and google doesn't seem to show anything. suggested content: * how to run the benchmarks for a Python 2 implementation * how to run the benchmarks for a Python 3 implementation Sorry if it exists and I missed it -- assignee: brett.cannon components: Devguide messages: 184421 nosy: brett.cannon, dmalcolm, ezio.melotti priority: normal severity: normal status: open title: dev guide appears not to cover the benchmarking suite ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17449 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17448] test_sax should skip when no xml parsers are found
Roundup Robot added the comment: New changeset 114e363ebf83 by R David Murray in branch '3.2': #17448: Make test_sax skip if there are no xml parsers. http://hg.python.org/cpython/rev/114e363ebf83 New changeset 3ab80610b2a2 by R David Murray in branch '3.3': Merge #17448: Make test_sax skip if there are no xml parsers. http://hg.python.org/cpython/rev/3ab80610b2a2 New changeset 59621d4f1171 by R David Murray in branch 'default': Merge #17448: Make test_sax skip if there are no xml parsers. http://hg.python.org/cpython/rev/59621d4f1171 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17448 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17448] test_sax should skip when no xml parsers are found
R. David Murray added the comment: Thanks, Rafael. -- nosy: +r.david.murray resolution: - fixed stage: - committed/rejected status: open - closed versions: +Python 3.2, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17448 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17415] Clarify docs of os.path.normpath()
Changes by Terry J. Reedy tjre...@udel.edu: -- assignee: docs@python - terry.reedy stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17415 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Return the type you accept
R. David Murray added the comment: That looks like a bug in difflib (regardless of what type it returns). But note that I'm agreeing that returning the same type you are given is generally preferrable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
paul j3 added the comment: I think the `re.compile(r'^-.+$')` behavior could be better achieved by inserting a simple test in `_parse_optional` before the `_negative_number_matcher` test. # behave more like optparse even if the argument looks like a option if self.args_default_to_positional: return None In effect, if the string does not match an action string, say it is a positional. Making this patch to argparse.py is simple. How much to test it, and how document it requires more thought. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9334 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17450] Failed to build _sqlite3
New submission from Christina Chan: Tried to install python 2.7.3 on Linux 2.6.18-194.8.1.el5 x86_64 with the following steps:- 1. after gunzip, did ./configure in Python-2.7.3 directory 2. make here is the error I ran into when executing make:- Python build finished, but the necessary bits to build these modules were not found: bsddb185 dl imageop sunaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module's name. Failed to build these modules: _sqlite3 I looked through the README and history and tried the followings but not successful:- 1. yum install libsqlite3-dev or libsqlite3-devel - cannot find either. 2. uncomment the Modules/Setup to build the bsdbb185 but that results in error. Question:- 1. Is this module _sqlite3 needed? If it is, how to fix this compiler error? -- components: Installation files: make_log.txt messages: 184426 nosy: cchan_95125 priority: normal severity: normal status: open title: Failed to build _sqlite3 type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file29436/make_log.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17450 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17451] Test to splitdoc in pydoc.py
New submission from Matt Bachmann: Found a line in splitdoc that was not being exercised. I added a test for it. -- components: Library (Lib) files: splitdoc_description_test.patch keywords: patch messages: 184427 nosy: Matt.Bachmann priority: normal severity: normal status: open title: Test to splitdoc in pydoc.py type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file29437/splitdoc_description_test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17451 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
