dont laugh

[Alex Martelli]

"Ian Hobson" <ian.hobson at ntlworld.com> wrote in message
news:NYOb1FAY83s5EwMB at ntlworld.com...
    [snip]
> >What do you mean by "it does not"?  You download a self-installing
> >executable, run it, and there's a 'Python' entry on the Programs menu
> >of your Start button (plus, probably, one or more other entry points,
> >such as IDLE and/or Pythonwin, depending on the contents of said
> >self-installing executable).  That seems to be pretty much "out of
> >the box" to me.
> The path initialisation is missing.

And it had better stay missing, IMHO.  Far too many programs stick
their directories into my lone little PATH variable, crowding it to
no purpose.  There's no need to have Python's directories in the
PATH in order to run Python itself (Start/Programs/etc) nor to
run scripts within the Python environment; only people keen to
use python at the (command.com or cmd.exe) commandline prompt
really need the PATH alteration -- and people knowledgeable about
commandline issues are likely to be well able to edit their PATH
by themselves.


> >> a) Understanding that "Name error" meant I had forgotten an import
line.
    [snip]
> >e) you forgot case matters, and mean 'Foo' or 'FOO'
> >or other causes yet?  "Name error" seems appropriately generic for
> >an error which could be due to so many disparate causes.
> >
> Name "foo" not found
>
>  would do less to confuse: it reports the truth, and does not confuse
> the reader with all the other possibilities of name errors such as using
> an improper character, conflicting with a keyword, conflicting with an
> imported name. (I have even had similar errors because the editor left a
> formatting character in the source and then hid it from view!)

The exception NameError is only raised when a name is not found (and
the errormessage you see is always of the form ExceptionType: content,
so the "NameError:" part of it is not going to change).  I _think_ the
content part *could* be changed to say
    NameError: foo not found
rather than the more concise
    NameError: foo
and maybe that 'explanation' might be of some transient use to the
newbie (before he or she learns enough for the 'not found' part to
be a redundancy).

I'm not sure how suggested enhancements to error-messages are best
reported to the Python team (discussing them on a thread here is not
likely to catch their attention, I think).  Maybe entering a bug
report on sourceforge might help (but it could be more useful to do
it after 2.0b1 is out: 2.0 is where any change in messages could
maybe happen).  Do you know how to proceed, or want me to do it
for you...?  This goes for both the NameError and SyntaxError parts
of your post.


> >I guess that's not something the typical newbie would attempt;
> >those who do want it may know it's just an issue of setting a
> >shortcut appropriately (e.g., right-button/Explore on the Start
> >menu, navigate to the apropriate subfolder, right-button/New/
> >Shortcut, enter the commandline you desire, possibly edit the
> >Properties of the resulting shortcut; strictly an issue of Windows
> >GUI).
> Don't forget to set the associations and the paths.

I _do_, as you put it, "forget" to set "associations and paths";
rather, I use something such as
    c:\py16\python c:\py\myscript
as the 'commandline I desire'/'property of the resulting shortcut',
just as I would do for any other Windows program (it's suboptimal
to rely on 'paths and associations' for shortcuts, when you can
be explicit and solid about it; and that was always true of Windows
in my experience, well before I'd even heard about Python).


> > Do you think automating these tasks would greatly
> >enhance Python's accessibility for newbies?  I'm dubious, since
> >no major programming environment I know of for Windows
> >does it, not even Visual Basic I believe...
>
> Enhance yes. Greatly - perhaps no.
>
> Most systems produce .exe files, which can be handled in a standard way.

Hmmm, maybe; those exe files tend to need lots of associated DLL's
(runtime libraries, etc) for which there is no real de-facto standard
(many get crammed into system-directories, leading to well-known "DLL
Hell"; those who don't are often not easily found by EXE's needing
them -- paths become subtly important then).

Looking at a selection of typical programming-newbies (who tend
to be experienced Windows *users*) I don't see any of them trying
to set their own first programs *to be run from the Start button*;
you're the first Python-newbie (clearly not a newbie to programming
in general) who I heard having problems attempting that.  Rather,
the rule seems to be a lot of shortcuts in one directory (the desktop,
or a folder off it, for typically-sloppy guys:-) with maybe a few
copies to the QuickLaunch bar.

Anyway, the general issue is clearly: how to make it very easy to
create a shortcut-to-a-Python-script in a given folder -- it can
then be copied, moved, property-edited, etc, without too much
trouble, by any user with any significant Windows experience (by
placing it under Start/Programs, it will meet your needs; also,
it can meet other needs, which feel more typical to me, for
QuickLaunch & other folders/taskbars yet).  It should not be
very hard to add to PythonWin's Tools menu, for example (having
such a platform-specific issue addressed in a non-Windows-specific
standard Python distribution is of course unlikely in the extreme).
Would that satisfy your request?  Note that no associations, nor
paths settings, would need to be altered for the purpose.


> If you want to run a script on *nix the first line of the script has to
> be some magic incantation, AND you must chmod the file. Finding that one
> is necessary is relatively easy. Finding both are usually requires a
> tame guru. And if you are not near such a guru.......

...you need to post to Usenet:-).  Actually, any Unix user who's
ever run any script not in Bourne-Shell (or whatever default shell
they have) knows that.

> In the same way, setting the associations so the .py files invoke the
> interpreter is easy - once you know which of those executables is the
> interpreter. I found that by trial and error.

I agree that the typical Windows user, even one with some experience,
will not gladly muck about the View/Folder Options/Types menus, to
change/add/edit associations.  But I don't think that associating .py
to the interpreter is optimal (although I believe some Windows Python
installers do it -- at least, optionally) -- see above.

> But if you put 20 small hurdles in some ones way, they will say sodit
> and do something that is more fun.

Sure, "removing hurdles" is always good if it has no unpleasant side
effects (I think that having .py associated with the interpreter as
the default does have unpleasant side effects, as does mucking with
that limited-resource which is a user's Path variable).


Alex