[Python-Dev] Issue 6081: format string using mapping rather than kwargs

2010-03-24 Thread Filip Gruszczyński
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

2010-03-25 Thread Filip Gruszczyński
> 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

2010-03-25 Thread Filip Gruszczyński
>> 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

2008-11-30 Thread Filip Gruszczyński
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

2008-11-30 Thread Filip Gruszczyński
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

2008-11-30 Thread Filip Gruszczyński
> 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

2008-11-30 Thread Filip Gruszczyński
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

2008-11-30 Thread Filip Gruszczyński
> 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

2008-12-01 Thread Filip Gruszczyński
> 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

2008-12-08 Thread Filip Gruszczyński
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

2008-12-08 Thread Filip Gruszczyński
> 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