Re: is there somebody that have experince with python and canopen
More information plz. WH-2099 From: Python-list on behalf of luca72.b...@gmail.com Sent: Saturday, April 16, 2022 1:18:33 AM To: python-list@python.org Subject: is there somebody that have experince with python and canopen We are searching for someone that can develop a python program for use servomotor for automotive. -- https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-listdata=04%7C01%7C%7C09d5bd1f71984d617a7108da1f119560%7C84df9e7fe9f640afb435%7C1%7C0%7C637856457645434752%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=lMZ%2Bfpc5AsKEtFfgM9BPNAo4U81eKYxxgsjq2Jdas1E%3Dreserved=0 -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)
On Sat, 16 Apr 2022 at 17:14, Peter J. Holzer wrote: > > On 2022-04-16 16:49:17 +0200, Marco Sulla wrote: > > Furthermore, you didn't answer my simple question: why does the > > security update package contain metadata about Debian patches, if the > > Ubuntu security team did not benefit from Debian security patches but > > only from internal work? > > It DOES NOT contain metadata about Debian patches. You are > misinterpreting the name "debian". The directory has this name because > the tools (dpkg, quilt, etc.) were originally written by the Debian team > for the Debian distribution. Ubuntu uses the same tools. They didn't > bother to rename the directory (why should they?), so the directory is > still called "debian" on Ubuntu (and yes I know this because I've built > numerous .deb packages on Ubuntu systems). Ah ok, now I understand. Sorry for the confusion. -- https://mail.python.org/mailman/listinfo/python-list
Re: No shortcut Icon on Desktop
On 4/15/22, Grant Edwards wrote: > > The problem is that people run the installer, don't see a desktop > icon, and think nothing has been installed. Such people need to learn how to use the start menu, where all of Python's shortcuts are installed in a folder named "Python ". One can also press the Windows key and type "python" to get a filtered view of the application shortcuts. > Or they think the installer "is python", and run it over and over > again trying to "run Python". I'm not opposed to renaming the installer to something that makes it more obvious that it's only an installer. But, to put this in perspective, I think you're talking about a small number of people out of the millions of users who I presume install and use Python without a problem. It could be that thousands of people install Python and give up without complaining when they can't use it, but I doubt it. > If the installer, by default, created an IDLE desktop shortcut and a > cmd.exe shortcut that ran Python, I believe it would eliminate most of > those problems. The installed shortcuts are to IDLE (via "pythonw.exe") and "python.exe". IDLE is a graphical integrated development environment (shell, editor, debugger) that by default runs an interactive shell. The "python.exe" executable is a console (terminal) application that by default runs an interactive shell if its arguments do not specify a script file, -m module, or -c command to run. A console application is attached to a console session, a resource that's hosted by an instance of "conhost.exe" or (in a tab of Windows Terminal) "openconsole.exe". It connects to the console session via files on the ConDrv device (e.g. "\Device\ConDrv\Connect", "\Device\ConDrv\Input", "\Device\ConDrv\Output"). If an application executable is flagged as a console application, such as "python.exe", and no console session was inherited from the parent process, and the process wasn't spawned with the DETACHED_PROCESS flag, then the Windows base API automatically allocates and attaches to a new console session at startup during the initialization of kernelbase.dll. If an application executable is flagged as a graphical application, such as "pythonw.exe", then a console session is never inherited and never automatically allocated, but one can be manually allocated or acquired via AllocConsole() or AttachConsole(dwProcessId). -- https://mail.python.org/mailman/listinfo/python-list
Re: Pre-Pre-PEP: The datetime.timedeltacal class
> On 18 Apr 2022, at 13:01, Peter J. Holzer wrote: > > On 2022-04-16 20:25:45 +0100, Barry wrote: >> Suggest that you start with the use cases that you want supported. >> Then you can turn them into a set of tests to check that the solution works. > > Writing test cases is always a good idea :-) Did you write the use cases? Without them how can anyone review the tests? Barry > > I have now written a first set of test cases: > https://git.hjp.at:3000/hjp/timedeltacal > (together with a quick and dirty implementation that passes them). > > That's not complete yet. > > If covers addition of timezone aware datetime values and timedeltacal > values fairly well, and also tests the t0 + (t1 - t0) == t1 property I > alluded to elsewhere in this thread. > > It doesn't test canonicalization yet (and indeed the prototype > implementation is a mess in this regard) and subtracting timedeltacals > from datetimes is also still missing. > >hp > > -- > _ | Peter J. Holzer| Story must make more sense than reality. > |_|_) || > | | | h...@hjp.at |-- Charles Stross, "Creative writing > __/ | http://www.hjp.at/ | challenge!" > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Pre-Pre-PEP: The datetime.timedeltacal class
On 2022-04-16 20:25:45 +0100, Barry wrote: > Suggest that you start with the use cases that you want supported. > Then you can turn them into a set of tests to check that the solution works. Writing test cases is always a good idea :-) I have now written a first set of test cases: https://git.hjp.at:3000/hjp/timedeltacal (together with a quick and dirty implementation that passes them). That's not complete yet. If covers addition of timezone aware datetime values and timedeltacal values fairly well, and also tests the t0 + (t1 - t0) == t1 property I alluded to elsewhere in this thread. It doesn't test canonicalization yet (and indeed the prototype implementation is a mess in this regard) and subtracting timedeltacals from datetimes is also still missing. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
