[issue24632] Improve documentation about __main__.py
New submission from Ezio Melotti: __main__.py seems to only be mentioned briefly in a couple of places in the official docs: 1) https://docs.python.org/3/library/__main__.html 2) https://docs.python.org/3/using/cmdline.html#cmdoption-m The first link only says: For a package, the same effect can be achieved by including a __main__.py module, the contents of which will be executed when the module is run with -m. (-m should actually use :option:`-m` to automatically link to the second URL.) The second link mentions __main__.py in two sentences: Execute the Python code contained in script, which must be a filesystem path (absolute or relative) referring to either a Python file, a directory containing a __main__.py file, or a zipfile containing a __main__.py file. If the script name refers to a directory or zipfile, the script name is added to the start of sys.path and the __main__.py file in that location is executed as the __main__ module. I think it would be better to expand the first link to state clearly what is __main__.py and what is its purpose. In addition, the section should clarify a few more things, e.g. when it should be used, what it should contain, if it's ok to have other __main__.py in the subpackages (e.g. test/__main__.py to run the tests with python -m package.test), how it interacts __init__.py (which one is executed first?). Perhaps it should also get a glossary entry and/or a short mention in the tutorial together with zip imports. In addition to the two links above, a Google search returns the stackoverflow question What is __main__.py? as first result, and a couple more related questions that could/should be answered by our docs. -- assignee: docs@python components: Documentation messages: 246719 nosy: docs@python, ethan.furman, ezio.melotti, nedbat priority: normal severity: normal stage: needs patch status: open title: Improve documentation about __main__.py type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24632 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14373] C implementation of functools.lru_cache
Ned Deily added the comment: Serhiy, I'll try making a 3.5.0b3+patch installer build in the same manner as the 3.5.0b3 installer build. But I may not get to it for several days. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14373 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24633] Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py'
New submission from Sébastien Celles: Hello, the package name readme conflicts with Python installed site-packages/README file on case-insensitive filesystems (Mac OS X). https://github.com/pypa/readme/issues/26 https://github.com/mgedmin/restview/issues/30 https://groups.google.com/a/continuum.io/forum/#!topic/anaconda/AGHXzB1sN0I I wonder if README file should be be renamed README.rst or README.txt or README.md to avoid this issue or if readme package should be renamed. Kind regards -- components: Macintosh messages: 246721 nosy: Sébastien Celles, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py' versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24633 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16041] poplib: unlimited readline() from connection
Chris Smowton added the comment: +1 to the above; suggest this should be rolled back and replaced with a total message size limit. -- nosy: +Chris Smowton ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16041 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24539] StreamReaderProtocol.eof_received() should return True to keep the transport open
Guido van Rossum added the comment: I've added the return True from eof_received() to the asyncio repo (https://github.com/python/asyncio/commit/ce3ad816a2ef9456b4b1c26b99dfc85ea1236811), but it still needs a unittest and merging into CPython 3.4 and up. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24539 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24632] Improve documentation about __main__.py
Ned Batchelder added the comment: BTW, the Stack Overflow answer: http://stackoverflow.com/a/4043007 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24632 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24633] Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py'
Changes by Robert Collins robe...@robertcollins.net: -- keywords: +patch Added file: http://bugs.python.org/file39924/issue24633.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24633 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24629] unittest.main shadows unittest.main module
Changes by Martin Panter vadmium...@gmail.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24629 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24633] Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py'
Robert Collins added the comment: So, README is a valid package name. readme conflicting with README on case insensitive filesystems is a special case, but the general problem remains. We've no particular reason to use README rather than e.g. README.txt, which would open with a much more reasonable program on Windows, and would also remove this problem. -- nosy: +rbcollins versions: +Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24633 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23906] poplib maxline behaviour may be wrong
Chris Smowton added the comment: I found the same problem retrieving mail from my ISP's (unknown) POP3 server. I was sent an HTML email as one long 50KB line, which naturally broke everything. Instead of limiting line length, I suggest you should limit total message body size, since that's what you're actually trying to defend against here. You could also either use the +OK XXX octets line to set a more conservative limit (and fail fast if it announces intent to send more than your limit). As above the workaround was to insert import poplib; poplib._MAXLINE = 100 at the top of the 'getmail' script. A side-note: one message that is broken this way causes all future messages to fail because poplib does not flush the connection when bailing due to a 'line too long' error. If it isn't prepared to read the rest of the incoming data, it *must* hang up the connection and re-login to fetch the next message. -- nosy: +Chris Smowton ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23906 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21952] fnmatch.py can appear in tracemalloc diffs
Serhiy Storchaka added the comment: In 3.5+ lru_cache() is implemented in C. Is this issue still actual? -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21952 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24633] Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py'
Ned Deily added the comment: I agree with IIan's comments you cited in https://groups.google.com/a/continuum.io/forum/#!topic/anaconda/AGHXzB1sN0I. Python has been installing the README file in site-packages for a very long time and there have been case-insensitive file systems for a very long time, including, but not limited to, the default case-insensitive variant of HFS on OS X. So this seems to be an issue for the readme package, not for Python. Even if the Python-installed README file were installed under a different name in future release, it wouldn't solve the problem for trying to install the readme package under current and past Python releases. CC-ing Donald, as the author of readme, for his comments. -- nosy: +dstufft ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24633 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24633] Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py'
Ronald Oussoren added the comment: I agree with Robert: renaming the file to README.txt would be a good idea regardless to enable easily opening the file with a GUI editor and as a bonus removes any change of conflict with a package name. The patch looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24633 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24633] Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py'
Ned Deily added the comment: I'm +0 on the name change but, again, it wouldn't solve the conflict problem for potential users of the readme package until 3.6. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24633 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24633] Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py'
Ned Deily added the comment: (And such a change would only be appropriate in a feature release, as it would complicate things for existing release installers and downstream distributions, etc.) -- stage: - patch review versions: -Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24633 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23906] poplib maxline behaviour may be wrong
R. David Murray added the comment: Could you open a separate bug for the recovery problem, please? Using a maximum message size would not solve this problem, but it would give the library user control of when it failed, so it is a good feature request. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23906 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24633] README file installed into site-packages conflicts with package named readme
Changes by Brett Cannon br...@python.org: -- title: Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py' - README file installed into site-packages conflicts with package named readme ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24633 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24633] README file installed into site-packages conflicts with package named readme
Brett Cannon added the comment: +1 on the file renaming. There really shouldn't be any files we put into site-packages that don't have a dot or some other symbol that we would never support as a file name for importing. -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24633 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24630] null pointer dereference in `load_newobj_ex`
Brad Larsen added the comment: Both test cases cause segfaults for me: (1) on 64-bit Python 3.4.3 built from source on Mac OS X (2) on the system 64-bit Python 3.4.3 from Debian Jessie I do not see the segfaults with a 64-bit build of the latest sources (cpython `default` branch at 231bf0840f8f). Instead, I see an unhandled `_pickle.UnpicklingError`. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24630 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24631] Regression in timeit with multyline setup
Brett Cannon added the comment: There's no patch to review. -- nosy: +brett.cannon stage: patch review - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24631 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24631] Regression in timeit with multyline setup
Serhiy Storchaka added the comment: Oh, sorry. Here is it. -- keywords: +patch stage: needs patch - patch review Added file: http://bugs.python.org/file39925/timeit_multiline_setup.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24631 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21750] mock_open data is visible only once for the life of the class
Robert Collins added the comment: This is a regression in 3.5 vs 3.3 I think. It would have worked with the initial mock import. https://github.com/testing-cabal/mock/issues/280 Minimal reproducer case attached (With commentted out bits to switch out the mock for the rolling backport etc). -- nosy: +rbcollins Added file: http://bugs.python.org/file39926/mock-280.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21750 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24634] Importing uuid should not try to load libc on Windows
New submission from Steve Dower: Lib/uuid.py includes the following code that runs on import: import ctypes, ctypes.util # The uuid_generate_* routines are provided by libuuid on at least # Linux and FreeBSD, and provided by libc on Mac OS X. for libname in ['uuid', 'c']: try: lib = ctypes.CDLL(ctypes.util.find_library(libname)) except Exception: continue if hasattr(lib, 'uuid_generate_random'): _uuid_generate_random = lib.uuid_generate_random if hasattr(lib, 'uuid_generate_time'): _uuid_generate_time = lib.uuid_generate_time if _uuid_generate_random is not None: break # found everything we were looking for This code can cause issues on Windows when loading the CRT outside of an activation context (2.7) or in one case crashed Python 3.4 on a server (unfortunately I couldn't get access to the error logs - but I guessed that this section was responsible and turned out it was). I propose adding a sys.platform check before running this code, to omit it on any platform starting with 'win' (patch to follow). I believe this should apply to all current versions of Python. It is possible that someone has added their own uuid.dll to the DLL search path and is relying on that being found by uuid.py. I consider that unlikely and unsupported, but if people think that's a valid concern I can rework the patch to attempt to load uuid.dll but not the CRT on Windows. -- assignee: steve.dower components: Windows messages: 246740 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Importing uuid should not try to load libc on Windows type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24634] Importing uuid should not try to load libc on Windows
Steve Dower added the comment: Patch is against Python 3.5, but uuid.py is identical in all versions and the change should be applied to all four branches. -- keywords: +patch Added file: http://bugs.python.org/file39927/24634_1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18622] reset_mock on mock created by mock_open causes infinite recursion
Changes by Robert Collins robe...@robertcollins.net: -- nosy: +rbcollins versions: +Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18622 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24634] Importing uuid should not try to load libc on Windows
eryksun added the comment:
This code can cause issues on Windows
What's the issue or issues here? For 2.7, Windows won't be able to find
msvcr90.dll without an activation context, but that's just an
ERROR_MOD_NOT_FOUND OS error. It should be ignored by the try/except block. For
3.4, it shouldn't be using SxS for msvcr100.dll, so the server in question must
have an unusual configuration. Still, the OSError that gets raised should be
ignored.
3.5 built with VC 14 has a separate issue related to this. Due to changes from
issue 23606, find_msvcrt now returns None. But the TypeError raised by
CDLL(None) should be ignored here all the same.
BTW, in Windows 10 I'm still able to reference CRT functions by name using
CDLL('ucrtbase'). Are you sure the ultimate plan is to remove the named exports?
--
nosy: +eryksun
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24634
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24635] test_typing is flaky
New submission from R. David Murray: See for example: http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%203.x/builds/106 It might be a test order dependency, but see http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/11931 where the test passed when re-run at the end. I'm making this a release blocker because it would be pretty sad to ship a new feature with a flaky test. Larry can of course overrule me on that :) I note that no one is yet listed as the subject expert for the typing module. I've at least added a line for the module to experts.rst. -- components: Tests messages: 246750 nosy: Guido.van.Rossum, r.david.murray priority: release blocker severity: normal stage: needs patch status: open title: test_typing is flaky type: behavior versions: Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24635 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22858] unittest.__init__:main shadows unittest.main
Robert Collins added the comment: So unittest.main, the symbol, needs to exist. What currently references unittest.main, the module, today? AFAICT its only accessible vis sys.modules['unittest.main'] because of the shadowing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22858 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18622] reset_mock on mock created by mock_open causes infinite recursion
Robert Collins added the comment: Applying this to 3.4 and up with a test. Laurent, it would be good to sign the CLA - since your change here is minimal and Nicola has, I'm just going ahead. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18622 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18622] reset_mock on mock created by mock_open causes infinite recursion
Roundup Robot added the comment: New changeset 4c8cb603ab42 by Robert Collins in branch '3.4': - Issue #18622: unittest.mock.mock_open().reset_mock would recurse infinitely. https://hg.python.org/cpython/rev/4c8cb603ab42 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18622 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24379] operator.subscript
Joe Jevnik added the comment: I updated the docstring -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24379 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24634] Importing uuid should not try to load libc on Windows
eryksun added the comment:
That would break anyone else who's manually managing their own
activation context around ctypes.
Since this can't be made to work automatically, I prefer your suggestion to
continue checking for uuid.dll. You could just do something like the following:
libnames = ['uuid']
if sys.platform != 'win32':
libnames.append('c')
for libname in libnames:
...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24634
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24634] Importing uuid should not try to load libc on Windows
eryksun added the comment: Actually, it finds the DLL fine and the DLL terminates the entire process when it fails to detect an activation context. OK, in that case it finds msvcr90.dll via PATH. I was only thinking of the DLL being installed in a subdirectory of the system WinSxS directory. I still think in this case it would be better to let extension modules get access to the activation context that Python saves and subsequently activates when loading extension modules. ctypes could activate this context before calling LoadLibrary. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21750] mock_open data is visible only once for the life of the class
Robert Collins added the comment: I think its worth noting that both the original mock_open and the new one are entirely broken for mocking access to multiple files. But, the breakage was not deliberate, and as the mock-280 example shows, folk subclassing a test suite will be surprisingly broken vs the long table releases of mock itself. So, I think its ok to fix this - relying on the second file appearing empty is IMO unlikely, and being more compatible with the prior releases of mock is good. We probably need to rethink this interface and provide a better one though, so that you can mock a filesystem easily. Thats a different discussion though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21750 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24634] Importing uuid should not try to load libc on Windows
Steve Dower added the comment:
For 2.7, Windows won't be able to find msvcr90.dll without an activation
context, but that's just an ERROR_MOD_NOT_FOUND OS error.
Actually, it finds the DLL fine and the DLL terminates the entire process when
it fails to detect an activation context. There's #24429 on this, which I
forgot to link to (note that this bug is related to that one, but is much
smaller in scope).
For 3.4, it shouldn't be using SxS for msvcr100.dll, so the server in
question must have an unusual configuration. Still, the OSError that gets
raised should be ignored.
Unfortunately I can't get hold of the error. It's almost certainly a strange
configuration, but it was a commodity, publicly available server where the
configuration is completely outside of the user's control. If we can avoid
crashing when importing stdlib modules regardless of configuration, we should.
3.5 built with VC 14 has a separate issue related to this. Due to changes
from issue 23606, find_msvcrt now returns None. But the TypeError raised by
CDLL(None) should be ignored here all the same.
And it will be ignored, but when we know it's going to raise, why bother trying
to load the library?
BTW, in Windows 10 I'm still able to reference CRT functions by name using
CDLL('ucrtbase'). Are you sure the ultimate plan is to remove the named
exports?
It looks like on Windows 10 the CRT has switched to the transparent API schema.
My python35.dll does not directly reference ucrtbase, and so it's still
intended to be non-public API, and I still want to discourage its use because
the chance of applications on different Windows versions is too high.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24634
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21750] mock_open data is visible only once for the life of the class
Changes by Robert Collins robe...@robertcollins.net: -- keywords: +patch Added file: http://bugs.python.org/file39928/issue-21750.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21750 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23004] mock_open() should allow reading binary data
Changes by Robert Collins robe...@robertcollins.net: -- nosy: +rbcollins versions: +Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23004 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18622] reset_mock on mock created by mock_open causes infinite recursion
Changes by Robert Collins robe...@robertcollins.net: -- assignee: michael.foord - rbcollins resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18622 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21750] mock_open data is visible only once for the life of the class
Changes by Robert Collins robe...@robertcollins.net: -- assignee: - rbcollins versions: +Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21750 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24634] Importing uuid should not try to load libc on Windows
Steve Dower added the comment: ctypes could activate this context before calling LoadLibrary. That would break anyone else who's manually managing their own activation context around ctypes. At best we could expose functions to enable Python's activation context (which I'm willing to help review and merge a patch for on the other issue), but calling them while importing uuid when we know that we should just skip that part of the module's logic is silly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24634 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24429] msvcrt error when embedded
eryksun added the comment:
windll.python27._Py_ActivateActCtx would suffice
It would instead be ctypes.pythonapi._Py_ActivateActCtx -- if the DLL exported
a function with this name. ctypes.pythonapi is a PyDLL instance that wraps
sys.dllhandle.
I think it would be more useful in general to add an actctx parameter to
CDLL. Then make PyWin_DLLhActivationContext public in PC/dl_nt.c, and add it as
sys.dllactctx. Example usage:
libc = CDLL('msvcr90', actctx=sys.dllactctx)
Along the lines of changing CDLL, it would also be nice to add a flags
parameter and switch to using LoadLibraryEx. In comparison, POSIX users have
easy access to the mode parameter (i.e. RTLD_LOCAL, RTLD_GLOBAL).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24429
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18622] reset_mock on mock created by mock_open causes infinite recursion
Roundup Robot added the comment: New changeset c0ec61cf5a7d by Robert Collins in branch '3.5': - Issue #18622: unittest.mock.mock_open().reset_mock would recurse infinitely. https://hg.python.org/cpython/rev/c0ec61cf5a7d New changeset a4fe32477df6 by Robert Collins in branch 'default': - Issue #18622: unittest.mock.mock_open().reset_mock would recurse infinitely. https://hg.python.org/cpython/rev/a4fe32477df6 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18622 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24630] null pointer dereference in `load_newobj_ex`
Serhiy Storchaka added the comment: Likely this crash was fixed by issue24552 patch. -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24630 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22858] unittest.__init__:main shadows unittest.main
Brett Cannon added the comment: The modules seem to have existed since at least Python 3.2, so I think a proper DeprecationWarning is necessary for just one release. The trick is going to be unittest.main since it seems code in the wild relies on it at least partially existing and Michael thinks it should stick around in some form or another. If the desire is there to limit the API for unittest.main compared to what it is now, either people have to go with stuff disappearing on users that get moved out to _main, or you have to do a somewhat evil import hack and turn unittest.main into an object with attributes which raise a DeprecationWarning for those objects you want to relocate and not for those you want to leave in place. -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22858 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
