Opened 8 years ago

Closed 4 years ago

Last modified 2 years ago

#3381 closed Bug (fixed)

[PATCH] make manage.py read PYTHONSTARTUP

Reported by: Baurzhan Ismagulov <ibr@…> 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)

trunk-ibr-pystartup-20070128-2331.diff (844 bytes) - added by Baurzhan Ismagulov <ibr@…> 8 years ago.
pythonstartup.diff (1.1 KB) - added by deryck 8 years ago.
Here is a patch that applies against trunk as of r6230. The patch on #3386 looked better to me, with some modifications to honor both $PYTHONSTARTUP and .pythonrc.py

Download all attachments as: .zip

Change History (18)

Changed 8 years ago by Baurzhan Ismagulov <ibr@…>

comment:1 Changed 8 years ago by adrian

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Looks pretty good so far! Regarding throwing errors to the user, we should do whatever the standard Python interpreter does.

comment:2 Changed 8 years ago by adrian

  • Triage Stage changed from Unreviewed to Accepted

comment:3 Changed 8 years ago by Michael Radziej <mir@…>

#3386 marked as duplicate

comment:4 Changed 8 years ago by Jeff Bauer <jbauer@…>

It appears I was posting ticket #3386 shortly after this patch appeared.

Two minor details about my patch.

  1. 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.
  1. The second difference is to import user unless --plain is 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 Changed 8 years ago by adrian

  • Keywords sprintsept14 added

comment:6 Changed 8 years ago by deryck

  • Owner changed from nobody to deryck
  • Status changed from new to assigned

Changed 8 years ago by deryck

Here is a patch that applies against trunk as of r6230. The patch on #3386 looked better to me, with some modifications to honor both $PYTHONSTARTUP and .pythonrc.py

comment:7 Changed 8 years ago by deryck

  • Triage Stage changed from Accepted to Ready for checkin

comment:8 Changed 8 years ago by jacob

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [6231]) Fixed #3381 - manage.py shell now respects PYTHONSTARTUP/.pythonrc.py.

comment:9 Changed 7 years ago by anonymous

  • Cc me@… added

comment:10 Changed 5 years ago by vak

  • Resolution fixed deleted
  • Status changed from closed to 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 Changed 5 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from reopened to closed
  • Triage Stage changed from Ready for checkin to 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 Changed 4 years ago by anonymous

  • Easy pickings unset
  • Severity set to Normal
  • Type set to Bug
  • UI/UX unset
  • Version changed from SVN to 1.2

This doesn't work for me either.

comment:13 Changed 4 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:14 Changed 4 years ago by anonymous

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:15 Changed 3 years ago by saulshanabrook@…

  • 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.

comment:16 Changed 2 years ago by Ramiro Morales <cramm0@…>

In 1f6b2e7a658594e6ae9507c5f98eb429d19c0c9d:

Fixed #6682 -- Made shell's REPL actually execute $PYTHONSTARTUP and ~/.pythonrc.py.

Also:

  • Added a --no-startup option to disable this behavior. Previous logic to try to execute the code in charge of this funcionality was flawed (it only tried to do so if the user asked for ipython/bpython and they weren't found)
  • Expand ~ in PYTHONSTARTUP value.

Thanks hekevintran at gmail dot com for the report and initial patch.

Refs #3381.

Note: See TracTickets for help on using tickets.
Back to Top