[Tutor] file permissions

[Danny Yoo]

> > I agree with Danny, the question lacks any evidence of prior
> > investigation on the part of the poster, and that makes it a lousy
> > candidate for the helpful guidance of the python tutor list.

Hi Eric,

It there's something I want to avoid, it's the impression that we're
looking at each question and saying "That's not worthy of our attention."
That's not the real motivation behind asking for more details.

The issue is similar to what typically happens in grade school
when students learn arithmetic.  If I see something like:

          1 2
        - 1 5
        -----
            7

then obviously the student is thinking of something, and doing some sort
of operation in their head.  And even if that operation isn't quite right,
at least we can try to figure out why the student's doing addition in some
places, and subtraction in another.


Contrast that transparent situation to another.  Imagine seeing a
student's worksheet:

          1 2
        - 1 5
        -----
         WRONG WRONG WRONG

where we don't get any information at all about what the student was
trying to do.


That silliness is what I'd like to avoid, because that's not how things
work in the real world.  We all have partial knowledge, and we know how to
do some things: it's not a binary thing, even if we're dealing with
computer programming.



> I did google and found the same pages that Danny mentioned. Just
> couldn't get the stuff to work, or understand what modules needed to be
> imported to get them to work.

That's information that would have been useful;  we'd then concentrate
more on how to filter out the documentation to stuff that's useful to you.

For the programs that was written that didn't work, we'd like to see why
they didn't work: perhaps it might be a misdesign in the module itself,
and perhaps that misdesign can be corrected.



(I know, for example, that Tkinter should do more early error trapping on
its input.  For example:

######
>>> Tkinter.Message('hello world')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/export/home/dyoo/local/python-2.4//lib/python2.4/lib-tk/Tkinter.py",
line 2634, in __init__
    Widget.__init__(self, master, 'message', cnf, kw)
  File
"/export/home/dyoo/local/python-2.4//lib/python2.4/lib-tk/Tkinter.py",
line 1856, in __init__
    BaseWidget._setup(self, master, cnf)
  File
"/export/home/dyoo/local/python-2.4//lib/python2.4/lib-tk/Tkinter.py",
line 1834, in _setup
    self.tk = master.tk
AttributeError: 'str' object has no attribute 'tk'
######

There's an error message, but it doesn't really say up front what the real
issue is.  It's complaining that 'str' doesn't have the 'tk' attribute,
which is technically true, but what it really should be saying is that the
first argument to Tkinter.Message() has to be a master widget.

But that's something that has a technical fix --- we can modify the
Tkinter.py library to check for that attribute early, and give a good
error message if it see's something wrong.  I'm planning to send some
patches later through SF because I know people on Tutor occassionally run
into these bad error messages.)



> > If I may hijack the thread, does anyone more knowledgeable than me
> > know why os.stat and stat are so low-level and esoteric?  Am I crazy
> > for wanting to replace
> >
> > 	oct(stat.S_IMODE(os.stat(thefile)[stat.ST_MODE]))
> >
> > with, say,
> >
> > 	stat.getmode(os.stat(thefile))
> >
> > or even
> >
> > 	os.getmode(thefile)


It's possible that no one has considered it a problem yet!  *grin*

The design is closely mimicing the interface that C provides us.  There's
a case for making it less obscure, but no one has gone through the effort
to make it better yet.

It might make a good project for someone to make grabbing file permissions
a bit nicer.