fields 0.2.0

Want tuples ?

Namedtuple alternative:

>>> from fields import Tuple
>>> class Pair(Tuple.a.b):
...     pass
...
>>> p = Pair(1, 2)
>>> p.a
1
>>> p.b
2
>>> tuple(p)
(1, 2)
>>> a, b = p
>>> a
1
>>> b
2

Why ???

It’s less to type, why have quotes around when the names need to be valid symbols anyway.

Really … why ???

Because it’s possible.

But you’re abusing a very well known syntax. You’re using attribute access instead of a list of strings. Why ?

Symbols should be symbols. Why validate strings so they are valid symbols when you can avoid that ? Just use symbols. Dooh !

The use of language constructs is not that surprising - it’s pretty obvious that in field2 of field1 of fields.Fields there can’t possibly be anything else but a class implementing a container for said two fields.

Why would anyone with a brain expect anything else ? It’s like looking at a cake resembling a dog and expecting the cake to bark and run around.

What’s good about this ?

It’s one of the shortest forms possible.

Is this stable ? Is it tested ?

Yes. Mercilessly tested on Travis and AppVeyor.

Is the API stable ?

It can’t get worse can it ;)

Why not namedtuple ?

It’s ugly, repetivive and unflexible. Compare this:

>>> from collections import namedtuple
>>> class MyContainer(namedtuple("MyContainer", ["field1", "field2"])):
...     pass
>>> MyContainer(1, 2)
MyContainer(field1=1, field2=2)

To this:

>>> class MyContainer(Tuple.field1.field2):
...     pass
>>> MyContainer(1, 2)
<MyContainer(field1=1, field2=2)>

Why not characteristic ?

Ugly, inconsistent - you don’t own the class:

Lets try this:

>>> import characteristic
>>> @characteristic.attributes(["field1", "field2"])
... class MyContainer(object):
...     def __init__(self, a, b):
...         if a > b:
...             raise ValueError("Expected %s < %s" % (a, b))
>>> MyContainer(1, 2)
Traceback (most recent call last):
    ...
ValueError: Missing value for 'field1'.

WHAT !? Ok, lets write some more code:

>>> MyContainer(field1=1, field2=2)
Traceback (most recent call last):
    ...
TypeError: __init__() ... arguments...

This is banans. You have to write your class around these quirks.

Lets try this:

>>> class MyContainer(Fields.field1.field2):
...     def __init__(self, a, b):
...         if a > b:
...             raise ValueError("Expected %s < %s" % (a, b))
...         super(MyContainer, self).__init__(a, b)

Just like a normal class, works as expected:

>>> MyContainer(1, 2)
<MyContainer(field1=1, field2=2)>