[issue10637] Calling CloseHandle twice (Modules/posixmodule.c)

Changes by Hirokazu Yamamoto : -- Removed message: http://bugs.python.org/msg123461 ___ Python tracker ___ ___ Python-bugs-list mailin

[issue10637] Calling CloseHandle twice (Modules/posixmodule.c)

Hirokazu Yamamoto added the comment: Well, I'm not sure. I didn't realize it while running python_d.exe. I just realized it while re-reading source code. MSDN says, (http://msdn.microsoft.com/en-us/library/ms724211%28VS.85%29.aspx) > If the application is running under a debugger, the function

[issue10637] Calling CloseHandle twice (Modules/posixmodule.c)

Georg Brandl added the comment: OK, I would say this is an acceptable bug in a beta release. Will fix it after the release is done. -- ___ Python tracker ___ _

[issue10635] Calling subprocess.Popen with preexec_fn=signal.pause blocks forever

Georg Brandl added the comment: After forking, the parent waits for the child's exec call to determine if it succeeds. Otherwise, you wouldn't get an exception in the parent when you do Popen('/bin/ech') or somesuch. -- nosy: +georg.brandl resolution: -> invalid status: open -> pen

[issue10637] Calling CloseHandle twice (Modules/posixmodule.c)

Martin v. Löwis added the comment: quick followup: there is a chance that this closes the wrong file due to race conditions, in case a different thread opens a file in-between that gets the same handle. Due to the GIL, this is unlikely -- ___ Pytho

[issue10637] Calling CloseHandle twice (Modules/posixmodule.c)

Martin v. Löwis added the comment: The second CloseHandle call will fail. As we are not checking the CloseHandle result, this has no further consequences, AFAICT. -- ___ Python tracker ___

[issue10637] Calling CloseHandle twice (Modules/posixmodule.c)

Georg Brandl added the comment: What is the result of calling it twice? -- ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue10637] Calling CloseHandle twice (Modules/posixmodule.c)

Martin v. Löwis added the comment: > Very sorry, I created the bug calling CloseHandle twice > in Modules/posixmodule.c. I think this should be fixed > before beta1 released. Can I commit it? Even if you commit it now, it won't get into beta1: the Windows binaries for that are already built. -

[issue10482] subprocess and deadlock avoidance

Nick Coghlan added the comment: The general idea is sound. My work colleagues have certainly had to implement their own reader/writer thread equivalents to keep subprocess from blocking. It makes sense to provide more robust public support for such techniques in process itself. -- no

[issue10516] Add list.clear() and list.copy()

Eli Bendersky added the comment: Boštjan, "a shallow copy": I took this directly from the documentation of dicts, which says: "D.copy() -> a shallow copy of D") As I mentioned in an earlier message, the doc-strings of list and dict methods are inconsistent in more than one way, so I'm go

[issue10637] Calling CloseHandle twice (Modules/posixmodule.c)

New submission from Hirokazu Yamamoto : Very sorry, I created the bug calling CloseHandle twice in Modules/posixmodule.c. I think this should be fixed before beta1 released. Can I commit it? -- components: None files: posixmodule.diff keywords: needs review, patch messages: 123452 nosy:

[issue10626] test_concurrent_futures implicitly installs a logging handler on import

Nick Coghlan added the comment: For 3.2, writing such errors directly to stderr would be fine (we already do that in other places via PyErr_WriteUnraisable) The test could then be modified to use test.support.captured_output to temporarily replace stderr and look at the output. The problem o

[issue10631] ZipFile and current directory change

R. David Murray added the comment: So, Martin, are you then arguing that this should in fact be considered a bug in ZipFile? The documentation for the constructor says "Open a ZIP file, where file can be either a path to a file (a string) or a file-like object." Reading that I would certain

[issue10633] string.format() Unexpected output with numeric '#' prefix and 0 width

R. David Murray added the comment: Eric, I'm assuming you just forgot to close this. On the other hand, if you wanted a +1 from another dev, you've got it :) Besides the considerations you mentioned, changing this would be a significant backward incompatibility, and is therefore pretty much

[issue10636] subprocess module has race condition with SIGCHLD handlers

joseph.h.garvin added the comment: Sorry I wasn't trying to make a request, just suggesting one potential 'fix' (I agree that it isn't really though) to make things more intutive. Unless the app is delayed from launching until after the assignment finishes though I think a workaround is requi

[issue10636] subprocess module has race condition with SIGCHLD handlers

Martin v. Löwis added the comment: > If when it caught SIGCHLD python pushed an event onto its internal > event loop to execute the handler, I think that would make sure it's > deferred until after the assignment. This is not a reasonable request. How long would you want to postpone this? Suppo

[issue10634] Windows timezone changes not reflected by time.localtime

Martin v. Löwis added the comment: This is not a bug in Python, but in the Microsoft CRT. Rewriting Python to not use the CRT anymore for this is non-trivial, in particular as the semantics of environment variables (TZ) needs to be considered. -- nosy: +loewis ___

[issue10636] subprocess module has race condition with SIGCHLD handlers

New submission from joseph.h.garvin : The following code will result in a traceback 99% of the time, though it may take two runs (sometimes the first run won't trigger it, I think due to the changing in timing from genrating the .pyc file). It spawns an instance of /bin/echo, chosen because it

[issue10635] Calling subprocess.Popen with preexec_fn=signal.pause blocks forever

New submission from joseph.h.garvin : The following code will cause the interpreter to hang: import subprocess import signal subprocess.Popen("/bin/echo", preexec_fn=signal.pause) Replace "/bin/echo" with any valid program on your box, it's just the simplest Linux example. It's expected for si

[issue10633] string.format() Unexpected output with numeric '#' prefix and 0 width

Eric Smith added the comment: I disagree that your expected output is how it should behave. I believe it's more likely that the user wants the entire field width specified. In addition, compatibility with %-formatting would dictate that we keep the current behavior. >>> '%#02x' % 10 '0xa' -

[issue10634] Windows timezone changes not reflected by time.localtime

Changes by Brian Curtin : -- components: +Library (Lib) stage: -> unit test needed versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5, Python 2.6 ___ Python tracker ___ _

[issue10588] imp.find_module raises unexpected SyntaxError

Changes by Éric Araujo : -- nosy: +brett.cannon, eric.araujo, ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue10634] Windows timezone changes not reflected by time.localtime

New submission from Eric Pruitt : If the current time zone changes on Windows, time.localtime will continue to return results that reflect the time zone the system used when the module was imported. My current work around is to use GetLocalTime from kernel32 with ctypes. Windows does not have

[issue10633] string.format() Unexpected output with numeric '#' prefix and 0 width

New submission from Alex Leone : When using the '#' to prefix a numeric argument in format() with a '0x' or others, the 0-width padding takes into account the '0x' characters. This is unexpected - the 0-width should NOT take into account the prefix. Current Behavior: > "{0:#02x}".format(10) '

[issue8910] Write a text file explaining why Lib/test/data exists

Martin v. Löwis added the comment: All README files are automatically packages, and so is this one. -- status: open -> closed ___ Python tracker ___ _

[issue8910] Write a text file explaining why Lib/test/data exists

Éric Araujo added the comment: Temporarily reopening so that Martin can decide whether he wants to add Lib/test/data/README to msi.py -- status: closed -> open ___ Python tracker __

[issue10596] modulo operator bug

Сергей Хлутчин added the comment: Yes i agree, the first example is the result of rounding error, as well as here: >>> 4.0-2.22044604925e-16==4.0 True -- ___ Python tracker ___

[issue10631] ZipFile and current directory change

Martin v. Löwis added the comment: More formally: it's unspecified. I'd like to propose this general principle: If you pass a relative path to some library that gets stored in the library, it's unspecified whether the cwd is consider at the point of passing the path or at the point of using i

[issue10632] multiprocessing generates a fatal error

Changes by Brian Quinlan : -- title: multiprocessing gene -> multiprocessing generates a fatal error ___ Python tracker ___ ___ Python

[issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...

Georg Brandl added the comment: I leave this to MAL, on whose behalf I finished this to be in time for beta. -- assignee: -> lemburg ___ Python tracker ___ _

[issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...

Martin v. Löwis added the comment: As per http://mail.python.org/pipermail/python-dev/2010-December/106374.html I think this checkin should be reverted, as it's breaking the language moratorium. -- ___ Python tracker

[issue10517] test_concurrent_futures crashes with "Fatal Python error: Invalid thread state for this thread"

Brian Quinlan added the comment: I've filed a new bug (http://bugs.python.org/issue10632) against multiprocessing and this bug dependent on it. In the meantime, I can't repro this on ubuntu 10.04 LTS so I'm going to install Centos and give that a go. -- dependencies: +multiprocessing

[issue10632] multiprocessing gene

New submission from Brian Quinlan : multiprocessing generates fatal error "Invalid thread state for this thread" in PyThreadState_Swap This seems to happen on RHEL 5 and Centos 5.5 Here is the minimal repro: >>> import multiprocessing.managers >>> mpp = multiprocessing.Pool(4) >>> sm = multipr

[issue5587] vars() no longer has a useful __repr__

Changes by Éric Araujo : -- nosy: +eric.araujo -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue10630] dict_proxy.keys() / values() / items() are lists

Changes by Éric Araujo : -- nosy: +eric.araujo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue8194] Incompatible API change in xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue10626] test_concurrent_futures implicitly installs a logging handler on import

Brian Quinlan added the comment: I've attached a patch that removes the code that installs a handler to the futures logger. I'm not sure if this is the correct approach though - it means that "impossible" errors will only be reported to the user through a message like "no handler installed f

[issue10516] Add list.clear() and list.copy()

Terry J. Reedy added the comment: Objects/dictobject.c -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue10631] ZipFile and current directory change

Antoine Pitrou added the comment: I don't know, but I wouldn't call it a bug either. In general it's not recommended to change the current directory except at the very beginning of your application. -- nosy: +pitrou ___ Python tracker

[issue6490] os.popen documentation in 2.6 is probably wrong

Éric Araujo added the comment: I will refresh the patch, update it to recommend use as a context manager, and submit the patch here for review before committing. It’s too late for 2.6, though. Benjamin, I hope you won’t mind me taking the assignment from you. -- assignee: benjamin.p

[issue9101] reference json format in file formats chapter

Changes by Éric Araujo : -- status: closed -> open versions: -Python 2.6 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue10631] ZipFile and current directory change

New submission from Hirokazu Yamamoto : Is this intended behavior? Creating zipfile.ZipFile with relative path and changing current directory, relative path is resolved from new directory not from the directory object was created. F:\>py3k Python 3.2a4+ (py3k, Dec 3 2010, 22:11:05) [MSC v.1200

[issue10630] dict_proxy.keys() / values() / items() are lists

New submission from Daniel Urban : The keys, values and items methods of dict_proxy return a list, while dict.keys, etc. return dictionary views (dict_keys, etc.). dict_proxy is used as the __dict__ attribute of classes. This is documented at http://docs.python.org/dev/py3k/reference/datamodel

[issue10516] Add list.clear() and list.copy()

Changes by Mark Dickinson : Removed file: http://bugs.python.org/file19948/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue10516] Add list.clear() and list.copy()

Changes by Mark Dickinson : Removed file: http://bugs.python.org/file19947/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue5587] vars() no longer has a useful __repr__

Daniel Urban added the comment: > Thanks for the patch! Can you include also a test that verifies > that the repr is printed correctly? Sure. Where should I put the test? I didn't found any dict_proxy tests, except in test_descr.py ("# Classes don't allow __dict__ assignment and have readonly

[issue5587] vars() no longer has a useful __repr__

Ezio Melotti added the comment: Thanks for the patch! Can you include also a test that verifies that the repr is printed correctly? (You can take a look at #7310 if you want to see a possible approach.) -- ___ Python tracker

[issue5587] vars() no longer has a useful __repr__

Daniel Urban added the comment: Based on David Stanek's patch I've made a patch against the current py3k branch. The only difference is, that dict_proxy.__repr__ instead of simply returning the repr of the dict, returns approximately "dict_proxy({!r})".format(self.dict). -- nosy: +du

[issue10576] Add a progress callback to gcmodule

Changes by Antoine Pitrou : -- stage: -> patch review versions: +Python 3.3 -Python 3.2 ___ Python tracker ___ ___ Python-bugs-list m

[issue10629] Arbitrary precision

Mark Dickinson added the comment: Right; this is expected behaviour. The error you're seeing comes from the implicit conversion of 1234! from long to float. -- status: pending -> closed ___ Python tracker __

[issue10629] Arbitrary precision

Georg Brandl added the comment: Note that while Python's long type gives you unlimited-size integers, the float type doesn't make such promises: it is just a double-precision float. As such, math.factorial(1234) cannot be interpreted; it would simply be positive infinity. -- compone

[issue10292] tarinfo should use relative symlinks

Lars Gustäbel added the comment: Okay, this bug has been fixed in the 2.7 series. Python 2.6 is now in security-fix-only mode which means that there will not be a fix for it. Therefore, I close this issue. -- resolution: -> fixed status: open -> closed versions: +Python 2.6 -Python 2

[issue1294232] Error in metaclass search order

Daniel Urban added the comment: > What also worries me is the difference between the "class" > statement and the type() function. I think the reason of this is that the class statement uses the __build_class__ builtin function. This function determines the metaclass to use (by getting the met

[issue10626] test_concurrent_futures implicitly installs a logging handler on import

Georg Brandl added the comment: What a nice mess :) Raising priority so that this doesn't get overlooked. -- priority: normal -> deferred blocker ___ Python tracker ___ ___

[issue4391] use proper gettext plurals forms in argparse and optparse

Steven Bethard added the comment: The workaround in TestImportStar is fine. The test is really just meant to make sure that __all__ contains all the current API methods, and the "_" checks were the easiest way at the time to check that. -- ___ Pyth

[issue10516] Add list.clear() and list.copy()

Boštjan Mejak added the comment: Can you please help me find the definition of the copy() method of dict in the Python sources? I want to see how that method is defined and compare the definition to the one in Eli's patch. -- Added file: http://bugs.python.org/file19948/unnamed __

[issue10516] Add list.clear() and list.copy()

Boštjan Mejak added the comment: I'm troubled with one little letter: "L.copy() -> list -- a shallow copy of L"); should be "L.copy() -> list -- shallow copy of L"); without the letter 'a', because other sentences also don't say "L.__sizeof__() -- *A* size of L in memory, in bytes"); Plea

[issue10576] Add a progress callback to gcmodule

Kristján Valur Jónsson added the comment: Here is a third patch. The callback now gets two argument, phase and info. I've added documentation and unittests. -- Added file: http://bugs.python.org/file19946/gccallback3.patch ___ Python tracker

[issue10629] Arbitrary precision

New submission from Bill McEachen : from this link [http://en.wikipedia.org/wiki/PARI/GP#Usage_examples], I wanted to contrast arbitrary precision with the other pgm I use, Pari/GP. I tried the xample there which was: 123456! + 0. Now, behavior seems the same without the "+0." for both. Howev

[issue10626] test_concurrent_futures implicitly installs a logging handler on import

Nick Coghlan added the comment: This is unrelated to issue 10517 (based on Dave Malcolm's initial investigation, that looks like it may be a genuine problem in multiprocessing) Instead, this relates to a problem in concurrent.futures where it installs a logging *handler* as a side effect of i

[issue10628] Typos in 3.2 what’s new

Georg Brandl added the comment: Applied rest in r87083. -- nosy: +georg.brandl resolution: -> fixed status: open -> closed ___ Python tracker ___ __