Fwd: Python Question re Executing a Script (dn)
Perhaps an MS-Win user can help the OP, please? -- Regards, =dn--- Begin Message --- Hello dn, Thanks for your reply. My apologies, I should have provided more background information. I was recently running a Windows 10 machine and I believe it was running Python 3.8. All I did was create a batch file titled Start-AIG.bat which simply contained the following: "pythonw AIG.py". It started a python program titled "AIG.py" and the Python dialog box was displayed on my screen, running all day and night. I set up Windows to run this batch file upon startup and it worked fine. I remember having to do a bunch of research before I learned that I needed to put "pythonw AIG.py" in the batch file as opposed to "python AIG.py". However, my old windows 10 desktop crashed and I have a new Windows 11 machine. I installed the latest stable version of Python, which is 3.10. Now, when I try to execute the same batch file, it doesn't launch the app. It could be because I'm using Windows 11 or could be because I now have a newer version of Python. With this additional information, do you have any ideas what I should do to get the Python script running in the same way I had it running before? Thank you! Brent -Original Message- From: Python-list On Behalf Of dn Sent: Saturday, April 30, 2022 5:48 PM To: [email protected] Subject: Re: Python Question re Executing a Script On 01/05/2022 10.37, Brent Hunter wrote: > Hello, > > I just purchased a new Windows 11 computer and installed Python 3.10.4 (64 > bit). I can't figure out from your documentation, how do I: > > > 1. Run a python script that is located in the same directory ( > C:\Users\Brent\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Python > 3.10 ) > > > 1. How do I automatically run a python app at Windows startup? > > Thank you! > > Brent Hunter Please start with https://docs.python.org/3/using/windows.html -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list --- End Message --- -- https://mail.python.org/mailman/listinfo/python-list
Re: new sorting algorithm
Hi, > The median-of-three partitioning technique makes that work reasonably well, so it won't be pathologically slow Just to be clear because I've wondered but haven't looked into it, we know naive quicksorting of already-sorted data is pathalogical, but median-of-3 is known to fix this pathology? cheers jan On 02/05/2022, Chris Angelico wrote: > On Mon, 2 May 2022 at 09:20, Dan Stromberg wrote: >> >> >> On Sun, May 1, 2022 at 1:44 PM Chris Angelico wrote: >>> >>> On Mon, 2 May 2022 at 06:43, Dan Stromberg wrote: >>> > On Sun, May 1, 2022 at 11:10 AM Chris Angelico >>> > wrote: >>> >> >>> >> On Mon, 2 May 2022 at 01:53, Nas Bayedil wrote: >>> >> > We believe that using this method to develop completely new, fast >>> >> > algorithms, approaching the speed of the famous *QuickSort*, the >>> >> > speed of >>> >> > which cannot be surpassed, but its drawback can be circumvented, in >>> >> > the >>> >> > sense of stack overflow, on some data. >>> >> >>> >> Hmm, actually TimSort *does* exceed the speed of quicksort for a lot >>> >> of real-world data. For instance, if you take a large sorted list, >>> >> append a handful of (unsorted) items to it, and then sort the list, >>> >> TimSort can take advantage of the fact that the bulk of the list is >>> >> sorted. It ends up significantly faster than re-sorting the entire >>> >> list. >>> > >>> > >>> > In fact, Timsort is O(n) for already-sorted data, while many quicksorts >>> > are O(n^2) for already-sorted data. >>> > >>> > Quicksort can be salvaged by using a median-of-3 partitioning, but it's >>> > still O(n^2) in the (less common) worst case. >>> > >>> >>> This is true, but purely sorted data isn't a very practical case. The >>> case of mostly-sorted data IS practical, though, so it's a quite big >>> win that it can be close to O(n), and still faster than inserting each >>> item individually. >> >> >> You seem to be of the impression that nearly-sorted data isn't an uphill >> battle with a straightforward quicksort. >> >> I'm having a hard time convincing myself of that. >> > > The median-of-three partitioning technique makes that work reasonably > well, so it won't be pathologically slow. It's hardly Quicksort's best > feature, but it could easily be a lot worse. I'd have to check, but I > think it still manages to be O(n log n). Merge sort, of course, is a > lot more consistent, but the asymptotic cost is still broadly the > same. > > But Timsort manages to be close to O(n) for sorted data, reversed > data, nearly-sorted or nearly-reversed data, etc. Makes it very handy > for jobs like "click a heading to sort by it", where you might add > multiple sort keys. > > (Plus, Python's implementation has some cool tricks for small > collections that make it quite efficient.) > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: new sorting algorithm
On 5/1/2022 7:45 PM, Chris Angelico wrote: On Mon, 2 May 2022 at 09:20, Dan Stromberg wrote: On Sun, May 1, 2022 at 1:44 PM Chris Angelico wrote: On Mon, 2 May 2022 at 06:43, Dan Stromberg wrote: On Sun, May 1, 2022 at 11:10 AM Chris Angelico wrote: On Mon, 2 May 2022 at 01:53, Nas Bayedil wrote: We believe that using this method to develop completely new, fast algorithms, approaching the speed of the famous *QuickSort*, the speed of which cannot be surpassed, but its drawback can be circumvented, in the sense of stack overflow, on some data. Hmm, actually TimSort *does* exceed the speed of quicksort for a lot of real-world data. For instance, if you take a large sorted list, append a handful of (unsorted) items to it, and then sort the list, TimSort can take advantage of the fact that the bulk of the list is sorted. It ends up significantly faster than re-sorting the entire list. In fact, Timsort is O(n) for already-sorted data, while many quicksorts are O(n^2) for already-sorted data. Quicksort can be salvaged by using a median-of-3 partitioning, but it's still O(n^2) in the (less common) worst case. This is true, but purely sorted data isn't a very practical case. The case of mostly-sorted data IS practical, though, so it's a quite big win that it can be close to O(n), and still faster than inserting each item individually. You seem to be of the impression that nearly-sorted data isn't an uphill battle with a straightforward quicksort. I'm having a hard time convincing myself of that. The median-of-three partitioning technique makes that work reasonably well, so it won't be pathologically slow. It's hardly Quicksort's best feature, but it could easily be a lot worse. I'd have to check, but I think it still manages to be O(n log n). Merge sort, of course, is a lot more consistent, but the asymptotic cost is still broadly the same. But Timsort manages to be close to O(n) for sorted data, reversed data, nearly-sorted or nearly-reversed data, etc. Makes it very handy for jobs like "click a heading to sort by it", where you might add multiple sort keys. (Plus, Python's implementation has some cool tricks for small collections that make it quite efficient.) ChrisA Some versions of Quicksort switch over to Straight Insertion Sort when the partitions become small enough. The correct size will vary depending on the hardware. I have not kept up with the latest improvements and I am not familiar with TimSort. However Heapsort should always be O(n log n) and there are modifications to Heapsort that can make it faster than vanilla Heapsort and closer to the speed of Quicksort. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Python Question re Executing a Script (dn)
On Mon, 2 May 2022 20:33:02 +1200, dn
declaimed the following:
>Perhaps an MS-Win user can help the OP, please?
Not really -- at least from my viewpoint there is not enough
information to perform any diagnoses... Other than to recommend that, if
the OP initially posted to the list/newsgroup, they should ensure any
replies also go to the same (I don't respond to what should be group
replies that appear in my personal mail -- which is what the OP did for me
also).
{Hmmm, appears the quoted content is below your signature block, and my
client doesn't quote standard signatures and below... time for some nasty
cut&paste}
>From: Brent Hunter
>Date: Mon, 2 May 2022 00:30:22 +
>
>I was recently running a Windows 10 machine and I believe it was running
>Python 3.8. All I did was create a batch file titled Start-AIG.bat which
>simply contained the following: "pythonw AIG.py". It started a python program
>titled "AIG.py" and the Python dialog box was displayed on my screen, running
>all day and night. I set up Windows to run this batch file upon startup and
>it worked fine. I remember having to do a bunch of research before I learned
>that I needed to put "pythonw AIG.py" in the batch file as opposed to "python
>AIG.py".
>
What in particular is a "Python dialog box"? Python doesn't, of its
own, have dialog boxes. Add-on libraries: Tkinter, wxPython, the win32
extensions, et al. allow one to code scripts that produce dialogs, but the
dialogs are specific to the library.
"pythonw" is the name of the interpreter meant for use with programs
that do not use console I/O -- IOW, pure GUI (one of the aforesaid
libraries).
Normally such programs are given the extension .pyw rather than .py --
and (at least on my system), .pyw files are automatically associated with
pythonw. Just providing the script name with extension is sufficient.
Though there is the matter that giving said name in a command line prompt
means one still has a console active. .pyw files are meant to be started
from the file explorer by double-clicking on them, and one doesn't want to
have a console window popping up if it is never used (which is what happens
if one double-clicks on a plain .py file).
HOW did you "set up Windows to run this batch file upon startup"?
Windows used to support (and still does if
https://www.thewindowsclub.com/startup-folder-in-windows-8 is correct
[ignore the -8, the site is updated for 10/11]). This is per user start up
(unless one uses the "all users" path). The Windows task scheduler also
allows one to create tasks that run on a schedule -- said schedule
including options for specific user logging in, any user logging in,
computer start-up, etc. The scheduler is probably the recommended way to
set up things.
>However, my old windows 10 desktop crashed and I have a new Windows 11
>machine. I installed the latest stable version of Python, which is 3.10.
>Now, when I try to execute the same batch file, it doesn't launch the app. It
>could be because I'm using Windows 11 or could be because I now have a newer
>version of Python.
>
>With this additional information, do you have any ideas what I should do to
>get the Python script running in the same way I had it running before?
As I stated above -- insufficient information.
Is Python installed for all users or just one?
Is "pythonw" on the system PATH?
Is the script meant to only run for one user or any user?
How was the script configured to start?
Is the script in a valid directory (I believe in a previous post it was
mentioned that you had the script in the directory used for per user
START-MENU entries; that is not meant for user files!).
My first approach would be to open a console and run the script
manually (not the BAT file) -- does any error message appear in the
console? Running using pythonw suppresses console, error messages would be
lost -- GUI applications are expected to trap any runtime errors and either
write to a log file or pop-up a dialog for them.
Then, after getting it to run in a console, I'd try it by
double-clicking on the file (rename it to .pyw so you get the no-console
interpreter). If Windows says it doesn't know how to run .pyw, it implies
that there is no file association set up in Windows telling it how to run
that extension.
NO BAT file should be required for a one-liner that does no parameter
substitution.
If using the "startup" directory method, create a shortcut for the
script (right-click, drag, create shortcut here). Right-click/Properties.
If you don't have associations set to run that extension type, prefix the
Target box with the path to the python(w) executable. Move the shortcut to
the proper startup directory -- Note that if you put it in the all-users
startup, you have to make sure that the script and shortcut themselves are
not in protected (single user) locations.
Re: Fwd: Python Question re Executing a Script (dn)
On 2022-05-02 17:23, Dennis Lee Bieber wrote:
On Mon, 2 May 2022 20:33:02 +1200, dn
declaimed the following:
Perhaps an MS-Win user can help the OP, please?
Not really -- at least from my viewpoint there is not enough
information to perform any diagnoses... Other than to recommend that, if
the OP initially posted to the list/newsgroup, they should ensure any
replies also go to the same (I don't respond to what should be group
replies that appear in my personal mail -- which is what the OP did for me
also).
{Hmmm, appears the quoted content is below your signature block, and my
client doesn't quote standard signatures and below... time for some nasty
cut&paste}
From: Brent Hunter
Date: Mon, 2 May 2022 00:30:22 +
I was recently running a Windows 10 machine and I believe it was running Python 3.8. All I did was create a batch file
titled Start-AIG.bat which simply contained the following: "pythonw AIG.py". It started a python program
titled "AIG.py" and the Python dialog box was displayed on my screen, running all day and night. I set up
Windows to run this batch file upon startup and it worked fine. I remember having to do a bunch of research before I
learned that I needed to put "pythonw AIG.py" in the batch file as opposed to "python AIG.py".
[snip]
FTR, I've already posted the suggestion to try the Python Launcher
"pyw", and the OP replied off-list that it worked.
--
https://mail.python.org/mailman/listinfo/python-list
Re: tail
On Mon, 2 May 2022 at 18:31, Stefan Ram wrote: > > |The Unicode standard defines a number of characters that > |conforming applications should recognize as line terminators:[7] > | > |LF:Line Feed, U+000A > |VT:Vertical Tab, U+000B > |FF:Form Feed, U+000C > |CR:Carriage Return, U+000D > |CR+LF: CR (U+000D) followed by LF (U+000A) > |NEL: Next Line, U+0085 > |LS:Line Separator, U+2028 > |PS:Paragraph Separator, U+2029 > | > Wikipedia "Newline". Should I suppose that other encodings may have more line ending chars? -- https://mail.python.org/mailman/listinfo/python-list
Re: tail
On Tue, 3 May 2022 at 04:38, Marco Sulla wrote: > > On Mon, 2 May 2022 at 18:31, Stefan Ram wrote: > > > > |The Unicode standard defines a number of characters that > > |conforming applications should recognize as line terminators:[7] > > | > > |LF:Line Feed, U+000A > > |VT:Vertical Tab, U+000B > > |FF:Form Feed, U+000C > > |CR:Carriage Return, U+000D > > |CR+LF: CR (U+000D) followed by LF (U+000A) > > |NEL: Next Line, U+0085 > > |LS:Line Separator, U+2028 > > |PS:Paragraph Separator, U+2029 > > | > > Wikipedia "Newline". > > Should I suppose that other encodings may have more line ending chars? No, because those are Unicode characters. How they're encoded may affect the bytes you see, but those are code point values after decoding. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: tail
Ok, I suppose \n and \r are enough: readline(size=- 1, /) Read and return one line from the stream. If size is specified, at most size bytes will be read. The line terminator is always b'\n' for binary files; for text files, the newline argument to open() can be used to select the line terminator(s) recognized. open(file, mode='r', buffering=- 1, encoding=None, errors=None, newline=None, closefd=True, opener=None) [...] newline controls how universal newlines mode works (it only applies to text mode). It can be None, '', '\n', '\r', and '\r\n' -- https://mail.python.org/mailman/listinfo/python-list
Re: new sorting algorithm
On 5/2/22 07:09, charles hottel wrote: > Some versions of Quicksort switch over to Straight Insertion Sort when > the partitions become small enough. The correct size will vary depending > on the hardware. > > I have not kept up with the latest improvements and I am not familiar > with TimSort. However Heapsort should always be O(n log n) and there > are modifications to Heapsort that can make it faster than vanilla > Heapsort and closer to the speed of Quicksort. A quick read might be in order then... https://en.wikipedia.org/wiki/Timsort -- https://mail.python.org/mailman/listinfo/python-list
Re: tail
On Mon, 2 May 2022 at 00:20, Cameron Simpson wrote: > > On 01May2022 18:55, Marco Sulla wrote: > >Something like this is OK? > [...] > >def tail(f): > >chunk_size = 100 > >size = os.stat(f.fileno()).st_size > > I think you want os.fstat(). It's the same from py 3.3 > >chunk_line_pos = -1 > >pos = 0 > > > >for pos in positions: > >f.seek(pos) > >chars = f.read(chunk_size) > >chunk_line_pos = chars.rfind(b"\n") > > > >if chunk_line_pos != -1: > >break > > Normal text file _end_ in a newline. I'd expect this to stop immediately > at the end of the file. I think it's correct. The last line in this case is an empty bytes. > >if chunk_line_pos == -1: > >nbytes = pos > >pos = 0 > >f.seek(pos) > >chars = f.read(nbytes) > >chunk_line_pos = chars.rfind(b"\n") > > I presume this is because unless you're very lucky, 0 will not be a > position in the range(). I'd be inclined to avoid duplicating this code > and special case and instead maybe make the range unbounded and do > something like this: > > if pos < 0: > pos = 0 > ... seek/read/etc ... > if pos == 0: > break > > around the for-loop body. Yes, I was not very happy to duplicate the code... I have to think about it. > Seems sane. I haven't tried to run it. Thank you ^^ -- https://mail.python.org/mailman/listinfo/python-list
Re: error of opening Python
On Friday, April 15, 2022 at 2:17:28 AM UTC+5:30, Andrew Hernandez wrote: > that is not an error, its simply the python console intrepeter how do I open this file -- https://mail.python.org/mailman/listinfo/python-list
Re: new sorting algorithm
On Mon, May 2, 2022 at 2:25 AM jan via Python-list wrote: > Hi, > > > The median-of-three partitioning technique makes that work reasonably > well, so it won't be pathologically slow > > Just to be clear because I've wondered but haven't looked into it, we > know naive quicksorting of already-sorted data is pathalogical, but > median-of-3 is known to fix this pathology? > Median-of-3 helps, but it's still possible to construct inputs that make quicksort break down to an O(n^2) algorithm in the worst case. These inputs are much less common than sorting an already sorted, or reverse-sorted list. -- https://mail.python.org/mailman/listinfo/python-list
