Feedback wanted on programming introduction (Python in Windows)

Alf P. Steinbach alfps at
Mon Nov 2 01:49:50 CET 2009

* Rhodri James:
> On Sun, 01 Nov 2009 21:20:20 -0000, Alf P. Steinbach <alfps at> 
> wrote:
>> * Rhodri James:
> This is a weird attribution style, by the way.  I don't think it helps.

That's a pretty weird thing to comment on.

And as far as I can see the comment doesn't make sense except as an attempt to 
find something negative to say.

But anyway, the point about '*' was, once upon a time, that it made for a very 
clear style of quoting in old newsreaders. Nowadays the tools are generally of 
lesser quality (e.g. I'm using Thunderbird). And so it doesn't really have much 
of that advantage left, but I'm using it anyway; I can be pretty stubborn about 
issues of quality.

>>> On Fri, 30 Oct 2009 03:26:45 -0000, Alf P. Steinbach <alfps at> 
>>> wrote:
>>>> * Rhodri James:
>>>>> On Thu, 29 Oct 2009 16:53:05 -0000, Alf P. Steinbach 
>>>>> <alfps at> 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.
>> For NTFS it's 32K or 64K wide characters, I don't recall which. But 
>> what's important is that that's also the API level limit. You can find 
>> most of the details in Microsoft's documentation of CreateFile (but 
>> it's off-topic here).
> Actually it [the limit]'s not

You're disputing a plain fact.

For which you've been given a technical reference, as well as concrete example.

I'm sorry, but it's idiotic to dispute plain facts.

>, since it's a perfect example of the "not reading quite
> carefully enough" others have pointed out before.  You make this statement
> as an absolute, iron-clad assertion.  Checking the MS website, we find it
> actually says:
> "Maximum Path Length Limitation
> In the Windows API (with some exceptions discussed in the following 
> paragraphs), the maximum length for a path is MAX_PATH, which is defined 
> as 260 characters."
> The exceptions are unicode versions of some of the functions, which do
> give you ~32K characters.  However, the docs are pretty specific about
> what is and isn't the API limit.

I'm sorry but you're misunderstanding the documentation.

In your own words, you're "not reading quite carefully enough".

By the way, your technique of vague ad hominem attack here is detestable.

But anyway, if you read the documentation of CreateFile as I directed you to, or 
simply read on where you was, then you get a more technically correct picture.

Or, by applying logic you can /deduce/ that since >260 character paths can and 
do exist, 260 characters is not "the limit".

The MS documentation is unfortunately not all that clear. In many cases (the 
most infamous one is perhaps the claim that a program's entry point is WinMain) 
it's just plain incorrect, being written by technical writers. But it's simple 
enough to write a few programs to check it out.

>  Since this applies to the command
> line just as much as to GUIs,

No, it doesn't. And you've been given a concrete example of how.

You can't just go on *inventing* facts.

Facts are facts, your fantasies & wishes are your fantasies & wishes.

> I'll repeat my claim that blaming Explorer
> for something that causes just as much grief on a command line is a
> tad unfair.

I'm sorry, but there's a complete lack of logic in that, as well as misdirection.

First, regarding the misdirection, it is untrue that I have "blamed" Windows 
Explorer for this. The blame, if any is to be affixed anywhere, belongs 
elsewhere than with a computer program.

Second, regarding the logic, that a program exhibits low quality in some respect 
is not OK just because there's another program that also exhibits low quality.

> More importantly, I accuse you of making very definitive statments
> that turn out to be insufficiently researched.

That would be OK and what I want. :-) But you haven't. You're making general 
vague statements about quality, but haven't addressed any concrete thing in the 
text. And what you have responded to here in this thread, it's all been 
incorrect. In this latest article you have even started disputing simple 
technical facts and started making fallacious deductions, shown above.

>  That's not an
> encouraging state of affairs in someone planning to write a beginners'
> textbook.  Having originally learned C from one of Herbert Schildt's
> books, I reckon I've earned the right to be highly allergic to this!

I'm sorry to hear that you had to endure that.

It's an old saying that the low price of Herbert's annotated C++ reference, 
compared to the official standard, reflected the value of his annotations...

But that's no excuse to now start emulating Herbert, regarding blatant disregard 
for facts and logic, as you've done above.

Cheers & hth.,

- Alf

More information about the Python-list mailing list