Re: [Python-Dev] Thoughts fresh after EuroPython
Terry Reedy wrote: Should CPython be optimized for 1, 2, 3, or 4 or more cores? The answer to this is obviously changing. I will soon replace a single core with a 4/6 core machine, I don't think you can answer that just by considering the average number of cores in a CPU. Even if my CPU has 4 cores, most of the time the Python code I run on it isn't going to take advantage of more than one of them, simply because it's not written to be multi-threaded. I would not like to be in a position where I *have* to use some number of cores in order to get reasonable performance from my Python code. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Readability of hex strings (Was: Use of coding cookie in 3.x stdlib)
anatoly techtonik wrote: I wonder if it is possible to introduce an effective binary string type that will be represented as h"XX XX XX" in language syntax? Rather than a new type, maybe bytes objects could just have a bit indicating whether they were best thought of as containing characterish stuff or just raw data. It wouldn't affect the behaviour in any way except that the repr would come out in hex instead of text. Then b"..." and h"..." literals could produce bytes objects with different settings for the raw-data bit. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts fresh after EuroPython
Am 27.07.2010 04:43, schrieb Terry Reedy: > On 7/26/2010 5:15 PM, Georg Brandl wrote: > >> Sure PyPI is part of the ecosystem. But so are quite a lot of other tools, >> and none of them are tracked in bugs.python.org. (This is also the case >> for the website.) I'd really like bugs.python.org to remain a tracker for >> what we ship as the CPython distribution, and nothing else. There's enough >> content in there already. > > How about one other tracker, say bugs.python/org/tools (or projects, or > ???) for everything else: pypi, distribute2 (until part of release), web > site, sandbox projects? It would have to be taught how to turn rev + > component into a link to the appropriate repository. I still think that one tracker per project/site is the better way. However, I would be +0 on a common "infrastructure" tracker (also subsuming the meta-tracker). Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts fresh after EuroPython
2010/7/27 "Martin v. Löwis" : >> I would classify the changes in three kinds: >> >> - minor: a new feature, a UI bugfix etc >> - important: a new feature that changes a lot the end-user experience >> (like the rating system) >> - major: a change to the APIs (HTTP/XML-RPC) >> >> I think you should briefly present your plans for important or major >> changes in catalog-SIG >> prior to starting them, so we can discuss them. > > So would you consider the addition of JSON a major feature (as it > introduces a new API)? I doubt Richard would have been willing to wait > for the end of some discussion before implementing it. That's "minor" since it's a new feature that does not interfere with existing features -- I hope it doesn't :) "major" is a change to existing APIs that could potentially break existing software. PyPI is not different from other software in that respect, e.g. we need to be careful with the changes we make and push in production. But, if Richard sprints again and change the JSON output --let's say it use to return a mapping, but now it returns a list with a timestamp as the first member and the original mapping as the second member--, he should first explain that change to the ML so people that potentially uses the JSON version can be aware of that. In case of doubt, a change to an existing piece should be mentioned. Ideally, as I said in a previous mail, we should document in a single place (a PEP I guess) the PyPI specification, and maybe version it. Regards, Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Define a place for code review in Python workflow
> > I'd welcome any patch submitted to Rietveld for review. However, your > proposed "review.py" module does not exist as far as I know, and unless > someone writes it, it won't. > Haven't personally tested that it works with Rietveld due to lack of patches sitting around, but cursory investigation suggests that reports of non-existence may have been exaggerated ;) http://pypi.python.org/pypi/review/r537 Love regards etc David Miller ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts fresh after EuroPython
On Tue, 27 Jul 2010 09:57:22 +0200 Georg Brandl wrote: > Am 27.07.2010 04:43, schrieb Terry Reedy: > > On 7/26/2010 5:15 PM, Georg Brandl wrote: > > > >> Sure PyPI is part of the ecosystem. But so are quite a lot of other tools, > >> and none of them are tracked in bugs.python.org. (This is also the case > >> for the website.) I'd really like bugs.python.org to remain a tracker for > >> what we ship as the CPython distribution, and nothing else. There's enough > >> content in there already. > > > > How about one other tracker, say bugs.python/org/tools (or projects, or > > ???) for everything else: pypi, distribute2 (until part of release), web > > site, sandbox projects? It would have to be taught how to turn rev + > > component into a link to the appropriate repository. > > I still think that one tracker per project/site is the better way. Only if they have similar look and feel, and don't require you to register the same login N times, though. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts fresh after EuroPython
On 7/27/2010 11:02 AM, Antoine Pitrou wrote: > On Tue, 27 Jul 2010 09:57:22 +0200 > Georg Brandl wrote: > >> Am 27.07.2010 04:43, schrieb Terry Reedy: >>> On 7/26/2010 5:15 PM, Georg Brandl wrote: >>> Sure PyPI is part of the ecosystem. But so are quite a lot of other tools, and none of them are tracked in bugs.python.org. (This is also the case for the website.) I'd really like bugs.python.org to remain a tracker for what we ship as the CPython distribution, and nothing else. There's enough content in there already. >>> >>> How about one other tracker, say bugs.python/org/tools (or projects, or >>> ???) for everything else: pypi, distribute2 (until part of release), web >>> site, sandbox projects? It would have to be taught how to turn rev + >>> component into a link to the appropriate repository. >> >> I still think that one tracker per project/site is the better way. > > Only if they have similar look and feel, and don't require you to > register the same login N times, though. > Is it really time to give devs a distributed identity good for a range of systems? Sounds like a potentially hairy management task. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] versioned .so files for Python 3.2
On 26.07.2010 22:53, Ralf Schmitt wrote: Barry Warsaw writes: That's fine, but it's not the way Debian/Ubuntu works today. PEP 3149 adoption will definitely remove significant complication for deploying multiple Python versions at the same time on those systems. You're just moving that complication into python. There is nothing which prevents you to still deploy/use python modules in separate directories, and if you see a python package as a directory, nothing will change for you with this PEP besides the naming of the extensions. > I'd much prefer to have cleanly separated environments by having > separate directories for my python modules. That is your preference, but not what standards like the FHS talk about (i.e. having different locations for data, docs, headers). > Sharing the source code and > complicating things will not lead to increased robustness. Not true. Package managers like dpkg/apt-get, rpm/yum and maybe others do this for ages. And yes, the added "complexity" of package managers does lead to increased robustness. Matthias ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts fresh after EuroPython
Am 27.07.2010 12:49, schrieb Steve Holden: > On 7/27/2010 11:02 AM, Antoine Pitrou wrote: >> On Tue, 27 Jul 2010 09:57:22 +0200 >> Georg Brandl wrote: >> >>> Am 27.07.2010 04:43, schrieb Terry Reedy: On 7/26/2010 5:15 PM, Georg Brandl wrote: > Sure PyPI is part of the ecosystem. But so are quite a lot of other > tools, > and none of them are tracked in bugs.python.org. (This is also the case > for the website.) I'd really like bugs.python.org to remain a tracker for > what we ship as the CPython distribution, and nothing else. There's > enough > content in there already. How about one other tracker, say bugs.python/org/tools (or projects, or ???) for everything else: pypi, distribute2 (until part of release), web site, sandbox projects? It would have to be taught how to turn rev + component into a link to the appropriate repository. >>> >>> I still think that one tracker per project/site is the better way. >> >> Only if they have similar look and feel, and don't require you to >> register the same login N times, though. >> > Is it really time to give devs a distributed identity good for a range > of systems? Sounds like a potentially hairy management task. IMO supporting OpenID is good enough. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Define a place for code review in Python workflow
Am 27.07.2010 10:54, schrieb David: > I'd welcome any patch submitted to Rietveld for review. However, your > > proposed "review.py" module does not exist as far as I know, and unless > someone writes it, it won't. > > > Haven't personally tested that it works with Rietveld due to lack of patches > sitting around, but cursory investigation suggests that reports of > non-existence > may have been exaggerated ;) > > http://pypi.python.org/pypi/review/r537 Ah! Well, a link to this instead of tirades would have been helpful from the OP; now at least we know what he's talking about. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts fresh after EuroPython
Steve Holden writes: > > Only if they have similar look and feel, and don't require you to > > register the same login N times, though. > > > Is it really time to give devs a distributed identity good for a range > of systems? Sounds like a potentially hairy management task. Sure, but Python can leave management up to Google, Yahoo, and several other well-known providers. This is what "OpenId" is all about. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] versioned .so files for Python 3.2
Matthias Klose writes: > Not true. Package managers like dpkg/apt-get, rpm/yum and maybe others > do this for ages. And yes, the added "complexity" of package managers > does lead to increased robustness. but how does sharing things lead to increased robustness (even if it might be managed by your package manager)? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts fresh after EuroPython
On Mon, Jul 26, 2010 at 12:00 PM, Michael Foord wrote: > At Resolver Systems we created a "calculation system" that does large > calculations on background threads using IronPython. Doing them on a > background thread allows the ui to remain responsive. Several calculations > could run simultaneously using multiple cores. > > As the calculation operates on a large object graph (which the ui then needs > access to in order to display it) using multiprocessing would have imposed a > very big overhead due to serialization / deserialization (the program runs > on windows). [...] > All the best, > > Michael Hey, (De)serialization being a much bigger cost than cache invalidation for a low amount of threads that do a lot of work each is definitely a common "problem" (in quotes, because as you mentioned: it actually *works*!). There are a number of ways that CSP tries to solve that (generally involving more locking), but they are not currently applicable to CPython because of the state of the GIL. Unfortunately, CSP theory appears to predict this is something that starts breaking down around 16 or so cores. Since x86-64 CPUs (Opterons) are currently available with 12 cores and their 16 core bigger brother coming in 2011, I guess now would be a good time to start worrying about it :-) I'd like to chime in from my experience with E, because they've ran into this problem (processors want many processes to perform, but (de)serialization makes that prohibitive) and tried to solve it (and I think they did well). As always when I talk about E, I'm not suggesting everyone drops everything and does this, but it might be interesting to look at. (Disclaimer: the following explanations makes minor concessions to pedant-proof levels of purity in the interest of giving everyone an idea of what something is that's correct enough to reason about it on an abstract level -- people who are interested, please read the Wikipedia bits, they're surprisingly good :-)) E introduces a concept called "vats". They have an event queue, their own stack and N objects. Vats run on top of real processes, which have 0..N vats. The advantage is that vats don't share namespaces but can (but don't necessarily do) share memoryspaces. So, messaging between vats *can* be cheap (I'm unfamiliar with threading under .NET, but if it's similar to how it happens on the JVM: same ballpark), but the vat is completely oblivious to the fact it's running on the same process as a different vat or a completely different one running on a CPU on the other side of the world. Because inter-vat message passing is explicit, these vats can also run in parallel with no issues. The simplest way to implement this would be a vat-local GIL (I realise the name GIL no longer makes sense there) for each vat, and then the process (most likely written in C(ython)) and the objects inside each vat contesting it. Or, in closing, but less exciting sounding: we've reinvented threads and they're called vats now! (The advantage is that you get the distributed nature, and only pay for it when you actually need it.) Computers are reasonably good at this sort of scheduling (putting the appropriate vats together), but it wouldn't be unthinkable to have the programmer hint at it. You just have to be careful not to take it too far and get into gcc realm, where higher levels of optimization include things like "ignore programmer hints". Caveat emptor: E has always cared much more about capabilities (so the security aspect) than parallel execution. thanks for reading Laurens ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Define a place for code review in Python workflow
On Tue, 27 Jul 2010 13:11:48 +0200, Georg Brandl wrote: > Am 27.07.2010 10:54, schrieb David: > > I'd welcome any patch submitted to Rietveld for review. However, your > > proposed "review.py" module does not exist as far as I know, and unless > > someone writes it, it won't. > > > > Haven't personally tested that it works with Rietveld due to lack of patches > > sitting around, but cursory investigation suggests that reports of > > non-existence > > may have been exaggerated ;) > > > > http://pypi.python.org/pypi/review/r537 > > Ah! Well, a link to this instead of tirades would have been helpful from > the OP; now at least we know what he's talking about. Indeed. If Anatoly had said, "Hey, there's this cool tool called 'review.py' on PyPI, and I think it would improve the tracker workflow if it was used something like thiswhat do other people think?" *That* kind of post would have gotten a completely different, and most likely more constructive, response. Anatoly, you might want to think about the fact that at this point I suspect most people's reactions to anything you post tend to be along the lines of "oh, another Anatoly rant" and either ignore it or look immediately for what's *wrong* with what you post, instead of seeing the good suggestions that are occasionally hidden inside your rants. In other words, your negative attitude toward us results in us taking a negative attitude toward you. If you engaged positively with the community instead of negatively, you'd have a much better chance of your ideas getting a positive reception. As an author I respect a lot once said, politeness is the grease that keeps the gears of society working smoothly. Your not "wasting time" being a "polite bastard" is the equivalent of deliberately throwing sand in the gears. It is, to say the least, counter-productive to your stated goals of improving the Python workflow for yourself and others. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] View tracker patches with ViewVC?
On 7/27/2010 1:42 AM, "Martin v. Löwis" wrote: Should I open a tracker issue to add something to the tracker doc? I recommend that you use it for some time before changing anything. How is someone suppose to use it without instructions? I also suggest that, instead of uploading the patch to Rietveld yourself, you can ask the submitter to do it. That adds another step. Let me repeat me original question: Would it be feasible to add a [view] button that I could click to get a nice view of a patch, such as provided by ViewVC? -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] View tracker patches with ViewVC?
On Tue, Jul 27, 2010 at 10:56 AM, Terry Reedy wrote: .. > Let me repeat me original question: Would it be feasible to add a [view] > button that I could click to get a nice view of a patch, such as provided by > ViewVC? I would at best +0 on such an addition. As I mentioned before, the largest obstacle for me in reviewing the patches is being unable to open them in the browser due to the use of a non-standard extension. For small patches, as long as they open and are in unified diff format, I don't have a problem reviewing them in plain text view. For larger patches, colored diff offers only a minor improvement over plain text compared to a large improvement I get from Rietveld. I believe this should be treated as any other RFE. AFAICT, tracker sources are available from SVN and metatracker is the place to post a patch. I don't think ViewVC module is available within roundup and there may be licensing issues that need to be looked into before it can be integrated. Other than that, writing viewvc-style diff viewer plugin for roundup does not strike me as a terribly difficult project, but my +0 vote means that I am not going to write it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] View tracker patches with ViewVC?
On Tue, Jul 27, 2010 at 7:56 AM, Terry Reedy wrote:
>> I also suggest that, instead of uploading the patch to Rietveld
>> yourself, you can ask the submitter to do it.
>
> That adds another step.
>
> Let me repeat me original question: Would it be feasible to add a [view]
> button that I could click to get a nice view of a patch, such as provided by
> ViewVC?
How are you proposing to use ViewVC to view the patch? I'd think that
you'd have to commit it first, unless it has some functionality that
I'm unaware of.
Anyway, one uses Rietveld mostly via upload.py, not the form above.
Instead of running 'svn diff' + uploading the patch file in a web
browser and having several versions accumulate, you run `upload.py -i
` and it uploads the diff to rietveld. Rietveld's
diff view is quite nice.
Would the ViewVC functionality you are proposing look like this?
http://svn.python.org/view/python/branches/release27-maint/Demo/classes/Vec.py?r1=82503&r2=83175&pathrev=83175
Rietveld's differ is smarter (it does intra-line diffs) and the inline
comments there are a lot better than pasting the diff into an email.
It's true that the workflow isn't really described anywhere, so I'll
try to outline it in detail here.
Author's steps to upload a patch and create an issue:
- Discuss issue in the tracker
- Hack away at solution in svn checkout
- When done, run `upload.py` (no args creates a new issue and prints URL)
- When prompted, enter Google account credentials
- When prompted, enter the issue title you want to give it, probably
by pasting in the tracker title plus IssueXXX
- I always check the diff on Rietveld to make sure it looks good to me
before sending
- Go to the URL printed and click 'Start Review' to send mail
Reviewer's steps to add review comments:
- Receive mail, click URL to open issue
- Click the link to the first file, and read through the colored diff,
using 'n' to scroll down and 'j' to go to the next file.
- To make a comment, double click the line you want to comment on.
This is the most unintuitive part to beginners.
- Enter the comment in the textbox that appears.
- Repeat until done reading the diff, then go back to the issue page
and click 'Publish+Mail Comments'
Author's steps to respond to comments:
- Open the files in the issue
- Read through the comments ('N' skips from comment to comment)
- Apply fixes, reply to each comment
- Run `upload.py -i ` to add a new patch with your fixes.
- Reply by clicking 'Publish+Mail Comments' to let your reviewer know
that you've addressed the comments
Repeat ad nauseum until reviewer is happy, then commit.
===
Not sure why I spelled that all out when these docs exist:
http://code.google.com/p/rietveld/wiki/CodeReviewHelp
Hopefully my outline reflects the Python workflow more accurately, though. :)
Reid
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mkdir -p in python
On Tue, Jul 20, 2010 at 10:20 AM, R. David Murray wrote: > I'd go with putting it in shutil. +1 I would also call it shutil.mktree which will go well with shutil.rmtree next to it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] View tracker patches with ViewVC?
On 7/27/2010 11:52 AM, Reid Kleckner wrote:
Let me repeat me original question: Would it be feasible to add a [view]
button that I could click to get a nice view of a patch, such as provided by
ViewVC?
How are you proposing to use ViewVC to view the patch? I'd think that
you'd have to commit it first, unless it has some functionality that
I'm unaware of.
The point of the tracker is to review patches *before* they are
committed. The information is the same before and after it is committed.
The question of 'feasible' asks whether ViewVC is inextricably linked to
an svn repository. If it is, either technically or legally, then it is.
Anyway, one uses Rietveld mostly via upload.py, not the form above.
I had never heard of upload.py. Like Rietveld, it is not mentioned in
the tracker docs. I see it mentioned on he rietveld page linked below.
The page says it requires 2.5 (which newcomers will not have laying
aroung)and only says how to run it on *nix, so I would not be surprised
if it were to not run on Windows due to using *nix only functions.
Would the ViewVC functionality you are proposing look like this?
http://svn.python.org/view/python/branches/release27-maint/Demo/classes/Vec.py?r1=82503&r2=83175&pathrev=83175
Yes, I presume that is what some people use to do post-commit reviews.
Rietveld's differ is smarter (it does intra-line diffs)
Ok, that would be even better.
and the inline comments there are a lot better
than out of context comments in a tracker message.
It's true that the workflow isn't really described anywhere,
So don't expect ignorant folks like me to follow it ;-).
so I'll try to outline it in detail here.
Like code patches, doc patches in here-today, gone-tomorrow email is not
too useful. Better to put it the doc or in a tracker issue for further
revision.
Author's steps to upload a patch and create an issue:
- Discuss issue in the tracker
- Hack away at solution in svn checkout
- When done, run `upload.py` (no args creates a new issue and prints URL)
- When prompted, enter Google account credentials
- When prompted, enter the issue title you want to give it, probably
by pasting in the tracker title plus IssueXXX
- I always check the diff on Rietveld to make sure it looks good to me
before sending
- Go to the URL printed and click 'Start Review' to send mail
Reviewer's steps to add review comments:
- Receive mail, click URL to open issue
- Click the link to the first file, and read through the colored diff,
using 'n' to scroll down and 'j' to go to the next file.
- To make a comment, double click the line you want to comment on.
This is the most unintuitive part to beginners.
- Enter the comment in the textbox that appears.
- Repeat until done reading the diff, then go back to the issue page
and click 'Publish+Mail Comments'
Author's steps to respond to comments:
- Open the files in the issue
- Read through the comments ('N' skips from comment to comment)
- Apply fixes, reply to each comment
- Run `upload.py -i` to add a new patch with your fixes.
- Reply by clicking 'Publish+Mail Comments' to let your reviewer know
that you've addressed the comments
Repeat ad nauseum until reviewer is happy, then commit.
===
Not sure why I spelled that all out when these docs exist:
http://code.google.com/p/rietveld/wiki/CodeReviewHelp
Because
a) someone reading http://wiki.python.org/moin/TrackerDocs/
would not know it exists and
b) because the above is *much* cleared than that page.
Let me try to explain better what my original post was about.
There have been many posts on pydev about the need for more patch
reviews. A couple of people have even made 5 for 1 offers to encourage
more reviews and have emphasized that even partial reviews are more
helpful than none. In response to these appeals, including the last
point, I recently starting doing more patch reviews than in the past.
Simple diffs that replace block A with block B I can read fine.
Sufficiently complex diffs, say with 10 interlaced changed, I cannot.
A couple of days ago, I got an email that a doc issue I opened was now
closed with revx, patch never posted to the tracker. I followed the
link, saw the [text] button, and got the page with the colored,
side-by-side display. I thought, "Wow, I wish I could see patches like
this while reviewing, before they are committed!". And to do so just as
easily, with one click. (As it turns out, the patch needed review
because it had a minor error, but that is another issue.)
Rietveld may be a bit better, but it potentially is a lot of work to get
that bit better, especially the firs time. And it may be overkill for
small to medium patches.
So what I am suggesting it this: to get more and better patch reviews,
especially from new reviewers, make it as easy to get an improved view
of diffs as it is now to view the raw file.
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@p
Re: [Python-Dev] View tracker patches with ViewVC?
On Tue, Jul 27, 2010 at 1:19 PM, Terry Reedy wrote: .. > A couple of days ago, I got an email that a doc issue I opened was now > closed with revx, patch never posted to the tracker. I followed the > link, saw the [text] button, and got the page with the colored, side-by-side > display. I thought, "Wow, I wish I could see patches like this while > reviewing, before they are committed!". And to do so just as easily, with > one click. (As it turns out, the patch needed review because it had a minor > error, but that is another issue.) Multicolored diffs may look impressive the first time you see them, but they are not really that useful at the patch review stage. With a text link I often do curl | patch -p0 with pasted after "copy link". That would not work with a rev-style link. Copying code from side by side view may or may not work depending on your browser. Even with doc patches, for a serious review you need to apply and compile the patch (make html in case of the docs.) Post-commit rev link offers much more than a nice diff: it shows comments, allows you to explore the history etc. Colored diffs do help spotting spelling mistakes, but there is not much harm in finding them post-commit. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] View tracker patches with ViewVC?
On 7/27/2010 1:48 PM, Alexander Belopolsky wrote: Multicolored diffs may look impressive the first time you see them, Side-by-side was the important part > Copying code from side by side view may or may not work depending on your browser. It is a nuisance with FireFox. For a patch on the tracker, I would cut from the raw diff. Even with doc patches, for a serious review you need to apply and compile the patch (make html in case of the docs.) I know that and I would not commit an issue without doing that. I am talking about partial pre-commit reviews by a beginner who does not have the tools to do that. The kind that have been requested here on pydev. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] View tracker patches with ViewVC?
On 7/27/10 2:31 PM, Terry Reedy wrote: On 7/27/2010 1:48 PM, Alexander Belopolsky wrote: Multicolored diffs may look impressive the first time you see them, Side-by-side was the important part > Copying code from side by side view may or may not work depending on your browser. It is a nuisance with FireFox. For a patch on the tracker, I would cut from the raw diff. Even with doc patches, for a serious review you need to apply and compile the patch (make html in case of the docs.) I know that and I would not commit an issue without doing that. I am talking about partial pre-commit reviews by a beginner who does not have the tools to do that. The kind that have been requested here on pydev. I agree with Terry that this would be a useful feature to have integrated with the tracker. I'd use it. But until someone write it, it's an academic point. -- Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] View tracker patches with ViewVC?
On Tue, Jul 27, 2010 at 2:48 PM, Eric Smith wrote: .. > I agree with Terry that this would be a useful feature to have integrated > with the tracker. I'd use it. But until someone write it, it's an academic > point. I don't say it is useless. It is just not useful enough to justify the required development effort. A low hanging fruit in this area would be to teach the tracker to recognize diffs regardless of file extension and present them as text/plain. For me that would give 99% of the benefit a full-blown diff-to-html converter may bring. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] View tracker patches with ViewVC?
> On Tue, Jul 27, 2010 at 2:48 PM, Eric Smith wrote: > .. >> I agree with Terry that this would be a useful feature to have >> integrated >> with the tracker. I'd use it. But until someone write it, it's an >> academic >> point. > > I don't say it is useless. And I never said you said that :) > It is just not useful enough to justify > the required development effort. A low hanging fruit in this area > would be to teach the tracker to recognize diffs regardless of file > extension and present them as text/plain. For me that would give 99% > of the benefit a full-blown diff-to-html converter may bring. That would be sort of handy, but detecting a diff is of course problematic. I'd rather have the viewvc sort of view, but it's moot until someone does the work. I don't want it bad enough to write it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] View tracker patches with ViewVC?
Am 27.07.2010 16:56, schrieb Terry Reedy: > On 7/27/2010 1:42 AM, "Martin v. Löwis" wrote: >>> Should I open a tracker issue to add something to the tracker doc? >> >> I recommend that you use it for some time before changing anything. > > How is someone suppose to use it without instructions? I'd expect that most committers would be able to learn using it quickly, without explicit instructions. However, I think there might also be a Rietveld manual somewhere. > Let me repeat me original question: Would it be feasible to add a [view] > button that I could click to get a nice view of a patch, such as > provided by ViewVC? I think this would be very difficult to implement, plus it would be a wasted effort, since we are going to switch to Mercurial, and would stop using ViewVC. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] View tracker patches with ViewVC?
On 26/07/2010 01:24, Terry Reedy wrote: To review a patch on the tracker, I have to read and try to make sense of the raw diff file. Sometimes that is easy, sometimes not. *After* a patch is applied, I can click the rev link and then the 'text changed' link and see a nice, colored, side-by-side web-pace view created by ViewVC. Is there any way a 'view' button could be added, along with the current edit and remove buttons, to produce the same web page and make it easier to review patches *before* commitment? Apologies if I've missed this from earlier parts of this thread. On my windows box I have maintainance versions for 2.6, 2.7, 3.1 and 3.2 plus tortoisesvn. Download the patch file, right click, select tortoisesvn then apply patch. Go to the version I'm interested in. Double click to select the unit test file to start things off. If I'm lucky get a coloured output in parallel highlighting removals, additions and conflicts. If I'm unlucky, get the message "The patch seems outdated". Is this what you're asking for? Can this be (simply) implemented on the issue tracker? What do *nix or OS X users do? Cheers. Mark Lawrence. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] View tracker patches with ViewVC?
> On my windows box I have maintainance versions for 2.6, 2.7, 3.1 and 3.2 > plus tortoisesvn. Download the patch file, right click, select > tortoisesvn then apply patch. Go to the version I'm interested in. > Double click to select the unit test file to start things off. If I'm > lucky get a coloured output in parallel highlighting removals, additions > and conflicts. If I'm unlucky, get the message "The patch seems > outdated". Is this what you're asking for? Can this be (simply) > implemented on the issue tracker? What do *nix or OS X users do? Automatically checking whether a patch still applies? That could certainly be implemented, although it might be expensive in terms of CPU time. Anything more frequent than daily runs is likely not feasible. In addition, it might be tricky to determine what branches a patch is meant to apply to. It would be nice if the patch author gets notified when a patch becomes stale, but that would require to be certain what branches a patch is targetted for. In any case: contributions are welcome. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] versioned .so files for Python 3.2
On Jul 26, 2010, at 10:53 PM, Ralf Schmitt wrote: >Some of the things that need to be adapted are e.g. Makefiles >(basically anything that assumes modules have a certain name), all of >the freezers (cxFreeze, py2exe, ...). The biggest problem probably >will be that an import will load the wrong module or no module at all. >I'm just speculating here... I took a look at cx_freeze - it doesn't support Python 3.2 yet afaict (the build fails but it may be shallow). I'm going to look at py2exe as soon as I can get a Windows VM up and running. Since import is (usually) handled by the built-in dynload_shlib.c code it should generally Just Work I think, unless some application installs custom import hooks. In any case, I think this will be a fairly standard and probably simple, porting effort, which goes along with supporting any new major release. >> "Change is bad" isn't a constructive argument. ;) > >Did I make that argument? Apologies. >> That's fine, but it's not the way Debian/Ubuntu works today. PEP >> 3149 adoption will definitely remove significant complication for >> deploying multiple Python versions at the same time on those systems. > >You're just moving that complication into python. It's a much different level and scope of complexity though. For Python, it's pretty simple: look for an additional .so file name pattern which gets baked into Python at compile time. For that, you're able to remove a huge amount of complexity on Debian/Ubuntu by removing the need to manage multiple directory trees and symlinks between files in those trees. The tools that manage them (i.e. handle package installs and removals) also get much simpler. I think it's a worthwhile trade-off. Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] versioned .so files for Python 3.2
On Jul 27, 2010, at 01:54 PM, Ralf Schmitt wrote: >Matthias Klose writes: > >> Not true. Package managers like dpkg/apt-get, rpm/yum and maybe >> others do this for ages. And yes, the added "complexity" of package >> managers does lead to increased robustness. > >but how does sharing things lead to increased robustness (even if it >might be managed by your package manager)? It removes the need to maintain multiple directory trees and the symlinks between them. The tools that manage all this platform complexity get simpler, and thus easier to maintain, leading to increased robustness on the platform. Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New regex module for 3.2?
On Tue, 27 Jul 2010 08:27:35 +0200, Stefan Behnel wrote: > Gregory P. Smith, 27.07.2010 07:40: > > A max cache size of 100 was too small. I just increased it to 500 in the > > py3k branch along with implementing a random replacement cache overflow > > policy. It now randomly drops 20% of the compiled regular expression cache > > instead of simply dropping the entire cache on overflow. > > > > With the regex_v8 benchmark, the better cache replacement policy sped it up > > ~7% while raising the cache size on top of that (likely meaning the cache > > was never overflowing) sped it up ~25%. > > > > Random replacement without dropping everything at least means apps thrashing > > the cache degrade much more gracefully. > > The same algorithm should be helpful in ElementTree's ElementPath module. We recently added the old re cache-clearing strategy to fnmatch, because previously its cache would grow indefinitely. It sounds like this should be applied there as well. That's three...time to figure out how to share the code? -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] caching in the stdlib? (was: New regex module for 3.2?)
R. David Murray, 28.07.2010 03:43: On Tue, 27 Jul 2010 08:27:35 +0200, Stefan Behnel wrote: Gregory P. Smith, 27.07.2010 07:40: A max cache size of 100 was too small. I just increased it to 500 in the py3k branch along with implementing a random replacement cache overflow policy. It now randomly drops 20% of the compiled regular expression cache instead of simply dropping the entire cache on overflow. With the regex_v8 benchmark, the better cache replacement policy sped it up ~7% while raising the cache size on top of that (likely meaning the cache was never overflowing) sped it up ~25%. Random replacement without dropping everything at least means apps thrashing the cache degrade much more gracefully. The same algorithm should be helpful in ElementTree's ElementPath module. We recently added the old re cache-clearing strategy to fnmatch, because previously its cache would grow indefinitely. It sounds like this should be applied there as well. That's three...time to figure out how to share the code? What about actually putting it visibly into the stdlib? Except for files, I didn't see much about caching there, which seems like a missing battery to me. Why not do it as with the collections module and add stuff as it comes in? Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New regex module for 3.2?
On Tue, Jul 27, 2010 at 6:43 PM, R. David Murray wrote: > On Tue, 27 Jul 2010 08:27:35 +0200, Stefan Behnel > wrote: > > Gregory P. Smith, 27.07.2010 07:40: > > > A max cache size of 100 was too small. I just increased it to 500 in > the > > > py3k branch along with implementing a random replacement cache overflow > > > policy. It now randomly drops 20% of the compiled regular expression > cache > > > instead of simply dropping the entire cache on overflow. > > > > > > With the regex_v8 benchmark, the better cache replacement policy sped > it up > > > ~7% while raising the cache size on top of that (likely meaning the > cache > > > was never overflowing) sped it up ~25%. > > > > > > Random replacement without dropping everything at least means apps > thrashing > > > the cache degrade much more gracefully. > > > > The same algorithm should be helpful in ElementTree's ElementPath module. > > We recently added the old re cache-clearing strategy to > fnmatch, because previously its cache would grow indefinitely. > It sounds like this should be applied there as well. > > That's three...time to figure out how to share the code? > No doubt. Its already a standalone _shrink_cache function with unit tests that doesn't care the dictionaries it is shrinking are composed of. Easy enough to move somewhere more useful. Any proposed stdlib locations? I'll be offline on vacation soon so I may not get to it for a couple weeks but feel free to move it without me if anyone is interested. -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
