Re: asyncio+tkinter
On Tue, 22 Mar 2022 at 10:52, Skip Montanaro wrote: > > Given that both asyncio & tkinter are modules in the standard lib and both > have event loops, I would have expected to find some "best practice" > solution to mixing the two. I've not used asyncio, but might find it useful > with the pynput module in the context of a Tk app. I see a few solutions > out in the wild, but this seems like something which might best be > addressed in either the asyncio or tkinter documentation, or better yet, > implemented in one or the other. > Agreed. For GTK, you can use a dedicated loop policy like this: import asyncio_glib asyncio.set_event_loop_policy(asyncio_glib.GLibEventLoopPolicy()) It should be possible to make it this easy for asyncio + tkinter. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
asyncio+tkinter
Given that both asyncio & tkinter are modules in the standard lib and both have event loops, I would have expected to find some "best practice" solution to mixing the two. I've not used asyncio, but might find it useful with the pynput module in the context of a Tk app. I see a few solutions out in the wild, but this seems like something which might best be addressed in either the asyncio or tkinter documentation, or better yet, implemented in one or the other. Skip Montanaro -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
On 22/03/2022 10.17, Chris Angelico wrote: > On Tue, 22 Mar 2022 at 08:13, Paul St George wrote: >> >> >> When I am writing code, I often do things like this: >> >> context = bpy.context # convenience >> >> then whenever I need bpy.context, I only need to write context >> >> >> Here’s my question: >> >> When I forget to use the convenient shorter form >> >> why is bpy.context not interpreted as bpy.bpy.context? >> > > I don't understand the question. When you do that "for convenience" > assignment, what you're doing is creating a local variable named > "context" which refers to the same thing that bpy.context does (or did > at the time of the assignment, but presumably you only do this when > bpy.context won't get reassigned). It has no effect on any other name. > There's no magic happening here - it's just assignment to the name > context, like anything else. > > What are you expecting to happen here? It's the way Python works. try: context = bpy.context # convenience print( id(context), id(bpy.context) ) Remember that the 'relationship' between the two is established at run-time and at the data/address 'level' - and not at compile-time. Thus "context" points to a memory location, and does not 'stand for' "bpy.context" anywhere other than in your mind. (which is why we often need to use a copy() when we want 'separate data' - see also the 'counters' Python uses to manage "garbage collection") -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
On 21Mar2022 22:12, Paul St George wrote: >When I am writing code, I often do things like this: > >context = bpy.context # convenience > >then whenever I need bpy.context, I only need to write context > > >Here’s my question: > >When I forget to use the convenient shorter form > >why is bpy.context not interpreted as bpy.bpy.context? Because it still has its original meaning. You haven't changed the meaning of the word "context" in any position, you have simply made a module level name "context" referring to the same object to which "bpy.context" refers. So your module global namespace contains, initially, "bpy". Then you assign: context = bpy.context and now your module global namespace contains "bpy" and "context". But "bpy.context" is still what it was, because "bpy" is an object and you have done nothing to its ".context" attribute. Consider this code: class O: pass o = O() o.x = 3 x = o.x print(x) print(o.x) I expect to see "3" twice. What do you expect? "bpy" is no different to "o" - it's just a name. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
Chris, I think you understood the context but not the premise in a sense that wasin the way Paul was thinking. His premise is way off He seems to be thinking of something like a macro concept as iscommonly used in languages like C so: #define context bpy.context That could, in such languages, use a macro preprocessor, to parse the code once to make various textual changes without any real understanding of thelanguage and produce output ready for a compiler or interpreter phase. Python has nothing really like that albeit I can think of some things as well asgimmicks and tricks that can result in less typing. As an example, you canarrange for an object embedded within another to have some way to manipulate deeper structures from a higher level meaning less typing. As you point out, in many languages, often we are dealing with an implicit pointer withvery different results. And it is not at all the same in other ways, as you againpoint out so if you later re-assign bpy to anything else, including anotherdistinct object of the same kind, the variable called "context" keeps pointingto the old part of bpy. It is not an alias that can be used and it also is a potential problemfor various reasons such as retarding garbage collection or being used laterto make a change in the wrong place. So, I ask Paul what other language than python he has used before, just out of curiosity.Many and perhaps most of use regulars here have used quite a few others and eachhas its own quirks and we have adjusted our thinking multiple times by the time welearned Python. What Paul suggests is just a convenience is more than that. It is a variablebinding with many ramifications. -Original Message- From: Chris Angelico To: python-list@python.org Sent: Mon, Mar 21, 2022 5:17 pm Subject: Re: for convenience On Tue, 22 Mar 2022 at 08:13, Paul St George wrote: > > > When I am writing code, I often do things like this: > > context = bpy.context # convenience > > then whenever I need bpy.context, I only need to write context > > > Here’s my question: > > When I forget to use the convenient shorter form > > why is bpy.context not interpreted as bpy.bpy.context? > I don't understand the question. When you do that "for convenience" assignment, what you're doing is creating a local variable named "context" which refers to the same thing that bpy.context does (or did at the time of the assignment, but presumably you only do this when bpy.context won't get reassigned). It has no effect on any other name. There's no magic happening here - it's just assignment to the name context, like anything else. What are you expecting to happen here? ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
No, nor did I suggest that you did. `context` is presumably an attribute in the `bpy` module, for which you are creating a `context` attribute in your module. On Mon, 2022-03-21 at 22:31 +0100, Paul St George wrote: > Hi, > I do not (knowingly) have a module called ‘context'. > > > > > > On 21 Mar 2022, at 22:24, Paul Bryan wrote: > > > > Assuming `bpy` is a module, you're creating a new attribute in your > > module, `context`, that contains a reference to the same object > > that is referenced in the `context` attribute in the `bpy` module. > > > > On Mon, 2022-03-21 at 22:12 +0100, Paul St George wrote: > > > > > > When I am writing code, I often do things like this: > > > > > > context = bpy.context # convenience > > > > > > then whenever I need bpy.context, I only need to write context > > > > > > > > > Here’s my question: > > > > > > When I forget to use the convenient shorter form > > > > > > why is bpy.context not interpreted as bpy.bpy.context? > > > > > > > > > — > > > Paul St George > > > > > > > > > > > > > > > > > > > > -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
Hi, I do not (knowingly) have a module called ‘context'. > On 21 Mar 2022, at 22:24, Paul Bryan wrote: > > Assuming `bpy` is a module, you're creating a new attribute in your module, > `context`, that contains a reference to the same object that is referenced in > the `context` attribute in the `bpy` module. > > On Mon, 2022-03-21 at 22:12 +0100, Paul St George wrote: >> >> When I am writing code, I often do things like this: >> >> context = bpy.context # convenience >> >> then whenever I need bpy.context, I only need to write context >> >> >> Here’s my question: >> >> When I forget to use the convenient shorter form >> >> why is bpy.context not interpreted as bpy.bpy.context? >> >> >> — >> Paul St George >> >> >> >> >> > -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
Assuming `bpy` is a module, you're creating a new attribute in your module, `context`, that contains a reference to the same object that is referenced in the `context` attribute in the `bpy` module. On Mon, 2022-03-21 at 22:12 +0100, Paul St George wrote: > > When I am writing code, I often do things like this: > > context = bpy.context # convenience > > then whenever I need bpy.context, I only need to write context > > > Here’s my question: > > When I forget to use the convenient shorter form > > why is bpy.context not interpreted as bpy.bpy.context? > > > — > Paul St George > > > > > -- https://mail.python.org/mailman/listinfo/python-list
Re: for convenience
On Tue, 22 Mar 2022 at 08:13, Paul St George wrote: > > > When I am writing code, I often do things like this: > > context = bpy.context # convenience > > then whenever I need bpy.context, I only need to write context > > > Here’s my question: > > When I forget to use the convenient shorter form > > why is bpy.context not interpreted as bpy.bpy.context? > I don't understand the question. When you do that "for convenience" assignment, what you're doing is creating a local variable named "context" which refers to the same thing that bpy.context does (or did at the time of the assignment, but presumably you only do this when bpy.context won't get reassigned). It has no effect on any other name. There's no magic happening here - it's just assignment to the name context, like anything else. What are you expecting to happen here? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
for convenience
When I am writing code, I often do things like this: context = bpy.context # convenience then whenever I need bpy.context, I only need to write context Here’s my question: When I forget to use the convenient shorter form why is bpy.context not interpreted as bpy.bpy.context? — Paul St George -- https://mail.python.org/mailman/listinfo/python-list
Re: Pycharm IDE: seeking an assist!
On Mon, 21 Mar 2022 15:36:50 + (UTC), "Kevin M. Wilson" declaimed the following: >The use of Java options environment variables detected. >Such variables override IDE configuration files (*.vmoptions) and may cause >performance and stability issues. >Please consider deleting these variables: _JAVA_OPTIONS. > >Now I've opened the installed .bat files...append.bat, format.bat, >inspect.bat, itedit.bat, and pycharm.bat! >Of the Five(5) listed above, only 'pycharm.bat' contains statements setting up >the IDE' run environment, beyond >Seven (7) lines. > >Having searched the 'pycharm.bat' file for "_JAVA_OPTIONS", and the >'pycharm64.exe.vmoptions' file as well. The key words are "environment variables". The message is telling you that you have things set on your computer that take effect regardless of config files -- so will not be found IN the config files. https://docs.microsoft.com/en-us/windows/win32/procthread/environment-variables https://www.computerhope.com/issues/ch000549.htm You may need to find out what you installed before that created the environment variable -- since deleting the variable might affect how that application operates. -- Wulfraed Dennis Lee Bieber AF6VN wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/ -- https://mail.python.org/mailman/listinfo/python-list
Pycharm IDE: seeking an assist!
Greetings Python coders, I have installed the Pycharm IDE, and upon successfully auto install of the path/environment statements. The IDE opened and displayed (bottom right corner): The use of Java options environment variables detected. Such variables override IDE configuration files (*.vmoptions) and may cause performance and stability issues. Please consider deleting these variables: _JAVA_OPTIONS. Now I've opened the installed .bat files...append.bat, format.bat, inspect.bat, itedit.bat, and pycharm.bat! Of the Five(5) listed above, only 'pycharm.bat' contains statements setting up the IDE' run environment, beyond Seven (7) lines. Having searched the 'pycharm.bat' file for "_JAVA_OPTIONS", and the 'pycharm64.exe.vmoptions' file as well. I was able to add the line '-Djava.net.preferIPv4Stack=False', reboot, and still no JOY. Message is still popping open, when the IDE first executes. No documentation have I found, details what this option, the setting of...will do! Any and all help, please! Kevin Good sense makes one slow to anger, and it is his glory to overlook an offense. Proverbs 19:11 -- https://mail.python.org/mailman/listinfo/python-list
Re: Compiling and Linking pre-built Windows Python libraries with C++ files on Linux for Windows
Am 19.03.22 um 01:08 schrieb Ankit Agarwal: This is a very specific question. I am trying to figure out whether or not I can use pre-built python libraries and headers on Windows in a MinGW build on Linux. With the mingw cross-compiler on Linux that should be possible, however I guess it might be difficult to set it up. Setuptools is not good for crosscompiling. The easiest way to build Python extensions across multiple OSes is cibuildwheel: https://github.com/pypa/cibuildwheel Especially if your code lives on Github, then you can simply add cibuildwheel to your workflow and it will build for multiple OSes and Python versions on every commit. For OpenSource projects, Githubs build servers are even for free! Otherwise, the prices are moderate as well. If you happen to have your own build server farm (as in a commercial setting) then you can also use other CI tools with cibuildwheel. Christian -- https://mail.python.org/mailman/listinfo/python-list
