By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,095 Members | 1,586 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,095 IT Pros & Developers. It's quick & easy.

My Python annoyances

P: n/a
I'm really annoyed at Python - and not for the reasons already
mentioned on this list.

Everyone know that programming is supposed to be a dark art, nearly
impossible to learn. Computer code is supposed to be something
impossible to read to the common person and yet reveal their secrets
to the initiated - just remember the code displayed in the Matrix...

Python takes all of that away. It is just too readable. Even
beginners can quickly learn to read code written by experts.

To make it even friendlier to beginners, Python uses ugly double
underscores both as prefix and suffix on "magic methods" to be invoked
only by more advanced programmers. What's the fun in hiding the
complexity so that beginners can stay away from potential problems.

And why, oh why, does raw_input() have to go? Here was at least one
good example of something that gave a hint (what does "raw" mean?) at
the underlying complexity. Combined with the evil of the hidden eval
in the more obvious input(), there was at least a chance to trip
beginners into doing something "dangerous". Alas, that will no longer
be the case...

Python does not even make good use of weird symbols like $ and @ and %
to define variable types like Perl does. Now, that's a language to
learn if you want to be respected. I think that Georg Brandl had it
right in his recent proposal:
http://mail.python.org/pipermail/pyt...il/072419.html

If not Perl, perhaps Python should be inspired by a language like C++,
full of arcane stuff and, thankfully, requiring typing declaration.
This dynamic typing thing makes it just too easy to write working
programs quickly, especially combined with the ease of use of the
interpreter. And this other thing called "duck typing" is just too
flexible to use.

No, Python should be more difficult. It should take a full two
minutes to compile a "Hello World" program on a modern computer.

Also, this "docstring" business has to go. Any programmer should, as
a rite of passage, have to spend countless hours reading obscure
documentation to learn other people's code before finding out what
methods can be used and how they should be used. Having to use things
like "dir" and "help" just makes it too easy.

And don't get me started about the absence of curly braces to define
blocks of code. What's the fun in making it so darn visually easy to
define such blocks of code, removing the possibility of creating
subtle bugs due to the misplacement of a curly bracket. No sir, with
Python, the structure has to be obvious at a glance - newbies can see
it just as well as experts, thereby decreasing the aura surrounding
the latter. This is not fair for people that have spent dozens of
hours in learning to program using Python!

And don't talk to me about functions, classes and methods, not to
mention modules. Python makes it too easy to write code in many
different styles, trying to please people who like to write only
object-oriented code as well as those that follow the more traditional
procedural approach. Even "functional" type people find their way to
write code in their preferred method using Python. This is not right.

Fortunately, Python has incorporated some newbie-unfriendly features,
like metaclasses and, to a lesser extent, decorators which, at last,
make use of a special character. There should be more of these, to
make Python something more challenging to learn.

Programming should be more difficult than this - otherwise, how can
programmers be respected by the common folks?
---
André

Apr 28 '07 #1
Share this Question
Share on Google+
40 Replies


P: n/a
Programming should be more difficult than this - otherwise, how can
programmers be respected by the common folks?
the answer is very simple (even more simple than Python ;-) ...
.... create what common folks ask for !!

cheers,
Stef Mientki
Apr 28 '07 #2

P: n/a
Everyone know that programming is supposed to be a dark art, nearly
impossible to learn. Computer code is supposed to be something
impossible to read to the common person and yet reveal their secrets
to the initiated - just remember the code displayed in the Matrix...
Hmm, on my PyCon mug there are words "Python: so easy...even your BOSS
can use it!"
Thankfully, my boss doesn't know the difference between directories
and files, so I can easily succeed in making him think that Python
really IS a black art :)

Cheers
-Basilisk96

Apr 28 '07 #3

P: n/a
André wrote:
I'm really annoyed at Python - and not for the reasons already
mentioned on this list.

Everyone know that programming is supposed to be a dark art, nearly
impossible to learn. Computer code is supposed to be something
impossible to read to the common person and yet reveal their secrets
to the initiated - just remember the code displayed in the Matrix...

Python takes all of that away. It is just too readable. Even
beginners can quickly learn to read code written by experts.

To make it even friendlier to beginners, Python uses ugly double
underscores both as prefix and suffix on "magic methods" to be invoked
only by more advanced programmers. What's the fun in hiding the
complexity so that beginners can stay away from potential problems.

And why, oh why, does raw_input() have to go? Here was at least one
good example of something that gave a hint (what does "raw" mean?) at
the underlying complexity. Combined with the evil of the hidden eval
in the more obvious input(), there was at least a chance to trip
beginners into doing something "dangerous". Alas, that will no longer
be the case...

Python does not even make good use of weird symbols like $ and @ and %
to define variable types like Perl does. Now, that's a language to
learn if you want to be respected. I think that Georg Brandl had it
right in his recent proposal:
http://mail.python.org/pipermail/pyt...il/072419.html

If not Perl, perhaps Python should be inspired by a language like C++,
full of arcane stuff and, thankfully, requiring typing declaration.
This dynamic typing thing makes it just too easy to write working
programs quickly, especially combined with the ease of use of the
interpreter. And this other thing called "duck typing" is just too
flexible to use.

No, Python should be more difficult. It should take a full two
minutes to compile a "Hello World" program on a modern computer.

Also, this "docstring" business has to go. Any programmer should, as
a rite of passage, have to spend countless hours reading obscure
documentation to learn other people's code before finding out what
methods can be used and how they should be used. Having to use things
like "dir" and "help" just makes it too easy.

And don't get me started about the absence of curly braces to define
blocks of code. What's the fun in making it so darn visually easy to
define such blocks of code, removing the possibility of creating
subtle bugs due to the misplacement of a curly bracket. No sir, with
Python, the structure has to be obvious at a glance - newbies can see
it just as well as experts, thereby decreasing the aura surrounding
the latter. This is not fair for people that have spent dozens of
hours in learning to program using Python!

And don't talk to me about functions, classes and methods, not to
mention modules. Python makes it too easy to write code in many
different styles, trying to please people who like to write only
object-oriented code as well as those that follow the more traditional
procedural approach. Even "functional" type people find their way to
write code in their preferred method using Python. This is not right.

Fortunately, Python has incorporated some newbie-unfriendly features,
like metaclasses and, to a lesser extent, decorators which, at last,
make use of a special character. There should be more of these, to
make Python something more challenging to learn.

Programming should be more difficult than this - otherwise, how can
programmers be respected by the common folks?
---
André
I want to complain about the fact that I wrote 200 lines the other day
and it worked first time. Problem was, I spent 20 minutes before I
realized that the lack of errors was a result of the lack of bugs.
Apr 28 '07 #4

P: n/a
In article <11**********************@l77g2000hsb.googlegroups .com>,
=?iso-8859-1?B?QW5kcuk=?= <an***********@gmail.comwrote:
>
Programming should be more difficult than this - otherwise, how can
programmers be respected by the common folks?
http://www.netfunny.com/rhf/jokes/98...troustrup.html
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"...string iteration isn't about treating strings as sequences of strings,
it's about treating strings as sequences of characters. The fact that
characters are also strings is the reason we have problems, but characters
are strings for other good reasons." --Aahz
Apr 28 '07 #5

P: n/a
James Stroud <js*****@mbi.ucla.eduwrote:
André wrote:
[snipping total repost of André's post]
I'm really annoyed at Python - and not for the reasons already
mentioned on this list.

Everyone know that programming is supposed to be a dark art, nearly
impossible to learn. Computer code is supposed to be something
impossible to read to the common person and yet reveal their secrets
to the initiated - just remember the code displayed in the Matrix...

Python takes all of that away. It is just too readable. Even
beginners can quickly learn to read code written by experts.

To make it even friendlier to beginners, Python uses ugly double
underscores both as prefix and suffix on "magic methods" to be invoked
only by more advanced programmers. What's the fun in hiding the
complexity so that beginners can stay away from potential problems.

And why, oh why, does raw_input() have to go? Here was at least one
good example of something that gave a hint (what does "raw" mean?) at
the underlying complexity. Combined with the evil of the hidden eval
in the more obvious input(), there was at least a chance to trip
beginners into doing something "dangerous". Alas, that will no longer
be the case...

Python does not even make good use of weird symbols like $ and @ and %
to define variable types like Perl does. Now, that's a language to
learn if you want to be respected. I think that Georg Brandl had it
right in his recent proposal:
http://mail.python.org/pipermail/pyt...il/072419.html

If not Perl, perhaps Python should be inspired by a language like C++,
full of arcane stuff and, thankfully, requiring typing declaration.
This dynamic typing thing makes it just too easy to write working
programs quickly, especially combined with the ease of use of the
interpreter. And this other thing called "duck typing" is just too
flexible to use.

No, Python should be more difficult. It should take a full two
minutes to compile a "Hello World" program on a modern computer.

Also, this "docstring" business has to go. Any programmer should, as
a rite of passage, have to spend countless hours reading obscure
documentation to learn other people's code before finding out what
methods can be used and how they should be used. Having to use things
like "dir" and "help" just makes it too easy.

And don't get me started about the absence of curly braces to define
blocks of code. What's the fun in making it so darn visually easy to
define such blocks of code, removing the possibility of creating
subtle bugs due to the misplacement of a curly bracket. No sir, with
Python, the structure has to be obvious at a glance - newbies can see
it just as well as experts, thereby decreasing the aura surrounding
the latter. This is not fair for people that have spent dozens of
hours in learning to program using Python!

And don't talk to me about functions, classes and methods, not to
mention modules. Python makes it too easy to write code in many
different styles, trying to please people who like to write only
object-oriented code as well as those that follow the more traditional
procedural approach. Even "functional" type people find their way to
write code in their preferred method using Python. This is not right.

Fortunately, Python has incorporated some newbie-unfriendly features,
like metaclasses and, to a lesser extent, decorators which, at last,
make use of a special character. There should be more of these, to
make Python something more challenging to learn.

Programming should be more difficult than this - otherwise, how can
programmers be respected by the common folks?
---
André

I want to complain about the fact that I wrote 200 lines the other day
and it worked first time. Problem was, I spent 20 minutes before I
realized that the lack of errors was a result of the lack of bugs.
Apr 28 '07 #6

P: n/a
Hmm, on my PyCon mug there are words "Python: so easy...even your BOSS
can use it!"
Oh man! I would've killed for a mug like that a year ago. I was
working for this guy, who had the entire build process automated
in .BAT scripts. We spent more time fixing the build process than
devoloping our product.

Anyway, I started to move the entire thing to Python. Using a real
programming language, allows creating a more robust process. It also
allows separating data and code, which comes very handy when the data
changes to not have to touch the code.

So a year ago, I moved to another department. I would not get into the
details of why, but I am just going to say that I'm much happier now.
One day, I walking down the hall, and I see a book in my old boss'
desk: "Learning Perl." I thought to my self, "You gotta be kiddin". So
I saw him in the coffee area, and I asked him about it. His answer
was, "Yeah, I'm re-writing the build scripts in Perl because you are
the only one that knew Python, and we need to maintain them."

Well, there is no-one in that team that knows Perl either, and if they
haven't been able to learn Python in the couple of years I tried to
push it, I really doubt they are going to learn Perl. Or maybe, the
problem was that I was trying to push Python, so they are doing this
just to prove me wrong.

Like I said, I'm much happier now, and so much glad to be out of that
team.

Thanks,

- Isaac.

Apr 30 '07 #7

P: n/a
James Stroud a écrit :
(snip)
>
I want to complain about the fact that I wrote 200 lines the other day
and it worked first time. Problem was, I spent 20 minutes before I
realized that the lack of errors was a result of the lack of bugs.
+1 QOTW
May 2 '07 #8

P: n/a
I rewrote my code in Python and I found myself running into many of the
same hassles that I run into with other languages: inaccurate and
incomplete documentation, a maze of little platform-specific quirks to
work around in the base classes, and a macho community of users.

The python web site recommended Dive Into Python, so I learned by
reading that. It has several examples that don't work because the
Python base classes have changed behavior. I should have taken that as
lesson.

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.

I installed Cygwin on a Windows machine. I try to quit from an
interactive Python session. It tells me that on my platform, I must
press Control-Z to exit. I press Control-Z and it makes Python a
background process.

I tried to use the XML.minidom. The documentation here is minimal as
well. So I read up on other web sites. It turns out that the interface
has changed quite a bit from the documentation I found on other web
sites. Where are the much loved docstrings? In 2.3 minidom, they are
sparse and cryptic.

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.

I decided to make a tkinter front-end for a Python program. I decided
to go with tkinter because it is included with many Python
installations, so it maximizes the chance for my program to run out of
the box.

The tkinter documentation on the Python site mainly consists of loose
notes and links to other sites. The documentation on other sites is
great, if you already know how to use tkinter. I ran into bugs in
TkAqua which make the grid layout unusable for me. So I will need to
ask potential users to install Xcode, X11, and mac ports, if they want
to run my program.

In short, there is plenty of room for improvement. Admittedly these are
not problems with the language definition. But I downloaded a Python
distribution, and the problems are Python specific.
May 3 '07 #9

P: n/a
On 3 Mai, 15:49, Ben Collver <coll...@peak.orgwrote:
I rewrote my code in Python and I found myself running into many of the
same hassles that I run into with other languages: inaccurate and
incomplete documentation, a maze of little platform-specific quirks to
work around in the base classes, and a macho community of users.
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.
The python web site recommended Dive Into Python, so I learned by
reading that. It has several examples that don't work because the
Python base classes have changed behavior. I should have taken that as
lesson.
Really Dive Into Python should be a sufficient guide, and it was
perhaps the best introduction to the language when it was written. It
is very unfortunate that the language has changed in a number of ways
(and exhibits continued change) whilst effort into documenting what is
already there remains neglected amongst the people making all the
changes.
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.
I installed Cygwin on a Windows machine. I try to quit from an
interactive Python session. It tells me that on my platform, I must
press Control-Z to exit. I press Control-Z and it makes Python a
background process.
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.
I tried to use the XML.minidom. The documentation here is minimal as
well. So I read up on other web sites. It turns out that the interface
has changed quite a bit from the documentation I found on other web
sites. Where are the much loved docstrings? In 2.3 minidom, they are
sparse and cryptic.
I really don't know what to say about the PyXML/xmlcore situation. I
don't use ElementTree and hardly use PyXML or minidom, but something
really should have been done about the maintenance of the established
libraries rather than declaring them as legacy items and pretending
that they don't exist.
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.
I decided to make a tkinter front-end for a Python program. I decided
to go with tkinter because it is included with many Python
installations, so it maximizes the chance for my program to run out of
the box.

The tkinter documentation on the Python site mainly consists of loose
notes and links to other sites. The documentation on other sites is
great, if you already know how to use tkinter. I ran into bugs in
TkAqua which make the grid layout unusable for me. So I will need to
ask potential users to install Xcode, X11, and mac ports, if they want
to run my program.
Take a look at the python.org Wiki for links to other resources on
Tkinter:

http://wiki.python.org/moin/TkInter

Or consider other graphical frameworks:

http://wiki.python.org/moin/GuiProgramming
In short, there is plenty of room for improvement. Admittedly these are
not problems with the language definition. But I downloaded a Python
distribution, and the problems are Python specific.
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?

http://www.google.com/search?q=%22th...bout+Python%22

Paul

May 3 '07 #10

P: n/a
On May 3, 9:27 am, Paul Boddie <p...@boddie.org.ukwrote:
On 3 Mai, 15:49, Ben Collver <coll...@peak.orgwrote:
I rewrote my code in Python and I found myself running into many of the
same hassles that I run into with other languages: inaccurate and
incomplete documentation, a maze of little platform-specific quirks to
work around in the base classes, and a macho community of users.

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.
The python web site recommended Dive Into Python, so I learned by
reading that. It has several examples that don't work because the
Python base classes have changed behavior. I should have taken that as
lesson.

Really Dive Into Python should be a sufficient guide, and it was
perhaps the best introduction to the language when it was written. It
is very unfortunate that the language has changed in a number of ways
(and exhibits continued change) whilst effort into documenting what is
already there remains neglected amongst the people making all the
changes.
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.
I installed Cygwin on a Windows machine. I try to quit from an
interactive Python session. It tells me that on my platform, I must
press Control-Z to exit. I press Control-Z and it makes Python a
background process.

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.
I tried to use the XML.minidom. The documentation here is minimal as
well. So I read up on other web sites. It turns out that the interface
has changed quite a bit from the documentation I found on other web
sites. Where are the much loved docstrings? In 2.3 minidom, they are
sparse and cryptic.

I really don't know what to say about the PyXML/xmlcore situation. I
don't use ElementTree and hardly use PyXML or minidom, but something
really should have been done about the maintenance of the established
libraries rather than declaring them as legacy items and pretending
that they don't exist.
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.
I decided to make a tkinter front-end for a Python program. I decided
to go with tkinter because it is included with many Python
installations, so it maximizes the chance for my program to run out of
the box.
The tkinter documentation on the Python site mainly consists of loose
notes and links to other sites. The documentation on other sites is
great, if you already know how to use tkinter. I ran into bugs in
TkAqua which make the grid layout unusable for me. So I will need to
ask potential users to install Xcode, X11, and mac ports, if they want
to run my program.

Take a look at the python.org Wiki for links to other resources on
Tkinter:

http://wiki.python.org/moin/TkInter

Or consider other graphical frameworks:

http://wiki.python.org/moin/GuiProgramming
In short, there is plenty of room for improvement. Admittedly these are
not problems with the language definition. But I downloaded a Python
distribution, and the problems are Python specific.

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?

http://www.google.com/search?q=%22th...bout+Python%22

Paul
I agree with Paul and Ben. The Docs need some help. Some are excellent
and others are hosed because of changes to the language. I started
with Tkinter, but quickly got frustrated with the lack of
documentation or screwy out-dated docs. What really annoys me is that
some very good authors state that Tkinter has excellent docs and
multiple published books. I found one book by Grayson that is 7 years
old. So I switched to wxPython.

wxPython has a better user group and better docs. Unfortunately, they
also have quite a few man pages, as do other external modules and man
pages typically make my eyes swim.

The closest thing to real docs by a real person for Python is Lundh's
site: http://effbot.org/librarybook/

Fortunately, since Python is so easy, some of this can be overcome.

Mike

May 3 '07 #11

P: n/a
Ben Collver wrote:
I rewrote my code in Python and I found myself running into many of the
same hassles that I run into with other languages: inaccurate and
incomplete documentation, a maze of little platform-specific quirks to
work around in the base classes, and a macho community of users.
That's about typical. I've had much the same experiences, but
with a completely different set of external packages. I was doing
a web application in Linux; this user was doing a desktop
app on Windows. Yet he's reporting much the same kinds of quality
problems I noticed.

In general, the libraries outside of the core are not well
maintained. The user communities are small and bug reports can
take years to resolve.
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.
That's the problem with bug reporting systems which let developers
close bugs arbitrarily. Defect reporting systems should have a status
for "developer in denial".

Bug handling in loosely managed projects tends to follow the
same path as the "stages of grief": denial, anger, bargaining,
depression, and acceptance. Getting through the process requires
a year or so.

There's an integration problem with the CPython implementation.
The mechanism for supporting extensions in other languages does not
have a tightly defined API which remains constant across versions.
Thus, C extensions are tied to a specific version of CPython compiled
with a specific compiler. There's no effort by the core Python
development group to keep third-party extensions in sync with the core,
so whenever a new core version comes out, many third party extensions
are unusuable with it for some months. The integration problem is
dumped on the third party extension developers. Most of the items
the user here is complaining about fall into that category.
In short, there is plenty of room for improvement. Admittedly these are
not problems with the language definition. But I downloaded a Python
distribution, and the problems are Python specific.
That's the usual observation. The language is in good shape, but
the libraries are not. Python is better than Perl, but CPAN is better
than Cheese Shop.

John Nagle
May 3 '07 #12

P: n/a
André wrote:
Fortunately, Python has incorporated some newbie-unfriendly features,
like metaclasses and, to a lesser extent, decorators which, at last,
make use of a special character. There should be more of these, to
make Python something more challenging to learn.
After reading the entire post about Python's ease of use, I find this
particular paragraph especially pointed. :)

I guess all the previous points about Python's features helps to show
how these other things (decorators, etc.) really stand out as perhaps
being un-Pythonic? At least, to me, it was an interesting way to make
that argument.
May 3 '07 #13

P: n/a

"John Nagle" <na***@animats.comwrote in message
news:Ee*****************@newssvr14.news.prodigy.ne t...
| Ben Collver wrote:
|| from the person who closed it. I get the unspoken message: bug
reports
| are not welcome.
|
| That's the problem with bug reporting systems which let developers
| close bugs arbitrarily.

I think you should have looked at the actual tracker item, the evidence,
before responding, instead of relying on a misleading claim. The item was
closed as invalid three week after an explantion was given with no response
from the OP. The link is in my response.

| Defect reporting systems should have a status for "developer in denial".

The willingness of bystanders like you to trash volunteers with random
hobby horses is one reason there are fewer volunteers than needed.

| Bug handling in loosely managed projects tends to follow the
| same path as the "stages of grief": denial, anger, bargaining,
| depression, and acceptance.

Blah, blah. Not as profound as you seem to think.

| Getting through the process requires a year or so.

Ben got a respond in 3 days.

Terry Jan Reedy



May 3 '07 #14

P: n/a

"Ben Collver" <co*****@peak.orgwrote in message
news:Fb******************************@scnresearch. com...
|I rewrote my code in Python and I found myself running into many of the
| same hassles that I run into with other languages: inaccurate and
| incomplete documentation, a maze of little platform-specific quirks to
| work around in the base classes, and a macho community of users.

Including you.

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

Misleading and untrue. Here is the link you omitted
http://sourceforge.net/tracker/index...70&atid=105470

www.python.org/sf/1678102

Three days after you posted, 'gagenellina' explained that he thought your
complaint was invalid.
"py-531560245 & 0xffffffff
3763407051L

It's the same number (actually, the same bit pattern). ..."

A few weeks later, noticing that you had not challenged his explanation, I
closed after changing the Resolution box to Invalid. THAT WAS MY COMMENT.

A month later, I notice that you still have not directly challenged G's
claim of invalidity. Instead, you ignored it and simply repeated your
claim here. WHO IS IGNORING WHO?

| I get the unspoken message: bug reports are not welcome.

Giving the shortage of reviewer time, invalid bug reports on tracker are a
nuisance and a diversion from attending to valid reports and reviewing
patches. That is why I encourage people to post here for community review.

Real bug reports are quite welcome, as any honest person could determine by
looking thru the tracker.

Terry Jan Reedy

May 3 '07 #15

P: n/a
* Paul Boddie (3 May 2007 07:27:11 -0700)
On 3 Mai, 15:49, Ben Collver <coll...@peak.orgwrote:
I installed Cygwin on a Windows machine. I try to quit from an
interactive Python session. It tells me that on my platform, I must
press Control-Z to exit. I press Control-Z and it makes Python a
background process.

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.
He was using /Windows/ Python in Cygwin *chuckle*... Windows Python
says Ctrl-Z because it doesn't know that it's been run from bash where
Ctrl-Z is for job control.

And the lesson we learn from that: if you're using Windows Python use
a Windows shell. If you're using a Cygwin shell use Cygwin Python -
unless you know what you're doing (which he wasn't).
Thorsten
May 3 '07 #16

P: n/a
Terry Reedy wrote:
"John Nagle" <na***@animats.comwrote in message
news:Ee*****************@newssvr14.news.prodigy.ne t...
| Ben Collver wrote:
|| from the person who closed it. I get the unspoken message: bug
reports
| are not welcome.
>
| Getting through the process requires a year or so.

Ben got a respond in 3 days.
He didn't actually need anything fixed.

John Nagle
May 3 '07 #17

P: n/a
En Thu, 03 May 2007 10:49:26 -0300, Ben Collver <co*****@peak.org>
escribió:
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.
You got a comment from me, that you never disputed nor commented further.
I would have changed the status to "invalid" myself, if I were able to do
so.
I installed Cygwin on a Windows machine. I try to quit from an
interactive Python session. It tells me that on my platform, I must
press Control-Z to exit. I press Control-Z and it makes Python a
background process.
Maybe because you were running Windows Python from inside a bash prompt?
The Cygwin version tells you to use the right key combination to exit.
In short, there is plenty of room for improvement. Admittedly these are
not problems with the language definition. But I downloaded a Python
distribution, and the problems are Python specific.
Yes, some documentation is a bit outdated as Python is evolving
continuously. I prefer that, to a frozen language.

--
Gabriel Genellina
May 4 '07 #18

P: n/a
On May 3, 9:27 pm, "Gabriel Genellina" <gagsl-...@yahoo.com.arwrote:
En Thu, 03 May 2007 10:49:26 -0300, Ben Collver <coll...@peak.org
escribió:
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.

You got a comment from me, that you never disputed nor commented further.
I would have changed the status to "invalid" myself, if I were able to do
so.
I think it should have been marked as "won't fix" as it's a wart just
like
1/2 == 0, but as there are many users of the current behaviour it's
"impossible"
to fix it in Python 2.x. Maybe in Python 3.0?

-- Leo

May 4 '07 #19

P: n/a
Thorsten Kampe <th******@thorstenkampe.dewrote:
He was using /Windows/ Python in Cygwin *chuckle*... Windows Python
says Ctrl-Z because it doesn't know that it's been run from bash where
Ctrl-Z is for job control.

And the lesson we learn from that: if you're using Windows Python use
a Windows shell. If you're using a Cygwin shell use Cygwin Python -
unless you know what you're doing (which he wasn't).
I've noticed in the past that using cygwin python under a cygwin shell
is broken in some subtle ways when building extensions. Using the
windows python build in a windows command windows always works though
(with mingw as the compiler).

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick
May 4 '07 #20

P: n/a
Thorsten Kampe <th******@thorstenkampe.dewrote:
>He was using /Windows/ Python in Cygwin *chuckle*... Windows Python
says Ctrl-Z because it doesn't know that it's been run from bash where
Ctrl-Z is for job control.
No, if you run Windows Python from Cygwin bash CTRL-Z works as the
EOF character:

~$ /cygdrive/e/util/python24/python
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>quit
'Use Ctrl-Z plus Return to exit.'
>>^Z
~$ jobs
~$ python
Python 2.5 (r25:51908, Mar 13 2007, 08:13:14)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>quit
Use quit() or Ctrl-D (i.e. EOF) to exit
>>>
[1]+ Stopped python
~$

Apparently though the Cygwin version of Python now prints the correct
message for quit.

Ross Ridge

--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rr****@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
May 4 '07 #21

P: n/a
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
May 4 '07 #22

P: n/a
On 5/4/07, Ben Collver <co*****@peak.orgwrote:
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
May 4 '07 #23

P: n/a
Terry Reedy wrote:
Three days after you posted, 'gagenellina' explained that he thought your
complaint was invalid.
"py-531560245 & 0xffffffff
3763407051L

It's the same number (actually, the same bit pattern). ..."

A few weeks later, noticing that you had not challenged his explanation, I
closed after changing the Resolution box to Invalid. THAT WAS MY COMMENT.

A month later, I notice that you still have not directly challenged G's
claim of invalidity. Instead, you ignored it and simply repeated your
claim here. WHO IS IGNORING WHO?
...
Real bug reports are quite welcome, as any honest person could determine by
looking thru the tracker.
Hi Terry,

I understand and agree that the number was the same bit pattern. I
don't remember being asked to challenge this. I must have missed the
status change notification.

I do wonder whether the diagnosis is accurate: is the sparc64 port
actually using an unsigned int where the i386 port is using a signed int?

Either way, I don't see how it reflects on the validity of the report.
I reported that the resulting numbers were different. To me that seems
a trap for the unwary.

All I saw was a comment on what might cause my problem, and then I saw
that the problem report was closed. Now I am told that I didn't even
file a real bug report. I don't know whether to take that as "this is a
trivial problem not worth reporting" or "this is a poorly filed bug report".

I am an honest person, honestly!

Ben
May 4 '07 #24

P: n/a
Thorsten Kampe wrote:
He was using /Windows/ Python in Cygwin *chuckle*... Windows Python
says Ctrl-Z because it doesn't know that it's been run from bash where
Ctrl-Z is for job control.

And the lesson we learn from that: if you're using Windows Python use
a Windows shell. If you're using a Cygwin shell use Cygwin Python -
unless you know what you're doing (which he wasn't).
The reason I tried to do this: Cygwin python lacks _winreg, but I wanted
to SSH into Cygwin to run this script.

I suppose the folks who know what they are doing probably stick to
wscript and WMI for this sort of stuff.

Ben
May 4 '07 #25

P: n/a
Chris Mellon wrote:
#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 generally use IRC for idle chat and mulling over problems, and I
realize it would be the wrong place to ask for a change. At the time I
was talking about XML in the Python library. I was informed that I was
unwise to read 3rd party documentation for the Python library. I get
"Don't complain about documentation we didn't write" instead of "Yeah
it's broken, use pyxml instead."
>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"?
I made a mistake when I first read the response: it does not drop any bits.

In the bug report itself, I saw a diagnosis of my problem's cause, and
then I saw the bug report closed as invalid. I did not know why the bug
was flagged invalid and closed, because I received no comment from the
person who closed it. I assumed that I should not have filed the bug
report.

Feedback in this newsgroup names my bug report as a "hobby horse", a
"wart", and "not a real bug report". I apologize for this noise over
such a small issue. It is clear now that real bug reports are welcome.
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.
I am unqualified to comment on the Python philosophy, but I would like
for my function to do some basic error checking on its arguments. I
will read up on the Python philosophy.

Ben
May 4 '07 #26

P: n/a
Ben Collver wrote:
Chris Mellon wrote:
>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.

I am unqualified to comment on the Python philosophy, but I would like
for my function to do some basic error checking on its arguments.
By "basic error checking" I mean "verify that the file argument actually
is a file-like object". By same interface, do you mean that I should
check for the methods that I depend on? That sounds easy enough.

Thanks for the hint,

Ben
May 4 '07 #27

P: n/a
On 5/4/07, Ben Collver <co*****@peak.orgwrote:
Ben Collver wrote:
Chris Mellon wrote:
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.
I am unqualified to comment on the Python philosophy, but I would like
for my function to do some basic error checking on its arguments.

By "basic error checking" I mean "verify that the file argument actually
is a file-like object". By same interface, do you mean that I should
check for the methods that I depend on? That sounds easy enough.
You should "check" for the methods by calling them. If the object
doesn't support the method in question, you will get a runtime
exception. Premature inspection of an object is rarely useful and
often outright harmful.
May 4 '07 #28

P: n/a
Ant
On May 4, 3:17 pm, Ben Collver <coll...@peak.orgwrote:
Chris Mellon wrote:
....
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.

I am unqualified to comment on the Python philosophy, but I would like
for my function to do some basic error checking on its arguments. I
will read up on the Python philosophy.
The basic point here is that the code will do it's own error checking.
If you pass in a string to your function, and it tries to call
write("xxx") on it, then you will get an exception thrown:

AttributeError: 'str' object has no attribute 'write

If your goal is to provide feedback to a potential user that they are
using the wrong arguments, then you can use something like the
following (the "Easier to ask for forgiveness than for permission"
idiom):
>>arg = "A String not a File"
try:
.... arg.write("")
.... except AttributeError:
.... print "You need to pass in a file like object!"
....
You need to pass in a file like object!
May 4 '07 #29

P: n/a
Chris Mellon wrote:
You should "check" for the methods by calling them. If the object
doesn't support the method in question, you will get a runtime
exception. Premature inspection of an object is rarely useful and
often outright harmful.
That makes sense, thank you for the response.

What about the case where I have an array of objects that represent some
particular binary file format. If the object is a file, then I want to
copy its contents. If the object is a string, then I want to write the
string. And so forth.

Should I assume that an object is file-like if it has a read method, and
that I can call the read method without unexpected side effects?

Ben
May 4 '07 #30

P: n/a
Chris Mellon <ar*****@gmail.comwrote:
I am unqualified to comment on the Python philosophy, but I would like
for my function to do some basic error checking on its arguments.
By "basic error checking" I mean "verify that the file argument actually
is a file-like object". By same interface, do you mean that I should
check for the methods that I depend on? That sounds easy enough.

You should "check" for the methods by calling them. If the object
doesn't support the method in question, you will get a runtime
exception. Premature inspection of an object is rarely useful and
often outright harmful.
However, hoisting method extraction out of the loop is often useful,
because it may speed up operations, and when you do that you might as
well use a try/except AttributeError to provide better diagnostics if
something is missing. E.g., suppose you have a need to slurp away one
char at a time from a file until you get a 'Z':

def readToZ(f):
while True:
c = f.read(1)
if c == 'Z': return
elif not c: raise ValueError, "No Z in file f"

this may also raise IOError if the read fails, AttributeError if f does
not have a read method, TypeError (or who knows what) if f.read is not
callable, or does not let you call it with one int argument, etc, etc.

A slightly faster approach:

def readToZ(f):
read = f.read
while True:
c = read(1)
if c == 'Z': return
elif not c: raise ValueError, "No Z in file f"

this has exactly the same exception-behavior as the previous version.
It's hardly an error to tweak that behavior slightly:

def readToZ(f):
try: read = f.read
except AttributeError: raise TypeError, "%s has no read" % type(f)
while True:
c = read(1)
if c == 'Z': return
elif not c: raise ValueError, "No Z in file f"

going to horrid amounts of trouble to check that the call to read(1)
won't produce weird failures would be unwarranted, but making one case
of AttributeError into a TypeError in this way is quite OK, for example.
Alex
May 4 '07 #31

P: n/a
Ben Collver <co*****@peak.orgwrote:
Chris Mellon wrote:
You should "check" for the methods by calling them. If the object
doesn't support the method in question, you will get a runtime
exception. Premature inspection of an object is rarely useful and
often outright harmful.

That makes sense, thank you for the response.

What about the case where I have an array of objects that represent some
particular binary file format. If the object is a file, then I want to
copy its contents. If the object is a string, then I want to write the
string. And so forth.
"Type-switching" in this way is a rather dubious practice in any
language (it can't respect the "open-closed" principle). Can't you have
those objects wrapped in suitable wrappers with a "copyorwrite" method
that knows what to do? For example, StringIO.StringIO is a standard
library wrapper type that makes a string look like a file.

It's a reasonable request you can make to whatever code is putting stuff
in that container: make the container "weakly homogeneous" by having it
stuffed only with "suitably file-like" objects. Dealing with totally
and weirdly heterogeneous containers is not a sensible task, because
there will be infinite types that COULD be in the container and about
which your code just can't be expected to guess right what to do.
Alex
May 4 '07 #32

P: n/a
Alex Martelli wrote:
"Type-switching" in this way is a rather dubious practice in any
language (it can't respect the "open-closed" principle). Can't you have
those objects wrapped in suitable wrappers with a "copyorwrite" method
that knows what to do? For example, StringIO.StringIO is a standard
library wrapper type that makes a string look like a file.
That is very reasonable. Thanks again,

Ben
May 4 '07 #33

P: n/a
* Ben Collver (Fri, 04 May 2007 06:40:50 -0700)
Thorsten Kampe wrote:
He was using /Windows/ Python in Cygwin *chuckle*... Windows Python
says Ctrl-Z because it doesn't know that it's been run from bash where
Ctrl-Z is for job control.

And the lesson we learn from that: if you're using Windows Python use
a Windows shell. If you're using a Cygwin shell use Cygwin Python -
unless you know what you're doing (which he wasn't).

The reason I tried to do this: Cygwin python lacks _winreg, but I wanted
to SSH into Cygwin to run this script.

I suppose the folks who know what they are doing probably stick to
wscript and WMI for this sort of stuff.
No, they stick to Python and WMI for this sort of stuff:
http://tgolden.sc.sabren.com/python/wmi.html
May 4 '07 #34

P: n/a

"Ben Collver" <co*****@peak.orgwrote in message
news:Ov******************************@scnresearch. com...
| Hi Terry,
|
| I understand and agree that the number was the same bit pattern.

OK

| I don't remember being asked to challenge this.

You don't need an invitation to disagree with another person's tracker
comment. I assumed you knew this and took non-response as acquiesence.
That (closing no response by item submitter) is a fairly typical pattern ,
by the way. I wish it were otherwise.

| I must have missed the status change notification.

The SF item-change emails indicate the changes, but you have to look.

| I do wonder whether the diagnosis is accurate: is the sparc64 port
| actually using an unsigned int where the i386 port is using a signed int?

I have no idea. I was essentially acting on GG's behalf since I know him
to be techically competent and stronly suspected (correctly, it turns out)
that could not put the close button himself.

| Either way, I don't see how it reflects on the validity of the report.

A bug is a discrepancy between promise and performance

| I reported that the resulting numbers were different.

I understand CRC checks to produce bit patterns rather than 'numbers'.

| To me that seems a trap for the unwary.

That is a different issue. If, for instance, you think the docs could and
should be improved to make people more wary, reopen the item, change the
appropriate field to 'documentation' and please give a suggested addition
or change.

| All I saw was a comment on what might cause my problem,

I understood (correctly, as it turns out) GG as saying 'invalid'.

| and then I saw that the problem report was closed.

Think of GG and I as a team acting as one. I had nothing to add and other
bug reports to attend to.

| Now I am told that I didn't even file a real bug report.

Invalid reports are more common than I wish. We try to be polite and
accurate in rejecting them. Once a seemingly competant judgement is made
in this direction, the ball is in the submitter's court, so to speak.

| don't know whether to take that as "this is a
| trivial problem not worth reporting" or "this is a poorly filed bug
report".

Your choice. See above.

| I am an honest person, honestly!

I can see that there was some non-understanding both ways, which is why I
have tried to clarify things.

Terry Jan Reedy

May 5 '07 #35

P: n/a

"Ben Collver" <co*****@peak.orgwrote in message
news:Cu******************************@scnresearch. com...

| In the bug report itself,

See my other response to you.

| Feedback in this newsgroup names my bug report as a "hobby horse",

That was not directed as you but the claim by someone else that I and other
reviewers are in the 'denial' stage of the 5 Stages of Grieving.

tjr

May 5 '07 #36

P: n/a
Ben Collver <co*****@peak.orgwrote:
>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.
The workaround doesn't drop any bits, it converts the value to a Python
long and extracts the lower 32 bits.

There's really no good reason for Python to give two different results
here. It should either return a signed 32-bit CRC value in a Python int,
or return a unsigned 32-bit CRC value in either Python long or a Python
int, if it's big enough. What it's doing now, returning unsigned value in
a Python int, even when it's not big enough to hold the result, is wrong.

Ross Ridge

--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rr****@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
May 5 '07 #37

P: n/a
Terry Reedy wrote:
You don't need an invitation to disagree with another person's tracker
comment. I assumed you knew this and took non-response as acquiesence.
That (closing no response by item submitter) is a fairly typical pattern ,
by the way. I wish it were otherwise.
I (incorrectly) took the comment to support rather than invalidate my
report, and did not see anything to challenge. Email is not 100%
reliable, but I understand you don't have the time to hound submitters.
Do you think it might help to ask a question when you expect a
response from the submitter? It might act as a prompt.
That is a different issue. If, for instance, you think the docs could and
should be improved to make people more wary, reopen the item, change the
appropriate field to 'documentation' and please give a suggested addition
or change.
I trust the experts to take the appropriate action. It seems equally
reasonable to ignore the report for its triviality, or to treat the
checksum as a long, since that is what zlib returns.

Ben
May 5 '07 #38

P: n/a
On Fri, 04 May 2007 07:55:25 -0700, Alex Martelli wrote:
>What about the case where I have an array of objects that represent some
particular binary file format. If the object is a file, then I want to
copy its contents. If the object is a string, then I want to write the
string. And so forth.

"Type-switching" in this way is a rather dubious practice in any
language (it can't respect the "open-closed" principle).
What do people think about functions that accept either a file name or a
file object?
def handle_file(obj):
if type(obj) == str:
need_to_close = True
obj = file(obj, 'r')
else:
need_to_close = False
do_something_with(obj.read())
if need_to_close:
data.close()
Good idea? Bad idea? Just a matter of personal preference?

--
Steven.

May 5 '07 #39

P: n/a
Steven D'Aprano wrote:
>
What do people think about functions that accept either a file name or a
file object?
def handle_file(obj):
if type(obj) == str:
need_to_close = True
obj = file(obj, 'r')
else:
need_to_close = False
do_something_with(obj.read())
if need_to_close:
data.close()
Good idea? Bad idea? Just a matter of personal preference?
I sometimes write functions like this myself. However, the matter of
testing for file-like objects can obviously vary somewhat in terms of
personal preference and correctness. Some would argue that this is a
situation which would benefit from interfaces:

if isinstance(obj, FileLike): # or obj.implements(FileLike), perhaps
do_something_with(obj.read())

In the original example, we can intuitively see that a file-like
object need only support the read and close methods, and in the case
of receiving a file-like object, only the read method need exist on
the object. Consequently, we can write the following:

if hasattr(obj, "read"):
do_something_with(obj.read())

Some would rightly say that this is ridiculous: you're testing
something which will be discovered straight away. However, there can
be situations where you might want to know in advance whether the
object is suitable, especially if you may perform more than one kind
of operation on the object and where side-effects may occur - the "let
the code fail" attitude arguably doesn't hold up very well in such
cases.

The problem can then be framed in terms of being able to express the
set of required operations and whether something like interfaces is a
flexible enough means of doing so. We might have something like this:

if test_for_file(obj):
do_something_with(obj) # not the string but the object itself

Now, we have the choice of explicitly phrasing the test ourselves...

def test_for_file(obj):
return hasattr(obj, "read") and hasattr(obj, "close") # and ...

....or relying on an interface mechanism to do this for us, with the
possible additional overhead of declaring such interface usage when
defining or adopting classes.

It seems to me that there's a gulf between the use of interfaces, with
the cost of introducing declarations in the code and the benefit of
relatively easy verification of object "capabilities", and the current
situation where one might like to try and deduce the required
capabilities of an object at any given point in the code. Without
interfaces, such verification is difficult but there's less overhead
for the programmer; with interfaces, verification is easier but the
programmer has to work harder to do most of the work. I can't really
see a good compromise.

Paul

May 5 '07 #40

P: n/a
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:
...
What do people think about functions that accept either a file name or a
file object?

def handle_file(obj):
if type(obj) == str:
need_to_close = True
obj = file(obj, 'r')
else:
need_to_close = False
do_something_with(obj.read())
if need_to_close:
data.close()

Good idea? Bad idea? Just a matter of personal preference?
Acceptable as an idea, but a disaster in terms of this specific
implementation (as coded, it would reject a Unicode string, or any other
string-like object, for example). Also, if all you're going to do with
the file is .read() it in one big gulp, there's no real advantage to
this approach, either.

Assuming the way you're going to use the file-like object is subtler
(e.g., loop line by line so that huge files can be processed without
overwhelming memory), then a better implementation may be warranted:

def handle_file(file_or_path):
try:
f = open(file_or_path)
finis = f.close
except TypeError:
f = file_or_path
def finis(): pass
try:
for line in f:
...
finally:
finis()

This version accepts anything that open is happy with, or else any
sequence of lines, including but not limited to a file or file-like
object open for reading. Now this, it seems to me, is a helpful
approach to polymorphism.
Alex
May 6 '07 #41

This discussion thread is closed

Replies have been disabled for this discussion.