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 -- http://mail.python.org/mailman/listinfo/python-list
