My Python annoyances

[Ben Collver]

Paul Boddie wrote:
> I'm sorry to hear about that. If by "macho" you mean people who insist
> that things are good enough as they are, and that newcomers should
> themselves adapt to whatever they may discover, instead of things
> being improved so that they are more intuitive and reliable for
> newcomers and experienced developers alike, then I'd certainly be
> interested in undermining that culture.

That was the sort of response I got on freenode #python, which I realize 
I should not take as representative of the whole community.  Thank you 
for the thoughtful response.

>> I tried to write portable Python code.  The zlib CRC function returned
>> different results on architectures between 32 bit and 64 bit
>> architectures.  I filed a bug report.  It was closed, without a comment
>> from the person who closed it.  I get the unspoken message: bug reports
>> are not welcome.
> 
> Can you provide the bug identifier? Bug reports are generally welcome,
> and despite complaints about patch reviews, I've found people
> reviewing things I've submitted.

It is problem report #1678102.  I understand the problem: that a 32 bit 
number looks different in a 32 bit signed int than in a 64 bit signed 
int.  However, the workaround of dropping a bit seems to defeat the 
purpose of using a CRC.

> Yes, Ctrl-Z exits Python in the standard Windows edition. Since Cygwin
> provides a POSIX-like environment, Ctrl-D should be used instead. If
> the documentation is wrong, a bug report or patch should be filed
> against the software.

This morning I could not reproduce the problem.  When the user types 
"quit" at the Python prompt, the Cygwin port instructs the user to press 
Control-D, which works.  Even if you SSH in to Cygwin, and run the win32 
port, it instructs the user to press Control-Z plus Return, which works.
Maybe it was fixed after I had the problem.

>> Between 2.4 and 2.5, tempfile returns a different type of object.  My
>> code cannot have a single test, it has check for type(obj) == file or
>> obj.__class__ == tempfile._TemporaryFileWrapper.
> 
> Try using isinstance or relying on "deeper" knowledge of how the
> object will be used.

Thank you for the hint.  I just want my function to validate that one of 
its arguments is a file-like object.  It isn't necessarily going to be a 
temporary file, but it might be.

 >>> import temporaryfile
 >>> t = tempfile.TemporaryFile()
 >>> isinstance(t, file)
False

> My opinions, already expressed, include the observation that the core
> development community is more interested in extending the language
> than in strengthening the standard library (and its documentation). It
> should be noted that the proposed standard library reorganisation,
> which is a very conservative affair, has actually been postponed until
> after the release of Python 3.0a1 according to a message I read
> recently. And yet, if you read people's lists about what they "hate"
> about Python (amongst actual users of Python), guess which thing
> almost always comes up?

I guess you cannot blame folks for working on what they find interesting.

Ben