Re: Changing 'Scripts/*.exe'
dn wrote: E.g. 'Scripts/pip2.exe' has the path "f:\programfiler\python27\python.exe" hard-coded inside it. Is there a easy way to fix this w/o re-installing this old Python? Yes, by putting a symbolic-link at the old 'programfiler' location which points to the new 'gv' installation. I'm suspicious about sym-links. Instead for 'pip' I just did a 'py -2 get-ip.py' which seems to have fixed it. The newly generated 'f:\gv\Python27\Scripts\pip2.exe' seems to work fine; the list from 'pip2.7.exe list' is correct. -- --gv -- https://mail.python.org/mailman/listinfo/python-list
Re: Changing 'Scripts/*.exe'
On 03/10/2022 20.48, Gisle Vanem via Python-list wrote: > dn wrote: > >>> E.g. 'Scripts/pip2.exe' has the path >>> "f:\programfiler\python27\python.exe" hard-coded >>> inside it. >>> >>> Is there a easy way to fix this w/o re-installing this >>> old Python? >> >> Yes, by putting a symbolic-link at the old 'programfiler' location which >> points to the new 'gv' installation. > > I'm suspicious about sym-links. OT: I'm sufficiently intrigued to ask "why?" - or are you only talking of the MS-Windows implementation? > Instead for 'pip' I just did a 'py -2 get-ip.py' which seems > to have fixed it. The newly generated 'f:\gv\Python27\Scripts\pip2.exe' > seems to work fine; the list from 'pip2.7.exe list' is correct. As long as things are working again, we're all happy! -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: python developer
Jan van den Broek writes: > 2022-10-01, Mike Dewhirst schrieb: > >>So the answer to your question is signed email is easy and if it becomes >>popular it has potential to defeat hackers. > > Yes, but I'm reading this as a usenet-message (comp.lang.python), not as > a mail. You are reading a mirror of the mailing list: "This mailing list is a general discussion list for the Python programming language. Please note that for those who prefer, this list is mirrored to the Usenet newsgroup comp.lang.python" https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Changing 'Scripts/*.exe'
Gisle Vanem writes: > Hello list. > > I'm moved my old Python27 installation from > f:\ProgramFiler\Python27 ( == 'ProgramFiles') > to > f:\gv\Python27 > > and now many 'scripts/*.exe' program fails > to start since the old path to 'Python.exe' > is wrong. > > E.g. 'Scripts/pip2.exe' has the path > "f:\programfiler\python27\python.exe" hard-coded > inside it. > > Is there a easy way to fix this w/o re-installing this > old Python? Wouldn't it be great if it were portable by default? -- https://mail.python.org/mailman/listinfo/python-list
Re: on GNU EMACS's python-mode, loading entire buffer
Stephen Berman writes: > On Sun, 04 Sep 2022 16:47:07 -0300 Meredith Montgomery > wrote: > >> Meredith Montgomery writes: >> >>> Meredith Montgomery writes: >>> >>> [...] >>> I would also be interested in a command that restarts the REPL afresh and reloads my buffer --- sort of like keyboard's [F5] of the IDLE. >>> >>> A partial solution for this is the following procedure. >>> >>> (defun python-revert-and-send-buffer-to-repl () >>> "Revert current buffer and sends it to the Python REPL." >>> (interactive) >>> (revert-buffer "ignore-auto-no" "no-confirm") >>> (python-shell-send-buffer)) >>> >>> We can map this to the F5-key and that improves things. But a restart >>> of the REPL would be the ideal. (Sometimes we really want to start >>> afresh. Sometimes. Most often we don't want that.) >> >> It's not easy to restart the REPL. You can send "quit()" to it and >> invoke run-python again interactively by typing out one command after >> another, but if you write a procedure such as this one below, it doesn't >> work: it gives me the impression that there's a timing issue, that is, >> perhaps the procedure is too fast and something happens before it >> should. >> >> (defun python-save-send-buffer-to-repl () >> (interactive) >> (save-buffer) >> (python-shell-send-string "quit()") >> (run-python) >> (python-shell-send-buffer) >> (python-shell-switch-to-shell)) > > It does seem like a timing issue. This works for me: > > (defun python-save-send-buffer-to-repl () > (interactive) > (save-buffer) > (python-shell-send-string "quit()") > (sit-for 0.1) > (run-python) > (python-shell-send-buffer) > (python-shell-switch-to-shell)) > > But if I decrease the wait to 0.05 it doesn't work. Interesting. I can't reproduce this at all. No matter how long I sit, I always get a similar ``crash''. Here's what happens for me with your procedure, sitting for even 5 seconds. I'm adding a 5-second delay after quitting and after running the REPL. --8<---cut here---start->8--- (defun python-save-send-buffer-to-repl () "Save current buffer and sends it to the Python REPL." (interactive) (save-buffer) (python-shell-send-string "quit()") (sit-for 5) (run-python) (sit-for 5) (python-shell-send-buffer) (python-shell-switch-to-shell)) --8<---cut here---end--->8--- When the REPL comes up, it looks fine. When I try to see if a hello-procedure was defined, I get the following: --8<---cut here---start->8--- >>> Process Python finished Python 3.10.6 (tags/v3.10.6:9c7b4bd, Aug 1 2022, 21:53:49) [MSC v.1932 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> Traceback (most recent call last): File "", line 1, in File "c:/Users/mer/AppData/Local/Temp/pyoUKuUx", line 1 Python 3.10.6 (tags/v3.10.6:9c7b4bd, Aug 1 2022, 21:53:49) [MSC v.1932 64 bit (AMD64)] on win32 ^ SyntaxError: invalid decimal literal >>> >>> hello Traceback (most recent call last): File "", line 1, in NameError: name 'hello' is not defined. Did you mean: 'help'? >>> --8<---cut here---end--->8--- You see? It seems that the Python's banner is sent to the REPL, somehow. I actually see it being sent sometimes --- I see in the minibuffer that the string ``Python 3.10.6 (tags/v3.10.6:9c7b4bd[...]'' was sent to the REPL. Somehow my GNU EMACS is reading the banner and sending it back to the REPL as if it were code in my file. My file contained just this: --8<---cut here---start->8--- # -*- mode: python; python-indent-offset: 2 -*- def hello(): return 1 --8<---cut here---end--->8--- -- https://mail.python.org/mailman/listinfo/python-list
Re: python developer
2022-10-01, orzodk schrieb: > Jan van den Broek writes: > >> 2022-10-01, Mike Dewhirst schrieb: >> >>>So the answer to your question is signed email is easy and if it becomes >>>popular it has potential to defeat hackers. >> >> Yes, but I'm reading this as a usenet-message (comp.lang.python), not as >> a mail. > > You are reading a mirror of the mailing list: I was aware of that. -- Jan v/d Broek [email protected] -- https://mail.python.org/mailman/listinfo/python-list
Re: Changing 'Scripts/*.exe'
> On 1 Oct 2022, at 16:50, Gisle Vanem via Python-list > wrote: > > Hello list. > > I'm moved my old Python27 installation from > f:\ProgramFiler\Python27 ( == 'ProgramFiles') > to > f:\gv\Python27 The design of Windows installed software makes this hard to do without a lot of knowledge about what the installation did. For example there are registry keys that hold information on where python 2.7 is installed and there is other software that will read the registry and expect that information to be correct. I would have backed the old installation, uninstalled and the reinstalled python where you want it to be. > > and now many 'scripts/*.exe' program fails > to start since the old path to 'Python.exe' > is wrong. > > E.g. 'Scripts/pip2.exe' has the path > "f:\programfiler\python27\python.exe" hard-coded > inside it. > > Is there a easy way to fix this w/o re-installing this > old Python? The advice you have had will get you someway to fixing the breakage. But do not be surprised if more things break as you try different things out. As I say I would have backed up the files, uninstall and reinstall then put back from backup any files that are not installable anymore. Why did you move the files from where they where installed and working? Barry > > -- > --gv > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Changing 'Scripts/*.exe'
[email protected] (Stefan Ram) writes: > Meredith Montgomery writes: >>Wouldn't it be great if it were portable by default? > > I think under Windows there is a division of software > suggested by Microsoft, a division of software into > executable code and data (data may change in time). > > The executable code is supposed to rest under > "C:\Program Files" the contents of which cannot be > modified by user processes easily. Program configuration > can be stored below "AppData" in the user directory. > It is supposed to be more secure when executable code > cannot be modified easily by user processes. > > So far, Python has decided to ignore this and install > everything under AppData as I understand it. So one > gets neither the security of "Program Files" nor the > possibility to move it to another directory easily. Interesting. I like portable things. You copy from one place to another and it just runs. As it should. Things should be simple. -- https://mail.python.org/mailman/listinfo/python-list
Re: Changing 'Scripts/*.exe'
On 04/10/2022 14.10, Meredith Montgomery wrote: > [email protected] (Stefan Ram) writes: > >> Meredith Montgomery writes: >>> Wouldn't it be great if it were portable by default? >> >> I think under Windows there is a division of software >> suggested by Microsoft, a division of software into >> executable code and data (data may change in time). >> >> The executable code is supposed to rest under >> "C:\Program Files" the contents of which cannot be >> modified by user processes easily. Program configuration >> can be stored below "AppData" in the user directory. >> It is supposed to be more secure when executable code >> cannot be modified easily by user processes. >> >> So far, Python has decided to ignore this and install >> everything under AppData as I understand it. So one >> gets neither the security of "Program Files" nor the >> possibility to move it to another directory easily. > > Interesting. I like portable things. You copy from one place to At which point we mention that this is exactly how Linux works. A 'zen' of Linux applications and utilities has always been: "do one thing, and do it well". Then directory/file access controls aim to keep users in 'userland' and away from 'system', and for folk who want more there are security features such as apparmor which limit the types of usage of files (as well as resisting external threats). Extending this a little further: such philosophy enables Linux users to more-easily install (and run) multiple versions of Python*, Firefox, Chromium, etc, without resorting to containers or VMs. * eg v2 and v3 installed concurrently, to possibly suit OP > another and it just runs. As it should. Things should be simple. +1 -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
