Re: Helping Windows first time users
On 16/04/2020 2:46 pm, DL Neil via Python-list wrote: On 16/04/20 3:34 PM, Dennis Lee Bieber wrote: On Wed, 15 Apr 2020 19:23:43 +0100, Barry Scott declaimed the following: I post some suggestion to improve the Python installer for Windows to better sign post users on the next steps. https://mail.python.org/archives/list/[email protected]/message/TKHID7PMKN5TK5QDQ2BL3G45FYAJNYJX/ It also seems like we could do with drafting the text of a helpful reply to help the Windows first time users. This would help folks that reply to the Windows first time users to have a quick way to reply without drafting the text a reply every time. What are your thoughts on the installer changes and reply text? No other Windows installers that I know of provide information on how to use the installed application. Anyone installing software should realize that the installer file itself is just that, an installer, and not be used in attempts to run the installed application, they should look elsewhere for the application itself. I would also note that there are MANY Python installers for Windows: Python.org, ActiveState, Anaconda, Enthought, and even (for Win10) the M$ "app store" has one. Are you proposing that all these sources need to make changes to their distributions? @Barry's observation is that many first-time Python-on-Windows users seem to fail at the first click. (I have also voiced similar concerns 'here') I use Python on both Windows and Linux. Therefore I more or less disqualify myself from being able to comment. I have found ways to operate successfully and would only really be able to suggest what works for me. But I do feel moved to offer my thoughts. The real solution is to more closely define the target audience plus the Python precise skill attainment desired. Carefully describe/define the first-time Python user on Windows. Then prepare the installer to suit that definition. The description might specify the level of Windows expertise (or lack of) in exquisite detail. You need age, gender, education level, etc. You need a real person in your mind's eye to prepare the product for. You need to be able to imagine the answer to any question you might ask such an imaginary person. Plus understanding colleagues if they hear you asking :) Maybe the objective is to write hello world or a simple game in a dos prompt. If gui skill attainment is felt to be important for the defined audience then hello world would probably be enough. If the defined neophyte user is sufficiently inexperienced then forget IDEs and focus only on a text editor with syntax highlighting. We all know how important virtual envs are and multiple Python installs but newbies don't need or even want to know that. Time enough to realise you need it when it solves a future roadblock for you. It is impossible to get started when confronted with too much information. The bottom line is that Windows is designed to hide things from the user. Our new user might be very experienced in MS Office but knows nothing about the operating system. That means the installer needs to provide a desktop shortcut which delivers a pre-defined user experience and from which the user can emerge with clear understanding. I would suggest one click (double-click actually) to open a command prompt with the interpreter running ready to accept input. Another which opened a getting-started document which assumes no prior knowledge but requires a ready Python interpreter. Finally another entitled "Next steps". From my perspective the installer should create a desktop folder called "Python shortcuts" to contain all such clickable nirvana. Think about a bootstrap track on a disk. There is only enough there to get to the next step. As mentioned, I don't pay the regular 'MSFT-tax'. However, many use MS-Windows because that's what they've been given, or must use, at their work. I have read articles which suggest that MS-Windows has improved to the point of making a good/better dev.platform. Whether *I* agree, or not, is of no import in this conversation. But it is interesting. I use Windows because I have no choice. All my production machines are non-gui Ubuntu. I started my programming on non-gui PCs which made it simple with Windows. However, on reading some of these emails from struggling Windows users it is easy to agree Windows is not made for new devs. Cheers Mike PS: I think the installer on Windows should install to a user-accessible location on the file system - not Program files. When I first installed Python on Windows the default location was C:\Python24 (I think). New users won't see it there but when they do need to look at it they will find it much more accessible. PPS: Christoph Gohlke's work should be formally supported by PSF and become "Official". If one downloads other Win-installer installed software, what happens? Is Python's Win-download following t
Run code automatically
Dear All, I just start the self learning of python, and I tried to use it in jupyter notebook. I work on real dataset and I used pandas for that. Now my problem is I developed two separate code but dependent the first one should run to give me samples from my dataset and do the clustering (I use Kmeans) and the second should select data from each cluster provided by the first code. My question is: how can I run both code for many times without pushing the bottom "run" each time? make it automatic I tried to use Ipyparallel but seems that I don't know how to use it Thank you -- https://mail.python.org/mailman/listinfo/python-list
Re: Run code automatically
Do you want to run the code many times after just clicking run once? If so then I think grouping the whole program in one for loop would do the task. Souvik python dev On Thu, Apr 16, 2020, 4:57 PM hanan lamaazi wrote: > Dear All, > > I just start the self learning of python, and I tried to use it in jupyter > notebook. I work on real dataset and I used pandas for that. Now my problem > is I developed two separate code but dependent the first one should run to > give me samples from my dataset and do the clustering (I use Kmeans) and > the second should select data from each cluster provided by the first code. > > My question is: > how can I run both code for many times without pushing the bottom "run" > each time? make it automatic > > > I tried to use Ipyparallel but seems that I don't know how to use it > > > Thank you > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Threading module and embedded python
Barry, sorry for sending you a private message yesterday, was not intended. No, I only have rudimentary knowledge of C++, but it has been developing since I started using Cython. I haven't done any stack analysis yet but hey, there's always a first time. I think my stubbornness could be of help here :-) Visual Studio reports that the last location of the thread is in _ctypes.pyd and the call stack window shows that the last execution is user32.dll!InternalDailogBox(). Call Stack *user32.dll!InternalDialogBox()user32.dll!DialogBoxIndirectParamAorW()user32.dll!DialogBoxIndirectParamW()_ctypes.pyd!07fee7fc17e3()_ctypes.pyd!07fee7fbfee3()_ctypes.pyd!07fee7fbb4c5()_ctypes.pyd!07fee7fbc019()_ctypes.pyd!07fee7fb6dfa()python37.dll!_PyObject_FastCallKeywords(_object * callable=0x02fa8c78, _object * const * stack=0x05261c78, __int64 nargs=5, _object * kwnames=0x)* The thread is neither suspended nor does it have any different status than the main thread which loops through its main event queue at this point. Thank you Eren Am Mi., 15. Apr. 2020 um 22:57 Uhr schrieb Barry : > > > > On 15 Apr 2020, at 21:18, Eko palypse wrote: > > > > Thank you for your suggestion. I will give it a try. > > > >> What is the "stuck" thread doing? waiting for a lock? > > > > No, it should open a dialog created with DialogBoxIndirectParamW > > < > https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-dialogboxindirectparamw > > > > I assume you are a C++ developer and can look at the stack of the thread. > What is the thread doing? Is it in python code? Is it in windows code? > > Barry > > > . > > > > Eren > > > >> Am Mi., 15. Apr. 2020 um 20:12 Uhr schrieb Barry Scott < > >> [email protected]>: > >> > >> > >> > On 15 Apr 2020, at 13:30, Eko palypse wrote: > >>> > >>> Hi everyone, > >>> > >>> the following happens on Windows7 x64 and Python37 x64 > >>> > >>> I have a plugin DLL for a C++ application in which Python37 is > embedded. > >>> The plugin itself works, except when I want to use the threading > module. > >>> > >>> If I start a Python script in my plugin which uses the threading module > >>> I can verify via ProcessExplorer that the thread is started, > >>> but it doesn't do anything (??) and the c++ application doesn't really > >> do anything anymore either. > >>> > >>> Only when I stop the C++ Applikation, the thread becomes active for a > >> short time. > >>> Verified with logging module over time print-outs. > >>> > >>> Apparently I did not understand everything about threads and embedded > >> python. > >>> > >>> Any idea what I'm doing wrong? > >> > >> This is what I typically do. > >> > >> Make sure that you have installed the Python debug files. > >> Now you can use the visual C++ debugger to attach to the process and > >> look at what the threads are doing. > >> > >> I always have the python source code on hand to read as well. > >> > >> This should give you a clue. > >> > >> What is the "stuck" thread doing? waiting for a lock? > >> > >> Barry > >> > >> > >> > >> > >>> > >>> > >>> The whole thing is initialized by the DllMain routine. > >>> > >>> > >>> BOOL APIENTRY DllMain( HANDLE hModule, > >>> DWORD reasonForCall, > >>> LPVOID /* lpReserved */ ) > >>> { > >>> switch ( reasonForCall ) > >>> { > >>> case DLL_PROCESS_ATTACH: > >>> if (!Py_IsInitialized()) > >>> { > >>> PyImport_AppendInittab("Npp", &PyInit_Npp); > >>> Py_InitializeEx(0); > >>> PyEval_InitThreads(); //<- this shouldn't be needed as I > >> understand that it is called by Py_InitializeEx anyway > >>> } > >>> PyImport_ImportModule("Npp"); > >>> break; > >>> case DLL_PROCESS_DETACH: > >>> Py_Finalize(); > >>> break; > >>> > >>> case DLL_THREAD_ATTACH: > >>> break; > >>> > >>> case DLL_THREAD_DETACH: > >>> break; > >>> } > >>> > >>> return TRUE; > >>> } > >>> > >>> and the code in the plugin which executes the python scripts is this > >>> > >>> cdef void run_code(): > >>> try: > >>> global_dict = globals() > >>> if '__name__' not in global_dict or global_dict['__name__'] != > >> '__main__': > >>> global_dict.update({"__name__": "__main__",}) > >>> exec(compile(editor.getText(), '', 'exec'), global_dict) > >>> > >>> except Exception: > >>> MessageBoxW(nppData._nppHandle, > >>> traceback.format_exc(), > >>> 'RUN CODE EXCEPTION', > >>> 0) > >>> > >>> I don't know if this is important, but the DLL is generated by Cython. > >>> > >>> Thank you for reading and stay healthy > >>> > >>> Eren > >>> -- > >>> https://mail.python.org/mailman/listinfo/python-list > >>> > >> > >> > > -- > > https://mail.python.org/mailman/listinfo/python-list > > > > -- https://mail.python.org/mailm
Re: What variable type is returned from Open()?
On Wednesday, April 15, 2020 at 9:46:30 PM UTC-4, Michael Torrie wrote: > On 4/15/20 5:47 PM, dcwh wrote: > > So in the case of Python, whenever the type information is available, > > I want to make it explicit rather than inferred. Whether the A.I. is > > running a simulation of the software in an IDE, or analyzing them as > > text documents, they should be able to glean as much as possible. > > They should also be able to infer the type, via a Hungarian syntax > > variation. > > Hungarian syntax is definitely an acquired taste, and better suited to > statically-typed languages. > > In this specific case of dealing with open(), keep in mind that most > things that work with files (including something like, for example, > csvreader) only require a file-like object. That can be something that > open() returns, or some other object that implements the semantics. This > is important because anything that can work with files can also work > with any other implementation, provided it speaks the same protocol. > For example you could feed it a stream from a zip archive. Or a network > stream. Or something else of your own design. No need for "interface" > classes (although Zope does implement and use them for some reason), or > a special class hierarchy. > > In my opinion, the first line of documentation should be decent > docstrings that document the parameters and return values for functions. > I can think of some cases when type hinting would be desired and > recommended. But storing the result of open() isn't one of them. Thanks DL Neil, Michael Torrie ; and especially Random832 & Souvik Dutta. Although my coding style is still evolving, I'm already clear on how I personally want to name variables, and the question of clarifying their type. The Docstring of course is the first line of defense, but there's still something missing that I haven't fully worked out yet, regarding the purpose of analyzing the code by an artificial entity. Maybe a json or edn file with the same base filename as the source file, which contains details about the intent of the module. Whatever ; it'll take time to brainstorm something. Nevertheless, thanks for answering the question that was actually asked, which was the type of variable returned from an Open() statement. -- https://mail.python.org/mailman/listinfo/python-list
Re: What variable type is returned from Open()?
What are you making? Souvik flutter dev On Thu, Apr 16, 2020, 9:10 PM wrote: > On Wednesday, April 15, 2020 at 9:46:30 PM UTC-4, Michael Torrie wrote: > > On 4/15/20 5:47 PM, dcwh wrote: > > > So in the case of Python, whenever the type information is available, > > > I want to make it explicit rather than inferred. Whether the A.I. is > > > running a simulation of the software in an IDE, or analyzing them as > > > text documents, they should be able to glean as much as possible. > > > They should also be able to infer the type, via a Hungarian syntax > > > variation. > > > > Hungarian syntax is definitely an acquired taste, and better suited to > > statically-typed languages. > > > > In this specific case of dealing with open(), keep in mind that most > > things that work with files (including something like, for example, > > csvreader) only require a file-like object. That can be something that > > open() returns, or some other object that implements the semantics. This > > is important because anything that can work with files can also work > > with any other implementation, provided it speaks the same protocol. > > For example you could feed it a stream from a zip archive. Or a network > > stream. Or something else of your own design. No need for "interface" > > classes (although Zope does implement and use them for some reason), or > > a special class hierarchy. > > > > In my opinion, the first line of documentation should be decent > > docstrings that document the parameters and return values for functions. > > I can think of some cases when type hinting would be desired and > > recommended. But storing the result of open() isn't one of them. > > Thanks DL Neil, Michael Torrie ; and especially Random832 & Souvik Dutta. > Although my coding style is still evolving, I'm already clear on how I > personally want to name variables, and the question of clarifying their > type. > > The Docstring of course is the first line of defense, but there's still > something missing that I haven't fully worked out yet, regarding the > purpose of analyzing the code by an artificial entity. > > Maybe a json or edn file with the same base filename as the source file, > which contains details about the intent of the module. > > Whatever ; it'll take time to brainstorm something. Nevertheless, thanks > for answering the question that was actually asked, which was the type of > variable returned from an Open() statement. > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: What variable type is returned from Open()?
On 4/15/20 9:55 AM, [email protected] wrote: > Hi, > > > As much as possible, I make use of optional type hints. So if I know a > function returns an integer, then I use > > > this_number_i : int = GetThisNumber() > > > But there's no 'file' type, so I'm not sure what to use as the type for the > return value of an Open() function. > > > config_file : file = open(config_file_s, "r") > > > What type of variable should config_file (above) be declared as? > Running the simple test program in IDLE: f = open("TestFile.txt", "w") print (type(f)) I get the answer: So that is the name of the type that is returned, at least for that call. One key thing to note is that it begins with a _, so that type is actually an implementation detail, subject to change. This isn't that strange in Python as normally you don't really need to know the type of an object, but what capabilities the object supports (most from its type, but some operations can be just added to the object). This is largely because Python is based on a concept call 'Duck-Typing', where it is more important if the object quacks like a duck then if it technically IS a duck. (And strangely, I believe you can have something that technically is a duck, but doesn't quack like one, as well as something totally unrelated to the duck type but quacks just like one). Files are such an animal, 'fileness' is not based on type, but on capability. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Helping Windows first time users
> On 16 Apr 2020, at 08:45, Mike Dewhirst wrote: > > On 16/04/2020 2:46 pm, DL Neil via Python-list wrote: >> On 16/04/20 3:34 PM, Dennis Lee Bieber wrote: >>> On Wed, 15 Apr 2020 19:23:43 +0100, Barry Scott >>> declaimed the following: >>> I post some suggestion to improve the Python installer for Windows to better sign post users on the next steps. https://mail.python.org/archives/list/[email protected]/message/TKHID7PMKN5TK5QDQ2BL3G45FYAJNYJX/ It also seems like we could do with drafting the text of a helpful reply to help the Windows first time users. This would help folks that reply to the Windows first time users to have a quick way to reply without drafting the text a reply every time. What are your thoughts on the installer changes and reply text? >>> >>> No other Windows installers that I know of provide information on how >>> to use the installed application. Anyone installing software should realize >>> that the installer file itself is just that, an installer, and not be used >>> in attempts to run the installed application, they should look elsewhere >>> for the application itself. >>> >>> I would also note that there are MANY Python installers for Windows: >>> Python.org, ActiveState, Anaconda, Enthought, and even (for Win10) the M$ >>> "app store" has one. Are you proposing that all these sources need to make >>> changes to their distributions? >> >> >> @Barry's observation is that many first-time Python-on-Windows users seem to >> fail at the first click. (I have also voiced similar concerns 'here') > > I use Python on both Windows and Linux. Therefore I more or less disqualify > myself from being able to comment. I have found ways to operate successfully > and would only really be able to suggest what works for me. But I do feel > moved to offer my thoughts. > > The real solution is to more closely define the target audience plus the > Python precise skill attainment desired. > > Carefully describe/define the first-time Python user on Windows. Then prepare > the installer to suit that definition. At a first guess its the folks that email screen snap shots to us on a daily basis and ask about why python prompts to repair, uninstall. > > The description might specify the level of Windows expertise (or lack of) in > exquisite detail. You need age, gender, education level, etc. You need a real > person in your mind's eye to prepare the product for. You need to be able to > imagine the answer to any question you might ask such an imaginary person. > Plus understanding colleagues if they hear you asking :) > > Maybe the objective is to write hello world or a simple game in a dos prompt. > If gui skill attainment is felt to be important for the defined audience then > hello world would probably be enough. > > If the defined neophyte user is sufficiently inexperienced then forget IDEs > and focus only on a text editor with syntax highlighting. > > We all know how important virtual envs are and multiple Python installs but > newbies don't need or even want to know that. Time enough to realise you need > it when it solves a future roadblock for you. It is impossible to get started > when confronted with too much information. > > The bottom line is that Windows is designed to hide things from the user. Our > new user might be very experienced in MS Office but knows nothing about the > operating system. That means the installer needs to provide a desktop > shortcut which delivers a pre-defined user experience and from which the user > can emerge with clear understanding. > > I would suggest one click (double-click actually) to open a command prompt > with the interpreter running ready to accept input. Another which opened a > getting-started document which assumes no prior knowledge but requires a > ready Python interpreter. Finally another entitled "Next steps". From my > perspective the installer should create a desktop folder called "Python > shortcuts" to contain all such clickable nirvana. Interesting that's what I go from Dennis's reply. > > Think about a bootstrap track on a disk. There is only enough there to get to > the next step. > >> >> As mentioned, I don't pay the regular 'MSFT-tax'. However, many use >> MS-Windows because that's what they've been given, or must use, at their >> work. I have read articles which suggest that MS-Windows has improved to the >> point of making a good/better dev.platform. Whether *I* agree, or not, is of >> no import in this conversation. > > But it is interesting. I use Windows because I have no choice. All my > production machines are non-gui Ubuntu. I started my programming on non-gui > PCs which made it simple with Windows. However, on reading some of these > emails from struggling Windows users it is easy to agree Windows is not made > for new devs. > > Cheers > > Mike > > PS: I think the installer on Windows s
Re: What variable type is returned from Open()?
On Thursday, April 16, 2020 at 12:09:44 PM UTC-4, Souvik Dutta wrote: > What are you making? > > Souvik flutter dev > > On Thu, Apr 16, 2020, 9:10 PM wrote: > > > On Wednesday, April 15, 2020 at 9:46:30 PM UTC-4, Michael Torrie wrote: > > > On 4/15/20 5:47 PM, dcwh wrote: > > > > So in the case of Python, whenever the type information is available, > > > > I want to make it explicit rather than inferred. Whether the A.I. is > > > > running a simulation of the software in an IDE, or analyzing them as > > > > text documents, they should be able to glean as much as possible. > > > > They should also be able to infer the type, via a Hungarian syntax > > > > variation. > > > > > > Hungarian syntax is definitely an acquired taste, and better suited to > > > statically-typed languages. > > > > > > In this specific case of dealing with open(), keep in mind that most > > > things that work with files (including something like, for example, > > > csvreader) only require a file-like object. That can be something that > > > open() returns, or some other object that implements the semantics. This > > > is important because anything that can work with files can also work > > > with any other implementation, provided it speaks the same protocol. > > > For example you could feed it a stream from a zip archive. Or a network > > > stream. Or something else of your own design. No need for "interface" > > > classes (although Zope does implement and use them for some reason), or > > > a special class hierarchy. > > > > > > In my opinion, the first line of documentation should be decent > > > docstrings that document the parameters and return values for functions. > > > I can think of some cases when type hinting would be desired and > > > recommended. But storing the result of open() isn't one of them. > > > > Thanks DL Neil, Michael Torrie ; and especially Random832 & Souvik Dutta. > > Although my coding style is still evolving, I'm already clear on how I > > personally want to name variables, and the question of clarifying their > > type. > > > > The Docstring of course is the first line of defense, but there's still > > something missing that I haven't fully worked out yet, regarding the > > purpose of analyzing the code by an artificial entity. > > > > Maybe a json or edn file with the same base filename as the source file, > > which contains details about the intent of the module. > > > > Whatever ; it'll take time to brainstorm something. Nevertheless, thanks > > for answering the question that was actually asked, which was the type of > > variable returned from an Open() statement. > > -- > > https://mail.python.org/mailman/listinfo/python-list > > The current project is just a utility for checking connectivity, logging, and reporting any failures via email. But the point of the thread applies to any project or module. Regards, -- https://mail.python.org/mailman/listinfo/python-list
Re: What variable type is returned from Open()?
On Thursday, April 16, 2020 at 12:12:23 PM UTC-4, Richard Damon wrote:
> On 4/15/20 9:55 AM, dcw wrote:
> > Hi,
> >
> >
> > As much as possible, I make use of optional type hints. So if I know a
> > function returns an integer, then I use
> >
> >
> > this_number_i : int = GetThisNumber()
> >
> >
> > But there's no 'file' type, so I'm not sure what to use as the type for the
> > return value of an Open() function.
> >
> >
> > config_file : file = open(config_file_s, "r")
> >
> >
> > What type of variable should config_file (above) be declared as?
> >
> Running the simple test program in IDLE:
>
>
> f = open("TestFile.txt", "w")
> print (type(f))
>
> I get the answer:
>
> So that is the name of the type that is returned, at least for that
> call. One key thing to note is that it begins with a _, so that type is
> actually an implementation detail, subject to change. This isn't that
> strange in Python as normally you don't really need to know the type of
> an object, but what capabilities the object supports (most from its
> type, but some operations can be just added to the object). This is
> largely because Python is based on a concept call 'Duck-Typing', where
> it is more important if the object quacks like a duck then if it
> technically IS a duck. (And strangely, I believe you can have something
> that technically is a duck, but doesn't quack like one, as well as
> something totally unrelated to the duck type but quacks just like one).
> Files are such an animal, 'fileness' is not based on type, but on
> capability.
>
> --
> Richard Damon
Ok, thanks.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Threading module and embedded python
> On 16 Apr 2020, at 14:55, Eko palypse wrote: > > Barry, sorry for sending you a private message yesterday, was not intended. > > No, I only have rudimentary knowledge of C++, > but it has been developing since I started using Cython. > I haven't done any stack analysis yet but hey, there's always a first time. > I think my stubbornness could be of help here :-) Its a very useful when the simple debug stuff fails. > > Visual Studio reports that the last location of the thread is in _ctypes.pyd > and the call stack window shows that the last execution is > user32.dll!InternalDailogBox(). > > Call Stack > > > *user32.dll!InternalDialogBox()user32.dll!DialogBoxIndirectParamAorW()user32.dll!DialogBoxIndirectParamW()_ctypes.pyd!07fee7fc17e3()_ctypes.pyd!07fee7fbfee3()_ctypes.pyd!07fee7fbb4c5()_ctypes.pyd!07fee7fbc019()_ctypes.pyd!07fee7fb6dfa()python37.dll!_PyObject_FastCallKeywords(_object > * callable=0x02fa8c78, _object * const * stack=0x05261c78, > __int64 nargs=5, _object * kwnames=0x)* My guess is that you are missing an important parameter to the dialog that allows it be seen. Test the dialog code outside of the embedded python, with a command line python. I recall that you have to pass in the parent for a dialog. Maybe in the embedded version you do not have an HWND that is usable, can NULL be used? Is there a SHOW arg that you need to pass? I'd check the MSDN docs for the call you are making and check every param is as required. (Its been a along time since I did low level win32 in anger so forgive the lack of solutions) > > > The thread is neither suspended nor does it have any different status than > the main thread > which loops through its main event queue at this point. It is suspended inside the user32.dll. Barry > > Thank you > Eren > > > Am Mi., 15. Apr. 2020 um 22:57 Uhr schrieb Barry : > >> >> >>> On 15 Apr 2020, at 21:18, Eko palypse wrote: >>> >>> Thank you for your suggestion. I will give it a try. >>> What is the "stuck" thread doing? waiting for a lock? >>> >>> No, it should open a dialog created with DialogBoxIndirectParamW >>> < >> https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-dialogboxindirectparamw >>> >> >> I assume you are a C++ developer and can look at the stack of the thread. >> What is the thread doing? Is it in python code? Is it in windows code? >> >> Barry >> >>> . >>> >>> Eren >>> Am Mi., 15. Apr. 2020 um 20:12 Uhr schrieb Barry Scott < [email protected]>: >> On 15 Apr 2020, at 13:30, Eko palypse wrote: > > Hi everyone, > > the following happens on Windows7 x64 and Python37 x64 > > I have a plugin DLL for a C++ application in which Python37 is >> embedded. > The plugin itself works, except when I want to use the threading >> module. > > If I start a Python script in my plugin which uses the threading module > I can verify via ProcessExplorer that the thread is started, > but it doesn't do anything (??) and the c++ application doesn't really do anything anymore either. > > Only when I stop the C++ Applikation, the thread becomes active for a short time. > Verified with logging module over time print-outs. > > Apparently I did not understand everything about threads and embedded python. > > Any idea what I'm doing wrong? This is what I typically do. Make sure that you have installed the Python debug files. Now you can use the visual C++ debugger to attach to the process and look at what the threads are doing. I always have the python source code on hand to read as well. This should give you a clue. What is the "stuck" thread doing? waiting for a lock? Barry > > > The whole thing is initialized by the DllMain routine. > > > BOOL APIENTRY DllMain( HANDLE hModule, > DWORD reasonForCall, > LPVOID /* lpReserved */ ) > { > switch ( reasonForCall ) > { > case DLL_PROCESS_ATTACH: > if (!Py_IsInitialized()) > { > PyImport_AppendInittab("Npp", &PyInit_Npp); > Py_InitializeEx(0); > PyEval_InitThreads(); //<- this shouldn't be needed as I understand that it is called by Py_InitializeEx anyway > } > PyImport_ImportModule("Npp"); > break; > case DLL_PROCESS_DETACH: > Py_Finalize(); > break; > > case DLL_THREAD_ATTACH: > break; > > case DLL_THREAD_DETACH: > break; > } > > return TRUE; > } > > and the code in the plugin which executes the python scripts is this > > cdef void run_code(): > try: >>
Re: Detect dotted (broken) lines only in an image using OpenCV
> On 16 Apr 2020, at 00:36, Edu Py wrote:
>
> I am trying to learn techniques on image feature detection.
Cool.
>
> I have managed to detect horizontal line(unbroken/continuous), however I am
> having trouble detecting all the dotted/broken lines in an image.
We can help with the python side of things, but speaking for myself, I've little
knowledge of computer vision. Have you thought about looking for a specialist
list on computer vision or cv2?
Barry
>
> Here is my test image, as you can see there are dotted lines and some
> text/boxes etc.
>
>
> my code is below:
>
> import cv2
> import numpy as np
>
> img=cv2.imread('test.jpg')
> img=functions.image_resize(img,1000,1000) #function from a script to resize
> image to fit my screen
> imgGray=cv2.cvtColor(img,cv2.COLOR_BGR2GRAY)
> imgEdges=cv2.Canny(imgGray,100,250)
> imgLines= cv2.HoughLinesP(imgEdges,2,np.pi/100,60, minLineLength = 10,
> maxLineGap = 100)
> for x1,y1,x2,y2 in imgLines[0]:
>cv2.line(img,(x1,y1),(x2,y2),(0,255,0),2)
>
> cv2.imshow('Final Image with dotted Lines detected',img)
>
> My output image is below. As you can see I only managed to detect the last
> dotted line. I have played around with the parameters rho,theta,min/max line
> but no luck.
>
> Any advice is greatly appreciated :)
>
> For the original link - which has the images
> https://stackoverflow.com/questions/61239652/detect-dotted-broken-lines-only-in-an-image-using-opencv
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Helping Windows first time users
> On 16 Apr 2020, at 04:34, Dennis Lee Bieber wrote: > > On Wed, 15 Apr 2020 19:23:43 +0100, Barry Scott > declaimed the following: > >> I post some suggestion to improve the Python installer for Windows >> to better sign post users on the next steps. >> >> https://mail.python.org/archives/list/[email protected]/message/TKHID7PMKN5TK5QDQ2BL3G45FYAJNYJX/ >> >> It also seems like we could do with drafting the text of a helpful >> reply to help the Windows first time users. This would help folks that >> reply to the Windows first time users to have a quick way to reply >> without drafting the text a reply every time. >> >> What are your thoughts on the installer changes and reply text? > > No other Windows installers that I know of provide information on how > to use the installed application. Anyone installing software should realize > that the installer file itself is just that, an installer, and not be used > in attempts to run the installed application, they should look elsewhere > for the application itself. As I noted on the idea list the installer already has a wizard panel that provides pointer. I'm suggesting that given the misunderstandings that text can be improved in the hope that it helps. Is it as simple as the other installers insist on littering my desktop with icons? Is that the trick? > > I would also note that there are MANY Python installers for Windows: > Python.org, ActiveState, Anaconda, Enthought, and even (for Win10) the M$ > "app store" has one. Are you proposing that all these sources need to make > changes to their distributions? If core dev's agree we can fix the python.org installers. Maybe other will follow our lead if it helps. Barry -- https://mail.python.org/mailman/listinfo/python-list
Re: Helping Windows first time users
Could do that. But a more easier one might be an extra screen that says about how to start the idle. Souvik flutter dev On Thu, Apr 16, 2020, 10:37 PM Barry Scott wrote: > > > > On 16 Apr 2020, at 04:34, Dennis Lee Bieber > wrote: > > > > On Wed, 15 Apr 2020 19:23:43 +0100, Barry Scott > > declaimed the following: > > > >> I post some suggestion to improve the Python installer for Windows > >> to better sign post users on the next steps. > >> > >> > https://mail.python.org/archives/list/[email protected]/message/TKHID7PMKN5TK5QDQ2BL3G45FYAJNYJX/ > >> > >> It also seems like we could do with drafting the text of a helpful > >> reply to help the Windows first time users. This would help folks that > >> reply to the Windows first time users to have a quick way to reply > >> without drafting the text a reply every time. > >> > >> What are your thoughts on the installer changes and reply text? > > > > No other Windows installers that I know of provide information on > how > > to use the installed application. Anyone installing software should > realize > > that the installer file itself is just that, an installer, and not be > used > > in attempts to run the installed application, they should look elsewhere > > for the application itself. > > As I noted on the idea list the installer already has a wizard panel that > provides > pointer. I'm suggesting that given the misunderstandings that text can be > improved in the hope that it helps. > > Is it as simple as the other installers insist on littering my desktop > with icons? > Is that the trick? > > > > > I would also note that there are MANY Python installers for > Windows: > > Python.org, ActiveState, Anaconda, Enthought, and even (for Win10) the M$ > > "app store" has one. Are you proposing that all these sources need to > make > > changes to their distributions? > > If core dev's agree we can fix the python.org installers. Maybe other > will follow > our lead if it helps. > > Barry > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: What variable type is returned from Open()?
On Fri, Apr 17, 2020 at 2:13 AM Richard Damon wrote: > I get the answer: > > So that is the name of the type that is returned, at least for that > call. One key thing to note is that it begins with a _, so that type is > actually an implementation detail, subject to change. This is somewhat true; but when the *module* begins with an underscore, it often means it's a C accelerator for a Python module. You can often find the same thing exposed in a more visible way: >>> import io >>> io.TextIOWrapper And in that location, it is fully documented: https://docs.python.org/3/library/io.html#io.TextIOWrapper The fact that it comes from the accelerator *is* an internal implementation detail, but the class itself is a public one. That said, though: it is still very much incorrect to type hint in this way. The correct type hint is a generic one: https://docs.python.org/3/library/typing.html#typing.IO And the correct way to encode this on a variable is to let type inference figure it out. You'd use typing.IO or typing.TextIO to annotate a function parameter, perhaps, but don't annotate your variables at all. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Helping Windows first time users
a new users point of view
to the IEEE Electromagnetic Compatibility Society
I do not know how to ask a question when:
It isn't saying to type a $, it's saying to type at the system prompt.
Similarly, if it says:
>>> print("Hello")
it's saying to type at the Python prompt.
This is a common convention in instructions for programming.
I do not know anything about programming with python
I'm 80 and I grew up playing in dirt and failing,but I did learn.
we are a blank slate. we know nothing
we get embarrassed that you do not understand the question
not realizing you do not you do not understand the question
so we stop asking.
Thank you for trying
On Thu, Apr 16, 2020 at 10:27 AM Souvik Dutta
wrote:
> Could do that. But a more easier one might be an extra screen that says
> about how to start the idle.
>
> Souvik flutter dev
>
> On Thu, Apr 16, 2020, 10:37 PM Barry Scott wrote:
>
> >
> >
> > > On 16 Apr 2020, at 04:34, Dennis Lee Bieber
> > wrote:
> > >
> > > On Wed, 15 Apr 2020 19:23:43 +0100, Barry Scott <
> [email protected]>
> > > declaimed the following:
> > >
> > >> I post some suggestion to improve the Python installer for Windows
> > >> to better sign post users on the next steps.
> > >>
> > >>
> >
> https://mail.python.org/archives/list/[email protected]/message/TKHID7PMKN5TK5QDQ2BL3G45FYAJNYJX/
> > >>
> > >> It also seems like we could do with drafting the text of a helpful
> > >> reply to help the Windows first time users. This would help folks that
> > >> reply to the Windows first time users to have a quick way to reply
> > >> without drafting the text a reply every time.
> > >>
> > >> What are your thoughts on the installer changes and reply text?
> > >
> > > No other Windows installers that I know of provide information on
> > how
> > > to use the installed application. Anyone installing software should
> > realize
> > > that the installer file itself is just that, an installer, and not be
> > used
> > > in attempts to run the installed application, they should look
> elsewhere
> > > for the application itself.
> >
> > As I noted on the idea list the installer already has a wizard panel that
> > provides
> > pointer. I'm suggesting that given the misunderstandings that text can be
> > improved in the hope that it helps.
> >
> > Is it as simple as the other installers insist on littering my desktop
> > with icons?
> > Is that the trick?
> >
> > >
> > > I would also note that there are MANY Python installers for
> > Windows:
> > > Python.org, ActiveState, Anaconda, Enthought, and even (for Win10) the
> M$
> > > "app store" has one. Are you proposing that all these sources need to
> > make
> > > changes to their distributions?
> >
> > If core dev's agree we can fix the python.org installers. Maybe other
> > will follow
> > our lead if it helps.
> >
> > Barry
> >
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: What variable type is returned from Open()?
On Thursday, April 16, 2020 at 2:37:42 PM UTC-4, Chris Angelico wrote: > On Fri, Apr 17, 2020 at 2:13 AM Richard Damon wrote: > > I get the answer: > > > > So that is the name of the type that is returned, at least for that > > call. One key thing to note is that it begins with a _, so that type is > > actually an implementation detail, subject to change. > > This is somewhat true; but when the *module* begins with an > underscore, it often means it's a C accelerator for a Python module. > You can often find the same thing exposed in a more visible way: > > >>> import io > >>> io.TextIOWrapper > > > And in that location, it is fully documented: > > https://docs.python.org/3/library/io.html#io.TextIOWrapper > > The fact that it comes from the accelerator *is* an internal > implementation detail, but the class itself is a public one. > > That said, though: it is still very much incorrect to type hint in > this way. The correct type hint is a generic one: > > https://docs.python.org/3/library/typing.html#typing.IO > > And the correct way to encode this on a variable is to let type > inference figure it out. You'd use typing.IO or typing.TextIO to > annotate a function parameter, perhaps, but don't annotate your > variables at all. > > ChrisA "And the correct way to encode this on a variable is to let type inference figure it out. You'd use typing.IO or typing.TextIO to annotate a function parameter, perhaps, but don't annotate your variables at all." I don't know how many times I have to say this, but I've already decided that the types of variables are going to be part of my code base. Same as every other language I've programmed in, whether statically or dynamically typed. I don't care if it's 'incorrect' for most purposes. I'm doing it, for my specific purpose. Thanks everyone else, for their assistance on this, and for actually listening to the point of the thread. I'm done with this one. -- https://mail.python.org/mailman/listinfo/python-list
Re: What variable type is returned from Open()?
On Fri, Apr 17, 2020 at 5:06 AM wrote: > > On Thursday, April 16, 2020 at 2:37:42 PM UTC-4, Chris Angelico wrote: > > On Fri, Apr 17, 2020 at 2:13 AM Richard Damon wrote: > > > I get the answer: > > > > > > So that is the name of the type that is returned, at least for that > > > call. One key thing to note is that it begins with a _, so that type is > > > actually an implementation detail, subject to change. > > > > This is somewhat true; but when the *module* begins with an > > underscore, it often means it's a C accelerator for a Python module. > > You can often find the same thing exposed in a more visible way: > > > > >>> import io > > >>> io.TextIOWrapper > > > > > > And in that location, it is fully documented: > > > > https://docs.python.org/3/library/io.html#io.TextIOWrapper > > > > The fact that it comes from the accelerator *is* an internal > > implementation detail, but the class itself is a public one. > > > > That said, though: it is still very much incorrect to type hint in > > this way. The correct type hint is a generic one: > > > > https://docs.python.org/3/library/typing.html#typing.IO > > > > And the correct way to encode this on a variable is to let type > > inference figure it out. You'd use typing.IO or typing.TextIO to > > annotate a function parameter, perhaps, but don't annotate your > > variables at all. > > > > ChrisA > > "And the correct way to encode this on a variable is to let type > inference figure it out. You'd use typing.IO or typing.TextIO to > annotate a function parameter, perhaps, but don't annotate your > variables at all." > > I don't know how many times I have to say this, but I've already decided that > the types of variables are going to be part of my code base. Same as every > other language I've programmed in, whether statically or dynamically typed. > > I don't care if it's 'incorrect' for most purposes. I'm doing it, for my > specific purpose. > Oh! Okay then. Just annotate it as "int" - it's no more or less wrong than any other annotation :) Problem solved! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Threading module and embedded python
Thank you for your help.
I made a minimum example which just creates the dialog window.
This runs, using the standard python37.exe without a problem.
But this also runs within the embedded interpreter slightly different
then my previous code.
In my previous code I used the hwnd from the C++ app
DialogBoxIndirectParam(None,
(ctypes.c_ubyte *
len(self._array)).from_buffer_copy(self._array),
self.parent_hwnd,
DIALOGPROC(self._dlgproc),
0)
now I'm using None.
This still does NOT show the dialog when it is called,
BUT the C++ app keeps responsive and if I close it, then the dialog
appears. (???)
> Maybe in the embedded version you do not have an HWND that is usable, can
NULL be used?
The HWND I normally use should be correct as I have to use it in various
other calls
with SendMessageW and those methods works.
> Is there a SHOW arg that you need to pass?
No.
Here the minimal code, just in case one is interested.
import ctypes
from ctypes import wintypes
import platform
from threading import Thread
user32 = ctypes.WinDLL('user32')
LRESULT = wintypes.LPARAM
DIALOGPROC = ctypes.WINFUNCTYPE(LRESULT,
wintypes.HWND,
wintypes.UINT,
wintypes.WPARAM,
wintypes.LPARAM)
INT_PTR = wintypes.INT if platform.architecture()[0] == '32bit' else
wintypes.LARGE_INTEGER
DialogBoxIndirectParam = user32.DialogBoxIndirectParamW
DialogBoxIndirectParam.restype = wintypes.HWND
DialogBoxIndirectParam.argtypes = [wintypes.HINSTANCE,
ctypes.POINTER(ctypes.c_ubyte),
wintypes.HWND,
DIALOGPROC,
wintypes.LPARAM]
GetDlgItem = user32.GetDlgItem
GetDlgItem.restype = wintypes.HWND
GetDlgItem.argtypes = [wintypes.HWND, wintypes.INT]
EndDialog = user32.EndDialog
EndDialog.restype = wintypes.BOOL
EndDialog.argtypes = [wintypes.HWND, INT_PTR]
def align_struct(tmp):
''' align control structure to dword size '''
dword_size = ctypes.sizeof(wintypes.DWORD)
align = dword_size - (len(tmp) % dword_size)
if align < dword_size:
tmp += bytearray(align)
return tmp
class DlgWindow(Thread):
''' Implements a threaddialog template window '''
def __init__(self):
super().__init__()
self._array = bytearray() # DLGTEMPLATEEX structure buffer
self._array += wintypes.WORD(1) # dlgVer
self._array += wintypes.WORD(0x) # signature
self._array += wintypes.DWORD(0) # helpID
self._array += wintypes.DWORD(0) # exStyle
# WS_POPUP | WS_BORDER | WS_SYSMENU |
WS_CAPTION | DS_MODALFRAME | DS_SETFONT | DS_CENTER
self._array += wintypes.DWORD(0x8000 | 0x0080 | 0x0008
| 0x00C0 | 0x80 | 0x40 | 0x800) # style
self._array += wintypes.WORD(0) # cDlgItems
self._array += wintypes.SHORT(0) # x
self._array += wintypes.SHORT(0) # y
self._array += wintypes.SHORT(200) # cx
self._array += wintypes.SHORT(200) # cy
self._array += wintypes.WORD(0) # menu
self._array += wintypes.WORD(0) # windowClass
self._array += ctypes.create_unicode_buffer('Test Dialog') # title
self._array += wintypes.WORD(9) # pointsize
self._array += wintypes.WORD(400) # weight
self._array += wintypes.BYTE(0) # italic
self._array += wintypes.BYTE(0) # charset
self._array += ctypes.create_unicode_buffer('MS Shell Dlg') #
typeface
def _dlgproc(self, hwnd, msg, wparam, lparam):
print(hwnd, msg, wparam, lparam)
if msg == 16: # WM_CLOSE
EndDialog(hwnd, 0)
return 1
elif msg == 272: # WM_INITDIALOG
return 1
return 0
def run(self):
''' create the dialog window '''
self._array = align_struct(self._array)
DialogBoxIndirectParam(None,
(ctypes.c_ubyte *
len(self._array)).from_buffer_copy(self._array),
None,
DIALOGPROC(self._dlgproc),
0)
def test_window():
dlg = DlgWindow()
dlg.start()
if __name__ == '__main__':
test_window()
Thanks
Eren
Am Do., 16. Apr. 2020 um 18:33 Uhr schrieb Barry Scott <
[email protected]>:
>
>
> > On 16 Apr 2020, at 14:55, Eko palypse wrote:
> >
> > Barry, sorry for sending you a private message yesterday, was not
> intended.
> >
> > No, I only have rudimentary knowledge of C++,
> > but it has been developing since I started using Cython.
> > I haven't done any stack analysis yet but hey, there's always a first
> time.
> > I think my stubbornness could be of help here :-)
>
> Its a
Regarding Python
Dear All hope you all are fine and doing good in these critical conditions While I am need to Python And I a generally using it in running a software QIIME in virtual machine (Linux based). I need to install python 3.7 or above version, however the previously installed version is python2.7 I tried many commands sudo apt-get install python3.8 after running the command it fails I removed pthon 2.7 but again when I run the command Python --version it again shows python 2.7 please suggest the commands I have my python version 3.8 downloaded in the download folder -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding Python
I need to install python 3.7 or above version, however the previously installed version is python2.7 I tried many commands sudo apt-get install python3.8 after running the command it fails I removed pthon 2.7 but again when I run the command Python --version it again shows python 2.7 please suggest the commands I have my python version 3.8 downloaded in the download folder If you're using apt, "python" usually points to Python 2; try "python3" instead. You can also do $ dpkg -L python3.8 ...which will output a list of files installed with the python3.8 package. If you compare this with your PATH environment variable, you should be able to compare which binary is being executed vs. which one you want to execute. You may also want to look into using virtual environments, as using the system python often leads to confusion. -- https://mail.python.org/mailman/listinfo/python-list
Re: What variable type is returned from Open()?
Then there is no point of type setting. Type setting is a personal preferences and should be respected. Sometimes it saves the day. Sometimes it becomes a headache. Python developers also know and thus have never deprecated type setting. On Fri, 17 Apr, 2020, 12:40 am Chris Angelico, wrote: > On Fri, Apr 17, 2020 at 5:06 AM wrote: > > > > On Thursday, April 16, 2020 at 2:37:42 PM UTC-4, Chris Angelico wrote: > > > On Fri, Apr 17, 2020 at 2:13 AM Richard Damon wrote: > > > > I get the answer: > > > > > > > > So that is the name of the type that is returned, at least for that > > > > call. One key thing to note is that it begins with a _, so that type > is > > > > actually an implementation detail, subject to change. > > > > > > This is somewhat true; but when the *module* begins with an > > > underscore, it often means it's a C accelerator for a Python module. > > > You can often find the same thing exposed in a more visible way: > > > > > > >>> import io > > > >>> io.TextIOWrapper > > > > > > > > > And in that location, it is fully documented: > > > > > > https://docs.python.org/3/library/io.html#io.TextIOWrapper > > > > > > The fact that it comes from the accelerator *is* an internal > > > implementation detail, but the class itself is a public one. > > > > > > That said, though: it is still very much incorrect to type hint in > > > this way. The correct type hint is a generic one: > > > > > > https://docs.python.org/3/library/typing.html#typing.IO > > > > > > And the correct way to encode this on a variable is to let type > > > inference figure it out. You'd use typing.IO or typing.TextIO to > > > annotate a function parameter, perhaps, but don't annotate your > > > variables at all. > > > > > > ChrisA > > > > "And the correct way to encode this on a variable is to let type > > inference figure it out. You'd use typing.IO or typing.TextIO to > > annotate a function parameter, perhaps, but don't annotate your > > variables at all." > > > > I don't know how many times I have to say this, but I've already decided > that the types of variables are going to be part of my code base. Same as > every other language I've programmed in, whether statically or dynamically > typed. > > > > I don't care if it's 'incorrect' for most purposes. I'm doing it, for > my specific purpose. > > > > Oh! Okay then. Just annotate it as "int" - it's no more or less wrong > than any other annotation :) Problem solved! > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
