Feedback wanted on programming introduction (Python in Windows)

[Rhodri James]

On Fri, 30 Oct 2009 03:26:45 -0000, Alf P. Steinbach <alfps at start.no>  
wrote:

> * Rhodri James:
>> On Thu, 29 Oct 2009 16:53:05 -0000, Alf P. Steinbach <alfps at start.no>  
>> wrote:
>>> with the best knowledge of the program's environment, is unable to  
>>> handle (such as delete) files or folders with paths greater than some  
>>> 260 characters, is unable to handle filenames that differ only in case  
>>> and are in the same directory, and is unable to e.g. delete a folder  
>>> called "con"  --  although such files & folders can very easily be  
>>> created.
>>  You may or may not be aware that some of these things are limitations  
>> of
>> the underlying disc format,
>
> Sorry no, it isn't.
>
> Even assuming you meant the more reasonable "file system", no, it isn't.

Actually I should have mentioned the filing system as well as the disc
format (which does matter).  I may not be using correct Windows  
terminology,
since I'm referring to both the bytes on hardware and the software stack
that terminates in the OS API.

Still, colour me surprised.  I had assumed that NTFS had some (large)
limit on filenames, and 256 sounded plausible.  More to the point, I
was under the impression that path manipulation logic in the filing
system had limited sized buffers, which were the cause of this fault,
and that Exploder's only sin was not programming around the bug.  In
fact, the more I think about it, the more sure I am that I've had to
play silly buggers on the command line myself to get around this.

> Depending on the file system a program may be unable to create such  
> things as I mentioned. And depending on the program design it may be  
> reasonable to refuse to create them.
>
> But a program should have no trouble deleting the files etc. once  
> they're there.

Your faith is touching, but fundamentally misplaced.

> That's why the Windows API handles them just fine, while Windows  
> Explorer does not. You may consider, since you're unfamiliar with the  
> API, that mostly it's no problem doing these things in the command  
> interpreter, which has no special support (rather, the reason it's easy  
> is because it doesn't properly check command arguments). And from that  
> you can deduce that the API support is there.

Having stuffed this up many, many years ago, my recollection is that
it needed a certain deviousness to get around.  In the case of the long
path names, my deduction from comparing the behaviours of the command
line and Explorer was that the API limited the path name length, and
Explorer didn't use relative paths to get around it.  I find it hard
to call that a bug, when it's only really exposing a limitation of the
underlying FS.

>>> For example, for general tool usage in Windows the student needs to  
>>> know about levels of environment variable specifications and file  
>>> associations, which in turn requires knowledge of processes and the  
>>> Windows registry database and various commands.
>>  Mercifully this is rubbish.  For most purposes with most tools even
>> Windows users don't need to know much if anything about environment
>> variables and the registry.  Needing to know anything about the
>> registry is usually a sign that Windows has stuffed you up royally.
>
> I deduce that you mainly use IDEs and don't know about the things you're  
> commenting on here (more than you did above). Sorry, but there it is.

You deduce incorrectly.  I'd unbend enough to admit that setting
environment variables is frequently very useful to inveterate command-
line users like myself, and that Windows makes that a lot harder than
necessary, but your original statement still reads like scaremongering.

Why am I defending Windows again?

-- 
Rhodri James *-* Wildebeest Herder to the Masses