[Python-Dev] Issue 6081: format string using mapping rather than kwargs
Hello everyone, I was told to bring this issue to python-dev, but I was reluctant to do this until I was confident I can solve the problem. I have managed to provide the patch that works, so now I can talk about how this should be done, just as Eric told me. Here is the link to the ticket: http://bugs.python.org/issue6081. In the issue Raymond Hettinger proposed adding method to string, that would allow to explicitly pass subscriptable object, from which formatting of a string would be done. Two questions arise: 1) whether add such functionality at all? 2) how the method should be called? Should formatting options based on *args be kept (like using {0} in formatted string) or not and how argument should be passed. Eric suggested passing only mapping and only adding *args, if that is found useful by users; I have though about having both mapping and *args, which would keep it similar to the old formatting. Another option is to have *args and one keyword with the mapping (instead of kwargs). I would appreciate any advice on this topic, even if this ticket would be dismissed altogether, as I would like to learn as much as possible on practices on developing Python. -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 6081: format string using mapping rather than kwargs
> From that spec, a straightforward API falls out: > > def format_mapping(self, kwds): > # Method body actually written in C, so it can > # easily invoke the internal formatting operation > return do_string_format(self, NULL, kwds) Thanks a lot for the advice, I'll provide according patch hopefully in the few days. -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 6081: format string using mapping rather than kwargs
>> I'm inclined to leave it alone unless/until Raymond or somebody else >> steps up to really champion it. > > I'm okay with that. And I am looking for another bug, that I could get some python-fu from ;-) -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Attribute error: providing type name
This is my first message in this list, therefore I would like to say hello to everyone. I also hope, that I am not breaking any rules or guidelines for sending proposals. I would like to ask, if it is possible to provide type name of the object invoking the exception, when Attribute error is catched. It is done for functions, like: AttributeError: 'function' object has no attribute 'getValue' but for some objects there is only: AttributeError: connectToBases This is cool, when you know exactly what type of object cast the exception. But if there might be many of them, you must do one of two things: add print statement just before the line with the exception and check the type or iterate over all classes that might appear them. Showing the class name would solve this problem and could save a lot of time. -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
Well, if this is not an inconvenient spot that requires a gross hack to print the type name I'd love to get some instructions or direction, and try to change it myself. Unfortunately it's the first time I looked into Python source and it's pretty big - I tried browsing exceptions.c and errors.c, but couldn't find any simple place, where I could place the required type information. I can of course post it on the bug tracker, but I believe I could learn something on this ;-) And I don't like missing a chance to get a glance at something new. > I'm sure you'll get support for this, unless it's a really > inconvenient spot that requires a gross hack to print the type name. > Post a patch on the bug tracker. > > > -- > Adam Olsen, aka Rhamphoryncus > -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
> I would say this is due to Py_FindMethod being used. > It is a nice and easy function to use, but it fails to set a good > error message so maybe you are experiencing these error messages from > modules that are using it. Yep, found it and it does call PyErr_SetString with proper values. I'll try to change this, without breaking anything. Thanks for help :) -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
I have done some testing and it seems, that it might not be Python problem. Well, when I use only pure Python objects, I get really nice description of the object (which means the type). But I am using PyQt and it seems, that when an object is subclassing QObject (or possibly some other class from qt, that can be not derived from QObject) it can only display information about the name of the function. PyQt are python bindings for C++ qt library. Can this be the reason for not displaying type of the object? 2008/11/30 Nick Coghlan <[EMAIL PROTECTED]>: > Christian Heimes wrote: >> Adam Olsen wrote: >>> I'm sure you'll get support for this, unless it's a really >>> inconvenient spot that requires a gross hack to print the type name. >>> Post a patch on the bug tracker. >> >> So far I can see only one argument against the proposed idea: doc tests. >> The modified exception message would break existing doc tests. > > It wouldn't be the first time we've broken doc tests that way. Since the > details of the error messages aren't guaranteed to remain the same > across releases, doctests that aren't part of Python's own test suite > really should be using IGNORE_EXCEPTION_DETAIL when checking for > exceptions that are raised directly by the interpreter or standard library. > > Cheers, > Nick. > > -- > Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia > --- > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/gruszczy%40gmail.com > -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
> Yeah, any time someone implements their own attribute lookup process for > a class (be it via __getattr__, __getattribute__ or the C equivalents), > it is up to the reimplementation to appropriately format their error > message if they raise AttributeError directly. I guess, this means that I have to go to Phil Thompson at Riverbank and try to convince him to change the message. -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
> Yes, but he should be able to change it in one place (in sip, the C++ > to Python wrapper generator he's also authored and uses for PyQt) AND > it would make sip even better, so he may want to put it on his > backlog. He does. It is supposed to appear in 4.8. So I guess that's it, thanks a lot for your help. -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Self in method body
There is a large discussion on python-list about Guido's article about new self syntax, therefore I would like to use that to raise similar question: self in the body. Some time ago I was coding in Magik language (http://en.wikipedia.org/wiki/Magik_(programming_language), which is dynamically typed and similar to Smalltalk and actually to Python too - although the syntax is far less appalling. As you can see in the examples, defining methods is very similar to what Guido proposed in his blog, though you don't provide the name of the argument, but the name of the class. Then you just precede attributes with a '.', which is 4 letters less than self. And, well, this rocks ;-) It is really not a problem to type 4 letters (well, six with a coma and a space) in the signature, but it takes a lot of time to type all those selfs inside the function's body. So I was thinking, if this issue could be raised too, when new self syntax is proposed. Simple example looks like this: class bar: def bar.foo(): .x = 5 This could really save a lot of code, while attributes are still easily distinguishable. -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Self in method body
> I've just grabbed a random, heavily OO module from my own code library. > It has 60 instances of "self", or 240 characters, out of 18,839 > characters in total (including newlines). Removing self will decrease > the number of my keystrokes and the amount of pure typing time > (excluding thinking time, debugging time) by about 1.2%. I don't call > that "a lot" -- it's actually quite small. And it becomes vanishingly > trivial when you factor in that most of the time spent programming is > not typing but thinking, testing, debugging, etc. Well, maybe I don't program in Python the "right way" ;-), because it's a bit more in my code. I repeated this test, and for a random module holding some GUI stuff (built using PyQt) and it's more than 5% (213 selfs out of 16204 characters). With a small app for creating dungeon tiles for role playing games I astonishingly got same very similar value (484 * 4 / 35000) ;-) Maybe it's a feature of programming with a lot of gui stuff, which I do. But 1 of the 20 chars used for a self is quite a lot for me. -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com