Mailman 3 January 2011 - Python-Dev

Re: [Python-Dev] [Python-checkins] devguide: Short doc about where to get tech help related to developing Python.
by Sandro Tosi 20 Jan '11

20 Jan '11

Hi, On Wed, Jan 19, 2011 at 23:19, brett.cannon <python-checkins(a)python.org> wrote: > +Where to Get Help > +================= > +If you are working on Python it is very possible you will come across an issue > +where you need some assistance in solving (this happens to core developers all > +the time). You have a couple of options depending on what kind of help you need. > +If the question involves process or tool usage then please check the developer's > +guide first as is should answer your question. as it should > +Filing a Bug > +------------ > +If you come across an odd error message that seems like a bug, then file a bug > +on the `issue tracker`_. In the bug you can explain that you are not sure why > +the error is coming up or that the exact nature of the problem is. Someone will ...or what the exact...? > +Asking a Technical Question > +--------------------------- > +You have two avenues of communication out of the :ref:`myriad of options > +available <communication>`. If you are comfortable with IRC you can try asking > +in #python-dev. Typically there are a couple of experienced developers, ranging > +from triagers to core developers, who can ask questions about developing for who can answer questions Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi

2 1

Re: [Python-Dev] r88122 - python/branches/py3k/Doc/whatsnew/3.2.rst
by Antoine Pitrou 20 Jan '11

20 Jan '11

On Thu, 20 Jan 2011 10:47:04 +0100 (CET) raymond.hettinger <python-checkins(a)python.org> wrote: > > +Code Repository > +=============== > + > +In addition to the existing Subversion code repository at http://svn.python.org > +there is now a `Mercurial <http://mercurial.selenic.com/>`_ repository at > +http://hg.python.org/ . Shouldn't we wait until that repository is ready? Right now people willing to work with it will get the surprise that it hasn't been updated for 3 months. Regards Antoine.

2 2

Re: [Python-Dev] [Python-checkins] r88121 - python/branches/py3k/Doc/whatsnew/3.2.rst
by Victor Stinner 20 Jan '11

20 Jan '11

Le jeudi 20 janvier 2011 à 10:04 +0100, raymond.hettinger a écrit : > +Some operating systems allow direct access to the unencoded bytes in the > +environment. If so, the :attr:`os.supports_bytes_environ` constant will be > +true. > + > +For direct access to unencoded environment variables (if available), > +use the new :func:`os.getenvb` function or use :data:`os.environb` > +which is a bytes version of :data:`os.environ`. Hum, I think that "undecoded" bytes term is more appropriate. You can decode bytes and encode characters, but not the opposite. Victor

2 1

Re: [Python-Dev] [Python-checkins] r88119 - in python/branches/py3k/Doc: library/inspect.rst whatsnew/3.2.rst
by Victor Stinner 20 Jan '11

20 Jan '11

Le jeudi 20 janvier 2011 à 05:03 +0100, raymond.hettinger a écrit : > * Python's import mechanism can now load modules installed in directories with > - non-ASCII characters in the path name. > + non-ASCII characters in the path name: > + > + >>> import møøse.bites > > (Required extensive work by Victor Stinner in :issue:`9425`.) Ooops, it is not the good example :-) In this example, møøse is not a module path, but a module name... And Python 3.2 doesn't support correctly non-ASCII module names on all operating systems yet (see "[Python-Dev] Import and unicode: part two" thread :-)). #9425 only concerns sys.path (eg. sys.path.append('/home/møøse/modules/')). Victor

1 0

Tidying up the Meta-PEP and Other Informational PEP sections of PEP 0
by Nick Coghlan 19 Jan '11

19 Jan '11

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 | ncoghlan(a)gmail.com | Brisbane, Australia

2 2

Re: [Python-Dev] devguide: Cover how to (un-)apply a patch.
by Antoine Pitrou 19 Jan '11

19 Jan '11

On Mon, 17 Jan 2011 23:37:07 +0100 brett.cannon <python-checkins(a)python.org> wrote: > + > +To undo a patch, do:: > + > + patch -R -p0 < patch.diff > + Or, simply and more reliably, use the corresponding VCS incantation ("svn revert -R ." or "hg revert -a"). Regards Antoine.

11 23

[concurrentrotatingfilehandler]: How are the log files split up ?
by low kian seong 18 Jan '11

18 Jan '11

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?

2 1

Exception __name__ missing?
by Ron Adam 18 Jan '11

18 Jan '11

Is this on purpose? Python 3.2rc1 (py3k:88040, Jan 15 2011, 18:11:39) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> Exception.__name__ 'Exception' >>> e = Exception('has no name') >>> e.__name__ Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'Exception' object has no attribute '__name__' Ron Adam

5 7

Re: [Python-Dev] [Python-checkins] devguide: Write a guide to committing a patch.
by Brett Cannon 18 Jan '11

18 Jan '11

On Mon, Jan 17, 2011 at 22:14, Ezio Melotti <ezio.melotti(a)gmail.com> wrote: > Hi, > > On Thu, Jan 13, 2011 at 12:44 AM, brett.cannon <python-checkins(a)python.org> > wrote: >> >> brett.cannon pushed 75300a08c6d7 to devguide: >> >> http://hg.python.org/devguide/rev/75300a08c6d7 >> changeset: 88:75300a08c6d7 >> tag: tip >> user: Brett Cannon <brett(a)python.org> >> 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 <runtests>` 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/svnmer… >> 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 # r0002 >> - >> -To pull into py3k:: >> - >> - # In a py3k checkout. >> - svnmerge.py merge -r 0001 >> - svn commit -F svnmerge-commit-message.txt # r0003 >> - >> -The 3.x maintenance branch is a special case as you must pull from the >> py3k >> -branch revision, *not* trunk:: >> - >> - # In a 3.x maintenance checkout. >> - svnmerge.py merge -r 0003 # Notice the rev is the one from py3k! >> - svn resolved . >> - svn commit -F svnmerge-commit-message.txt >> - >> - >> -How do I block a specific revision from being merged into a branch? >> -------------------------------------------------------------------- >> - >> -With the revision number that you want to block handy and >> ``svnmerge.py``, go >> -to your checkout of the branch where you want to block the revision and >> run:: >> - >> - svnmerge.py block -r <revision #> >> - >> -This will modify the repository's top directory (which should be your >> current >> -directory) and create ``svnmerge-commit-message.txt`` which contains a >> -generated log message. >> - >> -If the command says "no available revisions to block", then it means >> someone >> -already merged the revision. >> - >> -To check in the new metadata, run:: >> - >> - svn ci -F svnmerge-commit-message.txt >> - >> >> SSH >> ======= >> @@ -158,21 +99,6 @@ >> >> .. _Pageant: >> http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html >> >> -Can I make check-ins from machines other than the one I generated the >> keys on? >> >> ------------------------------------------------------------------------------- >> - >> -Yes, all you need is to make sure that the machine you want to check >> -in code from has both the public and private keys in the standard >> -place that ssh will look for them (i.e. ~/.ssh on Unix machines). >> -Please note that although the key file ending in .pub contains your >> -user name and machine name in it, that information is not used by the >> -verification process, therefore these key files can be moved to a >> -different computer and used for verification. Please guard your keys >> -and never share your private key with anyone. If you lose the media >> -on which your keys are stored or the machine on which your keys are >> -stored, be sure to report this to pydotorg(a)python.org at the same time >> -that you change your keys. >> - >> >> >> Editors and Tools >> diff --git a/index.rst b/index.rst >> --- a/index.rst >> +++ b/index.rst >> @@ -16,6 +16,7 @@ >> languishing >> communication >> coredev >> + committing >> >> >> .. todolist:: >> @@ -48,7 +49,7 @@ >> * :ref:`languishing` >> * :ref:`communication` >> * :ref:`coredev` >> - * `Committing patches <XXX>`_ >> + * :ref:`committing` >> >> >> Proposing changes to Python itself >> >> -- >> Repository URL: http://hg.python.org/devguide >> _______________________________________________ >> Python-checkins mailing list >> Python-checkins(a)python.org >> http://mail.python.org/mailman/listinfo/python-checkins >> > > Best Regards, > Ezio Melotti > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins > >

1 0

Re: [Python-Dev] devguide: Write a guide to committing a patch.
by Antoine Pitrou 18 Jan '11

18 Jan '11

On Tue, 18 Jan 2011 07:14:51 +0100 Ezio Melotti <ezio.melotti(a)gmail.com> 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.

3 2