Fast progress

[Daniel Gagnon]

And we already have reify!

Timothy, I'm impressed at the speed at which you are developing this! I'm looking forward to having it available for actual projects!

[Timothy Baldridge]

> Timothy, I'm impressed at the speed at which you are developing this! I'm
> looking forward to having it available for actual projects!

Thanks, but I can't take all the credit. I think we're up to 4-5
active collaborators on this project.

I think the speed that this project is progressing is a great
testament to the power of Python as a platform. Things like defrecord
and proxy are full of "hacks" and complexity in the JVM. In python,
they're basically just classes with a few extra methods tossed in. For
those who don't know, this project was started around Dec 20th, 2011.
So yeah, we're doing really well for only 3 months of development.

Timothy

[Daniel Gagnon]

I think the speed that this project is progressing is a great
testament to the power of Python as a platform. Things like defrecord
and proxy are full of "hacks" and complexity in the JVM. In python,
they're basically just classes with a few extra methods tossed in. For
those who don't know, this project was started around Dec 20th, 2011.
So yeah, we're doing really well for only 3 months of development.

Timothy

I'm impressed by how little friction there is between Python and Clojure. It really is a natural fit.

Especially at using Clojure from Python. Records are to be done soon and I bet they will feel very natural by using python's properties.

[Daniel Gagnon]

 Actually, I think named tuples are an even better fit for records.

[Timothy Baldridge]

>  Actually, I think named tuples are an even better fit for records.

After looking into it, I think you're right. And these may actually
make records extremely fast in some cases on pypy....we'll see.

Timothy

--
“One of the main causes of the fall of the Roman Empire was
that–lacking zero–they had no way to indicate successful termination
of their C programs.”
(Robert Firth)

[Ivan Kozik]

On Tue, Mar 20, 2012 at 14:37, Daniel Gagnon <redal...@gmail.com> wrote:
>> Especially at using Clojure from Python. Records are to be done soon and I
>> bet they will feel very natural by using python's properties.
>
>
>  Actually, I think named tuples are an even better fit for records.

Keep in mind that different namedtuples with the same contents are
equal to each other:

>>> from collections import namedtuple
>>> A = namedtuple('A', 'x y z')
>>> B = namedtuple('B', 'x y z')
>>> A(1, 2, 3) == B(1, 2, 3)
True

records are not:

user=> (defrecord A [x y z])
user.A
user=> (defrecord B [x y z])
user.B
user=> (= (A. 1 2 3) (B. 1 2 3))
false

Ivan

[Daniel Gagnon]

Keep in mind that different namedtuples with the same contents are

equal to each other:

Good point.

I assume that Clojure-Py's = is not Python's == though.

[Timothy Baldridge]

> I assume that Clojure-Py's = is not Python's == though.

Actually it's exactly the same. We generate a COMPARE_OP "==" bytecode.

[Daniel Gagnon]

On Tue, Mar 20, 2012 at 11:13 PM, Timothy Baldridge <tbald...@gmail.com> wrote:

> I assume that Clojure-Py's = is not Python's == though.

Actually it's exactly the same. We generate a COMPARE_OP "==" bytecode.

Then can we fix the issue by subclassing the named tuples and overriding the __eq__ and __ne__ magic methods? 

[Ivan Kozik]

That's probably possible. Remember to add a __slots__ = () in the
subclass as well to avoid creating dict for every namedtuple.

Another possibility is to create namedtuples whose first item is a
per-namedtuple object() marker, making different namedtuples unequal.

Ivan

[Timothy Baldridge]

> That's probably possible. Remember to add a __slots__ = () in the
> subclass as well to avoid creating dict for every namedtuple.
>
> Another possibility is to create namedtuples whose first item is a
> per-namedtuple object() marker, making different namedtuples unequal.

At this point I have to ask "what's the point"? Why not just use
setattr/getattr and copy?

[Daniel Gagnon]

Another possibility is to create namedtuples whose first item is a
per-namedtuple object() marker, making different namedtuples unequal.

I don't like it because it's not friendly to people consuming those objects from Python. 

[Antony Lee]

We don't need to subclass the named tuples (and hence we don't need to take care of __slots__ either).

Point = namedtuple("Point", ["x", "y"])
Point2 = namedtuple("Point2", ["x", "y"])
Point(0, 1) == Point2(0, 1) # true
Point.__eq__ = lambda self, other: type(self) == type(other) and super(Point, self).__eq__(other)
Point(0, 1) == Point2(0, 1) # false

I actually prefer this solution.

Antony