matplotlib-devel Mailing List for matplotlib

On 2012年08月26日 5:50 AM, Michael Welter wrote:
> Hello,
>
> i made a patch which would allow the svg backend to make
> rasterized plots according to the dpi given in savefig.
> I wanted this in order to have high-res scatter plots.
> As you probably know it is hardcoded to 72 dpi right now.
> The idea how to, came from the pdf backend. I mostly
> copy pasted some code.
>
> I also added a test for it. Some other tests now fail
> the image comparison. It is nothing serious apparently.
> Probably roundoff errors. Except interp_nearest_vs_none.
> The result of which looks now exactly like the pdf which
> it did not before.
>
> Also, two other minor changes which i needed
>
> - Compare_images failed for older numy versions. Simple fix ...
> - A numpy.float32 variable got passed to the pdfRepr function in
> backend_pdf.py. I changed this function to accept this type, too.
>
>
> Cheers,
> Michael
Michael,
Thank you, this sounds good. Although we can deal with it as a patch if 
necessary, it would be greatly preferable to see it as a github PR:
http://matplotlib.sourceforge.net/devel/gitwash/git_development.html#git-development
Are you willing to give that a try?
Eric

As of now, we have 14 issues on the 1.2.x milestone, plus 6 issues on 
the 1.2.x known bugs milestone.
Since there's still a lot of work to be done on these before the rc1, 
I'm thinking I will continue to hold off on creating a 1.2.x branch. 
(Creating the branch would mean all of the pending PRs would have to be 
merged both to master and then manually pulled back to 1.2.x -- totally 
doable, or course, but an extra step.) Once we're down to only a 
handful, that might be a good time to create the branch.
Are there any objections to continuing to hold off? The downside is we 
can't continue to merge non 1.2.x "blue sky" PRs in the meantime.
Mike

On 08/26/2012 05:33 AM, Anton Akhmerov wrote:
> Michael Droettboom <mdroe@...> writes:
>
>>
>> 
>> Working with the documentation this past week has me a little
>> frustrated with the state of it. Enough to write a MEP.
> https://github.com/matplotlib/matplotlib/wiki/Mep10
>> In particular, it would be nice to compile a list of concerns about
>> the docstrings and documentation layout so that we can address as
>> much as possible in a single pass. Also, let me know if there are
>> any relevant PRs and Issues.
>> In particular, I think PR #1032, as it is a large structural
>> reorganization, my dovetail well with the proposed reorganization of
>> the docs.
>> Mike
> The proposal looks great. I would like to comment on one issue that it touches,
> and which I found very uncomfortable to work with as a newcomer. I think that
> matplotlib style of using *args and **kwargs for delegation of arguments is a
> rather bad practice, which is hard to solve by just updating documentation. It
> breaks many rules of pep 20: it is implicit, since it is not allowing
> introspection, it is nested, since it always involves nested calls, it allows
> for alternative ways to do things, and I also don't think it's anyhow beautiful.
> Most of the things passed with *args, **kwargs can be done with an added
> function call, like:
>
> points = ax.scatter(data)
> points.update(*args, **kwargs)
>
> What would be the disadvantage of abolishing this practice?
>
I understand the comments about the difficulty of introspection. The 
reason it works the way it does is so that additional parameters can be 
added to the artist layer without needing to update every single 
plotting function. A real world example of this is when hatching was 
added -- that feature only had to be added in one place and most artists 
were able to use it. In that sense, I think this approach is very 
beautiful in terms of code maintainability and extensibility.
I'm willing to consider this if there's a better suggestion, but I think 
pushing what is currently a single function call for the user in to two 
is not going to fly.
An alternative might be to have "style" objects that are passed to the 
plotting functions, and these style objects could grow new features over 
time. But that's going to break a lot of backward compatibility, of course.
Mike

Hello,
i made a patch which would allow the svg backend to make
rasterized plots according to the dpi given in savefig.
I wanted this in order to have high-res scatter plots.
As you probably know it is hardcoded to 72 dpi right now.
The idea how to, came from the pdf backend. I mostly
copy pasted some code.
I also added a test for it. Some other tests now fail
the image comparison. It is nothing serious apparently.
Probably roundoff errors. Except interp_nearest_vs_none.
The result of which looks now exactly like the pdf which
it did not before.
Also, two other minor changes which i needed
- Compare_images failed for older numy versions. Simple fix ...
- A numpy.float32 variable got passed to the pdfRepr function in
backend_pdf.py. I changed this function to accept this type, too.
Cheers,
Michael

Michael Droettboom <mdroe@...> writes:
> 
> 
> 
> Working with the documentation this past week has me a little
> frustrated with the state of it. Enough to write a MEP. 
https://github.com/matplotlib/matplotlib/wiki/Mep10
> In particular, it would be nice to compile a list of concerns about
> the docstrings and documentation layout so that we can address as
> much as possible in a single pass. Also, let me know if there are
> any relevant PRs and Issues.
> In particular, I think PR #1032, as it is a large structural
> reorganization, my dovetail well with the proposed reorganization of
> the docs.
> Mike
The proposal looks great. I would like to comment on one issue that it touches, 
and which I found very uncomfortable to work with as a newcomer. I think that 
matplotlib style of using *args and **kwargs for delegation of arguments is a 
rather bad practice, which is hard to solve by just updating documentation. It 
breaks many rules of pep 20: it is implicit, since it is not allowing 
introspection, it is nested, since it always involves nested calls, it allows 
for alternative ways to do things, and I also don't think it's anyhow beautiful.
Most of the things passed with *args, **kwargs can be done with an added 
function call, like:
points = ax.scatter(data)
points.update(*args, **kwargs)
What would be the disadvantage of abolishing this practice?
Anton