John Hunter writes:
> On Wed, Jul 22, 2009 at 8:15 AM, Jouni K. Seppänen wrote:
>
>> I finally committed the "boilerplate" variant. It seems to pass the
>> tests in pylab_examples, but now might be a good time for everyone to
>> take a look to see if I have broken anything.
>
> There is one probl
On Wed, Jul 22, 2009 at 8:15 AM, Jouni K. Seppänen wrote:
> I finally committed the "boilerplate" variant. It seems to pass the
> tests in pylab_examples, but now might be a good time for everyone to
> take a look to see if I have broken anything.
There is one problem, but I am not sure what the
Jouni K. Seppänen writes:
> I now have two different implementations in two branches of my
> github repository (patches attached):
>
> http://github.com/jkseppan/matplotlib/tree/boilerplate
> http://github.com/jkseppan/matplotlib/tree/autoboiler
I finally committed the "boilerplate" variant. It
On Mon, Jun 8, 2009 at 2:29 AM, Jouni K. Seppänen wrote:
>> Have you looked at the decorator module?
>> http://pypi.python.org/pypi/decorator
>
> That looks like it could work -- the memoize example seems to be pretty
> close to our wrapping needs. I'll spend some time thinking about this
> later.
On Sun, Jun 7, 2009 at 8:05 PM, Eric Firing wrote:
> Jouni K. Seppänen wrote:
>> The current pyplot wrappers all have an argspec of (*args, **kwargs),
>> which means that any interactive tools that show the possible arguments
>> will not be able to show anything very useful for the wrapped function
Eric Firing writes:
>> The current pyplot wrappers all have an argspec of (*args, **kwargs),
>> which means that any interactive tools that show the possible arguments
>
> It is in some ways a separate change, but it would be nice if the
> boilerplate were generated at build time, and/or generat
Andrew Straw writes:
> Anyhow, now that I've pushed up a more recent master, assuming you want
> to apply your work onto that, you could either rebase your commits onto
> the master -- thus ignoring the true historical state you developed them
> against -- or merge the master branch -- causing th
Andrew Straw wrote:
> Jouni K. Seppänen wrote:
>
>> I coded up what I think is an improvement, but since it has a lot of
>> potential to break something and release time is near, I didn't commit
>> my changes into svn. I tried playing around with git, to see if it is
>> useful for communicating pa
>> And now that we're talking about this, Eric, as the only MPL dev that I
>> know who prefers Hg over git, have you seen
>> http://github.com/blog/439-hg-git-mercurial-plugin and would you be
>> willing to try it out? I'd be very interested to know if it could make a
>> git central repo work seam
Eric Firing wrote:
>
>>> And now that we're talking about this, Eric, as the only MPL dev that I
>>> know who prefers Hg over git, have you seen
>>> http://github.com/blog/439-hg-git-mercurial-plugin and would you be
>>> willing to try it out? I'd be very interested to know if it could
>>> make a
>
Jouni K. Seppänen wrote:
> The current pyplot wrappers all have an argspec of (*args, **kwargs),
> which means that any interactive tools that show the possible arguments
> will not be able to show anything very useful for the wrapped functions.
> Also, since the docstrings are generated dynamicall
Jouni K. Seppänen wrote:
> I coded up what I think is an improvement, but since it has a lot of
> potential to break something and release time is near, I didn't commit
> my changes into svn. I tried playing around with git, to see if it is
> useful for communicating patches.
I think it's useful
The current pyplot wrappers all have an argspec of (*args, **kwargs),
which means that any interactive tools that show the possible arguments
will not be able to show anything very useful for the wrapped functions.
Also, since the docstrings are generated dynamically, any static code
analysis tools
13 matches
Mail list logo
