[issue37745] 3.8b3 - windows install gui/ inconsistent options
Dimitri Merejkowsky added the comment: > the inevitable confusion when multiple PATH updates do not play well together > (which they don't). Oh I see. Did not think about that. I can see a scenario where you install 3.9, PATH is set, you install 3.10, the PATH update fails for some reason and then you get stuck because PATH was not updated correctly... and then you're back to manually setting PATH which was the thing we were trying to prevent ... > you can modify [Python installations coming from the Windows store] through > the built-in "Manage App Execution Aliases" control panel if you have > multiple) Good to know, thanks. That was one of my concerns actually. > I'm sick to death of being abused over this issue I'm sorry to hear that and I apologize - I was simply trying to get answers. Well, now that I know why the box is not ticked, I can say I'm happy with the state of the installer, and I guess I'll continue to teach my students about PATH - after all, it's a useful skill to have ;) -- ___ Python tracker <https://bugs.python.org/issue37745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37745] 3.8b3 - windows install gui/ inconsistent options
Dimitri Merejkowsky added the comment: I know this is two years later so maybe this is not the best way to get answers, but Steve Dower said: > We don't add Python to PATH by default (because it's bad), and people > couldn't find the option Could someone clarify this for me? Because my experience as a Python teacher tells me the exact opposite. For context, I've been teaching Python to absolute beginners (some of them do not even know how to *use* Windows to begin with). I do tell them repeatedly to make sure to tick the "add python to Path", but every time, one of them forgot. This gets even worse when the course is done remotely because I have to *tell* the students what to do through a screen-sharing app ... Here's what I had to tell one of the students to do this morning. Step 1: Tick "Display Hidden Items" in the Display option of the Windows File Explorer Step 2: Go into c:\users\AppData Step 3: Type `python.exe` in the search bar Step 4: Copy/paste the full path Step 5: Open "Edit environment variables for my account" Step 6: Click on "Edit environment variables" Step 7: Click on Path Step 8: Copy/paste the full path, without "python.exe" Step 9: Copy/paste the full path, adding `\Scripts\` at the end Step 10: restart cmd.exe In insight, I wonder if I should have just told him to just re-run the installer and tick the box ... Some notes: Fixing #14302 would help for step 9, which is nice. I know very well that writing a Windows installer is far for trivial, but I'm ready to try and make a PR anyway. That being said, I understand there may be good reasons to *not* add python to PATH that I don't know about. -- nosy: +Dimitri Merejkowsky ___ Python tracker <https://bugs.python.org/issue37745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3041] autodoc does not support unicode docstrings
Changes by Dimitri Merejkowsky <d.me...@gmail.com>: -- pull_requests: +1227 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue3041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30041] subprocess: weird behavior with shell=True and args being a list
New submission from Dimitri Merejkowsky: If you have: subprocess.run(["ls", "--help"], shell=True) you'll see that the command run is actually just "ls", not "ls --help" -- components: Library (Lib) messages: 291473 nosy: Dimitri Merejkowsky priority: normal severity: normal status: open title: subprocess: weird behavior with shell=True and args being a list ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28559] Unclear error message when raising wrong type of exceptions
New submission from Dimitri Merejkowsky:
Motivation for the patch came from a tweet[1] of David Beazley:
def SomeError(Exception):
pass
raise SomeError('blah')
(Note the `def` keyword instead of `class`):
If you run that, you get:
> TypeError: exceptions must derive from BaseException
Which is not very helpful.
Attached patch changes the error message to be:
> TypeError: exceptions must derive from BaseException, got NoneType
(By the way, it's very close to what Python2 used to say in this case)
--
components: Interpreter Core
files: 0001-Fix-error-message-when-raising-with-the-wrong-type.patch
keywords: patch
messages: 279689
nosy: Dimitri Merejkowsky
priority: normal
severity: normal
status: open
title: Unclear error message when raising wrong type of exceptions
type: enhancement
versions: Python 3.7
Added file:
http://bugs.python.org/file45267/0001-Fix-error-message-when-raising-with-the-wrong-type.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28559>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28334] netrc does not work if $HOME is not set
Dimitri Merejkowsky added the comment: During review SilentGhost suggested that maybe a test was not essential. In any case, I think patching documentation about the new behavior won't hurt. Do you want me to do that? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28334] netrc does not work if $HOME is not set
Dimitri Merejkowsky added the comment: > if it make sense to run this on Windows I found this issue while running cross-platform code. I needed to store some credentials, did not mind having them in plain-text and I thought .netrc was a good place for this. (did not need to re-invent the wheel ...) > don't know what unix users might reasonbly expect. Well, I guess as a bonus of this patch we could add a link to the `os.path.expanduser` section[1] in `netrc` documentation. The behavior when $HOME is not set is properly documented there. [1] https://docs.python.org/3/library/os.path.html#os.path.expanduser -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28334] netrc does not work if $HOME is not set
Dimitri Merejkowsky added the comment: > However, since we are changing the behavior of the netrc() class, I'm not > sure this can be considered as a bug fix. I was not sure either. The patch does change behavior in subtle ways... I've added a new patch, and sent the CLA form. Thanks for your time! -- Added file: http://bugs.python.org/file44933/netrc-use-expanduser-with-test.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28334] netrc does not work if $HOME is not set
New submission from Dimitri Merejkowsky: If $HOME is not set, netrc will raise an exception. Attached patch fixes the problem by using `os.path.expanduser` instead -- components: Library (Lib) files: netrc-use-expanduser.patch keywords: patch messages: 277824 nosy: Dimitri Merejkowsky priority: normal severity: normal status: open title: netrc does not work if $HOME is not set type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file44914/netrc-use-expanduser.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
