My Python annoyances

Chris Mellon arkanes at gmail.com
Fri May 4 09:31:28 EDT 2007


On 5/4/07, Ben Collver <collver at peak.org> wrote:
> 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.
>

#python is one of the most accepting communities around. If the bug
reports here and the way you've presented them in this thread (vs the
way that they appear to an outside observer) are any indication,
though, I'm not surprised that you might have left in a huff.

Bear in mind that #python has no special status with regards to python
development and is primarily a community of *users*. If you go in with
some sort of thing you consider a problem, you are likely to be shown
a solution. Debate over whether it should be fixed in the core is
likely to be met with "patches accepted".

> >> 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.
>

That's a valid point. Maybe you should have responded on the tracker
with that viewpoint. Your characterization of what happened in your
original post borders on dishonest - how can you possibly view what
happened there as "bug reports not welcomed"?

> > 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.
>

Huh.

> >> 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
>

Code like this is working directly against Python philosophy. You
probably got told this on #python, too. There's hardly any
circumstance where you should need to validate the exact class of an
object, and as long as they have the same interface theres no harm
whatsoever in tempfile changing it's return value between Python
versions.

> > 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
>



More information about the Python-list mailing list