Re: [Python-Dev] Py2.6 ideas
More thoughts on named tuples after trying-out all of Michele's suggestions: * The lowercase 'namedtuple' seemed right only because it's a function, but as a factory function, it is somewhat class-like. In use, 'NamedTuple' more closely matches my mental picture of what is happening and distinguishes what it does from the other two entries in collections, 'deque' and 'defaultdict' which are used to create instances instead of new types. * I remembered why the __repr__ function had a 'show' argument. I've changed the name now to make it more clear and added a docstring. The idea was the some use cases require that the repr exactly match the default style for tuples and the optional argument allowed for that possiblity with almost no performance hit. The updated recipe is at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/500261 Raymond ___ 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] Py2.6 ideas
Thanks for the comments.
Will experiment with them and get back to you..
The alternate naming is fine. At work, we call it ntuple().
The constructor signature has been experimented with
several time and had best results in its current form
which allows the *args for casting a record set returned
by SQL or by the CSV module as in Point(*fetchall(s)),
and it allows for direct construction with Point(2,3) without the
slower and weirder form: Point((2,3)). Also, the current signature
works better with keyword arguments: Point(x=2, y=3) or
Point(2, y=3) which wouldn't be common but would be
consistent with the relationship between keyword arguments
and positional arguments in other parts of the language.
The string form for the named tuple factory was arrived at
because it was easier to write, read, and alter than its original
form with a list of strings:
Contract = namedtuple('Contract stock strike volatility expiration rate
iscall')
vs.
Contract = namedtuple('Contract', 'stock', 'strike', 'volatility',
'expiration', 'rate', 'iscall')
That former is easier to edit and to re-arrange. Either form is trivial to
convert
programmatically to the other and the definition step only occurs once while the
use of the new type can appear many times throughout the code.
Having experimented with both forms, I've found the string form to
be best thought it seems a bit odd. Yet, the decision isn't central to
the proposal and is still an open question.
The __module__ idea is nice. Will add it. Likewise with pickling.
The 'show' part of __repr__ was done for speed (localized access
versus accessing the enclosing scope. Will rename it to _show
to make it clear that it is not part of the API.
Thanks for the accolades and the suggestions.
Raymond
- Original Message -
From: "Michele Simionato" <[EMAIL PROTECTED]>
To:
Sent: Monday, February 19, 2007 9:25 PM
Subject: Re: [Python-Dev] Py2.6 ideas
> Raymond Hettinger verizon.net> writes:
>> * Add a pure python named_tuple class to the collections module. I've been
>> using the class for about a year and found that it greatly improves the
>> usability of tuples as records.
>> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/500261
>
> The implementation of this recipe is really clean and I like it a lot
> (I even think of including it in our codebase), but there are a few issues
> that I would like to point out.
>
> 1. I find the camelcase confusing and I think that NamedTuple should be
> spelled namedtuple, since is a function, not a class. The fact that it
> returns classes does not count ;)
>
> 2. I agree with Giovanni Bajo, the constructor signature should be consistent
> with regular tuples. For instance I want to be able to map a named tuple
> over a record set as returned by fetchall.
>
> 3. I would like to pass the list of the fields as a sequence, not as
> a string. It would be more consistent and it would make easier
> the programmatic creation of NamedTuple classes at runtime.
>
> 4. I want help(MyNamedTuple) to work well; in particular it should
> display the right module name. That means
> that in the m dictionary you should add a __module__ attribute:
>
>__module__ = sys._getframe(1).f_globals['__name__']
>
> 5. The major issue is that pickle does work with named tuples since the
> __module__ attribute is wrong. The suggestion in #4 would solve even
> this issue for free.
>
> 6. The ability to pass a show function to the __repr__ feems over-engineering
> to me.
>
> In short, here is how I would change the recipe:
>
> import sys
> from operator import itemgetter
>
> def namedtuple(f):
>"""Returns a new subclass of tuple with named fields.
>
>>>> Point = namedtuple('Point x y'.split())
>>>> Point.__doc__ # docstring for the new class
>'Point(x, y)'
>>>> p = Point((11,), y=22) # instantiate with positional args or keywords
>>>> p[0] + p[1] # works just like the tuple (11, 22)
>33
>>>> x, y = p# unpacks just like a tuple
>>>> x, y
>(11, 22)
>>>> p.x + p.y # fields also accessable by name
>33
>>>> p # readable __repr__ with name=value style
>Point(x=11, y=22)
>
>"""
>typename, field_names = f[0], f[1:]
>nargs = len(field_names)
>
>def __new__(cls, args=(), **kwds):
>if kwds:
>try:
>args += tuple(kwds[name] for name in field_names[len(args):])
>except KeyError, name:
>raise TypeError(
>'%s missing required argument: %s' % (typename, name))
>if len(args) != nargs:
>raise TypeError(
>'%s takes exactly %d arguments (%d given)' %
>(typename, nargs, len(args)))
>return tuple.__new__(cls, args)
>
>template = '%s(%s)' % (
>typename, ', '.join('%s=%%r' % name for name in field_names))
>
>def __repr__(self):
>
Re: [Python-Dev] Lack of sequential decompression in the zipfile module
On 2/17/07, Alan McIntyre <[EMAIL PROTECTED]> wrote: > I ran into the same thing and made a patch a long while ago (the one > Martin mentioned): > > https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_id=5470 > > I am actually working on it this weekend; if you'd like to exchange > code/test cases/whatever feel free to send me your stuff. I'll try to > get a patch that works against the trunk posted today or tomorrow if > you want to try it out. Derek mentioned something that hadn't occurred to me: adding ZipFile.open() is helpful, but if we don't provide something analogous to TarFile.extract, anybody wanting to just extract a file from an archive to disk will have to write their own "get and write chunks from the file object" loop. Since this is likely to be a common task, it makes sense to me to provide this capability in the ZipFile class with an extract method that takes an optional path argument (defaulting to the working directory + path for file in archive). I'll add this to the patch unless somebody greatly disagrees or has a better idea. ___ 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] Py2.6 ideas
Raymond Hettinger verizon.net> writes:
> * Add a pure python named_tuple class to the collections module. I've been
> using the class for about a year and found that it greatly improves the
> usability of tuples as records.
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/500261
The implementation of this recipe is really clean and I like it a lot
(I even think of including it in our codebase), but there are a few issues
that I would like to point out.
1. I find the camelcase confusing and I think that NamedTuple should be
spelled namedtuple, since is a function, not a class. The fact that it
returns classes does not count ;)
2. I agree with Giovanni Bajo, the constructor signature should be consistent
with regular tuples. For instance I want to be able to map a named tuple
over a record set as returned by fetchall.
3. I would like to pass the list of the fields as a sequence, not as
a string. It would be more consistent and it would make easier
the programmatic creation of NamedTuple classes at runtime.
4. I want help(MyNamedTuple) to work well; in particular it should
display the right module name. That means
that in the m dictionary you should add a __module__ attribute:
__module__ = sys._getframe(1).f_globals['__name__']
5. The major issue is that pickle does work with named tuples since the
__module__ attribute is wrong. The suggestion in #4 would solve even
this issue for free.
6. The ability to pass a show function to the __repr__ feems over-engineering
to me.
In short, here is how I would change the recipe:
import sys
from operator import itemgetter
def namedtuple(f):
"""Returns a new subclass of tuple with named fields.
>>> Point = namedtuple('Point x y'.split())
>>> Point.__doc__ # docstring for the new class
'Point(x, y)'
>>> p = Point((11,), y=22) # instantiate with positional args or keywords
>>> p[0] + p[1] # works just like the tuple (11, 22)
33
>>> x, y = p# unpacks just like a tuple
>>> x, y
(11, 22)
>>> p.x + p.y # fields also accessable by name
33
>>> p # readable __repr__ with name=value style
Point(x=11, y=22)
"""
typename, field_names = f[0], f[1:]
nargs = len(field_names)
def __new__(cls, args=(), **kwds):
if kwds:
try:
args += tuple(kwds[name] for name in field_names[len(args):])
except KeyError, name:
raise TypeError(
'%s missing required argument: %s' % (typename, name))
if len(args) != nargs:
raise TypeError(
'%s takes exactly %d arguments (%d given)' %
(typename, nargs, len(args)))
return tuple.__new__(cls, args)
template = '%s(%s)' % (
typename, ', '.join('%s=%%r' % name for name in field_names))
def __repr__(self):
return template % self
m = dict(vars(tuple)) # pre-lookup superclass methods (for faster lookup)
m.update(__doc__= '%s(%s)' % (typename, ', '.join(field_names)),
__slots__ = (),# no per-instance dict
__new__ = __new__,
__repr__ = __repr__,
__module__ = sys._getframe(1).f_globals['__name__'],
)
m.update((name, property(itemgetter(index)))
for index, name in enumerate(field_names))
return type(typename, (tuple,), m)
if __name__ == '__main__':
import doctest
TestResults = namedtuple(['TestResults', 'failed', 'attempted'])
print TestResults(doctest.testmod())
___
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] Wrapping up 'dynamic attribute' discussion
I wrote: > I've sent an updated version of PEP 363 to the editors, which > includes the following summary of the discussion. I hope I've > captured the important points, but please let me know if there's > something important I've left out or misrepresented. There were a couple of points made off-list, which I've incorporated. The final version of the PEP is now with the editors. Ben. ___ 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] A Survey on Defect Management Practices in Free/Open Source Software
Hi Python developers I seek help from designers, developers, testers,defect fixers,project managers or playing any other key role in Free/Open Source software development or maintenence in carrying out a study to identify practices and problems of defect management in various Free/Open Source Software projects. The insights gained from the study can further help us to extract publicly accessible defect data and determine impact of defect management practices on software quality. Please spend a few minutes of your precious time to fill up the Questionnaire. The most of the questions follow multiple choice formats and are quite easy to answer. To have the Online Questionnaire, please visit: http://anu.puchd.ac.in/phpESP/public/survey.php?name=FOSS_Defect_Survey (You can also copy and paste this link into your browser, and hit the 'Return' key.) I hope you will find all the questions interesting and thought-provoking. Your answers will be kept anonymous.The data thus collected will only be used for research purpose.It would be nice if you may further refer this mail to others actively engaged with Free/Open Source Software development. If you have any query or suggestions then feel free to contact. Thank You With regards, Anu Gupta Senior Lecturer Department of Computer Science and Applications, Panjab University, Chandigarh. INDIA In case of any problem in accessing/using the above mentioned link please contact: E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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
