On 23.03.2016 09:24, dieter wrote:
But you have observed that you cannot do everything with a
code substitution: a function call does not only depend on the code
but also on other properties of the function object: e.g. the
parameter processing.
Yep, that's because Python is very flexible and p
"Sven R. Kunze" writes:
> ...
> As far as I can see, the code replacement approach solves the problem
> once and for all. Thus is far more stable.
>
> Manually finding out every single module that might or might not have
> imported "reverse" before we could monkeypatch it might result in a
> maint
On 21.03.2016 21:42, Matt Wheeler wrote:
On 20 March 2016 at 16:46, Sven R. Kunze wrote:
On 19.03.2016 00:58, Matt Wheeler wrote:
I know you have a working solution now with updating the code &
defaults of the function, but what about just injecting your function
into the modules that had alre
On 20 March 2016 at 16:46, Sven R. Kunze wrote:
> On 19.03.2016 00:58, Matt Wheeler wrote:
>>
>> I know you have a working solution now with updating the code &
>> defaults of the function, but what about just injecting your function
>> into the modules that had already imported it after the
>> mo
On 19.03.2016 00:58, Matt Wheeler wrote:
I know you have a working solution now with updating the code &
defaults of the function, but what about just injecting your function
into the modules that had already imported it after the
monkeypatching?
Seems perhaps cleaner, unless you'd end up having
On Fri, Mar 18, 2016 at 7:47 AM, Ian Kelly wrote:
> Your patched version takes two extra arguments. Did you add the
> defaults for those to the function's __defaults__ attribute?
And as an afterthought, you'll likely need to replace the function's
__globals__ with your own as well.
--
https://ma
On Mar 18, 2016 8:33 AM, "Sven R. Kunze" wrote:
>
> On 18.03.2016 14:47, Ian Kelly wrote:
>>
>> Your patched version takes two extra arguments. Did you add the
>> defaults for those to the function's __defaults__ attribute?
>
>
> That's it! :-) Thanks a lot.
>
> Just to understand this better: why
On 18 March 2016 at 11:49, Sven R. Kunze wrote:
> Hi,
>
> we got an interesting problem. We need to monkeypatch Django's reverse
> function:
>
>
> First approach:
>
> urlresolvers.reverse = patched_reverse
>
>
> Problem: some of Django's internal modules import urlresolvers.reverse
> before we can
On Fri, Mar 18, 2016 at 9:01 AM, Sven R. Kunze wrote:
> On 18.03.2016 15:48, Ian Kelly wrote:
>>
>> Well I didn't design it, so I'm not really sure. But it could be argued
>> that the defaults are intrinsic to the function declaration, not the code
>> object, as not all code objects even have argu
On 18.03.2016 14:47, Ian Kelly wrote:
Your patched version takes two extra arguments. Did you add the
defaults for those to the function's __defaults__ attribute?
That's it! :-) Thanks a lot.
Just to understand this better: why is that not part of the code object
but part of the function?
On 18.03.2016 15:48, Ian Kelly wrote:
Well I didn't design it, so I'm not really sure. But it could be argued
that the defaults are intrinsic to the function declaration, not the code
object, as not all code objects even have arguments. It also makes it
straight-forward to create a new function t
On Fri, Mar 18, 2016 at 5:49 AM, Sven R. Kunze wrote:
> Hi,
>
> we got an interesting problem. We need to monkeypatch Django's reverse
> function:
>
>
> First approach:
>
> urlresolvers.reverse = patched_reverse
>
>
> Problem: some of Django's internal modules import urlresolvers.reverse
> before
On 18.03.2016 15:23, Ian Kelly wrote:
On Fri, Mar 18, 2016 at 7:47 AM, Ian Kelly wrote:
Your patched version takes two extra arguments. Did you add the
defaults for those to the function's __defaults__ attribute?
And as an afterthought, you'll likely need to replace the function's
__globals__
On Friday, March 18, 2016 at 10:33:46 AM UTC-4, Sven R. Kunze wrote:
> On 18.03.2016 15:23, Ian Kelly wrote:
> > On Fri, Mar 18, 2016 at 7:47 AM, Ian Kelly wrote:
> >> Your patched version takes two extra arguments. Did you add the
> >> defaults for those to the function's __defaults__ attribute?
On 18.03.2016 15:33, Sven R. Kunze wrote:
On 18.03.2016 15:23, Ian Kelly wrote:
On Fri, Mar 18, 2016 at 7:47 AM, Ian Kelly
wrote:
Your patched version takes two extra arguments. Did you add the
defaults for those to the function's __defaults__ attribute?
And as an afterthought, you'll likely
Hi,
we got an interesting problem. We need to monkeypatch Django's reverse
function:
First approach:
urlresolvers.reverse = patched_reverse
Problem: some of Django's internal modules import urlresolvers.reverse
before we can patch it for some reasons.
Second approach:
urlresolvers.rev
On 3/18/2016 10:32 AM, Sven R. Kunze wrote:
Just to understand this better: why is [function.__defaults__]
> not part of the code object but part of the function?
compile(codestring, ...) compiles code into a code object. Besides
being used to compile function bodies, which do have a functio
17 matches
Mail list logo
