[sqlalchemy] association_proxy usage in non-declarative style
Hello, i am trying to figure out how association_proxy() could be used in case of "regular" rather than declarative style definitions. I can't figure out what can be done to mitigate the issue and hence i seek help here. Thanks in advance... The code below is copy/pasted sample from the official docs without declarative part and when run outputs this: Traceback (most recent call last): File "d.py", line 36, in 'keywords': association_proxy('kw', 'keyword') File "/usr/local/python/3.2/lib/python3.2/site-packages/ SQLAlchemy-0.7.4-py3.2.egg/sqlalchemy/orm/__init__.py", line 1114, in mapper return Mapper(class_, local_table, *args, **params) File "/usr/local/python/3.2/lib/python3.2/site-packages/ SQLAlchemy-0.7.4-py3.2.egg/sqlalchemy/orm/mapper.py", line 201, in __init__ self._configure_properties() File "/usr/local/python/3.2/lib/python3.2/site-packages/ SQLAlchemy-0.7.4-py3.2.egg/sqlalchemy/orm/mapper.py", line 818, in _configure_properties self._configure_property(key, prop, False) File "/usr/local/python/3.2/lib/python3.2/site-packages/ SQLAlchemy-0.7.4-py3.2.egg/sqlalchemy/orm/mapper.py", line 1016, in _configure_property % (key, prop)) sqlalchemy.exc.ArgumentError: keywords= is not an instance of MapperProperty or Column #!/usr/bin/env python3 # -*- coding: utf-8 -*- from sqlalchemy import Column, Integer, String, ForeignKey, Table from sqlalchemy.orm import relationship, mapper from sqlalchemy.ext.associationproxy import association_proxy from sqlalchemy.schema import MetaData metadata = MetaData() class User(): def __init__(self, name): self.name = name class Keyword(): def __init__(self, keyword): self.keyword = keyword user_table = Table('user', metadata, Column('id', Integer, primary_key=True), Column('name', String(64)) ) keyword_table = Table('keyword', metadata, Column('id', Integer, primary_key=True), Column('keyword', String(64)) ) userkeywords_table = Table('userkeywords', metadata, Column('user_id', Integer, ForeignKey("user.id")), Column('keyword_id', Integer, ForeignKey("keyword.id")) ) mapper(Keyword, keyword_table) mapper(User, user_table, properties={ 'kw': relationship(Keyword, secondary=userkeywords_table), 'keywords': association_proxy('kw', 'keyword') }) user = User('jek') user.keywords.append('cheese inspector') print (user.keywords) user.keywords.append('snack ninja') print (user.kw) -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: keyword-only arguments in entity constructor confuse mapper
this is from the entity constructor: def __init__(self, *, login, password): this is the test for initialization with positional arguments: def test_incorrect_instantiation_positional(self): with self.assertRaises(TypeError): User("login", "password") It passes like this just fine and if I'd be to call: User("login", "password") the result is: TypeError: __init__() takes exactly 1 positional argument (3 given) IMHO, it works as expected and positional arguments are explicitly forbidden. Mind you, these tests are not SQLA-aware in any way and mapper will affect the classes, however I am under impression it is not meant to use/affect __init__() and nothing should change in this department. On Aug 5, 6:03 pm, Michael Bayer wrote: > that's actually interesting, does the constructor of your mapped object still > obey the same contract that the "*, x, y" syntax describes ? or can you > suddenly pass "first_name", "last_name" positionally as well ? > > On Aug 5, 2011, at 2:20 AM, Phazorx wrote: > > > > > The patch worked on 0.7.0 and i don't get warning from Python (3.2), > > so it seem to have addressed the issue correctly. > > (Well i don't get same error at least, once i finish with unittests i > > can either confirm or deny lack of side effects) > > Thanks! > > > On Jul 29, 6:38 pm, Michael Bayer wrote: > >> On Jul 29, 2011, at 3:45 AM, Phazorx wrote: > > >>> Most of my entities accept various combinations of parameters and it > >>> makes sense for my to use keyword-only pattern of constructors: > > >>> class Person(Root_Entity): > >>> def __init__(self, session, *, first_name, last_name): > > >>> class Address(Root_Entity): > >>> def __init__(self, session, *, street, building, unit=None, > >>> zip=None, office=None, city="My City", region=None, country="My > >>> Country"): > > >>> however, in this case i get following from python while SQLA figures > >>> out relationships: > >>> ValueError: Function has keyword-only arguments or annotations, > >>> use getfullargspec() API which can support them > > >>> full traceback:http://dpaste.com/hold/581307/ > > >>> Everything is peachy as soon as i get rid of "*," in constructor > >>> obviously... but what can i do to preserve such constructors and still > >>> be able to use SQLA? > > >> So you're using some Python syntax I've never seen before, let's check > >> (checking...OK its new in Python 3, does not appear to be in the language > >> tutorial either, just in the PEP) and in the first case we'd have to use > >> getfullargspec() in that case when Py3 is in use, however we'd also have > >> to interpret the extended tuple returned by getfullargspec() correctly > >> when we establish instrumentation. > > >> If the following patch works, then we could commit once a test is written, > >> though looking at it I'm not optimistic that some significant extra work > >> might be needed to do this correctly. Until then this is an unsupported > >> use case. Ticket #2237 is addedhttp://www.sqlalchemy.org/trac/ticket/2237. > > >> diff -r 87a1dc569235 lib/sqlalchemy/util/compat.py > >> --- a/lib/sqlalchemy/util/compat.py Thu Jul 28 11:53:18 2011 -0400 > >> +++ b/lib/sqlalchemy/util/compat.py Fri Jul 29 10:35:23 2011 -0400 > >> @@ -90,6 +90,11 @@ > >> from urlparse import parse_qsl > > >> if py3k: > >> + from inspect import getfullargspec as inspect_getfullargspec > >> +else: > >> + from inspect import getargspec as inspect_getfullargspec > >> + > >> +if py3k: > >> # they're bringing it back in 3.2. brilliant ! > >> def callable(fn): > >> return hasattr(fn, '__call__') > >> diff -r 87a1dc569235 lib/sqlalchemy/util/langhelpers.py > >> --- a/lib/sqlalchemy/util/langhelpers.py Thu Jul 28 11:53:18 2011 > >> -0400 > >> +++ b/lib/sqlalchemy/util/langhelpers.py Fri Jul 29 10:35:23 2011 > >> -0400 > >> @@ -15,7 +15,7 @@ > >> import sys > >> import types > >> import warnings > >> -from compat import update_wrapper, set_types, threading > >> +from compat import update_wrapper, set_types, threading, > >> inspect_getfullargspec > >> from sqlalchemy import exc > > >>
[sqlalchemy] Re: keyword-only arguments in entity constructor confuse mapper
The patch worked on 0.7.0 and i don't get warning from Python (3.2), so it seem to have addressed the issue correctly. (Well i don't get same error at least, once i finish with unittests i can either confirm or deny lack of side effects) Thanks! On Jul 29, 6:38 pm, Michael Bayer wrote: > On Jul 29, 2011, at 3:45 AM, Phazorx wrote: > > > Most of my entities accept various combinations of parameters and it > > makes sense for my to use keyword-only pattern of constructors: > > > class Person(Root_Entity): > > def __init__(self, session, *, first_name, last_name): > > > class Address(Root_Entity): > > def __init__(self, session, *, street, building, unit=None, > > zip=None, office=None, city="My City", region=None, country="My > > Country"): > > > however, in this case i get following from python while SQLA figures > > out relationships: > > ValueError: Function has keyword-only arguments or annotations, > > use getfullargspec() API which can support them > > > full traceback:http://dpaste.com/hold/581307/ > > > Everything is peachy as soon as i get rid of "*," in constructor > > obviously... but what can i do to preserve such constructors and still > > be able to use SQLA? > > So you're using some Python syntax I've never seen before, let's check > (checking...OK its new in Python 3, does not appear to be in the language > tutorial either, just in the PEP) and in the first case we'd have to use > getfullargspec() in that case when Py3 is in use, however we'd also have to > interpret the extended tuple returned by getfullargspec() correctly when we > establish instrumentation. > > If the following patch works, then we could commit once a test is written, > though looking at it I'm not optimistic that some significant extra work > might be needed to do this correctly. Until then this is an unsupported use > case. Ticket #2237 is addedhttp://www.sqlalchemy.org/trac/ticket/2237. > > diff -r 87a1dc569235 lib/sqlalchemy/util/compat.py > --- a/lib/sqlalchemy/util/compat.py Thu Jul 28 11:53:18 2011 -0400 > +++ b/lib/sqlalchemy/util/compat.py Fri Jul 29 10:35:23 2011 -0400 > @@ -90,6 +90,11 @@ > from urlparse import parse_qsl > > if py3k: > + from inspect import getfullargspec as inspect_getfullargspec > +else: > + from inspect import getargspec as inspect_getfullargspec > + > +if py3k: > # they're bringing it back in 3.2. brilliant ! > def callable(fn): > return hasattr(fn, '__call__') > diff -r 87a1dc569235 lib/sqlalchemy/util/langhelpers.py > --- a/lib/sqlalchemy/util/langhelpers.py Thu Jul 28 11:53:18 2011 -0400 > +++ b/lib/sqlalchemy/util/langhelpers.py Fri Jul 29 10:35:23 2011 -0400 > @@ -15,7 +15,7 @@ > import sys > import types > import warnings > -from compat import update_wrapper, set_types, threading > +from compat import update_wrapper, set_types, threading, > inspect_getfullargspec > from sqlalchemy import exc > > def _unique_symbols(used, *bases): > @@ -149,7 +149,7 @@ > 'apply_pos': '(self, a, b, c, **d)'} > > """ > - spec = callable(fn) and inspect.getargspec(fn) or fn > + spec = callable(fn) and inspect_getfullargspec(fn) or fn > args = inspect.formatargspec(*spec) > if spec[0]: > self_arg = spec[0][0] > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "sqlalchemy" group. > > To post to this group, send email to sqlalchemy@googlegroups.com. > > To unsubscribe from this group, send email to > > sqlalchemy+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] keyword-only arguments in entity constructor confuse mapper
Most of my entities accept various combinations of parameters and it makes sense for my to use keyword-only pattern of constructors: class Person(Root_Entity): def __init__(self, session, *, first_name, last_name): class Address(Root_Entity): def __init__(self, session, *, street, building, unit=None, zip=None, office=None, city="My City", region=None, country="My Country"): however, in this case i get following from python while SQLA figures out relationships: ValueError: Function has keyword-only arguments or annotations, use getfullargspec() API which can support them full traceback: http://dpaste.com/hold/581307/ Everything is peachy as soon as i get rid of "*," in constructor obviously... but what can i do to preserve such constructors and still be able to use SQLA? -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.