Re: My Python annoyances
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: My Python annoyances
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 -- http://mail.python.org/mailman/listinfo/python-list
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 -- http://mail.python.org/mailman/listinfo/python-list
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 -- http://mail.python.org/mailman/listinfo/python-list
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 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 -- http://mail.python.org/mailman/listinfo/python-list
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: My Python annoyances
Terry Reedy wrote: > Three days after you posted, 'gagenellina' explained that he thought your > complaint was invalid. > "py> -531560245 & 0x > 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: My Python annoyances
Paul Boddie wrote: > I'm sorry to hear about that. If by "macho" you mean people who insist > that things are good enough as they are, and that newcomers should > themselves adapt to whatever they may discover, instead of things > being improved so that they are more intuitive and reliable for > newcomers and experienced developers alike, then I'd certainly be > interested in undermining that culture. That was the sort of response I got on freenode #python, which I realize I should not take as representative of the whole community. Thank you for the thoughtful response. >> I tried to write portable Python code. The zlib CRC function returned >> different results on architectures between 32 bit and 64 bit >> architectures. I filed a bug report. It was closed, without a comment >> from the person who closed it. I get the unspoken message: bug reports >> are not welcome. > > Can you provide the bug identifier? Bug reports are generally welcome, > and despite complaints about patch reviews, I've found people > reviewing things I've submitted. It is problem report #1678102. I understand the problem: that a 32 bit number looks different in a 32 bit signed int than in a 64 bit signed int. However, the workaround of dropping a bit seems to defeat the purpose of using a CRC. > Yes, Ctrl-Z exits Python in the standard Windows edition. Since Cygwin > provides a POSIX-like environment, Ctrl-D should be used instead. If > the documentation is wrong, a bug report or patch should be filed > against the software. This morning I could not reproduce the problem. When the user types "quit" at the Python prompt, the Cygwin port instructs the user to press Control-D, which works. Even if you SSH in to Cygwin, and run the win32 port, it instructs the user to press Control-Z plus Return, which works. Maybe it was fixed after I had the problem. >> Between 2.4 and 2.5, tempfile returns a different type of object. My >> code cannot have a single test, it has check for type(obj) == file or >> obj.__class__ == tempfile._TemporaryFileWrapper. > > Try using isinstance or relying on "deeper" knowledge of how the > object will be used. Thank you for the hint. I just want my function to validate that one of its arguments is a file-like object. It isn't necessarily going to be a temporary file, but it might be. >>> import temporaryfile >>> t = tempfile.TemporaryFile() >>> isinstance(t, file) False > My opinions, already expressed, include the observation that the core > development community is more interested in extending the language > than in strengthening the standard library (and its documentation). It > should be noted that the proposed standard library reorganisation, > which is a very conservative affair, has actually been postponed until > after the release of Python 3.0a1 according to a message I read > recently. And yet, if you read people's lists about what they "hate" > about Python (amongst actual users of Python), guess which thing > almost always comes up? I guess you cannot blame folks for working on what they find interesting. Ben -- http://mail.python.org/mailman/listinfo/python-list
Re: Python user group in Portland, OR?
bradallen wrote: > I would be happy to meet with you and any other Portland Python > programmers to talk about ideas for organizing a user group. > There is also some good discussion about it on the Python Advocacy > the mailing list, because PSF has begun an effort to foster and > promote > user groups. I don't use Ruby, but I read the blog of a dude in Portland who went to the Ruby user group. He said that the programmers there spent as much time talking about Python and Perl as they did about Ruby, so you might be interested in that. Ben -- http://mail.python.org/mailman/listinfo/python-list
Re: My Python annoyances
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: osx tkinter listbox problem
James Stroud wrote: > A "cross platform" work-around might be to grid a frame at the row and > column of self.Main and pack the Listbox into the Frame. I don't have a > Mac at work to test this, however. But I would be curious to know your > results if you try it. Thank you for the sub-frame suggestion. I tried, but it didn't help. Ben -- http://mail.python.org/mailman/listinfo/python-list
osx tkinter listbox problem
I am using Darwin 10.4.9, tcl 8.4.7, tk 8.4, and python 2.3.5. I have also tried Python 2.5 on Darwin, Debian, and Fedora Core 6. I am working on a GUI front-end to a Python program of mine. It is a simple grid with labels in the left column and input widgets in the right column. One of the rows has a listbox in the right column. The listbox contains two items. I select one using widget.select_set(). The GUI is not complete yet, because I am still learning about Python and Tkinter. On Linux, the GUI works as expected. On OSX, when select_set() runs, the listbox disappears from its place in the grid, and appears in the upper left corner of the window. Here are screen shots to illustrate. http://terrorpin.net/~ben/docs/alt/music/soundfont/pysf-wip/pysfi-debian.jpg http://terrorpin.net/~ben/docs/alt/music/soundfont/pysf-wip/pysfi-osx.png The GUI code itself is at the following location. http://terrorpin.net/~ben/docs/alt/music/soundfont/pysf-wip/pysfi.py To run, it needs the Python program at the following location. http://terrorpin.net/~ben/docs/alt/music/soundfont/pysf-wip/pysf.py Why does the listbox change position at all? Am I using listbox incorrectly? Thank you, Ben -- http://mail.python.org/mailman/listinfo/python-list
