[issue3982] support .format for bytes

Martin v. Löwis added the comment: I admit that it is puzzling that string interpolation is apparently the fastest way to assemble byte strings. It involves parsing the format string, so it ought to be slower than anything that merely concatenates (such as cStringIO). (I do understand why + is

[issue3982] support .format for bytes

Antoine Pitrou added the comment: > > What I know from Twisted is there are many specific cases where, indeed, > > binary protocol strings are formed by string formatting, e.g. in the FTP > > implementation (and for good reason since those protocols are either ASCII > > or an ASCII superset). >

[issue3982] support .format for bytes

Terry J. Reedy added the comment: After re-reading everything, I have somewhat changed my mind on this proposal. Perhaps 3.0 threw out too much, making it overly difficult to do some things that were to easy in 2.x and to write cross-version code. String formatting converts all arguments to st

[issue3982] support .format for bytes

Antoine Pitrou added the comment: Le mardi 22 janvier 2013 à 23:34 +, Terry J. Reedy a écrit : > Terry J. Reedy added the comment: > > >it would probably be reasonable to make these protocols use str objects at > >the heart, and only convert to bytes after the formatting is done. > > I pre

[issue15359] Sockets support for CAN_BCM

Brian Thorne added the comment: I've added (some) docs and added checking of the BCM constants to the test_socket module. I would guess that checking each broadcast manager function provided by the kernel isn't required? -- Added file: http://bugs.python.org/file28805/bcm4.patch

[issue17016] _sre: avoid relying on pointer overflow

Matthew Barnett added the comment: Lines 1000 and 1084 will be a problem only if you're near the top of the address space. This is because: 1. ctx->pattern[1] will always be <= ctx->pattern[2]. 2. A value of 65535 in ctx->pattern[2] means unlimited, even though SRE_CODE is now UCS4. See also

[issue3982] support .format for bytes

Glyph Lefkowitz added the comment: On Jan 22, 2013, at 3:34 PM, Terry J. Reedy wrote: > I presume this would mean adding 'if py3: out = out.encode()' after the > formatting. As I said before, this works much better in 3.3+ than in 3.2-. > Some actual numbers: I'm glad that this operation has

[issue3982] support .format for bytes

Glyph Lefkowitz added the comment: > Antoine Pitrou added the comment: > The fact that "there are plenty of other Python applications that don't > use Twisted which nevertheless need to emit formatted sequences of > bytes" is *precisely* a good reason for this to be discussed more > visibly. I d

[issue17017] email.utils.getaddresses fails for certain addresses

New submission from Andreas Dewes: email.utils.getaddresses doesn't seem to work if the quoted part of address contains "\r" or "\n" characters. An example: --- from email.utils import getaddresses address = '"Data Mining, Statistics, Big Data, and Data Visualization Group\r\n Members" ' getad

[issue3982] support .format for bytes

Terry J. Reedy added the comment: >it would probably be reasonable to make these protocols use str objects at the >heart, and only convert to bytes after the formatting is done. I presume this would mean adding 'if py3: out = out.encode()' after the formatting. As I said before, this works muc

[issue15881] multiprocessing 'NoneType' object is not callable

Philip Jenvey added the comment: Targeting this for 2.7.4. If Alexander doesn't get to it, ping me and I'll do it -- nosy: +benjamin.peterson, georg.brandl, larry, pjenvey priority: normal -> release blocker ___ Python tracker

[issue3982] support .format for bytes

Glyph Lefkowitz added the comment: On Jan 22, 2013, at 1:46 PM, STINNER Victor wrote: > 2013/1/22 Guido van Rossum : >> Twisted still would like to see this. > > Sorry, but this argument doesn't convince me. A better argument is > that bytes+bytes+...+bytes is inefficient: it creates a lot of

[issue3982] support .format for bytes

STINNER Victor added the comment: 2013/1/22 Guido van Rossum : > Twisted still would like to see this. Sorry, but this argument doesn't convince me. A better argument is that bytes+bytes+...+bytes is inefficient: it creates a lot of temporary objects instead of computing the final size directly,

[issue1100942] Add datetime.time.strptime and datetime.date.strptime

Changes by Adam Collard : -- nosy: +adam-collard ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue11379] Remove "lightweight" from minidom description

Ezio Melotti added the comment: Fixed, thanks for the patch! -- assignee: docs@python -> ezio.melotti resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed type: performance -> enhancement ___ Python tracker

[issue11379] Remove "lightweight" from minidom description

Roundup Robot added the comment: New changeset c2ae1ed03853 by Ezio Melotti in branch '2.7': #11379: rephrase minidom documentation to use the term "minimal" instead of "lightweight". Patch by Éric Araujo. http://hg.python.org/cpython/rev/c2ae1ed03853 New changeset b9c0e050c935 by Ezio Melotti

[issue3982] support .format for bytes

Antoine Pitrou added the comment: > there are plenty of other Python applications that don't use Twisted > which nevertheless need to emit formatted sequences of bytes. The fact that "there are plenty of other Python applications that don't use Twisted which nevertheless need to emit formatted

[issue3982] support .format for bytes

Glyph Lefkowitz added the comment: On Jan 22, 2013, at 11:39 AM, Antoine Pitrou wrote: > Antoine Pitrou added the comment: > > I agree with the idea that the feature set should very limited, actually > perhaps more limited than what you just said. For example, I think any kind > of implicit

[issue15958] bytes.join() should allow arbitrary buffer objects

Changes by Glyph Lefkowitz : -- nosy: +glyph ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue3982] support .format for bytes

Antoine Pitrou added the comment: Right, but we're not writing builtin type methods specifically for Twisted. I agree with the idea that the feature set should very limited, actually perhaps more limited than what you just said. For example, I think any kind of implicit str->bytes conversion i

[issue3982] support .format for bytes

Changes by Glyph Lefkowitz : -- nosy: +glyph ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue3982] support .format for bytes

Guido van Rossum added the comment: Well, msg171804 makes it a much bigger project than the feature that Twisted actually needs. Quoting: * The default formatting should not use str(), but buffer protocol. Fine. * There is no place for floating point. Actually they do need it -- and it's triv

[issue12411] cgi.parse_multipart is broken on 3.x

Guido van Rossum added the comment: Thank you very much Senthil! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue12411] cgi.parse_multipart is broken on 3.x

Senthil Kumaran added the comment: I personally think, that the "grey area" of multipart form encoding and trying to use email's updated features for parsing was holding it, not the tests. This can be submitted IMO after looking at the "related bugs", I shall do a review on this one today. --

[issue3982] support .format for bytes

Ezio Melotti added the comment: Serhiy did a nice summary in msg171804, and I think this is PEP material too. What he wrote could be used as a starting point; the next step would be collecting use cases (the Twisted guys seem to have some). Once we have defined what we want we can figure out

[issue3982] support .format for bytes

Antoine Pitrou added the comment: Given the issues which have been brought here, I agree that it's PEP material. -- nosy: +pitrou ___ Python tracker ___ __

[issue12411] cgi.parse_multipart is broken on 3.x

Guido van Rossum added the comment: Does anyone who was on this bug previously (e.g. the original author or the reviewers) know what was holding up the patch? Does it need more review? More tests? Is there any reason to reject fixing this at all? (I hope not.) As far as replacing the whole thing

[issue16507] Patch selectmodule.c to support WSAPoll on Windows

Guido van Rossum added the comment: Agreed, it does not sound very useful to support WSAPoll(), neither in selector.py (which is intended to eventually be turned into stdlib/select.py) nor in PEP 3156. And then, what other use is there for it, really? --

[issue3982] support .format for bytes

Guido van Rossum added the comment: Honestly, what Twisted is mostly after is a way to write code that works both with Python 2 and Python 3. They need the types I mentioned only (bytes, int, float) and not too many advanced features of .format() -- but if it's not called .format() or if the synt

[issue17013] Allow waiting on a mock

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue16507] Patch selectmodule.c to support WSAPoll on Windows

Charles-François Natali added the comment: > I thought SOCK_DGRAM messages just got truncated at the receiving end. You were referring to partial writes: for a datagram-oriented protocol, if the datagram can't be sent atomically (in one send()/write() call), the kernel will return EAGAIN. On the

[issue9708] cElementTree iterparse does not support "parser" argument

Silvan Jegen added the comment: The situation is as follows. According to the online documentation of Python 2.7 the xml.etree.ElementTree.iterparse() function takes up to three arguments, two of them named ones: xml.etree.ElementTree.iterparse(source, events=None, parser=None) In the C i

[issue3982] support .format for bytes

Benjamin Peterson added the comment: The problem is not so much the types allowed the code for dealing with the format string. The parsing code for format specificers is pretty unicode specific now. If that was to be made generic again, it's worth considering exactly what features belong in a

[issue3982] support .format for bytes

Christian Heimes added the comment: IMHO a useful API has to provide a more low level functionality like "format number as 32 bit unsigned integer in network endian". A bytes.format() function should support all format chars from http://docs.python.org/3/library/struct.html#format-characters p

[issue12323] ElementPath 1.3 expressions

patrick vrijlandt added the comment: Dear Eli, According to the XPath spec, the 'position' as can be used in xpath expressions, should be positive. However, the current implementation (example below from 3.3.0) accepts some values that should not be ok. Therefore, I do not agree that it behav

[issue12411] cgi.parse_multipart is broken on 3.x

Changes by Glyph Lefkowitz : -- nosy: +glyph ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue12411] cgi.parse_multipart is broken on 3.x

Guido van Rossum added the comment: Twisted would really like to see this bug fixed. -- nosy: +gvanrossum ___ Python tracker ___ ___ P

[issue3982] support .format for bytes

Guido van Rossum added the comment: Would it be easier if the only format codes/types supported were bytes, int and float? -- ___ Python tracker ___ __

[issue3982] support .format for bytes

Benjamin Peterson added the comment: Implementing this certainly hasn't gotten any easier as 3.x str.format has evoled. The kind of format codes and modifiers wanted to for formatting byte strings might be different that those for text strings. I think it probably needs a pep. -- ___

[issue3982] support .format for bytes

Guido van Rossum added the comment: Twisted still would like to see this. -- nosy: +gvanrossum ___ Python tracker ___ ___ Python-bugs-l

[issue17012] Differences between /usr/bin/which and shutil.which()

Ned Deily added the comment: FWIW, the POSIX standard gives some guidance on how PATH is to be interpreted for conforming systems, including: "A zero-length prefix is a legacy feature that indicates the current working directory. It appears as two adjacent characters ( "::" ), as an initial

[issue16507] Patch selectmodule.c to support WSAPoll on Windows

Richard Oudkerk added the comment: > For SOCK_STREAM, yes, not for SOCK_DGRAM I thought SOCK_DGRAM messages just got truncated at the receiving end. -- ___ Python tracker ___ __

[issue17016] _sre: avoid relying on pointer overflow

Serhiy Storchaka added the comment: LGTM. There are other doubtful places, at lines: 658, 678, 1000, 1084, 2777, 3111. -- ___ Python tracker ___

[issue16507] Patch selectmodule.c to support WSAPoll on Windows

Guido van Rossum added the comment: Short reads/writes are orthogonal to EAGAIN. All the mainline code treats readiness as a hint only, so tests should too. --Guido van Rossum (sent from Android phone) -- ___ Python tracker

[issue11379] Remove "lightweight" from minidom description

Éric Araujo added the comment: Sure, feel free to commit this. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue16507] Patch selectmodule.c to support WSAPoll on Windows

Charles-François Natali added the comment: > For SOCK_STREAM, yes, not for SOCK_DGRAM (or for a pipe when trying to > write more than PIPE_BUF, although I guess any sensible implementation > doesn't report the pipe write ready if there's less than PIPE_BUF > space left). That should be of course

[issue16507] Patch selectmodule.c to support WSAPoll on Windows

Charles-François Natali added the comment: > If only one byte is available, recv(4096) should simply return a partial > result. Of course, but how do you know if there's data left to read without calling select() again? It's much better to call read() until you get EAGAIN than calling select()

[issue16672] improve tracing performances when f_trace is NULL

Xavier de Gaye added the comment: One may argue that this is not only a performances patch and that it fixes the wasting of cpu resources when tracing is on. Wasting cpu resources is a bug. Anyway, this is fine with me to close this minor issue on 2.7. The test_hotshot test is ok on my linux box

[issue17012] Differences between /usr/bin/which and shutil.which()

R. David Murray added the comment: And no, what I wrote wasn't clear :) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue17012] Differences between /usr/bin/which and shutil.which()

R. David Murray added the comment: I was speaking in general of 'which program would be executed if the command is typed at the prompt' as being system dependent, which it demonstrably is since the behavior on unix and windows differs with regards to the current directory. --

[issue17016] _sre: avoid relying on pointer overflow

Changes by Ezio Melotti : -- components: +Regular Expressions -None nosy: +ezio.melotti, mark.dickinson, mrabarnett, serhiy.storchaka stage: -> patch review versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 -Python 3.5 ___ Python tracker

[issue17016] _sre: avoid relying on pointer overflow

New submission from Nickolai Zeldovich: Modules/_sre.c relies on pointer overflow in 5 places to check that the supplied offset does not cause wraparound when added to a base pointer; e.g.: SRE_CODE prefix_len; GET_ARG; prefix_len = arg;

[issue16672] improve tracing performances when f_trace is NULL

Benjamin Peterson added the comment: That, too. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs

[issue16672] improve tracing performances when f_trace is NULL

Antoine Pitrou added the comment: I don't think performance patches should be committed to bugfix branches (especially 2.7 which is in slow maintenance mode). Recommend closing. -- nosy: +pitrou ___ Python tracker

[issue17012] Differences between /usr/bin/which and shutil.which()

Serhiy Storchaka added the comment: No, I noted that result of PATH=: or PATH=$PATH: can be platform dependent (I'm  not sure). -- ___ Python tracker ___

[issue1159051] Handle corrupted gzip files with unexpected EOF

Roundup Robot added the comment: New changeset 174332b89a0d by Serhiy Storchaka in branch '3.2': Issue #1159051: GzipFile now raises EOFError when reading a corrupted file http://hg.python.org/cpython/rev/174332b89a0d New changeset 87171e88847b by Serhiy Storchaka in branch '3.3': Issue #1159051

[issue17012] Differences between /usr/bin/which and shutil.which()

R. David Murray added the comment: What I think it is suppose to do (the user expects it to do) is find the program that would be run if the command were typed at the command prompt. rdmurray@hey:~>which python /usr/bin/python rdmurray@hey:~>export PATH= rdmurray@hey:~>which python python not f

[issue16507] Patch selectmodule.c to support WSAPoll on Windows

Richard Oudkerk added the comment: According to Alan Cox It's a design decision and a huge performance win. It's one of the areas where POSIX read in its strictest form cripples your performance. See https://lkml.org/lkml/2011/6/18/103 > (For write ready, you can obviously have "spurio

[issue16507] Patch selectmodule.c to support WSAPoll on Windows

Antoine Pitrou added the comment: > Also, in real code you have to be prepared to catch EAGAIN regardless > of spurious notifications: when a FD is reported as read ready, it > just means that there are some data to read. Depending on the > watermark, it could mean that only one byte is available

[issue16672] improve tracing performances when f_trace is NULL

Benjamin Peterson added the comment: This patch causes test_hotshot to fail. -- ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue16507] Patch selectmodule.c to support WSAPoll on Windows

Charles-François Natali added the comment: > It appears that Linux's "spurious readiness notifications" are a deliberate > deviation from the POSIX standard. (They are mentioned in the BUGS section > of the man page for select.) I don't think it's a deliberate deviation, but really bugs/limit

[issue11367] xml.etree.ElementTree.find(all): docs are wrong

Eli Bendersky added the comment: Patches to documentation of 3.2 and 2.7 are welcome -- ___ Python tracker ___ ___ Python-bugs-list ma

[issue16672] improve tracing performances when f_trace is NULL

Jesús Cea Avión added the comment: Benjamin, ans the previous commiter, could you possibly check the 2.7 proposed patch? -- ___ Python tracker ___ __

[issue16672] improve tracing performances when f_trace is NULL

Changes by Jesús Cea Avión : -- assignee: -> benjamin.peterson nosy: +benjamin.peterson resolution: fixed -> stage: committed/rejected -> patch review status: closed -> open ___ Python tracker ___

[issue16672] improve tracing performances when f_trace is NULL

Xavier de Gaye added the comment: Attached is a patch for the current head of 2.7. It would nice to have this patch on 2.7 too. With this patch, an implementation of pdb running on 2.7 with an extension module, runs at 1.2 times the speed of the interpreter when the trace function is active (see

[issue12323] ElementPath 1.3 expressions

Eli Bendersky added the comment: The official documentation of XML ET is at http://docs.python.org/dev/library/xml.etree.elementtree.html The arguments to XPath are clearly described, and the implementation behaves correctly. We will continue supporting XPath syntax there, rather than Python

[issue17014] _getfinalpathname() no more used in 3.4

Antoine Pitrou added the comment: Rejecting. It will be used for Windows realpath() (issue14094) and, even if it's a private function, it can also be useful for third-party libs such as pathlib. -- resolution: -> rejected stage: patch review -> committed/rejected status: open -> close

[issue15546] Iteration breaks with bz2.open(filename,'rt')

Roundup Robot added the comment: New changeset 0f25119ceee8 by Serhiy Storchaka in branch '3.2': #15546: Fix GzipFile.peek()'s handling of pathological input data. http://hg.python.org/cpython/rev/0f25119ceee8 -- ___ Python tracker

[issue9708] cElementTree iterparse does not support "parser" argument

Eli Bendersky added the comment: Could you point out specifically which methods in ET don't work with the argument, and describe the problem in general? -- ___ Python tracker ___

[issue16507] Patch selectmodule.c to support WSAPoll on Windows

Richard Oudkerk added the comment: It appears that Linux's "spurious readiness notifications" are a deliberate deviation from the POSIX standard. (They are mentioned in the BUGS section of the man page for select.) Should I just apply the following patch to the default branch? diff -r 3ef7f1

[issue17001] Make uuid.UUID use functools.total_ordering

Ramchandra Apte added the comment: @Raymond Hettinger Why? Please respond to my comments. -- ___ Python tracker ___ ___ Python-bugs-li

[issue17014] _getfinalpathname() no more used in 3.4

Ramchandra Apte added the comment: LGTM -- nosy: +ramchandra.apte ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue4934] tp_del and tp_version_tag undocumented

Changes by Ezio Melotti : -- type: -> enhancement versions: +Python 3.3, Python 3.4 -Python 3.1 ___ Python tracker ___ ___ Python-bugs

[issue4934] tp_del and tp_version_tag undocumented

Ronald Oussoren added the comment: tp_cache and tp_weaklist are also for internal use only, but are documented. One reason for documenting them is that users will run into them when running with a high enough warning level in GCC. -- nosy: +ronaldoussoren _

[issue17015] mock could be smarter and inspect the spec's signature

Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue10048] urllib.request documentation confusing

Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue8350] Document lack of support for keyword arguments in C functions

Changes by Ezio Melotti : -- nosy: +ezio.melotti title: Document lack of support for keyword arguments in C functions -> Document lack of support for keyword arguments in C functions versions: +Python 3.3, Python 3.4 -Python 3.1 ___ Python track

[issue9708] cElementTree iterparse does not support "parser" argument

Changes by Ezio Melotti : -- nosy: +ezio.melotti versions: +Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue12323] ElementPath 1.3 expressions

Changes by Ezio Melotti : -- stage: -> needs patch versions: +Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue10994] implementation details in sys module

Changes by Ezio Melotti : -- versions: +Python 3.3, Python 3.4 -Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue17015] mock could be smarter and inspect the spec's signature

Antoine Pitrou added the comment: (note: also fails if I use `mock = Mock(wraps=f)` instead of `mock = Mock(spec=f)`) -- ___ Python tracker ___ _

[issue4965] Can doc index of html version be separately scrollable?

Changes by Ezio Melotti : -- keywords: +easy stage: -> patch review versions: -Python 3.1 ___ Python tracker ___ ___ Python-bugs-list

[issue17015] mock could be smarter and inspect the spec's signature

New submission from Antoine Pitrou: This is a bit annoying: >>> def f(a, b): pass ... >>> mock = Mock(spec=f) >>> mock(1, 2) >>> mock.assert_called_with(1, 2) >>> mock.assert_called_with(a=1, b=2) Traceback (most recent call last): File "", line 1, in File "/home/antoine/cpython/default/L

[issue1554] socketmodule cleanups: allow the use of keywords in socket functions

Changes by Ezio Melotti : -- versions: +Python 3.4 -Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue8730] Spurious test failure in distutils

Changes by Ezio Melotti : -- versions: +Python 3.4 -Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue17012] Differences between /usr/bin/which and shutil.which()

Serhiy Storchaka added the comment: /usr/bin/which is not a Bash. ;) The path can be unexpectedly empty. If we got None then we can detect the error, but if we got something out of the path then we can miss our fault. -- ___ Python tracker

[issue15483] CROSS: initialise include and library paths in setup.py

Changes by Ezio Melotti : -- keywords: +easy stage: -> patch review type: -> behavior versions: +Python 3.4 ___ Python tracker ___ _

[issue11551] test_dummy_thread.py test coverage improvement

Changes by Ezio Melotti : -- keywords: +easy nosy: +ezio.melotti, ramchandra.apte stage: -> patch review versions: +Python 3.4 ___ Python tracker ___ ___

[issue17014] _getfinalpathname() no more used in 3.4

New submission from Serhiy Storchaka: It was a helper function for samepath on windows and not used more since samepath implementation was changed. Here is a patch which remove it. -- components: Extension Modules, Library (Lib), Windows files: drop_getfinalpathname.patch keywords: pat

[issue17012] Differences between /usr/bin/which and shutil.which()

Antoine Pitrou added the comment: I'm not sure reproducing the quirks of /usr/bin/which is a good idea. shutil.which() is meant to be useful and easy to understand, not to be 100% bash-compatible. And, anyway, what would be the point of passing an empty path, if the return value is guaranteed

[issue17013] Allow waiting on a mock

Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue17013] Allow waiting on a mock

New submission from Antoine Pitrou: In non-trivial tests, you may want to wait for a method to be called in another thread. This is a case where unittest.mock currently doesn't help. It would be nice to be able to write: myobj.some_method = Mock(side_effect=myobj.some_method) # launch some

[issue17012] Differences between /usr/bin/which and shutil.which()

New submission from Serhiy Storchaka: $ PATH= /usr/bin/which python $ PATH=: /usr/bin/which python ./python $ PATH=/usr: /usr/bin/which python ./python >>> shutil.which('python', path='') '/usr/bin/python' >>> shutil.which('python', path=':') 'python' >>> shutil.which('python', path='/usr:') 'py

[issue16957] shutil.which() shouldn't look in working directory on unix-y systems

Serhiy Storchaka added the comment: I have reorganized tests a little. -- assignee: -> serhiy.storchaka stage: patch review -> commit review versions: +Python 3.4 Added file: http://bugs.python.org/file28801/shutil_which_cwd4.patch ___ Python tracker

[issue11379] Remove "lightweight" from minidom description

Antoine Pitrou added the comment: Someone should go ahead and apply this. Éric, perhaps? -- stage: needs patch -> commit review ___ Python tracker ___ ___

[issue17011] ElementPath ignores different namespace mappings for the same path expression

Changes by Serhiy Storchaka : -- nosy: +eli.bendersky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue16993] shutil.which() should preserve path case

Serhiy Storchaka added the comment: I chose the first simplest variant. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker ___ _

[issue16208] getaddrinfo returns wrong results if IPv6 is disabled

Marc Schlaich added the comment: I agree with schmir, this is really unexpected behavior. At least it should be fixed in the documentation. The doc currently says you get a 4-tuple for IPv6, which is just wrong in this case. Prominent library stumbled about this issue is Tornado (https://gith

[issue16993] shutil.which() should preserve path case

Roundup Robot added the comment: New changeset 28282e4e9d04 by Serhiy Storchaka in branch '3.3': Fix shutil.which() test for issue #16993. http://hg.python.org/cpython/rev/28282e4e9d04 New changeset e8f40d4f497c by Serhiy Storchaka in branch 'default': Fix shutil.which() test for issue #16993. h

[issue8858] socket.getaddrinfo returns wrong results for IPv6 addresses

Marc Schlaich added the comment: Ok, I found #16208, just ignore me :-) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

  1   2   >