The single MONOLITHIC folder you SHOULD be using to contain all your personal modules and scripts! But of course you are not doing this, only professionals are consistent.
On the contrary; it's easy to be consistent in clinical conditions,
but the Real World is very messy. Just a few reasons for scripts to
move around a bit:
* A few of the files need to be auto-updated by some remote system, so
they're stored in a directory owned by some other user to isolate
rsync
* Some files come from a package that's managed by an external
facility (eg apt-get), so there's no point moving them
* Part of the code gets extracted or decrypted on-the-fly from some
other source, so they're in /tmp
* The most important scripts are in a source-control managed tree
You can't rely on a single directory ("folder") containing all the
non-system code. If Python were to absolutely *demand* that, then I
suppose you could set up a bunch of symlinks (as long as you're on
Linux - on Windows, you MIGHT be able to do that), but it wouldn't
gain you anything.
And why the HELL would you place scripts on the desktop? So you can easily double click and run them? *giggles* Steven, have you heard of the new invention called a symbolic link?
Back in the early 1990s, on our OS/2 boxes, I got into the rather
useful habit of creating a file called 1. If I want an extension on
that, I can call it "1.cmd" for a REXX command, or whatever. If I need
two, "2.cmd" comes next. Saves you the trouble of coming up with a
name that fits your "standard library", and it keeps showing the thing
to you, demanding attention, and asking either to be renamed to
something permanent or finished with and deleted. Not all files are
for long-term use.
Mind you, some temporary names end up surviving. I still have a file
called 1 that stores snippets and cool quotes from the MUDs I play,
and when I made them web-accessible, I kept the name -
http://rosuav.com/1/ - after all, nothing is so permanent as a
temporary name. But I digress.
So you understood my statement, however, you felt the need to correct me because i say "toe-mate-toe" and you say "toe-maught-toe"? interesting.
This is an argument I've had many times at work. Incorrect use of
language SHOULD be corrected, even when it's unambiguous; otherwise,
language becomes useless. If your and Steven's disagreement were
ignored, then sooner or later an ambiguous situation will arise, and
you'll understand different things from the same words. That's
dangerous. (And by the way, feel free to point out my own
spelling/grammar errors. I'm sure I've made some; one of the
fundamental rules of the universe is that it's impossible to nitpick
someone else's use of English without making your own mistakes.)
Another new invention you may not know of are "command line switches"
Errors are notoriously hard to replicate. That's why production code
has logfiles. There's only one state that matters, and that's the
state the system was in when the one-off error occurred. The
programmer gets called in, he pulls up the log, he finds a traceback,
and gets to work. If that traceback is clear, readable, and carries
all the information he needs, it's a ten-minute job; if it's
abbreviated and he has to search the whole filesystem to find the
files, it's a huge and onerous task. (The middle ground, that he can
inspect some environment variable or whatever, isn't too much work,
but it's still unnecessary; the traceback could just contain it
directly.)
Now /imaging/ all that, let's inspect these paths:
(Imagining, but I digress.)
These two are invalid because you can only repair one problem at a time. And if you don't know the username of the person who's problem you are repairing, then you are not fit to repair the problem are you? Next!
Since when do usernames relate to people? And since when do you know
whose problem you're repairing? Going back to my scenario examples
above, the username might actually relate to the rsync source, or it
might be a descriptive-only name - for instance, I have a user
"content" on one of our servers, and whenever the web site's content
gets updated, it's rsync'd up to that user. So most of the files are
in /home/content/.../.../... rather than anything relating to a human.
Python source files should NEVER be under a temp directory, you can safely ignore this one.
Well, see above. Perfectly plausible justification for executing code from /tmp.
If these last three files really exist, and are /actually/ Python scripts, i would suggest charging extra so you could have time to teach this "dev" how to intelligently store files using structure and consistency.
And how to totally trash his system by not being allowed to have
multiple versions of things. And forbid him to use virtualenv, too.
Come to think of it, we should all use the Macbook Wheel file system
model - never mind about paths, just press both sides of the wheel and
get an alphabetized list of all files on your disk.
Additionally: When heaps of text is scrolling past you, it's very easy
to eyeball it for differences. When most or all of your paths start
with the same string, the eye will happily skip over it and find
what's important.
Actually that is wrong. Because remember, the path, lineno, and containing object exist on the same line. Since paths tend to be long, i find this line is always wrapping and breaking up the block structure of a printed exception message.
A fair point. There are a few solutions to this; one is to abolish the
80-character width limit. When you're working in a log file (rather
than directly on a console) this is easy, and you can just scroll
horizontally. Another is...
Traceback (most recent call last):
File C:\users\user\documents\python\lib\sound\effects\echo.py, line 1423, in distribute_weights_evenly
By shorting paths (ONLY THOSE PATHS THAT LIVE IN A REGISTERED LIBRARY FOLDER), we can maintain printed exception message structure.
.... by shortening (please keep the 'en', this is an international
forum and we need to declare the language correctly - that way, you
can talk about 'shortdeing' German paths) the paths themselves. This
sounds like a job for a simple filter though, not for a language
feature.
I would go further and suggest moving the line number and containing object to their own lines.
Traceback (most recent call last):
File: "...\lib\sound\effects\echo.py"
Line: 1423
In: <function> "display_echo_waveform"
I disagree. It's much more useful to have the file name and line, at
least, together; but what might be useful would be to go for a more
compact notation:
C:\users\user\documents\python\lib\sound\effects\echo.py:1423:
display_echo_waveform
Trace....
This is a standard that many tools emit/recognize, and it's more
compact than showing "File" and "Line" in words. That might squidge
your traceback under the eighty-character limit. But whatever is done,
it's much easier to keep the file and line together; tools can more
easily work with it that way and smoothly take you to the appropriate
line in your editor, or whatever. Move the function name off, if you
need to, or just let it wrap. (That's why I put it at the end.)
ChrisA
