Hi, then intention of my first mail was to start a discussion about this topic about the pros and cons and possible alternatives. As long as it is not clear that recordclass or something like that is accepted to be implemented to the collections module I do not want to spend any effort on this. My wish that the collections module gets something like namedtuple, but writable, is based on my personal experience when projects are becoming bigger and data structures more complex it is sometimes useful to named items and not just an index. This improves the readability and makes development and maintenance of the code easier. Another important topic for me is performance. When I write applications then they should finish their tasks quickly. The performance of recordclass was one reason for me to use it (some benchmarks with Python 2 can be found on here https://gist.github.com/grantjenks/a06da0db18826be1176c31c95a6ee572). I've done some more recent and additional benchmarks with Python 3.7 on Linux which you can find here https://github.com/brmmm3/compare-recordclass. These new benchmarks show that namedtuple is as fast as recordclass in all cases, but with named attribute access. Named attribute access is faster with recordclass. Compared to dataclass: dataclass wins only on the topic object size. When it comes to speed and functionality (indexing, sorting) dataclass would be my last choice. Yes it is possible to make dataclass fast by using __slots__, but this always an extra programming effort. namedtuple and recordclass are easy to use with small effort. Adding new items: This is not possible with namedtuple and also not possible with recordclass. I see no reason why a namedlist should support this, because with these object types you define new object types and these types should not change. I hope 3.8 will get a namedlist and maybe it will be the recordclass module (currently my choice). As the author of this module already has responded to this discussion I hope he willing to contribute his code to the Python project. Best regards, Martin

This feels really useful to me to make some quick changes to a database - perhaps a database layer could return an class of type Recordclass, and then you just simply mutate it and shove it back into the database. Pseudocode: record = database.execute("SELECT * FROM mytable WHERE primary_key = 15") record.mostRecentLoggedInTime = time.time() database.execute(f"UPDATE mytable SET mostRecentLoggedInTime = {record.mostRecentLoggedInTime} WHERE primary_key = {record.primary_key}":) Or any smart database wrapper might just go: database.updateOrInsert(table = mytable, record = record) And be smart enough to figure out that we already have a primary key unequal to some sentinel value like None, and do an update, while it could do an insert if the primary key WAS some kind of sentinel value. which is something I really wanted to do in the past with namedTuples, but had to use dicts for instead. Also, it's rather clear that namedList is a really bad name for a Recordclass. It's cleary not intended to be a list. It's a record you can take out from somewhere, mutate, and push back in. We often use namedTuples as records now, but we can't just mutate those to shove them back in - you have to make new ones, and unless you write a smart wrapper for database handling yourself, you can't just shove them in either. Recordclass could be the gateway drug to a smart database access layer that reduces the amount of SQL we need to write - and that's a good thing in my opinion.

On Mon, Sep 3, 2018 at 3:25 AM Jacco van Dorp wrote:

This feels really useful to me to make some quick changes to a database - perhaps a database layer could return an class of type Recordclass, and then you just simply mutate it and shove it back into the database. Pseudocode:

record = database.execute("SELECT * FROM mytable WHERE primary_key = 15") record.mostRecentLoggedInTime = time.time() database.execute(f"UPDATE mytable SET mostRecentLoggedInTime = {record.mostRecentLoggedInTime} WHERE primary_key = {record.primary_key}":)

Or any smart database wrapper might just go:

database.updateOrInsert(table = mytable, record = record)

And be smart enough to figure out that we already have a primary key unequal to some sentinel value like None, and do an update, while it could do an insert if the primary key WAS some kind of sentinel value.

SQLAlchemy.orm solves for this (with evented objects with evented attributes): http://docs.sqlalchemy.org/en/latest/orm/session_state_management.html#sessi... - Transient, Pending, Persistent, Deleted, Detached http://docs.sqlalchemy.org/en/latest/orm/session_api.html#sqlalchemy.orm.att... - flag_modified isn't necessary in most cases because attribute mutation on mapped classes deriving from Base(declarative_base()) is evented http://docs.sqlalchemy.org/en/latest/orm/session_events.html#attribute-chang... http://docs.sqlalchemy.org/en/latest/orm/tutorial.html There are packages for handling attribute states with the Django ORM, as well: - https://github.com/romgar/django-dirtyfields - https://github.com/Suor/django-dirty What would be the performance impact of instead subclassing from recordclass? IDK. pyrsistent.PRecord(PMap) is immutable and supports .attribute access: https://github.com/tobgu/pyrsistent#precord

On Mon, Sep 3, 2018 at 4:17 AM Chris Angelico wrote:

...

This feels really useful to me to make some quick changes to a database - perhaps a database layer could return an class of type Recordclass, and

On Mon, Sep 3, 2018 at 5:23 PM, Jacco van Dorp wrote: then

...

you just simply mutate it and shove it back into the database. Pseudocode:

record = database.execute("SELECT * FROM mytable WHERE primary_key = 15") record.mostRecentLoggedInTime = time.time() database.execute(f"UPDATE mytable SET mostRecentLoggedInTime = {record.mostRecentLoggedInTime} WHERE primary_key = {record.primary_key}":)

Or any smart database wrapper might just go:

database.updateOrInsert(table = mytable, record = record)

And be smart enough to figure out that we already have a primary key unequal to some sentinel value like None, and do an update, while it could do an insert if the primary key WAS some kind of sentinel value.

In its purest form, what you're asking for is an "upsert" or "merge" operation:

https://en.wikipedia.org/wiki/Merge_(SQL)

In a multi-user transactional database, there are some fundamentally hard problems to implementing a merge. I'm not 100% certain, so I won't say "impossible", but it is certainly *extremely difficult* to implement an operation like this in application-level software without some form of race condition.

http://docs.sqlalchemy.org/en/latest/orm/contextual.html#contextual-thread-l... - scoped_session http://docs.sqlalchemy.org/en/latest/orm/session_state_management.html#mergi... http://docs.sqlalchemy.org/en/latest/orm/session_basics.html obj = ExampleObject(attr='value') assert obj.id is None session.add(obj) session.flush() assert obj.id is not None session.commit()

On Mon, Sep 3, 2018 at 4:40 AM Chris Angelico wrote:

On Mon, Sep 3, 2018 at 6:31 PM, Wes Turner wrote:

...

On Mon, Sep 3, 2018 at 4:17 AM Chris Angelico wrote:

...

On Mon, Sep 3, 2018 at 5:23 PM, Jacco van Dorp wrote:

...

This feels really useful to me to make some quick changes to a

database

...

...

...

- perhaps a database layer could return an class of type Recordclass, and then you just simply mutate it and shove it back into the database. Pseudocode:

record = database.execute("SELECT * FROM mytable WHERE primary_key = 15") record.mostRecentLoggedInTime = time.time() database.execute(f"UPDATE mytable SET mostRecentLoggedInTime = {record.mostRecentLoggedInTime} WHERE primary_key = {record.primary_key}":)

Or any smart database wrapper might just go:

database.updateOrInsert(table = mytable, record = record)

And be smart enough to figure out that we already have a primary key unequal to some sentinel value like None, and do an update, while it could do an insert if the primary key WAS some kind of sentinel value.

In its purest form, what you're asking for is an "upsert" or "merge" operation:

https://en.wikipedia.org/wiki/Merge_(SQL)

In a multi-user transactional database, there are some fundamentally hard problems to implementing a merge. I'm not 100% certain, so I won't say "impossible", but it is certainly *extremely difficult* to implement an operation like this in application-level software without some form of race condition.

http://docs.sqlalchemy.org/en/latest/orm/contextual.html#contextual-thread-l...

...

- scoped_session

http://docs.sqlalchemy.org/en/latest/orm/session_state_management.html#mergi...

...

http://docs.sqlalchemy.org/en/latest/orm/session_basics.html

obj = ExampleObject(attr='value') assert obj.id is None session.add(obj) session.flush() assert obj.id is not None session.commit()

Yep. What does it do if it's on a back-end database that doesn't provide a merge/upsort intrinsic? What if you have a multi-column primary key? There are, of course, easier sub-forms of this (eg you mandate that the PK be a single column and be immutable), but if there is any chance that any other client might simultaneously be changing the PK of your row, a perfectly reliable upsert/merge basically depends on the DB itself providing that functionality.

There's yet another argument for indeed, immutable surrogate primary keys. With appropriate foreign key constraints, changing any part of the [composite] PK is a really expensive operation because all references must also be updated (w/ e.g. ON UPDATE CASCADE), and that doesn't fix e.g. existing URLs or serialized references in cached JSON documents. Far better, IMHO, to just enforce a UNIQUE constraint on those column(s). UUIDs don't require a central key allocation service (such as AUTOINCREMENT, which is now fixed in MySQL AFAIU);. Should the __hash__() of a recordclass change when attributes are modified? http://www.attrs.org/en/stable/hashing.html has a good explanation. In general, neither .__hash__() nor id(obj) are good candidates for a database primary key because when/if there are collisions (birthday paradox) -- e.g. when an INSERT or UPSERT or INSERT OR REPLACE fails -- it has to change. Sorry getting OT, something like COW immutability is actually desirable with SQL databases, too. Database backups generally require offline intervention in order to rollback; if there's even a backup which contains those transactions. https://en.wikipedia.org/wiki/Temporal_database#Implementations_in_notable_p... (SELECT, ) https://django-reversion.readthedocs.io/en/stable/

ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Zaur Shibzukhov wrote:

`Recordclass` is defined on top of` memoryslots` just like `namedtuple` above` tuple`. Attributes are accessed via a descriptor (`itemgetset`), which supports both` __get__` and `__set__` by the element index.

As a result, `recordclass` takes up as much memory as` namedtuple`, it supports quick access by `__getitem__` /` __setitem__` and by attribute name via the protocol of the descriptors.

I'm not sure why you need a new C-level type for this. Couldn't you get the same effect just by using __slots__? e.g. class C: __slots__ = ('attr_1', ..., 'attr_m') def __new __ (cls, attr_1, ..., attr_m): self.attr_1 = attr_1 ... self.attt_m = attr_m -- Greg