[issue42962] Windows: SystemError during os.kill(..., signal.CTRL_C_EVENT)
William Schwartz added the comment: >For a new process group, the cancel event is initially ignored, but the break >event is always handled. To enable the cancel event, the process must call >SetConsoleCtrlHandler(NULL, FALSE), such as via ctypes with >kernel32.SetConsoleCtrlHandler(None, False). I think the signal module should >provide a function to enable/disable Ctrl+C handling without ctypes, and >implicitly enable it when setting a new SIGINT handler. That's what Lib/test/win_console_handler.py:39 does. What I don't understand is why that's necessary. Isn't that what PyConfig.install_signal_handlers is supposed to do? Which brings me to how I ended up here in the first place: I wanted to write a test that PyConfig.install_signal_handlers is set in an embedded instance of Python I'm working with. In outline, the following test works on both Windows and macOS *except on Windows running under Tox*. @unittest.removeHandler def test_signal_handlers_installed(self): SIG = signal.SIGINT if sys.platform == 'win32': SIG = signal.CTRL_C_EVENT with self.assertRaises(KeyboardInterrupt): os.kill(os.getpid(), SIG) if sys.platform == 'win32': time.sleep(.1) # Give handler's thread time to join Using SetConsoleCtrlHandler if I detect that I'm running on Windows under Tox would, if I understand correctly, hide whether PyConfig.install_signal_handlers was set before the Python I'm running in started, right? (I know this isn't the right venue for discussing my embedding/testing problem. But maybe the use case informs the pending discussion of what to do about os.kill's semantics.) -- ___ Python tracker <https://bugs.python.org/issue42962> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42962] Windows: SystemError during os.kill(..., signal.CTRL_C_EVENT)
William Schwartz added the comment: > Fixing the SystemError should be simple. Just clear an existing error if > TerminateProcess() succeeds. Should there be a `return NULL;` between these two lines? https://github.com/python/cpython/blob/e485be5b6bd5fde97d78f09e2e4cca7f363763c3/Modules/posixmodule.c#L7854-L7855 I'm not the best person to work on a patch for this. -- ___ Python tracker <https://bugs.python.org/issue42962> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42962] Windows: SystemError during os.kill(..., signal.CTRL_C_EVENT)
William Schwartz added the comment: > In Windows, os.kill() is a rather confused function. I know how it feels. To be honest, I don't have an opinion about whether the steps I laid out ought to work. I just reported it because the SystemError indicates that a C-API function was returning non-NULL even after PyErr_Occurred() returns true. I think that's what you're referring to here... > it doesn't clear the error that was set as a result of the > GenerateConsoleCtrlEvent() call, which causes SystemError to be raised. ...but I lost you on where that's happening and why. Frankly, Windows IPC is not in my wheelhouse. >> Oddly, `echo %errorlevel%` will print `0` rather than `-1073741510` > > There's nothing odd about that. Here's why I thought it was odd. The following session is from the Windows Command shell inside *Command Prompt* (not Windows Terminal): C:\Users\wksch>python --version Python 3.9.1 C:\Users\wksch>python -c"import os, signal, time; os.kill(os.getpid(), signal.CTRL_C_EVENT); time.sleep(1)" Traceback (most recent call last): File "", line 1, in KeyboardInterrupt ^C C:\Users\wksch>echo %errorlevel% -1073741510 In the Windows Command shell inside *Windows Terminal* (not Command Prompt): C:\Users\wksch>python -c"import os, signal, time; os.kill(os.getpid(), signal.CTRL_C_EVENT); time.sleep(1)" C:\Users\wksch>echo %errorlevel% 0 C:\Users\wksch>python -c"raise KeyboardInterrupt" Traceback (most recent call last): File "", line 1, in KeyboardInterrupt ^C C:\Users\wksch>echo %errorlevel% -1073741510 -- ___ Python tracker <https://bugs.python.org/issue42962> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42962] Windows: SystemError during os.kill(..., signal.CTRL_C_EVENT)
New submission from William Schwartz :
I don't have an automated test at this time, but here's how to get os.kill to
raise SystemError. I did this on Windows 10 version 20H2 (build 19042.746) with
Pythons 3.7.7, 3.8.5, and 3.9.1. os_kill_impl at Modules/posixmodule.c:7833
does not appear to have been modified recently (but I haven't checked its
transitive callees), so I imagine you can get the same behavior from os.kill on
Python 3.10.
1. Open two consoles, A and B. (I'm using tabs in Windows Terminal, if that
matters.)
2. In console A, type but DO NOT EXECUTE the following command:
python -c"import os, signal; os.kill(, signal.CTRL_C_EVENT)"
Move your cursor back before the comma.
3. In console B, create a process that does nothing but print its process
identifier and wait long enough for you to type it in console A:
python -c"import os, time; print(os.getpid()); time.sleep(60); print('exiting
cleanly')"
Copy or remember the printed PID. Hurry to step 4 before your 60 seconds
expires!
4. In console A, type the PID from console B and execute the command.
5. In console B, confirm that the Python exited without printing "exiting
cleanly". Oddly, `echo %errorlevel%` will print `0` rather than `-1073741510`
(which is `2**32 - 0xc13a`, the CTRL_C_EVENT exit code), which is what it
prints after `python -c"raise KeyboardInturrupt"`.
6. In console A, you should see the following traceback.
OSError: [WinError 87] The parameter is incorrect
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "", line 1, in
SystemError: returned a result with an error set
--
components: Extension Modules, Windows
messages: 385235
nosy: William.Schwartz, ncoghlan, paul.moore, petr.viktorin, steve.dower,
tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows: SystemError during os.kill(..., signal.CTRL_C_EVENT)
type: behavior
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42962>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42531] importlib.resources.path() raises TypeError for packages without __file__
William Schwartz added the comment: > For that, please submit a PR to importlib_resources and it will get synced to > CPython later. Will do once PR 23611 gets in shape. > Can you tell me more about the use-case that exhibited this undesirable > behavior? Using the [PyOxidizer] "freezer". It compiles Python together with frozen Python code or byte code. > That is, what loader is it that supports `open_binary` but not `is_resource` > and doesn't have a `__origin__`? PyOxidizer's [OxidizedImporter] importer. It [does not set `__file__`] (i.e., `__spec__.origin__ is None`). Its maintainer has resolved some ambiguities in the resources API contract (#36128) [differently from CPython], but I don't think that's related to the issue I ran into. The resource-related functionality of the importer is implemented here (extension module written in Rust): https://github.com/indygreg/PyOxidizer/blob/e86b2f46ed6b449bdb912900b0ac83576ad5ebe9/pyembed/src/importer.rs#L1078-L1269 [PyOxidizer]: https://pyoxidizer.readthedocs.io [OxidizedImporter]: https://pyoxidizer.readthedocs.io/en/v0.10.3/oxidized_importer.html [does not set `__file__`]: https://pyoxidizer.readthedocs.io/en/v0.10.3/oxidized_importer_behavior_and_compliance.html#file-and-cached-module-attributes [unsure about `ResourceReader` semantics]: https://pyoxidizer.readthedocs.io/en/v0.10.3/oxidized_importer_resource_files.html#resource-reader-support -- ___ Python tracker <https://bugs.python.org/issue42531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42531] importlib.resources.path() raises TypeError for packages without __file__
William Schwartz added the comment: @jaraco Did you have any other questions after my comments in msg382423? Do you think you or someone else could review PR 23611? Thanks! -- ___ Python tracker <https://bugs.python.org/issue42531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42531] importlib.resources.path() raises TypeError for packages without __file__
William Schwartz added the comment: > If the issue has been fixed on Python 3.9 but not on 3.8, then it was likely > a redesign that enabled the improved behavior That appears to be the case: path() shares code with files(). > a redesign that won't be ported back to Python 3.8 and earlier. Nor should it. > In these situations, the best recommendation is often to just rely on > importlib_resources (the backport) for those older Python versions. I do not need the files() API or anything else added in 3.9 at this time. I just need the existing 3.7/3.8 functionality to work as documented. > have you considered using importlib_resources for Python 3.8 and earlier? > That would likely also address the issue and you could adopt it sooner. My application is sensitive to the size of the installed site-packages both in bytes and in just the number of packages. Yes, importlib_resources would very likely solve the problem reported in the OP. However I don't need the files() API, so adding an extra requirement feels like a heavy solution. > To some extent, the behavior you've described could be considered a bug or > could be considered a feature request (add support for path on packages that > have no __spec__.origin). I am not aware whether this limitation was by > design or incidental. I agree there should be a high bar for patching old versions, but I posit that the behavior is an unintentional bug. In particular, I believe the behavior contradicts the documentation. Below I link and quote relevant documentation. The function in question: > importlib.resources.path(package, resource)¶ > ...package is either a name or a module object which conforms to the > Package requirements. https://docs.python.org/3.8/library/importlib.html#importlib.resources.path So we jump to Package: > importlib.resources.Package > The Package type is defined as Union[str, ModuleType]. This means that > where the function describes accepting a Package, you can pass in either a > string or a module. Module objects must have a resolvable > __spec__.submodule_search_locations that is not None. https://docs.python.org/3.8/library/importlib.html#importlib.resources.Package The Package type restricts the types of modules based on __spec__.submodule_search_locations. This suggests to me that the original author thought about which __spec__s to accept and which to reject but chose not to say anything about __spec__.origin, which is documented as possibly being None: > class importlib.machinery.ModuleSpec(...) > ...module.__spec__.origin == module.__file__ Normally “origin” should > be set, but it may be None (the default) which indicates it is unspecified > (e.g. for namespace packages). https://docs.python.org/3.8/library/importlib.html#importlib.machinery.ModuleSpec.origin In particular, __spec__.origin *should* be None in certain situations: > __file__ > __file__ is optional The import system may opt to leave __file__ unset > if it has no semantic meaning (e.g. a module loaded from a database). https://docs.python.org/3.8/reference/import.html#__file__ Taken together, the foregoing passages describe an `import` API in which path() works for all modules that are packages (i.e., __spec__.submodule_search_locations is not None), and in which some packages' __spec__.origin is None. That path() fails in practice to support some packages is therefore a bug not a the absence of a feature. Regardless of whether PR 23611 is accepted, the test that it adds should be added to Python master to guard against regressions. I can submit that as a separate PR. Before I do that, do I need to create a new bpo ticket, or can I just reference this one? -- ___ Python tracker <https://bugs.python.org/issue42531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42531] importlib.resources.path() raises TypeError for packages without __file__
Change by William Schwartz : -- keywords: +patch pull_requests: +22477 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23611 ___ Python tracker <https://bugs.python.org/issue42531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42531] importlib.resources.path() raises TypeError for packages without __file__
New submission from William Schwartz : Suppose pkg is a package, it contains a resource r, pkg.__spec__.origin is None, and p = importlib.resources.path(pkg, r). Then p.__enter__() raises a TypeError in Python 3.7 and 3.8. (The problem has been fixed in 3.9). The error can be demonstrated by running the attached path-test.py. The tracebacks in 3.7 and 3.8 are nearly identical, so I'll just show the 3.8 traceback. 3.8.6 (default, Nov 20 2020, 18:29:40) [Clang 12.0.0 (clang-1200.0.32.27)] Traceback (most recent call last): File "path-test.py", line 19, in p.__enter__() # Kaboom File "/usr/local/Cellar/python@3.8/3.8.6_2/Frameworks/Python.framework/Versions/3.8/lib/python3.8/contextlib.py", line 113, in __enter__ return next(self.gen) File "/usr/local/Cellar/python@3.8/3.8.6_2/Frameworks/Python.framework/Versions/3.8/lib/python3.8/importlib/resources.py", line 196, in path package_directory = Path(package.__spec__.origin).parent File "/usr/local/Cellar/python@3.8/3.8.6_2/Frameworks/Python.framework/Versions/3.8/lib/python3.8/pathlib.py", line 1041, in __new__ self = cls._from_parts(args, init=False) File "/usr/local/Cellar/python@3.8/3.8.6_2/Frameworks/Python.framework/Versions/3.8/lib/python3.8/pathlib.py", line 682, in _from_parts drv, root, parts = self._parse_args(args) File "/usr/local/Cellar/python@3.8/3.8.6_2/Frameworks/Python.framework/Versions/3.8/lib/python3.8/pathlib.py", line 666, in _parse_args a = os.fspath(a) TypeError: expected str, bytes or os.PathLike object, not NoneType The fix is super simple, as shown below. I'll submit this as a PR as well. diff --git a/Lib/importlib/resources.py b/Lib/importlib/resources.py index fc3a1c9cab..8d37d52cb8 100644 --- a/Lib/importlib/resources.py +++ b/Lib/importlib/resources.py @@ -193,9 +193,11 @@ def path(package: Package, resource: Resource) -> Iterator[Path]: _check_location(package) # Fall-through for both the lack of resource_path() *and* if # resource_path() raises FileNotFoundError. -package_directory = Path(package.__spec__.origin).parent -file_path = package_directory / resource -if file_path.exists(): +file_path = None +if package.__spec__.origin is not None: +package_directory = Path(package.__spec__.origin).parent +file_path = package_directory / resource +if file_path is not None and file_path.exists(): yield file_path else: with open_binary(package, resource) as fp: -- components: Library (Lib) files: path-test.py messages: 382297 nosy: William.Schwartz, brett.cannon priority: normal severity: normal status: open title: importlib.resources.path() raises TypeError for packages without __file__ type: behavior versions: Python 3.7, Python 3.8 Added file: https://bugs.python.org/file49643/path-test.py ___ Python tracker <https://bugs.python.org/issue42531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42315] `python -m` semantics conflict with `__file__`'s being optional
New submission from William Schwartz : `python -m mod` sets `sys.argv[0]` to the `mod.__file__` according to https://docs.python.org/3.9/using/cmdline.html#cmdoption-m > If ["-m"] is given, the first element of sys.argv will be the full path to > the module file (while the module file is being located, the first element > will be set to "-m"). But `__file__` may not exist according to https://docs.python.org/3.9/reference/import.html#__file__ > __file__ is optional. If set, this attribute’s value must be a string. The > import system may opt to leave __file__ unset if it has no semantic meaning > (e.g. a module loaded from a database). More technically, `__spec__.origin` is the source of `__file__`, and the former may be `None`, according to https://docs.python.org/3.9/library/importlib.html#importlib.machinery.ModuleSpec.origin > (__file__) > > Name of the place from which the module is loaded, e.g. “builtin” for > built-in modules and the filename for modules loaded from source. Normally > “origin” should be set, but it may be None (the default) which indicates it > is unspecified (e.g. for namespace packages). `python -m mod` sets sys.argv[0] to `mod.__spec__.origin` at 3.9/Lib/runpy.py:196 It seems clear to me that the code is doing the right thing relative to the documentation for `-m`. But as #26388 and https://github.com/indygreg/PyOxidizer/issues/307 show, embedded Python runs into the semantic conflict with the documented behavior of `__spec__.origin` and `__file__`. My proposed resolution of this contradiction is to set `sys.argv[0] = sys.orig_argv[0]` or, even better, `sys.argv[0] = sys.executable` when `PyConfig.run_module` is set but the named module's `__spec__.origin` is `None`. -- components: Interpreter Core, Library (Lib) messages: 380689 nosy: William.Schwartz, brett.cannon, eric.snow, ncoghlan priority: normal severity: normal status: open title: `python -m` semantics conflict with `__file__`'s being optional type: behavior versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26388] Disabling changing sys.argv[0] with runpy.run_module(...alter_sys=True)
Change by William Schwartz : -- nosy: +William.Schwartz ___ Python tracker <https://bugs.python.org/issue26388> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5614] Malloc errors in test_io
William Schwartz added the comment: In Jupyter Notebook, I tried to pass a large amount of data (about 2.3 GB) to Statsmodels's KDEUnivariate.fit (https://www.statsmodels.org/dev/generated/statsmodels.nonparametric.kde.KDEUnivariate.fit.html#statsmodels.nonparametric.kde.KDEUnivariate.fit) with kernel='cos'. In the Notebook, I got a MemoryError exception and traceback (which unfortunately I have since lost). In the terminal where I was running the Jupyter server, the Python 3.7 kernel spat out: Python(86244,0x7fff91104380) malloc: *** mach_vm_map(size=465845322670080) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug The MemoryError coming up in the Notebook interface is the correct behavior, but I wanted to bring to your attention that the malloc junk on stderr happens even outside of Python's tests. I'm on macOS 10.13.5. -- components: +macOS nosy: +William.Schwartz versions: +Python 3.7 -Python 3.1 ___ Python tracker <https://bugs.python.org/issue5614> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29620] unittest.TestCase.assertWarns raises RuntimeEror if sys.modules changes size
William Schwartz added the comment: I am also running into this problem. I'm not 100%, but I'm pretty sure that looping over sys.modules and accessing __warningregistry__ on each module triggers one of my module's __getattr__ functions (PEP 562), which in turn uses setuptools entry points to import an arbitrary set of other modules. Bizarrely, however, I cannot reproduce on macOS, only Linux. Presumably there's something platform dependent about how the default unittest test runner orders my tests, and hence which modules have already been loaded by the time I call assertWarnsRegex. -- nosy: +William.Schwartz ___ Python tracker <https://bugs.python.org/issue29620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21112] 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses
William Schwartz added the comment: 3.4.3 has been released, it seems, without this getting fixed. 3.4.4 then? -- William Schwartz On Mon, Sep 8, 2014 at 3:42 AM, Michael Foord rep...@bugs.python.org wrote: Michael Foord added the comment: The patch looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21112 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21112 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21112] 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses
William Schwartz added the comment: 3.4.2 has been released, it seems, without this getting fixed. 3.4.3 then? Are we still happy with the patch? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21112 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21112] 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses
New submission from William Schwartz: In Python 2.7 and 3.3, decorating a unittest.TestCase subclass with unittest.expectedFailure caused test discover to skip the decorated test case. Python 3.4 apparently ignores the decorator when applied to classes. The attached file when run with Python 2.7.6 on Mac OS X produces the following output $ python -m unittest discover F. == FAIL: test_fails (test.TestControl) -- Traceback (most recent call last): File /Users/schwartz_w/Documents/testtest/test.py, line 9, in test_fails self.assertFalse(True) AssertionError: True is not false -- Ran 2 tests in 0.000s FAILED (failures=1) When run with Python 3.4.0 produces the following output. ~/Documents/testtest $ python3 -m unittest discover F.F. == FAIL: test_fails (test.TestControl) -- Traceback (most recent call last): File /Users/schwartz_w/Documents/testtest/test.py, line 9, in test_fails self.assertFalse(True) AssertionError: True is not false == FAIL: test_fails (test.TestTreatment) -- Traceback (most recent call last): File /Users/schwartz_w/Documents/testtest/test.py, line 9, in test_fails self.assertFalse(True) AssertionError: True is not false -- Ran 4 tests in 0.001s FAILED (failures=2) The expectedFailure decorator when applied to a class should either skip the class or run all of its tests and check that they failed for consistency with how expectedFailure applies to test methods. -- components: Library (Lib) files: test_expectedFailure.py messages: 215240 nosy: William.Schwartz priority: normal severity: normal status: open title: 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file34680/test_expectedFailure.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21112 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
William Schwartz added the comment: Looks like this issue is closed, but I got IDLE to crash. On Python 3.3.2, Windows 7, and Tk version 8.5, IDLE crashes when pasting \U0001F382 (Unicode birthday cake character). Below is the version string for the Python I'm running. Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit (AMD64)] on win32. According to http://docs.python.org/3.3/whatsnew/changelog.html this issue was fixed in Python 3.3.1 RC 1. Indeed the patch discussed above exists in the cpython 3.3 branch: http://hg.python.org/cpython/file/910ec3471d55/Modules/_tkinter.c. But IDLE still crashes, at least for me. -- nosy: +William.Schwartz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13153 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15243] Misleading documentation for __prepare__
William Schwartz wkschwa...@gmail.com added the comment: Daniel, Good point. However it would still be useful for documentation to point out that __prepare__ can be passed the metaclass as the implicit first argument by being decorated by classmethod. I'll post a small patch when I get a chance to add a sentence saying as much in the documentation and reorganize the test cases in Lib/test/test_metaclass.py to make it part of the narrative of the doctests. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15243] Misleading documentation for __prepare__
New submission from William Schwartz wkschwa...@gmail.com: Section 3.3.3.2. Preparing the class namespace of the documentation (http://docs.python.org/dev/reference/datamodel.html#preparing-the-class-namespace) states that If the metaclass has a __prepare__ attribute, it is called as ``namespace = metaclass.__prepare__(name, bases, **kwds)`` This isn't quite true. By just defining a ``__prepare__`` method in a metaclass, the interpreter calls it as it would a static method -- there is no implicit first argument referring to ``metaclass`` as the documentation implies. The documentation should be amended to say that users can decorate ``__prepare__`` as a class method to get ``metaclass`` passed in as the implicit first argument. -- assignee: docs@python components: Documentation, Tests messages: 164606 nosy: William.Schwartz, docs@python priority: normal severity: normal status: open title: Misleading documentation for __prepare__ type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15243] Misleading documentation for __prepare__
William Schwartz wkschwa...@gmail.com added the comment: Attached a unittest script to demonstrate that __prepare__ is implicitly a staticmethod. -- Added file: http://bugs.python.org/file26245/test_metaclass.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
