[ python-Bugs-1000299 ] Make type system extensible

noreply at pgfoundry.org noreply at pgfoundry.org
Sun Feb 25 20:59:13 UTC 2007


Bugs item #1000299, was opened at 2005-04-28 01:16
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000299&group_id=1000094

Category: BE/TEOP
Group: To do
>Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: James Pye (jwp)
Assigned to: James Pye (jwp)
Summary: Make type system extensible

Initial Comment:
Give Postgres.Type a __metaclass__ to allow classes that inherit from it the ability to act as a type interface override.

This would ideally provide things such as:

class bytea(Postgres.Type):
 oid = Postgres.Const["BYTEAOID"]
 def __new__(subtype, str):
  return Postgres.Object(subtype, str)
 ...

The Postgres.Type metaclass creates a new Postgres.Type and puts it in the cache so later lookups for the type will give the new, custom interface rather than the old and moldy defaults.

This is important as currently all type specific features are hard coded into object.c, eewww.

----------------------------------------------------------------------

>Comment By: James Pye (jwp)
Date: 2007-02-25 13:59

Message:
Done enough. While there may be some specific aspects of this missing, the foundation is available. type specific features are ascribed to their associated type. Postgres.Type is subtype-able.

----------------------------------------------------------------------

Comment By: James Pye (jwp)
Date: 2005-12-31 11:44

Message:
The foundation for this has been set in 0.3. 0.4 or 0.5 will likely have functional extensibility. (0.3 needed to be released). Also, with this, support for a Proboscis type kit will be implemented so that the client can use the backend's type system to serialize and parse the remote end's objects.

----------------------------------------------------------------------

Comment By: James Pye (jwp)
Date: 2005-10-23 01:40

Message:
The foundation for the extensible type system interface has been laid[1]. This provides a more typ/typical like type system interface. PyPgType is PyPgObject's __metaclass__. PyPgType effectively manages the created types and allows lookup via the Lookup classmethod. Custom PostgreSQL types may be created by giving Postgres.Object.__new__. Overrides and such are not yet implemented, so it not yet extensible.

[1] http://archives.postgresql.org/pgsql-committers/2005-10/msg00322.php

----------------------------------------------------------------------

Comment By: James Pye (jwp)
Date: 2005-08-16 15:00

Message:
With some thought, I think that the current type system should be scrapped. isinstance(Postgres.Type[instance], TypeType) being false disallows subtyping via "class foo(super)". In addition, cajoling the current Postgres.Type to be a TypeType and a Datum(Postgres.Object) is mostly impossible. So, I think it best to eventually scrap the current implementation.

What I have in mind would hopefully produce something similar to what I envisioned previously:

class bytea(Postgres.types.Object):
 oid = Postgres.Const["BYTEAOID"]
 def __new__(subtype, input):
  return Postgres.types.Object.__new__(subtype, str)

Here, bytea is a subclass of Postgres.types.Object. Postgres.types.Object has a __metaclass__(Postgres.Type?) that registers the new type at the specified oid in the internal typcache. Abstract Postgres.types.Objects are possible by not specifying an oid.

Also, it might be desirable to have the type implementations in a seperate extension module/package/project.

----------------------------------------------------------------------

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000299&group_id=1000094


More information about the Python-general mailing list