> > what about adding a docopy=True (or dont_copy=False) to all > > methods that could be both copy_generative and modify-in-place? > > via some generic self=self.copy_if_required() func? > > Then one can choose at which point to split+copy > > well if you have switches that are dynamically modifying the > central paradigm of the API, that suggests you arent too sure about > that API.
well... sooner or later u'll have mostly generative methods (which is, copying/cloning+extras), and then someone may need a faster modify-in-place version. say, by a special (metaclass or decorating) wrapper i could make a cloning version from any inplace one; but i cannot do it viceversa - if u make the cloning one the base. This wrapper/decorator can go in SA interfaces if u wish - where there is alternative. For some methods the cloning version will be official, for others - the inplace one. another way is the command pattern, cloning some very_cheap object, but i dont think it is very usable here. > also that approach doesnt really solve this problem > since the goal is to execute just one query with many features > combined. it is not about solving some particular problem, it's just a "generic" way to modify/extend the API without really changing the look of it. so u dont end with manualy made filter_inplace() and filter_clone() one day.. Actualy inspired by the other thread about the inplace append_whereclause(). ciao svil --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
