Re: [matplotlib-devel] buggy legend behavior with "_nolegend_" label?
On Sun, Mar 6, 2011 at 7:18 AM, Jae-Joon Lee wrote: > Hi, > > According to the legend doc, > >If label is set to '_nolegend_', the item will not be shown in >legend. > > But I think the documented behavior a bit ambiguous. For example, > consider the example below. > >l1, = plot([1,2,3], label="_nolegend_") >l2, = plot([2,3,1]) >legend(["my line"]) > > I suppose the legend should show *l2* with "my line" label. But the > current master branch shows "l1" with "my line" label. > > In other words, in the current implementation, when the legend command > is called with a single nonkeyword argument (which is interpreted as a > list of labels), the given labels are applied to all the artists > regardless whether the artist has a label of "_nolegend_" or not. > > While there could be some cases that have relied on this behavior, I'm > inclined to fix this so that artists w/ "_nolegend_" are ignored. > However, fixing this requires "hist" command to be modified (there > could be more commands that need modification). > > Unless there is no objection from other developers, I'll go ahead and > commit the patch to fix this. > > Regards, > > -JJ > > I agree, the current behavior is buggy. Ben Root -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problems with new PyQt4 API
On Fri, Mar 4, 2011 at 4:23 AM, Martin Teichmann wrote: > Hi Ben, Hi list, > > > Exactly. That's all I found too. Nothing indicates that we need to > > change anything. We are throwing away the second part of the tuple > > which has the returned filter. The only reason I see for the new > > function is so the coder can get back the filter string, which we > > don't seem to use. > > It took me a while to see the problem, too. The point is: there is one > parameter > missing in the new API of getSaveFileName, called selectedFilter, > which we use, and > given that it is missing, python takes it to be the next parameter, which > must be an int, and you get a TypeError. I discussed this with > Phil Thompson (the author of PyQt4) over at the PyQt4 mailing list > (see > http://www.mail-archive.com/pyqt%40riverbankcomputing.com/msg23733.html) > and he told me to use getSaveFileNameAndFilter. > > The other option would be to change PyQt4, dunno which is best. > > Greetings > > Martin > > Martin, thanks for the explanation. That made a lot more sense. I will go ahead with the patch. Ben Root -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problems with new PyQt4 API
On Mon, Mar 7, 2011 at 11:04 AM, Benjamin Root wrote: > > > On Fri, Mar 4, 2011 at 4:23 AM, Martin Teichmann > wrote: >> >> Hi Ben, Hi list, >> >> > Exactly. That's all I found too. Nothing indicates that we need to >> > change anything. We are throwing away the second part of the tuple >> > which has the returned filter. The only reason I see for the new >> > function is so the coder can get back the filter string, which we >> > don't seem to use. >> >> It took me a while to see the problem, too. The point is: there is one >> parameter >> missing in the new API of getSaveFileName, called selectedFilter, >> which we use, and >> given that it is missing, python takes it to be the next parameter, which >> must be an int, and you get a TypeError. I discussed this with >> Phil Thompson (the author of PyQt4) over at the PyQt4 mailing list >> (see >> http://www.mail-archive.com/pyqt%40riverbankcomputing.com/msg23733.html) >> and he told me to use getSaveFileNameAndFilter. >> >> The other option would be to change PyQt4, dunno which is best. >> >> Greetings >> >> Martin >> > > Martin, thanks for the explanation. That made a lot more sense. I will go > ahead with the patch. getSaveFileNameAndFilter was only added in pyqt-4.6. -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problems with new PyQt4 API
On Mon, Mar 7, 2011 at 10:20 AM, Darren Dale wrote: > On Mon, Mar 7, 2011 at 11:04 AM, Benjamin Root wrote: > > > > > > On Fri, Mar 4, 2011 at 4:23 AM, Martin Teichmann < > lkb.teichm...@gmail.com> > > wrote: > >> > >> Hi Ben, Hi list, > >> > >> > Exactly. That's all I found too. Nothing indicates that we need to > >> > change anything. We are throwing away the second part of the tuple > >> > which has the returned filter. The only reason I see for the new > >> > function is so the coder can get back the filter string, which we > >> > don't seem to use. > >> > >> It took me a while to see the problem, too. The point is: there is one > >> parameter > >> missing in the new API of getSaveFileName, called selectedFilter, > >> which we use, and > >> given that it is missing, python takes it to be the next parameter, > which > >> must be an int, and you get a TypeError. I discussed this with > >> Phil Thompson (the author of PyQt4) over at the PyQt4 mailing list > >> (see > >> http://www.mail-archive.com/pyqt%40riverbankcomputing.com/msg23733.html > ) > >> and he told me to use getSaveFileNameAndFilter. > >> > >> The other option would be to change PyQt4, dunno which is best. > >> > >> Greetings > >> > >> Martin > >> > > > > Martin, thanks for the explanation. That made a lot more sense. I will > go > > ahead with the patch. > > getSaveFileNameAndFilter was only added in pyqt-4.6. > oy! Why the heck did qt4 change their API like this? What should we do? I also assume that some sort of fix should be applied to the v1.0.x? Ben Root -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problems with new PyQt4 API
On Mon, Mar 7, 2011 at 11:24 AM, Benjamin Root wrote:
>
>
> On Mon, Mar 7, 2011 at 10:20 AM, Darren Dale wrote:
>>
>> On Mon, Mar 7, 2011 at 11:04 AM, Benjamin Root wrote:
>> >
>> >
>> > On Fri, Mar 4, 2011 at 4:23 AM, Martin Teichmann
>> >
>> > wrote:
>> >>
>> >> Hi Ben, Hi list,
>> >>
>> >> > Exactly. That's all I found too. Nothing indicates that we need to
>> >> > change anything. We are throwing away the second part of the tuple
>> >> > which has the returned filter. The only reason I see for the new
>> >> > function is so the coder can get back the filter string, which we
>> >> > don't seem to use.
>> >>
>> >> It took me a while to see the problem, too. The point is: there is one
>> >> parameter
>> >> missing in the new API of getSaveFileName, called selectedFilter,
>> >> which we use, and
>> >> given that it is missing, python takes it to be the next parameter,
>> >> which
>> >> must be an int, and you get a TypeError. I discussed this with
>> >> Phil Thompson (the author of PyQt4) over at the PyQt4 mailing list
>> >> (see
>> >>
>> >> http://www.mail-archive.com/pyqt%40riverbankcomputing.com/msg23733.html)
>> >> and he told me to use getSaveFileNameAndFilter.
>> >>
>> >> The other option would be to change PyQt4, dunno which is best.
>> >>
>> >> Greetings
>> >>
>> >> Martin
>> >>
>> >
>> > Martin, thanks for the explanation. That made a lot more sense. I will
>> > go
>> > ahead with the patch.
>>
>> getSaveFileNameAndFilter was only added in pyqt-4.6.
>
>
> oy! Why the heck did qt4 change their API like this?
To make it more pythonic for python-3. You can set the api to v2 with
python-2, but it is not the default.
> What should we do?
I think the change being discussed is only necessary when the QString
api is set to v2. So, we should be able to do something along the
lines of:
import sip
try:
if sip.getapi("QString") > 1:
# support the new api
else:
# support the old api
except (AttributeError, KeyError): # call to getapi may fail with
older versions of sip
# support the old api
> I also assume that some sort of fix should be applied to the v1.0.x?
I think it should be, if the fix does not break backward compatibility
with http://p.sf.net/sfu/progress-d2d
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Merging instructions
I just wrote this as a response to a question on https://github.com/matplotlib/matplotlib/pull/32 about how to merge to v1.0.x and master. Please feel free to comment or ask for details. -- First make sure your v1.0.x branch is fresh: git checkout v1.0.x git pull --ff-only upstream v1.0.x (This assumes an "upstream" remote pointing to `git://github.com/matplotlib/matplotlib.git`.) Then merge your pull request and run the test suite (I don't know if this should be mandatory): git merge bugfix/legend_windowcall # replace by whatever you are merging python setup.py install # or however you compile things to run the tests ./tests.py # all new test runner script! If everything is fine, push: git push g...@github.com:matplotlib/matplotlib.git v1.0.x Next do the same with master, this time merging v1.0.x: git checkout master git pull --ff-only upstream master git merge v1.0.x python setup.py install ./tests.py git push g...@github.com:matplotlib/matplotlib.git master -- There are multiple ways things could go wrong, which will need instructions in the devel docs. These are the cases I can think of: 1. git pull --ff-only fails because fast-forward is impossible (you have commits on an integration branch that don't belong there) 2. the merge has conflicts 3. the tests fail (also a kind of merge conflict, assuming the tests passed before) 4. the push fails because fast-forward is impossible (someone has pushed in the meantime) 5. v1.0.x doesn't merge cleanly into master -- Jouni K. Seppänen http://www.iki.fi/jks -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Merging instructions
On 03/07/2011 09:36 AM, Jouni K. Seppänen wrote: > I just wrote this as a response to a question on > https://github.com/matplotlib/matplotlib/pull/32 > about how to merge to v1.0.x and master. > > Please feel free to comment or ask for details. > > -- > First make sure your v1.0.x branch is fresh: > > git checkout v1.0.x > git pull --ff-only upstream v1.0.x > > (This assumes an "upstream" remote pointing to > `git://github.com/matplotlib/matplotlib.git`.) Then merge your pull By default, however, if you have cloned from g...@github.com:matplotlib/matplotlib.git then instead of "upstream" the remote will be "origin". Are you recommending and assuming that we clone *only* from our individual github forks, and then add the "upstream" remote to point to the official repo? > request and run the test suite (I don't know if this should be > mandatory): > > git merge bugfix/legend_windowcall # replace by whatever you are merging > python setup.py install # or however you compile things to run the tests > ./tests.py # all new test runner script! > > If everything is fine, push: > > git push g...@github.com:matplotlib/matplotlib.git v1.0.x Can't this be simplified by using "origin" or "upstream" in place of the url? > > Next do the same with master, this time merging v1.0.x: > > git checkout master > git pull --ff-only upstream master > git merge v1.0.x > python setup.py install > ./tests.py > git push g...@github.com:matplotlib/matplotlib.git master > -- > > There are multiple ways things could go wrong, which will need > instructions in the devel docs. These are the cases I can think of: > > 1. git pull --ff-only fails because fast-forward is impossible > (you have commits on an integration branch that don't belong there) > 2. the merge has conflicts I encountered that last night. The conflict was a simple one that will occur often: the CHANGELOG needed to have the new entry prepended, so as to be at the top of the file, above new entries that were in master but not in v1.0.x. Instructions for simplest case: Edit the conflicted files, remembering to remove the conflict markers; test as needed; use "git add" to add the resolved files (and any other files that needed to be changed to make the merge work) to the index, e.g. git add CHANGELOG Then commit; a merge commit message will be generated, and can be edited as needed: git commit Now you are ready to push. > 3. the tests fail (also a kind of merge conflict, assuming the tests > passed before) > 4. the push fails because fast-forward is impossible (someone has > pushed in the meantime) > 5. v1.0.x doesn't merge cleanly into master What do you mean by this? What is the symptom? Eric -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Merging instructions
Hi Jouni, Thanks for doing this... On Mon, Mar 7, 2011 at 2:36 PM, Jouni K. Seppänen wrote: > I just wrote this as a response to a question on > https://github.com/matplotlib/matplotlib/pull/32 > about how to merge to v1.0.x and master. > > Please feel free to comment or ask for details. > > -- > First make sure your v1.0.x branch is fresh: > > git checkout v1.0.x > git pull --ff-only upstream v1.0.x > > (This assumes an "upstream" remote pointing to > `git://github.com/matplotlib/matplotlib.git`.) Then merge your pull > request and run the test suite (I don't know if this should be > mandatory): > > git merge bugfix/legend_windowcall # replace by whatever you are merging > python setup.py install # or however you compile things to run the tests > ./tests.py # all new test runner script! > > If everything is fine, push: > > git push g...@github.com:matplotlib/matplotlib.git v1.0.x > > Next do the same with master, this time merging v1.0.x: > > git checkout master > git pull --ff-only upstream master > git merge v1.0.x > python setup.py install > ./tests.py > git push g...@github.com:matplotlib/matplotlib.git master We might also want to mention the special case of what needs to be done for a change not intended for merging into master. > -- No comments, it's just the way I would have recommended it. > There are multiple ways things could go wrong, which will need > instructions in the devel docs. These are the cases I can think of: > > 1. git pull --ff-only fails because fast-forward is impossible > (you have commits on an integration branch that don't belong there) Right, and we should emphasize that integration branches (like master and v1.0.x) in your local repo should only ever get ahead of the remote repo for the few moments between merging a branch and pushing back up to the remote. > 2. the merge has conflicts > 3. the tests fail (also a kind of merge conflict, assuming the tests > passed before) > 4. the push fails because fast-forward is impossible (someone has > pushed in the meantime) > 5. v1.0.x doesn't merge cleanly into master Nicely summarized. Darren -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Merging instructions
On Mon, Mar 7, 2011 at 3:14 PM, Eric Firing wrote: > On 03/07/2011 09:36 AM, Jouni K. Seppänen wrote: >> I just wrote this as a response to a question on >> https://github.com/matplotlib/matplotlib/pull/32 >> about how to merge to v1.0.x and master. >> >> Please feel free to comment or ask for details. >> >> -- >> First make sure your v1.0.x branch is fresh: >> >> git checkout v1.0.x >> git pull --ff-only upstream v1.0.x >> >> (This assumes an "upstream" remote pointing to >> `git://github.com/matplotlib/matplotlib.git`.) Then merge your pull > > By default, however, if you have cloned from > g...@github.com:matplotlib/matplotlib.git then instead of "upstream" the > remote will be "origin". > > Are you recommending and assuming that we clone *only* from our > individual github forks, and then add the "upstream" remote to point to > the official repo? No, I don't think there is such an assumption. Remotes can be named whatever you want. I've ditched the "origin/upstream" convention for naming remotes entirely, and instead use "matplotlib", "darrendale", etc. I think Jouni was clear: "This assumes an "upstream" remote pointing to ..." >> request and run the test suite (I don't know if this should be >> mandatory): >> >> git merge bugfix/legend_windowcall # replace by whatever you are merging >> python setup.py install # or however you compile things to run the tests >> ./tests.py # all new test runner script! >> >> If everything is fine, push: >> >> git push g...@github.com:matplotlib/matplotlib.git v1.0.x > > Can't this be simplified by using "origin" or "upstream" in place of the > url? I think it can. >> >> Next do the same with master, this time merging v1.0.x: >> >> git checkout master >> git pull --ff-only upstream master >> git merge v1.0.x >> python setup.py install >> ./tests.py >> git push g...@github.com:matplotlib/matplotlib.git master >> -- >> >> There are multiple ways things could go wrong, which will need >> instructions in the devel docs. These are the cases I can think of: >> >> 1. git pull --ff-only fails because fast-forward is impossible >> (you have commits on an integration branch that don't belong there) >> 2. the merge has conflicts > > I encountered that last night. The conflict was a simple one that will > occur often: the CHANGELOG needed to have the new entry prepended, so as > to be at the top of the file, above new entries that were in master but > not in v1.0.x. Instructions for simplest case: > > Edit the conflicted files, remembering to remove the conflict markers; > test as needed; use "git add" to add the resolved files (and any other > files that needed to be changed to make the merge work) to the index, e.g. > > git add CHANGELOG > > Then commit; a merge commit message will be generated, and can be edited > as needed: > > git commit > > Now you are ready to push. > >> 3. the tests fail (also a kind of merge conflict, assuming the tests >> passed before) >> 4. the push fails because fast-forward is impossible (someone has >> pushed in the meantime) >> 5. v1.0.x doesn't merge cleanly into master > > What do you mean by this? What is the symptom? The master branch may have changed such that the same lines of code have been edited in different ways along the master and v1.0.x branches of development. Darren -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Merging instructions
Eric Firing writes: >> git pull --ff-only upstream v1.0.x >> >> (This assumes an "upstream" remote pointing to >> `git://github.com/matplotlib/matplotlib.git`.) Then merge your pull > > By default, however, if you have cloned from > g...@github.com:matplotlib/matplotlib.git then instead of "upstream" the > remote will be "origin". > > Are you recommending and assuming that we clone *only* from our > individual github forks, and then add the "upstream" remote to point to > the official repo? I was assuming that, based on the github instructions: http://help.github.com/fork-a-repo/ But of course there are many ways to do it. We'll have to decide what we like best and stick to it in the manual; I personally don't have any strong opinions on what to call the various repositories. Perhaps "origin" for the central repository and "public" for your own github repo (as in the public counterpart of your private development repo)? >> If everything is fine, push: >> >> git push g...@github.com:matplotlib/matplotlib.git v1.0.x > > Can't this be simplified by using "origin" or "upstream" in place of the > url? Yes, if that's the read-write address. If you cloned from the read-only address, you can't push to it. >> 2. the merge has conflicts > > I encountered that last night. The conflict was a simple one that will > occur often: the CHANGELOG needed to have the new entry prepended, Oh, of course. That's going to occur a lot. >> 5. v1.0.x doesn't merge cleanly into master > > What do you mean by this? What is the symptom? A merge conflict or (probably much less often) a test failure, because v1.0.x and master have diverged in the relevant part. An example is pull request #17, which modifies make.osx: https://github.com/matplotlib/matplotlib/pull/17 But make.osx has changed in master, so while merging this request will not have a merge conflict (at least with current v1.0.x), merging to master will. I created another pull request that includes this one and resolves the merge conflict: https://github.com/matplotlib/matplotlib/pull/30 So when #17 is merged into v1.0.x, #30 should be merged into master. -- Jouni K. Seppänen http://www.iki.fi/jks -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Merging instructions
On 03/07/2011 10:30 AM, Jouni K. Seppänen wrote: >>> 5. v1.0.x doesn't merge cleanly into master >> >> What do you mean by this? What is the symptom? > > A merge conflict or (probably much less often) a test failure, because > v1.0.x and master have diverged in the relevant part. An example is pull > request #17, which modifies make.osx: > > https://github.com/matplotlib/matplotlib/pull/17 This brings up something that confuses me, together with related questions, and so might be another topic for this part of the docs: 1) How is it that you were able to add commits to a branch of someone else's fork? 2) How should it be decided who merges a pull request, and when? 3) Under what circumstances, if any, should a pull request involving multiple commits be collapsed into a single changeset prior to being merged and pushed? Eric > > But make.osx has changed in master, so while merging this request will > not have a merge conflict (at least with current v1.0.x), merging to > master will. I created another pull request that includes this one and > resolves the merge conflict: > > https://github.com/matplotlib/matplotlib/pull/30 > > So when #17 is merged into v1.0.x, #30 should be merged into master. > -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problems with new PyQt4 API
On Mon, Mar 7, 2011 at 10:39 AM, Darren Dale wrote:
> On Mon, Mar 7, 2011 at 11:24 AM, Benjamin Root wrote:
> >
> >
> > On Mon, Mar 7, 2011 at 10:20 AM, Darren Dale wrote:
> >>
> >> On Mon, Mar 7, 2011 at 11:04 AM, Benjamin Root wrote:
> >> >
> >> >
> >> > On Fri, Mar 4, 2011 at 4:23 AM, Martin Teichmann
> >> >
> >> > wrote:
> >> >>
> >> >> Hi Ben, Hi list,
> >> >>
> >> >> > Exactly. That's all I found too. Nothing indicates that we need
> to
> >> >> > change anything. We are throwing away the second part of the tuple
> >> >> > which has the returned filter. The only reason I see for the new
> >> >> > function is so the coder can get back the filter string, which we
> >> >> > don't seem to use.
> >> >>
> >> >> It took me a while to see the problem, too. The point is: there is
> one
> >> >> parameter
> >> >> missing in the new API of getSaveFileName, called selectedFilter,
> >> >> which we use, and
> >> >> given that it is missing, python takes it to be the next parameter,
> >> >> which
> >> >> must be an int, and you get a TypeError. I discussed this with
> >> >> Phil Thompson (the author of PyQt4) over at the PyQt4 mailing list
> >> >> (see
> >> >>
> >> >>
> http://www.mail-archive.com/pyqt%40riverbankcomputing.com/msg23733.html)
> >> >> and he told me to use getSaveFileNameAndFilter.
> >> >>
> >> >> The other option would be to change PyQt4, dunno which is best.
> >> >>
> >> >> Greetings
> >> >>
> >> >> Martin
> >> >>
> >> >
> >> > Martin, thanks for the explanation. That made a lot more sense. I
> will
> >> > go
> >> > ahead with the patch.
> >>
> >> getSaveFileNameAndFilter was only added in pyqt-4.6.
> >
> >
> > oy! Why the heck did qt4 change their API like this?
>
> To make it more pythonic for python-3. You can set the api to v2 with
> python-2, but it is not the default.
>
> > What should we do?
>
> I think the change being discussed is only necessary when the QString
> api is set to v2. So, we should be able to do something along the
> lines of:
>
>
> import sip
>
> try:
> if sip.getapi("QString") > 1:
> # support the new api
> else:
> # support the old api
> except (AttributeError, KeyError): # call to getapi may fail with
> older versions of sip
> # support the old api
>
> > I also assume that some sort of fix should be applied to the v1.0.x?
>
> I think it should be, if the fix does not break backward compatibility
> with
> Darren
>
>
My attempt at this can be found in pull request 33:
https://github.com/matplotlib/matplotlib/pull/33
Ben Root
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Merging instructions
Eric Firing writes: >> https://github.com/matplotlib/matplotlib/pull/17 > > This brings up something that confuses me, together with related > questions, and so might be another topic for this part of the docs: > > 1) How is it that you were able to add commits to a branch of someone > else's fork? I sent Fernando a pull request: https://github.com/fgb/matplotlib/pull/1 He merged my commits to his branch, and his pull request was automatically updated. > 2) How should it be decided who merges a pull request, and when? I think John called for not too much bureaucracy - before git we were committing things without any review. On the other hand, with git there is less urgency to get things into master, since if you need someone's bugfix or feature to continue developing your own stuff, you can pull from their branch into your own. I think we can depend on everyone's good judgment. If we need a guideline, my suggestion is that if someone other than the author reviews the code and says it is good, or if no-one raises any issues for some time, it can be merged. If there are merge conflicts, usually the person who wrote the code is in the best position to resolve them. > 3) Under what circumstances, if any, should a pull request involving > multiple commits be collapsed into a single changeset prior to being > merged and pushed? If we had a strict policy that tests must pass for every revision (which I don't think we have had) it would make sense to squash multiple commits into one if the intermediate commits don't pass the test suite. Squashing is an instance of a rebase operation, so it should be avoided for any commits on which someone may have based further work. -- Jouni K. Seppänen http://www.iki.fi/jks -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Location of bleeding edge repository
Is it in git or svn? I just cloned and installed from git using: git clone git://github.com/astraw/matplotlib.git cd matplotlib sudo python setupegg.py develop Starting ipython, and importing matplotlib, I get: In [2]: matplotlib.__version__ Out[2]: '1.0.0' I thought v1.0.1 was available. Should I install from svn? As an aside, I first tried the proceedure outlined here: http://matplotlib.sourceforge.net/devel/coding_guide.html#using-git and got a public key error. Thanks, -paul -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
