[issue2657] Curses sometimes fails to initialize terminal
Fernando Pérez <[EMAIL PROTECTED]> added the comment: As reported by Ondrej Certik on the IPython mailing list: Here is how to reliably (100%) reproduce it in ipython 0.8.2 (the bug indeed goes away in 0.8.4): http://code.google.com/p/sympy/issues/detail?id=822 together with a screenshot how the terminal looks like (see the comment #6 for the exact sympy revision to use). Maybe you could use it to track the bug down in curses, as your patch only seems to be a workaround (albeit working). Ondrej /quote While unfortunately right now I don't have the time to try and whittle this down to a smaller, self-contained example, it's great to at least have a guaranteed reproducible way of triggering the bug. It requires installing specific versions of both ipython and sympy, but that's very straightforward to do, as both are pure-python projects with no dependencies outside the stdlib. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2657> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3158] Doctest fails to find doctests in extension modules
New submission from Fernando Pérez <[EMAIL PROTECTED]>: Doctest fails to find doctests defined in extension modules. With tools like cython (http://cython.org) it's trivially easy to add docstrings to extension code, a task that is much less pleasant with hand-written extensions. The following patch is a minimal fix for the problem: --- doctest_ori.py 2008-06-20 19:22:56.0 -0700 +++ doctest.py 2008-06-20 19:23:53.0 -0700 @@ -887,7 +887,8 @@ for valname, val in obj.__dict__.items(): valname = '%s.%s' % (name, valname) # Recurse to functions & classes. -if ((inspect.isfunction(val) or inspect.isclass(val)) and +if ((inspect.isfunction(val) or inspect.isclass(val) or + inspect.isbuiltin(val) ) and self._from_module(module, val)): self._find(tests, val, valname, module, source_lines, globs, seen) However, it is likely not sufficient as it doesn't take into account the __test__ dict, for which probably the same change would work, just a few lines later. Furthermore, the real issue is in my view in the distinction made by inspect between isfunction() and isbuiltin() for the sake of analyzing docstrings. isfunction() returns false for a function that is defined in an extension module (though it *is* a function) while isbuiltin returns True (though it is *not* a builtin). For purposes of doctesting, doctest should simply care: - That it is a function. - That it has a docstring that can be parsed. But in too many places in doctest there are currently assumptions about being able to extract full source, line numbers, etc. Hopefully this quick fix can be applied as it will immediately make doctest work with large swaths of extension code, while a proper rethinking of doctest is made. BTW, in that process doctest will hopefully be made more modular and flexible: its current structure forces massive copy/paste subclassing for any kind of alternate use, since it has internally hardwired use of its own classes. Doctest is tremendously useful, but it really could use with some structural reorganization to make it more flexible (cleanly). -- components: Library (Lib) messages: 68489 nosy: fer_perez severity: normal status: open title: Doctest fails to find doctests in extension modules versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3158> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3158] Doctest fails to find doctests in extension modules
Fernando Pérez <[EMAIL PROTECTED]> added the comment: I think there are two issues that need to be separated: 1. The doctest bug. I'm happy with any resolution for it, and I'm not claiming that my patch is the best approach. isroutine() indeed works in my case, and if that approach works well in general for doctest, I'm perfectly happy with it. 2. Terminology. I really disagree with the idea that - 'function' describes the implementation language of an object instead of whether it's a standalone callable (vs an object method). - 'builtin' doesn't mean the object is "built into the shipped Python" but instead that it's "written in C". The language exposes its builtins via the __builtin__ module precisely to declare what is part of itself, and it even has in the documentation: http://docs.python.org/lib/built-in-funcs.html a section that starts: """2.1 Built-in Functions The Python interpreter has a number of functions built into it that are always available.""" Nowhere does it say that "builtins are written in C and functions in Python". In summary, I'm happy with any fix for the bug, but I very strongly disagree with a use of terminology that is confusing and misleading (and which unfortunately is enshrined in the inspect and types modules in how they distinguish 'Function' from 'BuiltinFunctionType'). And by the way, by 'extension module' I mean to describe C-extensions, since that is how most C code is shipped by third-party authors, those affected by this bug (since the stdlib doesn't seem to use doctests itself for its own testing of C code). ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3158> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2657] curses
New submission from Fernando Pérez <[EMAIL PROTECTED]>: Curses sometimes fails to correctly initialize the terminal. Unfortunately I don't know how to reproduce the problem, it was reported multiple times by ipython users, but I have no idea what causes it. I finally found a workaround by making a termios call that at least restores terminal state (see attachment), but it's just a workaround, not a real fix. The issue manifests itself as follows: at some point (I don't know why), a call to curses.initscr() doesn't actually set the terminal in the usual mode where input isn't accepted, but instead the terminal continues accepting normal input, issuing newlines, etc. The only sign that curses is active is that in a modern terminal, the scrollbar changes to fill the screen. After this, calling curses.endwin(), instead of restoring terminal state, leaves the terminal in the mode that typically initscr() would put it in: no input is displayed, printouts swallow end-of-line characters, etc. When this happened in ipython sessions, we'd just suggest users call !reset (the system command), which would restore terminal state. But the problem is obviously in curses itself, because once this problem appeared, running the attached script would always print 'False' for the state condition checked there. For now in IPython we have a workaround, but perhaps with this little description/example, someone who knows the curses code might be able to actually fix the real problem. If I find a reliable way to trigger the bug, I'll add comments here indicating so. -- components: Extension Modules files: cursesbug.py messages: 65626 nosy: fer_perez severity: normal status: open title: curses type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file10059/cursesbug.py __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2657> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46412] PyQT6 projects crashes with python 3.10
New submission from Fernando Pérez Gómez : can't translate ui. files , flags of alignment , curve types of animation doesn´t wors ...etc -- messages: 410791 nosy: fernandoprezgmez priority: normal severity: normal status: open title: PyQT6 projects crashes with python 3.10 type: crash versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46412> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46412] PyQT6 projects crashes with python 3.10
Fernando Pérez Gómez added the comment: I have to perform several tests to provide a detailed report, check other third party libraries, mysql connector for example, and send it to you. There are several things that don't work with Qt libs (the one that works best is PyQt6). When I finish the tests and have the report, I'll send it to you. In the meantime I suggest you search for pyqt6 + python3.10 on the web. There are plenty of complaints on all platforms (Windows, Mac and Linux). My system is Manjaro Linux , kernel version 5.15-2 , the PyQt6 version installed is 6.22.3 . So far I have verified that it is not the fault of the IDE and that it does not install the plugins via pip . Of course I will report the same to River Bank Computing. Sorry I can't be more specific at the moment, because python has been updated on my system recently. Thanks for your patience , I 'll send you a full report in a couple of days . that takes work El lun, 17 ene 2022 a las 16:02, Ronald Oussoren () escribió: > > Ronald Oussoren added the comment: > > This is most likely a problem with PyQt6. Please ask that project first > (with a clearer description of what goes wrong and on which platforms). > > -- > nosy: +ronaldoussoren > resolution: -> third party > stage: -> resolved > status: open -> closed > > ___ > Python tracker > <https://bugs.python.org/issue46412> > ___ > -- ___ Python tracker <https://bugs.python.org/issue46412> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
