[issue41282] Deprecate and remove distutils
Ionel Cristian Mărieș added the comment: Alright so to get all the package paths, included distro-managed ones would be this right? for scheme in sysconfig.get_scheme_names(): for name in ['purelib', 'platlib']: sysconfig.get_path(name, scheme) -- ___ Python tracker <https://bugs.python.org/issue41282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41282] Deprecate and remove distutils
Ionel Cristian Mărieș added the comment:
That seems fine, tho for some of distros that do lots of python customizations
(tried the docker ubuntu image for 18.04.3) it get a bit strange:
Python 3.6.9 (default, Jan 26 2021, 15:33:00)
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> import distutils.sysconfig
>>> sysconfig.get_path('platlib')
'/usr/lib/python3.6/site-packages'
>>> sysconfig.get_path('purelib')
'/usr/lib/python3.6/site-packages'
>>> distutils.sysconfig.get_python_lib()
'/usr/lib/python3/dist-packages'
--
___
Python tracker
<https://bugs.python.org/issue41282>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41282] Deprecate and remove distutils
Ionel Cristian Mărieș added the comment: Hello everyone, How are we supposed to use get_python_lib now (a function that returned the site-packages location)? `from setuptools._distutils.sysconfig import get_python_lib` doesn't really seem like the right solution and the sysconfig stdlib module doesn't have any get_python_lib function. -- nosy: +ionelmc ___ Python tracker <https://bugs.python.org/issue41282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14803] Add feature to allow code execution prior to __main__ invocation
Ionel Cristian Mărieș added the comment: Note that coveragepy ain't the sole usecase for this. https://pypi.org/project/manhole/ - a debugging tool https://pypi.org/project/hunter/ - a tracer In addition to those there's https://pypi.org/project/pytest-cov/ which packages the pth trick so coverage works consistently in all scenarios without putting users through the trouble of messing their python installation. Also, the amount of activity and enthusiasm on changing something that already works while other inconsistencies in python's core like issue23990 are ignored is disheartening. -- nosy: +ionelmc ___ Python tracker <https://bugs.python.org/issue14803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29759] Deadlock in multiprocessing.pool.Pool on terminate
Change by Ionel Cristian Mărieș : -- nosy: +ionelmc ___ Python tracker <https://bugs.python.org/issue29759> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40442] Spurious warning emitted during fork() can deadlock a multi-threaded process
Change by Ionel Cristian Mărieș : -- nosy: +ionelmc ___ Python tracker <https://bugs.python.org/issue40442> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30744] Local variable assignment is broken when combined with threads + tracing + closures
Change by Ionel Cristian Mărieș : -- nosy: +ionelmc ___ Python tracker <https://bugs.python.org/issue30744> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Ionel Cristian Mărieș added the comment: No. You can't put an usercustomize in a wheel. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38227] Setting a signal handler gets multiprocessing.Pool stuck
Ionel Cristian Mărieș added the comment: atexit proved time and time again to be unreliable, not really an option. Not all programs shutdown nicely enough for atexit. Should I tell users "use forkserver on 3.8 because broken stuff"? -- ___ Python tracker <https://bugs.python.org/issue38227> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38227] Setting a signal handler gets multiprocessing.Pool stuck
Change by Ionel Cristian Mărieș : -- components: +Library (Lib) ___ Python tracker <https://bugs.python.org/issue38227> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38227] Setting a signal handler gets multiprocessing.Pool stuck
New submission from Ionel Cristian Mărieș : Running `python3.8 mp-bug-python2.8.py` usually gets stuck after a dozen iterations or so. It appears that if I stop setting that signal handler it doesn't get stuck. Unfortunately I need it to perform critical cleanup. This is what I got from gdb: (gdb) py-bt Traceback (most recent call first): File "/usr/lib/python3.8/multiprocessing/synchronize.py", line 95, in __enter__ return self._semlock.__enter__() File "/usr/lib/python3.8/multiprocessing/queues.py", line 355, in get with self._rlock: File "/usr/lib/python3.8/multiprocessing/pool.py", line 370, in worker `func` and (a, b) becomes func(a, b). File "/usr/lib/python3.8/multiprocessing/process.py", line 108, in run self._target(*self._args, **self._kwargs) File "/usr/lib/python3.8/multiprocessing/process.py", line 569, in _bootstrap File "/usr/lib/python3.8/multiprocessing/popen_fork.py", line 75, in _launch code = process_obj._bootstrap(parent_sentinel=child_r) File "/usr/lib/python3.8/multiprocessing/popen_fork.py", line 19, in __init__ self._launch(process_obj) File "/usr/lib/python3.8/multiprocessing/context.py", line 276, in _Popen return Popen(process_obj) File "/usr/lib/python3.8/multiprocessing/process.py", line 633, in start File "/usr/lib/python3.8/multiprocessing/pool.py", line 838, in _repopulate_pool_static self._length = None File "/usr/lib/python3.8/multiprocessing/pool.py", line 559, in _repopulate_pool outqueue.put(None) File "/usr/lib/python3.8/multiprocessing/pool.py", line 212, in __init__ self._repopulate_pool() File "/usr/lib/python3.8/multiprocessing/context.py", line 375, in Pool File "mp-bug-python2.8.py", line 21, in And without the macros: #0 0x7f51c79fb6d6 in futex_abstimed_wait_cancelable (private=128, abstime=0x0, expected=0, futex_word=0x7f51c7e29000) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 #1 do_futex_wait (sem=sem@entry=0x7f51c7e29000, abstime=0x0) at sem_waitcommon.c:111 #2 0x7f51c79fb7c8 in __new_sem_wait_slow (sem=0x7f51c7e29000, abstime=0x0) at sem_waitcommon.c:181 #3 0x7f51c79fb839 in __new_sem_wait (sem=) at sem_wait.c:42 #4 0x7f51c58d51f7 in semlock_acquire (self=0x7f51c58a60b0, args=, kwds=) at ./Modules/_multiprocessing/semaphore.c:319 #5 0x0067d929 in method_vectorcall_VARARGS_KEYWORDS (func=, args=0x7f51c58a4eb8, nargsf=, kwnames=) at ../Objects/descrobject.c:332 #6 0x0042c5dc in _PyObject_Vectorcall (kwnames=, nargsf=, args=, callable=) at ../Include/cpython/abstract.h:127 #7 call_function (kwnames=0x0, oparg=, pp_stack=, tstate=0x22bd160) at ../Python/ceval.c:4987 #8 _PyEval_EvalFrameDefault (f=, throwflag=) at ../Python/ceval.c:3486 #9 0x00425ed7 in function_code_fastcall (co=, args=, nargs=1, globals=) at ../Objects/call.c:283 #10 0x006761e4 in _PyObject_Vectorcall (kwnames=0x0, nargsf=1, args=0x7ffe20bcc908, callable=) at ../Include/cpython/abstract.h:127 #11 method_vectorcall (method=, args=, nargsf=, kwnames=0x0) at ../Objects/classobject.c:67 #12 0x0042857e in _PyObject_Vectorcall (kwnames=0x0, nargsf=0, args=0x0, callable=) at ../Include/cpython/abstract.h:127 #13 _PyObject_CallNoArg (func=) at ../Include/cpython/abstract.h:153 #14 _PyEval_EvalFrameDefault (f=, throwflag=) at ../Python/ceval.c:3287 #15 0x00425ed7 in function_code_fastcall (co=, args=, nargs=1, globals=) at ../Objects/call.c:283 #16 0x00676245 in _PyObject_Vectorcall (kwnames=0x0, nargsf=1, args=0x23cea18, callable=) at ../Include/cpython/abstract.h:127 #17 method_vectorcall (method=, args=0x23cea20, nargsf=, kwnames=0x0) at ../Objects/classobject.c:60 #18 0x0042cf2f in _PyObject_Vectorcall (kwnames=, nargsf=, args=, callable=) at ../Include/cpython/abstract.h:127 #19 call_function (kwnames=0x0, oparg=, pp_stack=, tstate=0x22bd160) at ../Python/ceval.c:4987 #20 _PyEval_EvalFrameDefault (f=, throwflag=) at ../Python/ceval.c:3500 #21 0x004f9f44 in PyEval_EvalFrameEx (throwflag=0, f=Frame 0x23ce820, for file /usr/lib/python3.8/multiprocessing/pool.py, line 370, in worker (inqueue=, _writer=, _rlock=, acquire=, release=) at remote 0x7f51c589d0d0>, _poll=, _wlock=, acquire=, release=) at remote 0x7f51c589deb0>) at remote 0x7f51c589d3a0>, outqueue=, globals=, locals=locals@entry=0x0, args=, argcount=6, kwnames=0x0, kwargs=0x7f51c636e628, kwcount=0, kwstep=1, defs=0x7f51c65a4828, defcount=4, kwdefs=0x0, closure=0x0, name='worker', qualname='worker') at ../Python/ceval.c:4298 #23 0x0043e7a2 in _PyFunction_Vectorcall (func=func@entry=, stack=, nargsf=nargsf@entry=6, kwnames=) at ../Objects/call.c:435 #24 0x0044143c in PyVectorcall_Call (callable=, tuple=, kwargs=) at ../Objects/call.c:199 #25 0x
[issue33944] Deprecate and remove pth files
Ionel Cristian Mărieș added the comment: What module? That check should be done directly in the pth file. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Ionel Cristian Mărieș added the comment: > because you’re on the same machine and you pip installed it, I have no > choice but to pay those costs, which I haven’t explicitly opted in to. > > At least for the coverage plugins there is a required opt in from > environment variable (as shown above). There's a simple `if 'COVSOMETHING' in os.environ` check to activate it. That can't cost a significant amount of time. This is rather another bad actor argument. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Ionel Cristian Mărieș added the comment: > * coverage, debugging, demo, except-hook - application/user responsibility, not a package's Elaborate please, as it sounds like you're simply dismissing my usecase. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Ionel Cristian Mărieș added the comment: > Doesn’t that kind of prove my point? :) So basically you'd remove the whole feature just cause one package no one installs abuses it. Doesn't make sense. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Ionel Cristian Mărieș added the comment: > There was a single .pth file that I deemed "malicious" since it completely breaks the `subprocess` module (`subprocess-run`) It only seems to set an attribute. What's wrong with that? Does the early import of subprocess cause problems? -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Ionel Cristian Mărieș added the comment: On Wed, Feb 27, 2019 at 1:41 AM Barry A. Warsaw wrote: > Basically yes, I’ve done this. But think of the poor user who doesn’t have that expertise or ability to hack on an installed Python’s site.py file. When their application breaks because some faulty pth was installed behind their back, how do they debug their application when the breakage has already occurred before Python even gets to their code? How do they answer questions like “where did that magical sys.path entry come from?” or “how did that module get in sys.modules already?” Aren't these sort of questions answered by using `strace python -v` or similar? What information is missing more exactly? -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Ionel Cristian Mărieș added the comment: On Wed, Feb 27, 2019 at 1:31 AM Barry A. Warsaw wrote: > Your sudo may not be my sudo. :) Let’s say I update my Ubuntu desktop and a new version of package with a pth breaks. > Maybe I didn’t even know I was doing that, via automated updates, or management portal, etc. > Now a poor user who depends on this has their code break. How do *they* debug the problem? Well that's easy: * update my Ubuntu desktop -> stuff breaks -> rollback/downgrade * automated updates -> stuff breaks -> stop using them, and learn lesson ;) * management portal -> stuff breaks -> complain to sysadmin Desktop users don't need to debug problems, devs/sysadmins do. They have sudo. > FWIW, `sudo pip install` should just be banned IMHO :). Lets also ban ctypes and threads right? :) > For sure. But here’s the thing: you need to know *which* pth file is problematic. Which means you have to debug the entire startup process where pth files are loaded. How many pth files could one have? 2-3 ... 5 at most. Just `locate .pth` and rename the biggest one till the problem goes away. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Ionel Cristian Mărieș added the comment: > Because there’s no good place to stick a pdb/breakpoint to debug such issues > other than site.py, and that usually requires sudo. Something bad was installed with sudo but suddenly sudo is not acceptable for debugging? This seems crazy. How exactly are pth files hard to debug? Are those files hard to edit? They sure are, but the problem ain't the point where they are run, it's the fact that a big lump of code is stuffed on a single line. Lets fix that instead! I've written pth files with lots of stuff in them, and my experience is quite the opposite - they help with debugging. A lot. It's an incredibly useful python feature. > I don’t remember the details, but yes I have been caught in this trap. Maybe if you remember the details we can discuss what are the debugging options, and what can be improved. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Ionel Cristian Mărieș added the comment: FYI I have 3 projects that use pth files to activate various features (an env var is usually the trigger): https://pypi.org/project/pytest-cov - enables coverage measurement in any subprocess https://pypi.org/project/manhole - installs a debug service https://pypi.org/project/hunter - installs a tracer I wouldn't like them being rendered almost or completely useless by such a hasty change. Running stuff during startup can be problematic and tricky, for example I have painfully found out that on python 2.7 you can completely hose up your codecs registry if you try to decode things during startup (before the registry is fully built) but I think it's a fair price for such a powerful feature. -- nosy: +ionelmc ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș <cont...@ionelmc.ro> added the comment: Alright, now it makes sense. Thank you for writing a thoughtful response. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue23990> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș <cont...@ionelmc.ro> added the comment: It should be open for getting some visibility, as I need some help here - Raymond, I hope you can find a way to be hospitable here and stop with the kindergarten behavior. -- status: closed -> open ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue23990> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș <cont...@ionelmc.ro> added the comment: Hello everyone, Is anyone still interested in fixing this bug and help with whatever PEP drafting was needed for convincing people? I would sketch up a draft but for me at least it's not clear what are the disadvantages of not fixing this, so I could use some help making a unbiased document that won't attract tons of negativity and contempt (yet again). -- status: closed -> open ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue23990> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: Okay ... is anyone interested in helping with this (reviewing drafts)? Who would be the BDFL? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23990> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: On Mon, May 23, 2016 at 11:04 PM, Ethan Furman <rep...@bugs.python.org> wrote: > `issubclass` doesn't "do the right thing", as evidenced by another dev. > Hmmm. Technically, in that case, the problem is in collections.abc.Iterable, not issubclass. I can extent the patch to fix that too. Continued complaining to this issue is not going to get you what you want, > but writing a PEP to address the issue might. > Not sure what you're going at here. Are you hinting that you'd support these changes if there would be a PEP? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23990> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: On Mon, May 23, 2016 at 9:34 PM, Ethan Furman <rep...@bugs.python.org> wrote: > "Add proxy support to builtins" and should address such things as > callable, issubclass, and whatever else is is appropriate. As previously stated this builtin is the only one not doing the right thing. If you think otherwise, please provide proof. I provided plenty of supporting examples. Your "working around" is basically saying "don't use callable or don't solve your problem". Not an option. Let me restate the problem: I want to implement a "proxy that resolves the target at a later time". That means I can't juggle classes ahead of time (no `resolve_proxy` or whatever) and I can't tell users "don't use callable" (what's the point of having a proxy then?). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23990> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Changes by Ionel Cristian Mărieș <cont...@ionelmc.ro>: Added file: http://bugs.python.org/file42957/callable2.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23990> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: On Mon, Apr 20, 2015 at 5:08 PM, Eric Snow <rep...@bugs.python.org> wrote: > FYI, I'll re-iterate something I said before, there is a different > approach you can take here if this is just an issue of proxying. Use two > different proxy types depending on if the proxied object is callable or not: > > > class Proxy: > # all the proxy stuff... > > > class CallableProxy(Proxy): > def __call__(self, *args, **kwargs): > ... > > > def proxy(obj): > if callable(obj): > return CallableProxy(obj) > else: > return Proxy(obj) > > > If that isn't a viable alternative then please explain your use case in > more detail. I'm sure we can find a solution that works for you. > This does not work if I need to resolve the `obj` at a later time (way later than the time I create the Proxy object). Unfortunately, I need exactly that. Not sure how that wasn't clear from all the examples I posted ... -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23990> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19072] classmethod doesn't honour descriptor protocol of wrapped callable
Changes by Ionel Cristian Mărieș <cont...@ionelmc.ro>: -- nosy: +ionelmc ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26060] Class __dict__ iteration order changing due to type instance key-sharing
Ionel Cristian Mărieș added the comment: As I understood it the issue is not with the order but with the iteration being "unstable" (eg: same key appears multiple times). Yes, the dict is mutated while it's being iterated on, but no keys are added or removed, only values are changed. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26060] Class __dict__ iteration order changing due to type instance key-sharing
Changes by Ionel Cristian Mărieș <cont...@ionelmc.ro>: -- nosy: +ionelmc ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25920] PyOS_AfterFork should reset socketmodule's lock
Changes by Ionel Cristian Mărieș <cont...@ionelmc.ro>: -- nosy: +ionelmc ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25920> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16500] Add an 'atfork' module
Changes by Ionel Cristian Mărieș <cont...@ionelmc.ro>: -- nosy: +ionelmc ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25392] setup.py --quiet doesn't silence "no previously-included directories" warnings from MANIFEST.in
Ionel Cristian Mărieș added the comment: I think those warning are about the fact that stuff that ain't in the packages list are added on PYTHONPATH. Not 100% sure tho. Nothing to do with MANIFEST.in (not used for develop). Plus it's more specific to setuptools (where develop is implemented) than distutils. -- nosy: +ionelmc ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25392> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24344] Overlap display issue in windows installer
New submission from Ionel Cristian Mărieș: It appears that the new installer has some overlap issue when displaying progress info. Attached a screenshot. -- components: Installation files: installer-display-bug.png messages: 244579 nosy: ionelmc, steve.dower priority: normal severity: normal status: open title: Overlap display issue in windows installer versions: Python 3.5 Added file: http://bugs.python.org/file39584/installer-display-bug.png ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24344 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24353] NameError: name 'path_separators' is not defined
New submission from Ionel Cristian Mărieș: I get this: Traceback (most recent call last): File c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\basecommand.py, line 223, in main status = self.run(options, args) File c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\commands\install.py, line 297, in run root=options.root_path, File c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\req\req_set.py, line 622, in install **kwargs File c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\req\req_install.py, line 808, in install self.move_wheel_files(self.source_dir, root=root) File c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\req\req_install.py, line 1003, in move_wheel_files isolated=self.isolated, File c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\wheel.py, line 266, in move_wheel_files compileall.compile_dir(source, force=True, quiet=True) File C:\Program Files\Python 3.5\lib\compileall.py, line 88, in compile_dir legacy, optimize): File C:\Program Files\Python 3.5\lib\compileall.py, line 126, in compile_file cfile = importlib.util.cache_from_source(fullname) File frozen importlib._bootstrap_external, line 267, in cache_from_source File frozen importlib._bootstrap_external, line 58, in _path_split NameError: name 'path_separators' is not defined Any idea what's going on? Should I try to make a minimal reproducing example? -- components: Interpreter Core messages: 244609 nosy: ionelmc priority: normal severity: normal status: open title: NameError: name 'path_separators' is not defined versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24353 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24353] NameError: name 'path_separators' is not defined
Ionel Cristian Mărieș added the comment: Ooops, sorry for the noise, I had some weird breakage in my virtualenv. -- resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24353 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23275] Can assign [] = (), but not () = []
Changes by Ionel Cristian Mărieș cont...@ionelmc.ro: -- nosy: +ionelmc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23275 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: My point was about consistency in descriptor handling, not consistency of fault (eg: broken everywhere). I don't understand why that's not clear here. The big idea here is to harmonize capability checking with descriptor handling. Justifying breakage in callable with breakage in collections.Callable serves it no justice. On Monday, April 20, 2015, R. David Murray rep...@bugs.python.org wrote: R. David Murray added the comment: I in case it wasn't clear, I closed this not because of my case closed statement, but because as Eric pointed out we *do* have consistency here: things which check *capabilities* (as opposed to actually *using* the special methods), like callable and Iterable, only look for the existence of the method, consistently. The fact that you can then get an AttributeError later when actually using the method is unfortunate, but there really isn't anything sensible to be done about it, due to backward compatibility concerns. -- ___ Python tracker rep...@bugs.python.org javascript:; http://bugs.python.org/issue23990 ___ -- Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: Also, descriptors are a core mechanism in new-style classes - you can't have methods without descriptors. Why would you even consider removing descriptors from the special method lookup if that's part of the object model design? On Monday, April 20, 2015, Ionel Cristian Mărieș rep...@bugs.python.org wrote: Ionel Cristian Mărieș added the comment: My point was about consistency in descriptor handling, not consistency of fault (eg: broken everywhere). I don't understand why that's not clear here. The big idea here is to harmonize capability checking with descriptor handling. Justifying breakage in callable with breakage in collections.Callable serves it no justice. On Monday, April 20, 2015, R. David Murray rep...@bugs.python.org javascript:; wrote: R. David Murray added the comment: I in case it wasn't clear, I closed this not because of my case closed statement, but because as Eric pointed out we *do* have consistency here: things which check *capabilities* (as opposed to actually *using* the special methods), like callable and Iterable, only look for the existence of the method, consistently. The fact that you can then get an AttributeError later when actually using the method is unfortunate, but there really isn't anything sensible to be done about it, due to backward compatibility concerns. -- ___ Python tracker rep...@bugs.python.org javascript:; javascript:; http://bugs.python.org/issue23990 ___ -- Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro -- ___ Python tracker rep...@bugs.python.org javascript:; http://bugs.python.org/issue23990 ___ -- Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: On Mon, Apr 20, 2015 at 7:02 AM, Raymond Hettinger rep...@bugs.python.org wrote: AFAICT, there isn't a real problem here and the API for better-or-worse has proven to be usable in practice (the callable() API has been around practically forever and the descriptor protocol has been around since Py2.2 -- if there were a real issue here, it would have reared it head long ago). I think this is largely a product of misunderstanding the issue. As you can see in the early comments in the thread, the fact that special methods use descriptors is really really obscure. Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: On Mon, Apr 20, 2015 at 4:50 AM, Eric Snow rep...@bugs.python.org wrote: We should simply leave callable alone (and consistent with the other helpers that inspect the special *capability* of objects). Which are the other helpers? Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: On Mon, Apr 20, 2015 at 5:42 PM, Raymond Hettinger rep...@bugs.python.org wrote: That is clear but also isn't sufficient motivation. The proposed change is unnecessary and not rooted in real use cases. It is a semantic change to a long-standing view that callable() means having a __call__ method. There is one use case: a lazy object proxy (there are some examples in the earlier replies). Eric proposed a CallableProxy/NonCallableProxy dichtonomy but I don't really like that API (feels wrong and verbose). Please stop using the bug tracker to post li Sorry about that, I've replied through email and wasn't aware of bugtracker etiquette. The bugtracker doesn't have a nice way to reply to messages and it's atrocious on a mobile device. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: I want to address the four main points of criticism in fixing this issue, just in case it's not clear why I think those lines of thought are wrong: #1. It's specified/documented, therefore it's intended The first thing a maintainer does is check the docs. This is a sensible thing to do - as you cannot have all the details in your hear. The main question at that point: is it really like that?. However, it's easy to miss the fact that the documentation explains an implementation issue (`callable` is not really reliable, blablabla), and not the intent of `callable`. I mean, the name is pretty clear on what it's supposed to do: is the object callable or not? - simple as that. If the intent of `callable` is being unreliable then maybe we should just rename it to `maybe_callable` or `unreliable_callable`, or maybe even crappy_callable_we_dont_want_to_fix. #2. But the call could fail anyway, so what's the point of fixing this? The problem with this argument is that it's the same argument people bring up to remove the `callable` builtin. The problem is that you wouldn't use `callable` at all if you can just try/call/except. So this argument is not pertinent to the problem at hand (`callable` doing incomplete checks). #3. But it's going to be too slow! I don't want to be mean here, but this is just FUD. Lets measure this first. Is there really a measurable and significant performance impact on major applications? Does the argument even make sense in theory? A function call is pretty expensive in python, a mere attribute lookup wouldn't increase the cost by an order of magnitude (like 10x), would it? py -3 -mtimeit -s def foo(): pass foo.__call__ 1000 loops, best of 3: 0.0585 usec per loop py -3 -mtimeit -s def foo(): pass callable(foo) 1000 loops, best of 3: 0.0392 usec per loop Is this a significant margin? Also, I'm pretty sure those numbers can be improved. Python 3 regressed performance in various aspects (and improved other things, of course), why would this be a roadblock now? #4. It's too tricky, and I had a bad time with pickle one time ago, or: Exception masking issues This is certainly a problem, but it's not a new problem. There are already dozens of places where AttributeError is masked into something else (like a TypeError, or just a different result). Were do we draw the line here? Do we want to eventually get rid of all exception masking in an eventual Python 4.0 - what's the overarching goal here? Or is this just one of the many quirks of Python? What's worse - a quirk or a inconsistent quirk? The problem with this argument is that it attacks a different problem, that's just being made more visible if and when this problem of `callable` is fixed. Lets consider this strawman here: if a an user writes code like this: try: do important stuff except: pass # have fun debugging, haha who's at fault here? Is it the user that wrote that debugging black hole or is it python for letting the user do things like that? I don't think it's reasonable for Python to prevent exception masking bugs if the user was brave enough to write a descriptor. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: On Sun, Apr 19, 2015 at 9:01 PM, Eric Snow rep...@bugs.python.org wrote: Finally, instead of changing callable, why not use a metaclass that does the right thing? I believe MagicMock does something along those lines. What would be the right thing? AFAIK this cannot be achieved with a metaclass, since the check in `callable` just does a dumb check for `x-ob_type-tp_call`. Seriously, if you know a way to make `x-ob_type-tp_call` run any python code please let me know :-) Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: On Sun, Apr 19, 2015 at 10:01 PM, Ethan Furman rep...@bugs.python.org wrote: The right thing, using a meta-class, is to have the meta-class check if the proxied object is callable, and if so, put in the __call__ function in the class that is being created. Yes indeed, for a plain proxy. Unfortunately for a *lazy* proxy this is not acceptable as it would create (or access) the target. The point is to delay that till it's actually needed, not when the proxy is created. Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment:
On Sun, Apr 19, 2015 at 10:29 PM, Steven D'Aprano rep...@bugs.python.org
wrote:
This bug report seems to be completely based on a false premise. In the
very first message of this issue, Ionel says:
it return True even if __call__ is actually an descriptor that raise
AttributeError (clearly not callable at all).
but that is wrong. It *is* callable, and callable() is correct to return
True. If you look at the stack trace, the __call__ method
(function/property, whatever you want to call it) is called, and it raises
an exception. That is no different from any other method or function that
raises an exception.
It is wrong to think that raising AttributeError *inside* __call__ makes
the object non-callable.
Ionel, I raised these issues on Python-list here:
https://mail.python.org/pipermail/python-ideas/2015-April/033078.html
but you haven't responded to them.
I was hoping my other replies had addressed those issues. Note that the
presence of __call__ on the callstack is merely an artefact of how
@property works, and it's not actually the __call__ method (it's just
something that property.__get__ calls).
Here's an example that hopefully illustrates the issue more clearly:
class CallDescriptor:
... def __get__(self, inst, owner):
... target = inst._get_target()
... if callable(target):
... return target
... else:
... raise AttributeError('not callable')
...
class LazyProxy:
... __call__ = CallDescriptor()
... def __init__(self, get_target):
... self._get_target = get_target
...
def create_stuff():
... # heavy computation here
... print(Doing heavey computation)
... return 1, 2, 3
...
proxy = LazyProxy(create_stuff)
callable(proxy) ### this should be false!
True
hasattr(proxy, '__call__')
Doing heavey computation
False
def create_callable_stuff():
... # heavy computation here
... print(Doing heavey computation)
... def foobar():
... pass
... return foobar
...
proxy = LazyProxy(create_callable_stuff)
callable(proxy)
True
hasattr(proxy, '__call__')
Doing heavey computation
True
Now it appears there's a second issue, slightly related - if you actually
call the proxy object AttributeError is raised (instead of the TypeError):
proxy = LazyProxy(create_stuff)
callable(proxy)
True
hasattr(proxy, '__call__')
Doing heavey computation
False
proxy()
Doing heavey computation
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 7, in __get__
AttributeError: not callable
target = create_stuff()
Doing heavey computation
target()
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: 'tuple' object is not callable
Contrast that to how iter works - if the descriptor raise AttributeError
then iter raises TypeError (as expected):
class IterDescriptor:
... def __get__(self, inst, owner):
... target = inst._get_target()
... if hasattr(type(target), '__iter__') and hasattr(target,
'__iter__'):
... return target.__iter__
... else:
... raise AttributeError('not iterable')
...
class LazyProxy:
... __iter__ = IterDescriptor()
... def __init__(self, get_target):
... self._get_target = get_target
...
def create_iterable_stuff():
... # heavy computation here
... print(Doing heavey computation)
... return 1, 2, 3
...
proxy = LazyProxy(create_iterable_stuff)
iter(proxy)
Doing heavey computation
tuple_iterator object at 0x02B7C908
def create_noniterable_stuff():
... # heavy computation here
... print(Doing heavey computation)
... def foobar():
... pass
... return foobar
...
proxy = LazyProxy(create_noniterable_stuff)
iter(proxy)
Doing heavey computation
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: 'LazyProxy' object is not iterable
proxy.__iter__
Doing heavey computation
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 7, in __get__
AttributeError: not iterable
So this is why I'm bringing this up. If `iter` wouldn't handle it like
that then I'd think that maybe this is the intended behaviour.
I hope the blatant inconsistency is more clear
now
, and you'll understand that this bug report is not just some flagrant
misunderstanding of how __call__ works.
To sum this up, the root of this issue is that `callable` doesn't do all
the checks that are done right before actually performing the call (like
the descriptor handling). It's like calling your doctor for an appointment
where the secretary schedules you, but forgets to check if the doctor is in
vacation or not.
Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: On Mon, Apr 20, 2015 at 2:59 AM, Eric Snow rep...@bugs.python.org wrote: However, that is consistent across Python and has been this way for a long time (so there are backward compatibility concerns that cannot be ignored). It's not. Did you see the example with iter()/__iter__? It does convert the AttributeError into a TypeError. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: On Mon, Apr 20, 2015 at 2:59 AM, Eric Snow rep...@bugs.python.org wrote: It not a problem currently for callable. It is one you are proposing to introduce. It is one which current users of callable don't have to worry about. Were do we draw the line here? We don't add to the problem. Instead, we work to decrease it. What exactly are you proposing? Getting rid of AttributeError masking? I'm talking about applying an old design decision (AttributeError masking) in `callable`. Doesn't seem useful to talk about not having exception making unless you have a plan to remove that from other places (that's even harder than fixing `callable` IMO) just to fix this inconsistent handling in Python. Unless you think having inconsistent handling is OK. I do not think it's OK. There should be the same rules for attribute access everywhere. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: This is exactly analogous to what you are seeing with __call__ and callable(). Your example is incorrect, __next__ is what makes an object iterable but not what makes an object have an iterator (what __iter__ does). This correctly characterises the issue: class NonIter: ... pass ... iter(NonIter()) Traceback (most recent call last): File stdin, line 1, in module TypeError: 'NonIter' object is not iterable class DynamicNonIter: ... has_iter = False ... ... @property ... def __iter__(self): ... if self.has_iter: ... from functools import partial ... return partial(iter, [1, 2, 3]) ... else: ... raise AttributeError(Not really ...) ... dni = DynamicNonIter() iter(dni) Traceback (most recent call last): File stdin, line 1, in module TypeError: 'DynamicNonIter' object is not iterable dni.has_iter = True iter(dni) list_iterator object at 0x0362FF60 Now, if this is possible for `iter`, why shouldn't it be possible for `callable`? I'm not opposed to writing a PEP but the issue with `callable` is the only one I'm aware of, and this seems too small in scope anyway. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: On Sat, Apr 18, 2015 at 7:23 PM, Ethan Furman rep...@bugs.python.org wrote: class GenericProxy: def __init__(self, proxied): self.proxied = proxied # in case proxied is an __iter__ iterator @property def __iter__(self): if not hasattr(self.proxied, '__iter__'): raise AttributeError else: return self @property def __next__(self): if not hasattr(self.proxied, '__next__'): raise AttributeError else: return next(self.proxied) Unfortunately your implementation is incorrect as you forgot to that the property needs to return a function. This is a correct implementation that works as expected (in the sense that *iter does in fact honor the descriptor protocol)*: class GenericProxy: def __init__(self, proxied): self.proxied = proxied # in case proxied is an __iter__ iterator @property def __iter__(self): if not hasattr(self.proxied, '__iter__'): raise AttributeError else: return *lambda:* self @property def __next__(self): if not hasattr(self.proxied, '__next__'): raise AttributeError else: return *lambda: *next(self.proxied) The iter machinery doesn't grab values and call them, you've misinterpreted the error. Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: Turns out I've replied through email, and code got mangled. This is the correct version: class GenericProxy: def __init__(self, proxied): self.proxied = proxied @property def __iter__(self): if not hasattr(self.proxied, '__iter__'): raise AttributeError else: return lambda: self @property def __next__(self): if not hasattr(self.proxied, '__next__'): raise AttributeError else: return lambda: next(self.proxied) Note the lambdas. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: On Sat, Apr 18, 2015 at 8:35 PM, Christian Heimes rep...@bugs.python.org wrote: You also haven't shown that this behavior violates the documentation and language spec. How can I show it violates the spec when there's not such thing? :-) AFAIK, `callable` is not specified in any PEP. Please give some references when you make such statements. [...] write a PEP and convince all implementors of Python implementations to change the current way callable() and other protocols like iter work. `iter` works fine, as outlined above? Am I missing something? What other protocols do you have in mind, wrt honoring descriptors? Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: Christian, it's not clear why you're closing this. You basically just described the current broken behaviour. That by itself is not a reason enough (it's a sort of circular argument ;-). Can you please explain what prevents this to be fixed or how we got this implementation in the first place? From my perspective the current behavior is inconsistent, as outlined in the above examples. -- resolution: not a bug - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: Ethan, those sections you have linked to have nothing to do with special methods that are descriptors, or behaviour regarding descriptors. As seen in this example, descriptors are working even for special methods: class B: ... @property ... def __call__(self): ... return lambda: 1 ... b = B() b() 1 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: Actually it does address it, as AttributeError is very special: a.__call__ Traceback (most recent call last): File stdin, line 1, in module File stdin, line 4, in __call__ AttributeError: go away hasattr(a, '__call__') False -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: Some more discussions happened here: https://mail.python.org/pipermail/python-ideas/2015-April/033027.html So for Christian or Ethan, can you reconsider this issue? Joe has already kindly provided a patch for this that just does one extra check. It still checks the type of the object first. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: But somehow defining them with @property works (I guess because @property is in the class). IMO, this is the bug and not the callable() behavior. By the same reasoning we shouldn't be able to use staticmethod or classmethod for special methods. I'm pretty sure that's intended, even if it looks useless. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
