#3381 closed Bug (fixed)
[PATCH] make manage.py read PYTHONSTARTUP
| Reported by: | Owned by: | deryck | |
|---|---|---|---|
| Component: | Uncategorized | Version: | 1.2 |
| Severity: | Normal | Keywords: | sprintsept14 |
| Cc: | ibr@…, me@… | Triage Stage: | Accepted |
| Has patch: | yes | Needs documentation: | yes |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Hello Adrian et al.,
here is the first draft. Is it ok to throw any errors on the user, or should I catch any exceptions?
With kind regards,
Baurzhan.
Attachments (2)
Change History (18)
by , 19 years ago
| Attachment: | trunk-ibr-pystartup-20070128-2331.diff added |
|---|
comment:1 by , 19 years ago
comment:2 by , 19 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:4 by , 19 years ago
It appears I was posting ticket #3386 shortly after this patch appeared.
Two minor details about my patch.
- I think if the user specifies
--plain, the PYTHONSTARTUP should be ignored. My rationale is that you could have a user with a difficult-to-debug problem resulting from unanticipated effects of startup code and it would be easy to advise him/her to try to run the shell with--plain. Indeed I found one of my ~/.pythonrc.py startup scripts broke the Django shell. It could be argued this makes the shell behavior more consistent wrt not invoking IPython.
- The second difference is to
import userunless--plainis specified. This will automatically (and somewhat portably) invoke .pythonrc.py if it's available in the user's home directory.
I'm not lobbying hard for either of my extensions, just presenting my rationale. I'm happy that any patch is being accepted.
comment:5 by , 18 years ago
| Keywords: | sprintsept14 added |
|---|
comment:6 by , 18 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
by , 18 years ago
| Attachment: | pythonstartup.diff added |
|---|
comment:7 by , 18 years ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
comment:8 by , 18 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:9 by , 18 years ago
| Cc: | added |
|---|
comment:10 by , 16 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
Not all seem to be happy with ipython. Just visit #python to get more ideas why.
However if you try to use --plain then command line history, auto-completion on TAB and so on -- all these become difficult.
It is difficult because PYTHONSTARTUP is not respected :-(
Finally, if it is respected then the current behaviour could be forced via:
PYTHONSTARTUP= manage.py shell --plain
comment:11 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
| Triage Stage: | Ready for checkin → Accepted |
It's not at all clear to me what the comment that reopened this ticket is reporting as a problem. This ticket was about adding PYTHONSTARTUP be considered and it handles that. Bugs due to that should go in another ticket, as they are a consequence, not a revisiting of the original decision. We need a clear explanation of what goes and what maybe should be happening. Also, not that django doesn't force/require ipython usage (and never has), so that part of the comment is superfluous.
comment:12 by , 14 years ago
| Easy pickings: | unset |
|---|---|
| Severity: | → Normal |
| Type: | → Bug |
| UI/UX: | unset |
| Version: | SVN → 1.2 |
This doesn't work for me either.
comment:13 by , 14 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
comment:14 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
comment:15 by , 13 years ago
| Needs documentation: | set |
|---|
Some people may have issues because Django checks if PYTHONSTARTUP points to a file, without path expansion. For instance if PYTHONSTARTUP is set to '~/Documents/Coding/python_script.py', Django will silently not import it. This was confusing for me, because I had no idea why it wasn't being imported.
Looks pretty good so far! Regarding throwing errors to the user, we should do whatever the standard Python interpreter does.