Re: My Python annoyances



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
.