Re: Replacement for pygtk?
Il 06/09/2020 06:20, Michael Torrie ha scritto: On 9/4/20 3:24 PM, Grant Edwards wrote: I assume that difference is because pygtk was hand-written and gi is built auto-magically using SWIG or something like that? Essentially, yes. Although pygobject does not use a tool like swig to generate static wrappers. Rather it uses the GTK introspection API to ask gobject's for their methods and attributes, and then marshalls and calls them at runtime. So you can use pygobject with any GObject-based binary library, not just GTK+. Hope that makes sense. AFAIK, from the source code / include files a .gir file is generated (an xml with all the functions, parameters and info). For example for a simple rectangle_int(x. y. width, height) in cairo you have: From this file a .typelib is generated (a binary, compact representation of the data) and the gi library, using this file and the .dll/.so, creates the correct bindings and function for the language you use (at runtime). Switching from Gtk 3.22 to Gtk 3.24 (or a new 3.26) is only a matter of using the new .typelib/.dll with your version of gi, at least until the gi folks puts the handling of the default values for parameters :) So with the gi package for your python (say 3.5.10) you can use all the Gtk versions, you don't have to recompile for example Gtk 3.24.13 for your python/gi version. To have all the Gtk works with python 3.8 you have only to port / build the gi part (and on windows make some magic to handle the new path handling for the .dll search/load location, but this is another story). With best regards Daniele Forghieri -- https://mail.python.org/mailman/listinfo/python-list
Re: Uninstall problem
On 5-9-2020 19:40, Mats Wichmann wrote: On 9/5/20 7:54 AM, f.le...@omnias.fr wrote: Hello, I commit an error to install python because I chose python 3.8.5 x32bytes So I wanted uninstalling it to install python 3.7.9 x64bytes why not 3.8.5, by the way? But 3.8.5 version don't want uninstall !?! what does this mean? uninstall should work like any uninstall on your platform. in what way doesn't it want to uninstall? And so I have the twice in my computer now ! How can I do to uninstall 3.8.5 ? it doesn't hurt to have more than one. If you're on Windows, and use the Python Launcher, you can show all your installs, and use it to select the one you want: py --list py -3.7# specifically pick 3.7 py -3.8-32 # pick 32-bit 3.8, if both 64-bit and 32-bit are installed py -3-64 # pick latest 64-bit Py3 The one reason you might be unhappy with both is that the Python Launcher picks the highest numbered one as the default, so just py would get you 32-bit 3.8. if both 64-bit and 32-bit of same version are installed, the 64-bit one is preferred. D:\TEMP>python -V Python 3.8.5 D:\TEMP>py --list Installed Pythons found by py Launcher for Windows -3.7-64 * Can you explain above? D:\TEMP>where py C:\Windows\py.exe D:\TEMP>where python C:\Users\Luuk\AppData\Local\Microsoft\WindowsApps\python.exe -- https://mail.python.org/mailman/listinfo/python-list
Re: Uninstall problem
On 9/6/20 6:24 AM, Luuk wrote: > On 5-9-2020 19:40, Mats Wichmann wrote: >> On 9/5/20 7:54 AM, f.le...@omnias.fr wrote: >>> Hello, >>> >>> >>> I commit an error to install python because I chose python 3.8.5 >>> x32bytes >>> >>> So I wanted uninstalling it to install python 3.7.9 x64bytes >> >> why not 3.8.5, by the way? >> >>> But 3.8.5 version don't want uninstall !?! >> >> what does this mean? uninstall should work like any uninstall on your >> platform. in what way doesn't it want to uninstall? >> >> >>> And so I have the twice in my computer now ! How can I do to >>> uninstall 3.8.5 >>> ? >> >> >> it doesn't hurt to have more than one. If you're on Windows, and use >> the Python Launcher, you can show all your installs, and use it to >> select the one you want: >> >> py --list >> py -3.7 # specifically pick 3.7 >> py -3.8-32 # pick 32-bit 3.8, if both 64-bit and 32-bit are installed >> py -3-64 # pick latest 64-bit Py3 >> >> The one reason you might be unhappy with both is that the Python >> Launcher picks the highest numbered one as the default, so just >> >> py >> >> would get you 32-bit 3.8. if both 64-bit and 32-bit of same version >> are installed, the 64-bit one is preferred. >> > > D:\TEMP>python -V > Python 3.8.5 > > D:\TEMP>py --list > Installed Pythons found by py Launcher for Windows > -3.7-64 * > > > Can you explain above? Not sure what you're asking here? The python launcher is a separate program which keeps track of (and launches) your python.org Python installations, intended to cut down on the amount of path fiddling you otherwise have to do. Because of where it's installed (your snip below), it's always found. However, the Microsoft Store version of Python doesn't participate in this, as far as I've found in the past - and this would seem to be borne out by your investigation. > D:\TEMP>where py > C:\Windows\py.exe > > D:\TEMP>where python > C:\Users\Luuk\AppData\Local\Microsoft\WindowsApps\python.exe > -- https://mail.python.org/mailman/listinfo/python-list
PyDev 8.0 Released
PyDev 8.0 Release Highlights - *MyPy* - Make sure that only one MyPy is running at a given time (to prevent cache corruptions). - Properly report MyPy messages that only have a line number. ( *#PyDev-1091*) - MyPy integration now also shows notes for a message. (*#PyDev-1088*) - *Debugger* (updated to pydevd 2.0.0) - The frame evaluation mode (which adds programmatic breakpoints by rewriting bytecode) was redone (it had a critical issue which could make it skip breakpoints). - Fixed issue collecting try..except information. - Fixed issue evaluating numpy array with unexpected dimension. - *Type Inference* - Option to create a method at a given class properly considers type-hinting. (*#PyDev-1092*) - Support code-completion for Optional[]. (*#PyDev-1089*) - Properly handle type information when given as a string. ( *#PyDev-1082*, *#PyDev-1087*) - Fixed issue where line/col was not forwarded properly in go to definition. (*#PyDev-1075*) - Typing info should have priority when available. (*#PyDev-1079*) - Properly get completions considering function annotation. ( *#PyDev-1078*) - *Test running* - Fixed issue running tests which override *address* with nose. ( *#PYDev-1095*) - Fixed issue where test import/export didn't deal well with binary chars that were collected from the test. (*#PyDev-1067*) - *Others* - When finding a file in a project on Windows consider paths as case insensitive. - .mypy_cache and .pytest_cache contents are now marked as derived (so they can be filtered out in searches). - Fixed case where auto-import could be added to wrong location. ( *#PyDev-1085*) - Occurrence was not found in type hint return. (*#PyDev-1076*) - Find references not working for constant depending how it's used. ( *#PyDev-1083*) - Backported fix to properly parse raw f-string in Python 3.6. ( *#PyDev-991*) - Code completion inside f-strings. (*#PyDev-1081*) About PyDev PyDev is an open-source Python IDE on top of Eclipse for Python, Jython and IronPython development, now also available for Python on Visual Studio Code. It comes with goodies such as code completion, syntax highlighting, syntax analysis, code analysis, refactor, debug, interactive console, etc. It is also available as a standalone through LiClipse with goodies such as multiple cursors, theming and support for many other languages, such as Django Templates, Jinja2, Html, JavaScript, etc. Links: PyDev: http://pydev.org PyDev Blog: http://pydev.blogspot.com PyDev on VSCode: http://pydev.org/vscode LiClipse: http://www.liclipse.com PyVmMonitor - Python Profiler: http://www.pyvmmonitor.com/ Cheers, Fabio Zadrozny -- https://mail.python.org/mailman/listinfo/python-list
Re: Replacement for pygtk?
On 2020-09-06, Michael Torrie wrote: > On 9/4/20 3:24 PM, Grant Edwards wrote: >> I assume that difference is because pygtk was hand-written and gi is >> built auto-magically using SWIG or something like that? > > Essentially, yes. Although pygobject does not use a tool like swig to > generate static wrappers. Rather it uses the GTK introspection API to > ask gobject's for their methods and attributes, and then marshalls and > calls them at runtime. I was wondering about that. Some of the error messages you get when you mistype something hinted that the "wrapping" is being done on-the-fly. > So you can use pygobject with any GObject-based binary library, not > just GTK+. Hope that makes sense. Yes, I think so. I can see how it would be far less work that maintaining something like pygtk. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
