Re: [Python-Dev] devguide: Cover how to (un-)apply a patch.
On Mon, Jan 17, 2011 at 06:19:50PM -0600, [email protected] wrote: > Antoine> On Mon, 17 Jan 2011 23:37:07 +0100 > Antoine> brett.cannon wrote: > >> + > >> +To undo a patch, do:: > >> + > >> +patch -R -p0 < patch.diff > >> + > > Antoine> Or, simply and more reliably, use the corresponding VCS > Antoine> incantation ("svn revert -R ." or "hg revert -a"). > > I prefer Brett's solution. It's one command instead of one command per VCS. > It works with other version control systems and provides me the opportunity > to save a copy I can restore later. "hg revert" saves files before reverting as *.orig. Oleg. -- Oleg Broytmanhttp://phdru.name/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devguide: Write a guide to committing a patch.
On Tue, 18 Jan 2011 07:14:51 +0100 Ezio Melotti wrote: > > + > > +Committing Patches > > +== [...] > > + > > +svnmerge.py merge -r 42 > > + > > +This will try to apply the patch to the current patch and generate a > > commit Do we want to spend so much time explaining how to use SVN for core developers while we're supposed to switch to Mercurial Real Soon Now? (current core devs already know how to use it, and we don't get many new ones every month) Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Moving stuff out of Misc and over to the devguide
On Tue, Jan 18, 2011 at 10:17 AM, Brett Cannon wrote: > I am not describing what is in Misc. > > It comes down to a question of whether any core dev-specific stuff > should be in Misc that is not a configuration file or not. I say no, > that the directory should contain stuff that applies to everyone and > not specifically to core devs. In that case, I think the memory profiling and debugging info should stay there, as should the build info. Not only can that stuff change between version, but it can all be useful to people that are merely embedding Python or invoking other code from it, and need to dig deeply into what is going on to figure things out. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devguide: Write a guide to committing a patch.
On Tue, Jan 18, 2011 at 10:35 PM, Antoine Pitrou wrote: > On Tue, 18 Jan 2011 07:14:51 +0100 > Ezio Melotti wrote: >> > + >> > +Committing Patches >> > +== > [...] >> > + >> > + svnmerge.py merge -r 42 >> > + >> > +This will try to apply the patch to the current patch and generate a >> > commit > > Do we want to spend so much time explaining how to use SVN for core > developers while we're supposed to switch to Mercurial Real Soon Now? > (current core devs already know how to use it, and we don't get many > new ones every month) Yes, since it makes it clear where the new hg instructions need to go and the minimum set of operations they have to cover. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tidying up the Meta-PEP and Other Informational PEP sections of PEP 0
python-checkins watchers would be aware that I just checked in a few
changes to the PEP 0 generator (and a few PEP statuses) to start
tidying up the first two sections of PEP 0. The old release schedule
PEPs and similarly obsolete files have been moved down to a new
historical section later in the document.
This was mostly straightforward and non-controversial, but I ran into
a problem with the Informational PEPs: we use the same status
("Final") to mean two completely different things for those PEPs.
For the release schedule PEPs it means "done and dusted" (similar to
the meaning for ordinary PEPs). For the API standardisation PEPs (like
WSGI) it instead means the spec has been locked down and any changes
will require a new PEP. This caused a problem for the PEP 0 generator,
since the former kind of PEP should be moved to the new historical
section, while the latter kind should remain up top.
Would anyone object if I switched all the API definition PEPs to the
"Active" state? PEP 1 indicates that is the appropriate state for
reference PEPs that are never truly "finished" (in the sense of code
being implemented and committed to the source control system).
In addition, I would like to mark PEP 42 as Withdrawn and PEP 3100 as
Final (the former is a random grab bag of feature requests better
handled via the tracker, while the latter is a similar py3k grab bag,
except we either did most of the things it lists or deliberately chose
not to)
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devguide: Write a guide to committing a patch.
On Tue, Jan 18, 2011 at 05:18, Nick Coghlan wrote: > On Tue, Jan 18, 2011 at 10:35 PM, Antoine Pitrou wrote: >> On Tue, 18 Jan 2011 07:14:51 +0100 >> Ezio Melotti wrote: >>> > + >>> > +Committing Patches >>> > +== >> [...] >>> > + >>> > + svnmerge.py merge -r 42 >>> > + >>> > +This will try to apply the patch to the current patch and generate a >>> > commit >> >> Do we want to spend so much time explaining how to use SVN for core >> developers while we're supposed to switch to Mercurial Real Soon Now? >> (current core devs already know how to use it, and we don't get many >> new ones every month) > > Yes, since it makes it clear where the new hg instructions need to go > and the minimum set of operations they have to cover. Plus it's from the dev FAQ so I didn't have to go and figure something out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] devguide: Write a guide to committing a patch.
On Mon, Jan 17, 2011 at 22:14, Ezio Melotti wrote: > Hi, > > On Thu, Jan 13, 2011 at 12:44 AM, brett.cannon > wrote: >> >> brett.cannon pushed 75300a08c6d7 to devguide: >> >> http://hg.python.org/devguide/rev/75300a08c6d7 >> changeset: 88:75300a08c6d7 >> tag: tip >> user: Brett Cannon >> date: Wed Jan 12 15:44:04 2011 -0800 >> summary: >> Write a guide to committing a patch. >> >> files: >> committing.rst >> faq.rst >> index.rst >> >> diff --git a/committing.rst b/committing.rst >> new file mode 100644 >> --- /dev/null >> +++ b/committing.rst >> @@ -0,0 +1,47 @@ >> +.. _committing: >> + >> +Committing Patches >> +== >> + >> +As a core developer you will occasionally want to commit a patch created >> by >> +someone else. When doing so you will want to make sure of some things. >> + >> +First, make sure the patch in a good state. Both :ref:`patch` and >> :ref:`triage` >> +explain what is to be expected of a patch. Typically patches that get >> passed by >> +triagers are good to go except maybe lacking ``Misc/ACKS`` and >> ``Misc/NEWS`` >> +entries. >> + >> +Second, make sure the patch does not break backwards-compatibility >> without a >> +good reason. This means :ref:`running the test suite ` to make >> sure >> +everything still passes. It also means that if semantics do change there >> must >> +be a good reason for the the breakage of code the change will cause (and >> it >> +**will** break someone's code). If you are unsure if the breakage is >> worth it, >> +ask on python-dev. >> + >> +Third, backport as necessary. If the patch is a bugfix and it does not >> break >> +backwards-compatibility *at all*, then backport it to the branch(es) in >> +maintenance mode. The easiest way to do this is to apply the patch in the >> +development branch, commit, and then use svnmerge.py_ to backport the >> patch. >> + >> +For example, let us assume you just made commit 42 in the development >> branch >> +and you want to backport it to the ``release31-maint`` branch. You would >> change >> +your working directory to the maintenance branch and run the command:: >> + >> + svnmerge.py merge -r 42 >> + >> +This will try to apply the patch to the current patch and generate a >> commit > > s/current patch/current branch/ Fixed in a previous commit. > >> >> +message. You will need to revert ``Misc/NEWS`` and do a new entry (the >> file >> +changes too much between releases to ever have a merge succeed). Once >> your >> +checkout is ready to be committed, do:: > > Here you could mention that there are two ways to deal with files that have > conflicts (marked with 'C' by svn): > 1) revert them with 'svn revert filename' and then change them manually; > 2) edit the file directly to resolve the conflict and then use 'svn resolved > filename'; > until there are no more files marked with 'C' in 'svn stat'. > It's also a good idea to cat svnmerge-commit-message.txt and double check > that the message is correct. Done. > >> >> + >> + svn ci -F svnmerge-commit-message.txt >> + >> +This will commit the bacport along with using the commit message created >> by > > s/bacport/backport/ Fixed in a previous commit. > >> >> +``svnmerge.py`` for you. >> + >> +If it turns out you do not have the time to do a backport, then at least >> leave >> +the proper issue open on the tracker with a note specifying that the >> change >> +should be backported so someone else can do it. > > Maybe a short paragraph about "svnmerge block" can be included here. No because I have not seen people bother with svnmerge block in a while. -Brett > >> >> + >> + >> +.. _svnmerge.py: >> http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svnmerge/svnmerge.py >> diff --git a/faq.rst b/faq.rst >> --- a/faq.rst >> +++ b/faq.rst >> @@ -44,65 +44,6 @@ >> === >> == >> == >> >> >> -How do I prepare a new branch for merging? >> --- >> - >> -You need to initialize a new branch by having ``svnmerge.py`` discover >> the >> -revision number that the branch was created with. Do this with the >> command:: >> - >> - svnmerge.py init >> - >> -Then check in the change to the root of the branch. This is a one-time >> -operation (i.e. only when the branch is originally created, not when each >> -developer creates a local checkout for the branch). >> - >> - >> -How do I merge between branches? >> - >> - >> -In the current situation for Python there are four branches under >> development, >> -meaning that there are three branches to merge into. Assuming a change is >> -committed into ``trunk`` as revision 0001, you merge into the 2.x >> maintenance >> -by doing:: >> - >> - # In the 2.x maintenance branch checkout. >> - svnmerge.py merge -r 0001 >> - svn commit -F svnmerge-commit-message.txt
Re: [Python-Dev] devguide: Cover how to (un-)apply a patch.
>> I prefer Brett's solution. It's one command instead of one command >> per VCS. It works with other version control systems and provides me >> the opportunity to save a copy I can restore later. Georg> It assumes you already have the copy. Sure, but the way to get the input to the patch command is easy, and is probably almost the same for any version control system: whatever-vcs diff > patch.diff The odds that someone will remember the syntax for the diff command for the VCS are much higher than the revert command. My guess is "diff" is executed more often than any other version control commands except "update" and "commit", and far more often than "revert". Personally, I'm not sure I've ever used "revert" more than a handful of times in my entire professional lifetime. I realize the world is passing me by and that I'm rapidly turning into a dinosaur w.r.t. distributed version control, but as you write/update the developer's guide remember that proficiency in Python does not necessarily equate to proficiency in version control systems, especially with the less frequently used commands. I personally would prefer that more general commands and concepts be used where possible so that newcomers not be put off unnecessarily by the complexity of version control. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception __name__ missing?
On 01/18/2011 01:14 AM, Georg Brandl wrote: For these cases, you can use traceback.format_exception_only(). Thanks George, That works nicely. Ron ;-) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [concurrentrotatingfilehandler]: How are the log files split up ?
Dear people, I am currently using concurrentrotatingfilehandler to handle my Python logs. The situation is okay when it's only one log, but when it needs to spill over to the next log (I configured to have 2) say test.log.2 then I see that the output is sort of shared between the first log test.log and test.log.2. Am I supposed to concatenate all the logs together to get my logs back ? Google hasn't brought back any results, so I am wondering is it just me using or reading the resultant logs wrong? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [concurrentrotatingfilehandler]: How are the log files split up ?
Hello. We are sorry but we cannot help you. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing list/news group is the best place; there are Python developers who participate in it; you may get a faster, and probably more complete, answer there. See http://www.python.org/community/ for other lists/news groups/fora. Thank you for understanding. On Wed, Jan 19, 2011 at 01:02:09PM +0800, low kian seong wrote: > Dear people, > > I am currently using concurrentrotatingfilehandler to handle my Python logs. > The situation is okay when it's only one log, but when it needs to spill > over to the next log (I configured to have 2) say test.log.2 then I see that > the output is sort of shared between the first log test.log and test.log.2. > > Am I supposed to concatenate all the logs together to get my logs back ? > Google hasn't brought back any results, so I am wondering is it just me > using or reading the resultant logs wrong? > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/phd%40phdru.name Oleg. -- Oleg Broytmanhttp://phdru.name/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
