Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #98025 > unrolled thread

Re: UNABLE TO GET IDLE TO RUN

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: UNABLE TO GET IDLE TO RUN Michiel Overtoom <motoom@xs4all.nl> - 2015-11-01 02:45 +0100
    Re: UNABLE TO GET IDLE TO RUN Steven D'Aprano <steve@pearwood.info> - 2015-11-02 01:27 +1100
      Re: UNABLE TO GET IDLE TO RUN Tim Golden <mail@timgolden.me.uk> - 2015-11-01 15:01 +0000
      Re: UNABLE TO GET IDLE TO RUN Laura Creighton <lac@openend.se> - 2015-11-01 17:17 +0100
        Re: UNABLE TO GET IDLE TO RUN Steven D'Aprano <steve@pearwood.info> - 2015-11-02 11:54 +1100
      Re: UNABLE TO GET IDLE TO RUN Terry Reedy <tjreedy@udel.edu> - 2015-11-01 19:07 -0500
        Re: UNABLE TO GET IDLE TO RUN Paul Rubin <no.email@nospam.invalid> - 2015-11-01 16:50 -0800
          Re: UNABLE TO GET IDLE TO RUN Terry Reedy <tjreedy@udel.edu> - 2015-11-02 02:46 -0500
        Re: UNABLE TO GET IDLE TO RUN Steven D'Aprano <steve@pearwood.info> - 2015-11-02 12:19 +1100
          Re: UNABLE TO GET IDLE TO RUN Chris Angelico <rosuav@gmail.com> - 2015-11-02 13:08 +1100

#98025 — Re: UNABLE TO GET IDLE TO RUN

> On 31 Oct 2015, at 06:59, Terry Reedy <tjreedy@udel.edu> wrote:
> This is a different issue than IDLE avoiding clashes.  I opened
> https://bugs.python.org/issue25522

Terry, thanks for recording this into the issue tracker.

I'd go even a step further. I think IDLE should not only warn, but completely prevent saving a file which shadows a stdlib module, which will effectively render Python unusable. I remember from a few weeks back, a teacher with the same problem posted this on the mailinglist. Eventually she had a technician coming in to reinstall Windows, just to fix this problem ;-) What an overkill...

Greetings,

[toc] | [next] | [standalone]

#98044

On Sun, 1 Nov 2015 12:45 pm, Michiel Overtoom wrote:

> 
>> On 31 Oct 2015, at 06:59, Terry Reedy <tjreedy@udel.edu> wrote:
>> This is a different issue than IDLE avoiding clashes.  I opened
>> https://bugs.python.org/issue25522
> 
> Terry, thanks for recording this into the issue tracker.
> 
> I'd go even a step further. I think IDLE should not only warn, but
> completely prevent saving a file which shadows a stdlib module, which will
> effectively render Python unusable.

Really?

[steve@ando ~]$ touch collections.py
[steve@ando ~]$ python -c "import math; print math.sin(1.25)"
0.948984619356

Looks like Python is still usable to me.


> I remember from a few weeks back, a 
> teacher with the same problem posted this on the mailinglist. Eventually
> she had a technician coming in to reinstall Windows, just to fix this
> problem ;-) What an overkill...

If that is true, that's really sad. Were we really unable to tell this
teacher to delete the shadowing file? Or was there more to the problem than
that?



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#98049

On 01/11/2015 14:27, Steven D'Aprano wrote:
>> I remember from a few weeks back, a
>> teacher with the same problem posted this on the mailinglist. Eventually
>> she had a technician coming in to reinstall Windows, just to fix this
>> problem ;-) What an overkill...
>
> If that is true, that's really sad. Were we really unable to tell this
> teacher to delete the shadowing file? Or was there more to the problem than
> that?

We tried, over the course of several days. It looked like a simple 
"delete this and try again" problem. After a couple of iterations she 
and her tech support obviously decided that re-imaging the lab machines 
was a better use of their time to achieve their goal (get the thing 
working) than further distance-learning diagnostics.

TJG

[toc] | [prev] | [next] | [standalone]

#98053

I managed to delete the real mail I would like to reply to.
This is, at least in the same thread ....

In a message of Mon, 02 Nov 2015 01:27:23 +1100, "Steven D'Aprano" writes
a reply to Michael Overtoon:

> Users are inclined to ignore alerts, dialogs and error messages, and
> applications try very, very hard to reinforce that tendency.

http://ux.stackexchange.com/questions/4518/should-alert-boxes-be-avoided-at-any-cost

(ok posting of question.)

> Good to see that IDLE is going to continue that fine old tradition of
> degrading usability for the sake of a quick and easy non-solution to a
> problem.

I think you owe Michael an apology.
Winning an argument on  'I should I get it my way because I can come up with
a pithy and condescending way to phrase my objection to what you
want to do' seems morally bankrupt to me.  Ditto on the idea of bashing
him just because he is handy and the world is a bad place for you right 
now.  It hardly counts as a technical reason for or against the issuing
of warnings in idle, or the more severe 'not allowing you to save'.

I have a professional carreer based on saying 'do not blather useless
error/warning messages' at people.  I am pretty much always on your
side of the argument.  But, here we are, first time in 22 years, and
I am here arguing in _favour_ of a warning message. :)

I very much want to convince Michael that my warning will be sufficient,
thus preventing people from writing out strings.py is unnecessary.
It's going to be damn hard to do so if he is stung by your 
non-constructive (however brilliant) remark.

Laura

[toc] | [prev] | [next] | [standalone]

#98076

On Mon, 2 Nov 2015 03:17 am, Laura Creighton wrote:

> I managed to delete the real mail I would like to reply to.
> This is, at least in the same thread ....
> 
> In a message of Mon, 02 Nov 2015 01:27:23 +1100, "Steven D'Aprano" writes
> a reply to Michael Overtoon:

Actually it's a reply to Terry.


>> Users are inclined to ignore alerts, dialogs and error messages, and
>> applications try very, very hard to reinforce that tendency.
> 
>
http://ux.stackexchange.com/questions/4518/should-alert-boxes-be-avoided-at-any-cost
> 
> (ok posting of question.)
> 
>> Good to see that IDLE is going to continue that fine old tradition of
>> degrading usability for the sake of a quick and easy non-solution to a
>> problem.
> 
> I think you owe Michael an apology.

I can't imagine why you think I owe Michael an apology. An apology for what?


> Winning an argument on  'I should I get it my way because I can come up
> with a pithy and condescending way to phrase my objection to what you
> want to do' seems morally bankrupt to me.  Ditto on the idea of bashing
> him just because he is handy and the world is a bad place for you right
> now.  

"Bashing" him? Really? A touch of sarcasm ("Good to see") about a technical
decision is bashing the author and "morally bankrupt"?

Laura, with respect, perhaps it isn't me who is writing from "a bad place"
right now.


> It hardly counts as a technical reason for or against the issuing 
> of warnings in idle, or the more severe 'not allowing you to save'.

There is a technical reason against the issuing of warnings in IDLE, namely
that their target audience is disinclined to read warnings, not well suited
to understand these specific warnings, and likely to click on whatever
random buttons it takes to make the warnings go away and let them save
their file under their chosen name.


> I have a professional carreer based on saying 'do not blather useless
> error/warning messages' at people.  I am pretty much always on your
> side of the argument.  But, here we are, first time in 22 years, and
> I am here arguing in _favour_ of a warning message. :)

I get that, I truly do, and believe me when I say I respect your expertise.
But it seems to me that you're falling for the fallacy "we must do
something, this is something, therefore we must do it".

I completely agree that accidental shadowing is a problem, especially for
beginners. I too would like to fix that, and (as you know, but others may
not) I've proposed a solution on the Python-Ideas mailing list.

But just because there is a problem doesn't mean that the first thing we
think of is the solution. I haven't come across anyone, not one person,
willing to dispute the conventional wisdom that users don't read alert
messages. We agree that users don't read warnings, but you're expecting
them to read *this* warning. What makes this proposed warning different
from all the other useless blatherings that users don't read? Why will they
read this one?

It is 2015, nearly 2016, and surely there isn't a professional developer
alive who hasn't come across the truism that users don't read warnings, and
that they should avoid putting up modal dialogs with a warning. And yet
they still do it. Why?

They're not all idiots. I don't believe either you or Terry are idiots. I
expect that, like you and Terry, they have fallen into the trap of
believing that *this one case is special*. This issue is important enough
that we have to do something, and users might not read all those other
blathering error messages, but they'll read this one, because it is
important that they do.

Otherwise, how can you justify this warning? Users won't read it. It will
just reinforce their tendency to ignore errors and warnings, and as an
educator surely you don't want that. If they click on the OK/Cancel button
at random, as UI studies suggest people tend to do, then 50% will end up
shadowing the file regardless, and 50% will have a second chance to pick a
better name -- which they may not do.

And most shadowing is harmless. If I name my script code.py, or this.py, it
will still run fine unless I directly or indirectly import `code` or
`this`. It is true that shadowing *can* leave Python effectively unusable
(try shadowing `os` and see how many things break) but most of the time
shadowing doesn't hurt. So most of the time, these warnings will be exactly
the pointless blatherings that you usually oppose.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#98073

On 11/1/2015 11:17 AM, Laura Creighton wrote:

> In a message of Mon, 02 Nov 2015 01:27:23 +1100, "Steven D'Aprano" writes
> a reply to Michael Overtoon:

He was actually responding to my proposal to warn about duplicating 
stdlib names when saving-as.

>> Users are inclined to ignore alerts, dialogs and error messages, and
>> applications try very, very hard to reinforce that tendency.
>
> http://ux.stackexchange.com/questions/4518/should-alert-boxes-be-avoided-at-any-cost

I read this and at least some of the concerns do not apply.

* IDLE does not spam users with alerts.  And I may move some of the rare 
ones to a new 'log' window. The only one I see with any regularity is 
'Save work before close?' and that I appreciate.

* 'Save-as' is not part of the regular workflow.  It is done once per 
file.  Experienced users who know to avoid stdlib names will not see the 
messages unless they accidentally duplicate one -- which is possible 
because there are now so many.  I personally would like being warned.

* The target of the message is naive beginners who have not read any 
docs and who may not yet even know about the stdlib and imports.  The 
*need* the info and may not be so jaded about alert messages.

One person suggested something I thought about: make the 'right thing' 
box bigger than the 'dangerous thing' box.

>> Good to see that IDLE is going to continue that fine old tradition of
>> degrading usability for the sake of a quick and easy non-solution to a
>> problem.

Doing nothing is also a non-solution.

> I have a professional carreer based on saying 'do not blather useless
> error/warning messages' at people.  I am pretty much always on your
> side of the argument.  But, here we are, first time in 22 years, and
> I am here arguing in _favour_ of a warning message. :)

Knowing that you are not a fan of such things makes your request stronger.

 > I very much want to convince Michael that my warning will be
 > sufficient,

If the message works half the time, I would consider it successful.

 > thus preventing people from writing out strings.py is unnecessary.

I will not absolutely prevent duplicate names unless Guido says to do so.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#98074

Terry Reedy <tjreedy@udel.edu> writes:
> * 'Save-as' is not part of the regular workflow.  It is done once per
> file.  Experienced users who know to avoid stdlib names will not see
> the messages unless they accidentally duplicate one -- which is
> possible because there are now so many.  I personally would like being
> warned.

I think there is something to be said for this.  I've gotten confused a
few times by accidentally re-using a stdlib name, and I'm experienced.

One thing I wish in IDLE is for ctrl-N (or some alternate) to prompt
for a filename immediately: opening a new window, then writing code in
it, and then using Save-as seems unnatural to me.  That would also be
a good time to validate the filename, by searching sys.path or whatever.

[toc] | [prev] | [next] | [standalone]

#98088

On 11/1/2015 7:50 PM, Paul Rubin wrote:
> Terry Reedy <tjreedy@udel.edu> writes:
>> * 'Save-as' is not part of the regular workflow.  It is done once per
>> file.  Experienced users who know to avoid stdlib names will not see
>> the messages unless they accidentally duplicate one -- which is
>> possible because there are now so many.  I personally would like being
>> warned.
>
> I think there is something to be said for this.  I've gotten confused a
> few times by accidentally re-using a stdlib name, and I'm experienced.
>
> One thing I wish in IDLE is for ctrl-N (or some alternate) to prompt
> for a filename immediately: opening a new window, then writing code in
> it, and then using Save-as seems unnatural to me.  That would also be
> a good time to validate the filename, by searching sys.path or whatever.

Given that one has to save-as before running, this seems somewhat 
sensible.  There is also request to be able to run 'Untitled' windows.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#98078

On Mon, 2 Nov 2015 11:07 am, Terry Reedy wrote:

> On 11/1/2015 11:17 AM, Laura Creighton wrote:
> 
>> In a message of Mon, 02 Nov 2015 01:27:23 +1100, "Steven D'Aprano" writes
>> a reply to Michael Overtoon:
> 
> He was actually responding to my proposal to warn about duplicating
> stdlib names when saving-as.
> 
>>> Users are inclined to ignore alerts, dialogs and error messages, and
>>> applications try very, very hard to reinforce that tendency.
>>
>>
http://ux.stackexchange.com/questions/4518/should-alert-boxes-be-avoided-at-any-cost
> 
> I read this and at least some of the concerns do not apply.
> 
> * IDLE does not spam users with alerts.

IDLE might not, but they will be using a computer that does. 

And frankly, I don't believe that users don't read alerts because they are
spammed by them. I've seen far too many new computer users who have not had
time to get jaded by excessive alerts click through without reading.

Certainly the excessive use of warnings makes the problem worse, teaching
even experienced users to ignore them. But that's not where the problem
starts.

We all agree on the nature of the problem, we all agree that the evidence
from systematic UI testing is that the general solution proposed ("put up a
warning dialog") is likely to be pointless, and yet some of us are sure
that the evidence doesn't apply in this case, this case is special.

I don't believe it is.


[...]
>>> Good to see that IDLE is going to continue that fine old tradition of
>>> degrading usability for the sake of a quick and easy non-solution to a
>>> problem.
> 
> Doing nothing is also a non-solution.

Some people may argue that Python has survived for over two decades with
this problem, so that "do nothing" is a perfectly valid thing to do.

But I haven't argued for "do nothing". I've offered two solutions:

- Python as a whole should move "" from the start of sys.path to the end (or
at least the middle, after the stdlib) so as to avoid accidental shadowing.

- Even if Python doesn't do this, IDLE could do it, and could do it
immediately, without waiting for a new point release. IDLE is an
application, an IDE, not the Python interpreter, and like IPython or any
other IDE, it is perfectly entitled to behave differently from the vanilla
Python interpreter.

I argue that IDLE is entitled to do anything which the site module or
PYTHONSTARTUP file could do, such as pre-import the most common modules, or
change the order of sys.path. As maintainer, you're entitled to reject my
solution. But it is a potential solution, and I believe it will come closer
to an actual fix for the shadowing issue than raising warnings.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#98081

On Mon, Nov 2, 2015 at 12:19 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> - Python as a whole should move "" from the start of sys.path to the end (or
> at least the middle, after the stdlib) so as to avoid accidental shadowing.
>
> - Even if Python doesn't do this, IDLE could do it, and could do it
> immediately, without waiting for a new point release. IDLE is an
> application, an IDE, not the Python interpreter, and like IPython or any
> other IDE, it is perfectly entitled to behave differently from the vanilla
> Python interpreter.

IDLE consists of two things: its own code, and a means of running user
code. Conceptually, they're entirely separate - it's almost a
coincidence that they happen to be using the same language. If the IDE
wants to protect itself against running unexpected userland modules,
it is absolutely allowed to do that, same as any other application is;
it can remove "" from sys.path, or reposition it, or add traps to see
where some_module.__file__ is, or anything at all.

But when it's running user code, it should be semantically as close as
possible to the command-line interpreter as it can be. If I type
"import foo" into IDLE's interactive mode, or if I type "import foo"
into IDLE's editor and hit Run, or if I type "import foo" into the
standard command-line interactive interpreter, I expect that they'll
all find the same module, and if they don't, it's an extra debugging
hassle. When I'm debugging a script, I'll often try some parts of it
in an interactive interpreter, and it should not matter whether I pick
"python", or Idle, or ipython in a terminal window, or the in-browser
ipython notebook, etc, etc, etc. I want to be able to keep the
differences *in my head*. There are already a few; interactive
interpreters...

* Can't have blank lines in class/function definitions;
* Automatically print non-None expression results;
* Recover from exceptions by returning to the main loop, rather than
bombing the whole module load
* Warnings are enabled by default

AFAIK, all of these are consistent across _all_ interactive Python
interpreters. (The second one is configurable, but it's always the
default.) I do *not* want to have to add "Local modules do not shadow
stdlib modules" as an additional difference, particularly not in one
specific interface and not others.

So yes, technically IDLE is allowed to behave differently. But I would
hope this is extremely rare and VERY solidly justified (eg "Python 3.6
will do it this way, and IDLE is a bit ahead of the curve").

ChrisA

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web