My Python annoyances

[Thorsten Kampe]

Re: My Python annoyances

* Paul Boddie (3 May 2007 07:27:11 -0700)

On 3 Mai, 15:49, Ben Collver <coll...@peak.o rgwrote:

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

[John Nagle]

Re: My Python annoyances

Terry Reedy wrote:

"John Nagle" <nagle@animats. comwrote in message
news:Eep_h.6829 $2v1.1832@newss vr14.news.prodi gy.net...
| 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

[Gabriel Genellina]

Re: My Python annoyances

En Thu, 03 May 2007 10:49:26 -0300, Ben Collver <collver@peak.o rg>
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

[Leo Kislov]

Re: My Python annoyances

On May 3, 9:27 pm, "Gabriel Genellina" <gagsl-...@yahoo.com.a rwrote:

En Thu, 03 May 2007 10:49:26 -0300, Ben Collver <coll...@peak.o rg
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

[Nick Craig-Wood]

Re: My Python annoyances

Thorsten Kampe <thorsten@thors tenkampe.dewrot e:

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 <nick@craig-wood.com-- http://www.craig-wood.com/nick

[Ross Ridge]

Re: My Python annoyances

Thorsten Kampe <thorsten@thors tenkampe.dewrot e:

>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] rridge@csclub.u waterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //

[Ben Collver]

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
>architecture s. 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._Tempo raryFileWrapper .

>
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.Tempor aryFile()
>>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

[Chris Mellon]

Re: My Python annoyances

On 5/4/07, Ben Collver <collver@peak.o rgwrote:

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 characterizatio n 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._Tempo raryFileWrapper .

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.Tempor aryFile()
>>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

>

[Ben Collver]

Re: My Python annoyances

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

[Ben Collver]

Re: My Python annoyances

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

[Ben Collver]

Re: My Python annoyances

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

[Ben Collver]

Re: My Python annoyances

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

[Chris Mellon]

Re: My Python annoyances

On 5/4/07, Ben Collver <collver@peak.o rgwrote:

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.

[Ant]

Re: My Python annoyances

On May 4, 3:17 pm, Ben Collver <coll...@peak.o rgwrote:

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!

[Ben Collver]

Re: My Python annoyances

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