[Python-Dev] Fwd: [docs] Python documentation missing
Hello, this happens every time we cut a RC release: the files referenced in the download section are missing and (rightfully so) people complain -- Forwarded message -- From: Ronald Legere rjl...@gmail.com Date: Wed, May 13, 2015 at 11:14 AM Subject: [docs] Python documentation missing To: d...@python.org The links to the downloadable documentation for python 2.7 are 404 on this page: https://docs.python.org/2/download.html Are they available somewhere -- Ron Legere (rjl...@gmail.com) C'est le temps que tu as perdu pour ta rose qui fait ta rose si importante ___ docs mailing list d...@python.org https://mail.python.org/mailman/listinfo/docs -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: [docs] Python documentation missing
On Wed, May 13, 2015 at 1:36 PM, Benjamin Peterson benja...@python.org wrote: On Wed, May 13, 2015, at 13:22, Sandro Tosi wrote: Hello, this happens every time we cut a RC release: the files referenced in the download section are missing and (rightfully so) people complain In this case, it was because the Python 3.5 docs were failing to build. Should be fixed in ~12 hours. awesome! that was also a sort of heads up that it has happened regularly in the past (I can remember for sure since last summer at least) that cutting a RC release broke the doc download Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #14814: addition of the ipaddress module (stage 1 - code and tests)
On Tue, May 22, 2012 at 10:43 PM, Terry Reedy tjre...@udel.edu wrote: On 5/22/2012 3:59 PM, Sandro Tosi wrote: On Sun, May 20, 2012 at 7:18 PM, Terry Reedytjre...@udel.edu wrote + Args: + first: the first IPv4Address or IPv6Address in the range. + last: the last IPv4Address or IPv6Address in the range. + + Returns: + An iterator of the summarized IPv(4|6) network objects. Very clear as to types. I don't think I get exactly what you mean here. This docstring clearly says what the input type is instead of the more vague 'address'. Also, the output is pretty clearly an iterable of IPv#Address objects. I meant to contrast this as a good example compared to some of the previous docstrings. Ah now I see, thanks for fixing my understanding ;) Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] [Python-checkins] cpython: Issue #14814: addition of the ipaddress module (stage 1 - code and tests)
Thanks Terry for the review! I've attached a patch to issue14814 addressing your points; but.. On Sun, May 20, 2012 at 7:18 PM, Terry Reedy tjre...@udel.edu wrote: +def _get_prefix_length(number1, number2, bits): + Get the number of leading bits that are same for two numbers. + + Args: + number1: an integer. + number2: another integer. + bits: the maximum number of bits to compare. + + Returns: + The number of leading bits that are the same for two numbers. + + + for i in range(bits): + if number1 i == number2 i: This non-PEP8 spacing is awful to read. The double space after the tighter binding operator is actively deceptive. Please use if number1 i == number2 i: I don't see this (and all the other) spacing issue you mentioned. Is it possible that your mail client had played some funny tricks? + Args: + first: the first IPv4Address or IPv6Address in the range. + last: the last IPv4Address or IPv6Address in the range. + + Returns: + An iterator of the summarized IPv(4|6) network objects. Very clear as to types. I don't think I get exactly what you mean here. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] cpython (2.7): Issue #14448: mention pytz; patch by Andrew Svetlov
On Wed, Apr 25, 2012 at 20:40, Georg Brandl g.bra...@gmx.net wrote: BTW, the single backticks don't do anything usable; use *pytz* to make something emphasized. yep, done. On Thu, Apr 26, 2012 at 03:06, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Apr 26, 2012 at 4:40 AM, Georg Brandl g.bra...@gmx.net wrote: Maybe it's useful to mention that that database is the one used on Linux (is it on other Unices?) and Windows has its own? pytz always uses the Olson/IANA database. I don't think we need to confuse matters further by mentioning the fact that Microsoft invented their own system without worrying about what anyone else was doing. I agree with that, so i'm about to commit a very similar diff than the one posted here. Thanks for your suggestions! -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] cpython (2.7): Issue #14448: mention pytz; patch by Andrew Svetlov
Hi Georg, thanks for the review! On Wed, Apr 25, 2012 at 09:37, Georg Brandl g.bra...@gmx.net wrote: On 24.04.2012 19:48, sandro.tosi wrote: http://hg.python.org/cpython/rev/e0e421133d0f changeset: 76532:e0e421133d0f branch: 2.7 parent: 76527:22767284de99 user: Sandro Tosi sandro.t...@gmail.com date: Tue Apr 24 19:43:33 2012 +0200 summary: Issue #14448: mention pytz; patch by Andrew Svetlov files: Doc/library/datetime.rst | 8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/Doc/library/datetime.rst b/Doc/library/datetime.rst --- a/Doc/library/datetime.rst +++ b/Doc/library/datetime.rst @@ -1521,6 +1521,14 @@ other fixed-offset :class:`tzinfo` subclass (such as a class representing only EST (fixed offset -5 hours), or only EDT (fixed offset -4 hours)). +.. seealso:: + + `pytz http://pypi.python.org/pypi/pytz/`_ + The Standard Library has no :class:`tzinfo` instances except for UTC, but we don't capitalize standard library + it exists a third-party library which brings Olson timezone database to ^^ there ^ the sigh, you're right: I'll fix them once the below point is clarified Also, I'm not sure everybody knows what the Olson database is, so maybe that should be explained too. I had considered that, but then I found another reference of Olson database in an example right before the seealso note, so I left it as it is. On a second thought, it might be better to clarify what Olson db is, do you think a link (f.e to here: http://www.iana.org/time-zones ) could be enough or (or in addition) also a brief note is needed? cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] cpython (2.7): Issue #14448: mention pytz; patch by Andrew Svetlov
On Wed, Apr 25, 2012 at 11:55, Nick Coghlan ncogh...@gmail.com wrote: On Wed, Apr 25, 2012 at 6:21 PM, Sandro Tosi sandro.t...@gmail.com wrote: On Wed, Apr 25, 2012 at 09:37, Georg Brandl g.bra...@gmx.net wrote: Also, I'm not sure everybody knows what the Olson database is, so maybe that should be explained too. I had considered that, but then I found another reference of Olson database in an example right before the seealso note, so I left it as it is. On a second thought, it might be better to clarify what Olson db is, do you think a link (f.e to here: http://www.iana.org/time-zones ) could be enough or (or in addition) also a brief note is needed? I think another see also with a link to that page would be appropriate. With maintenance of the database transferred to the IANA, I'd also rephrase the reference as the IANA timezone database (also known as the Olson database) Ah yes, I like that; what about this change (where the IANA tz db section is brutally copied from their website): diff --git a/Doc/library/datetime.rst b/Doc/library/datetime.rst --- a/Doc/library/datetime.rst +++ b/Doc/library/datetime.rst @@ -1524,12 +1524,19 @@ .. seealso:: `pytz http://pypi.python.org/pypi/pytz/`_ - The Standard Library has no :class:`tzinfo` instances except for UTC, but - it exists a third-party library which brings Olson timezone database to - Python: `pytz`. + The standard library has no :class:`tzinfo` instances except for UTC, but + there exists a third-party library which brings the `IANA timezone + database` (also known as the Olson database) to Python: `pytz`. `pytz` contains up-to-date information and its usage is recommended. + `IANA timezone database http://www.iana.org/time-zones`_ + The Time Zone Database (often called tz or zoneinfo) contains code and + data that represent the history of local time for many representative + locations around the globe. It is updated periodically to reflect changes + made by political bodies to time zone boundaries, UTC offsets, and + daylight-saving rules. + .. _strftime-strptime-behavior: Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] problem after installing python 3.2.2
Hello Vahid, i'm sorry but this mailing list is not the right place where to ask such question, I suggest get in touch with http://mail.python.org/mailman/listinfo/python-list for support. On Sat, Feb 18, 2012 at 18:15, Vahid Ghaderi vahid_male1...@yahoo.com wrote: i have downloaded and installed python 3.2.2 but still when i use python in terminal it show's: root@debian:~# python you're using the system 'python' here, not the new installed, which probably has landed in /usr/local (or where you installed it). Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40) [GCC 4.4.5] on linux2 Type help, copyright, credits or license for more information. how can i change the default to python 3.2.2? from a Debian Developer perspective, I'd suggest you not to switch the Debian default interpreter to python3.2 since it will make several system tools/debian packages to fail. If you need 3.2 explicitly, state it in the shebang or call the script with py3.2 explicitly. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] [Python-checkins] cpython (2.7): Issue #13605: add documentation for nargs=argparse.REMAINDER
On Thu, Jan 19, 2012 at 22:09, Nadeem Vawda nadeem.va...@gmail.com wrote: On Thu, Jan 19, 2012 at 11:03 PM, sandro.tosi python-check...@python.org wrote: + are gathered into a lits. This is commonly useful for command line s/lits/list ? crap! I committed an older version of the patch... thanks for spotting it, i'll fix it right away -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] [Python-checkins] cpython (2.7): Issue #13605: add documentation for nargs=argparse.REMAINDER
On Thu, Jan 19, 2012 at 22:07, Terry Reedy tjre...@udel.edu wrote: typo ... lits . list yep, i've already fixed it committing a more useful example too -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] Sphinx version for Python 2.x docs
On Mon, Jan 16, 2012 at 16:42, Éric Araujo mer...@netwok.org wrote: Hi, Le 14/01/2012 15:31, Sandro Tosi a écrit : On Sat, Jan 14, 2012 at 04:24, Éric Araujo mer...@netwok.org wrote: Doc/glossary.rst:520: WARNING: unknown keyword: nonlocal That’s a mistake I did in cefe4f38fa0e. This sentence should be removed. Do you mean revert this whole hunk: [...] or just The :keyword:`nonlocal` allows writing to outer scopes.? My proposal was to remove just that one last sentence, but the only other change in the diff hunk is the addition of “by default”, which is connected to the existence of nonlocal. Both changes, i.e. the whole hunk, should be reverted (I think I’ll have time to do that today). I've reverted it with ef1612a6a4f7 Doc/library/stdtypes.rst:2372: WARNING: more than one target found for cross-reference u'next': Need to use :meth:`.next` to let Sphinx find the right target (more info on request :) it seems what it needed to was :meth:`next` (without the dot). The current page links all 'next' in file.next() to functions.html#next, and using :meth:`next` does that. I should have given more info, as I wanted the opposite result :) file.next should not link to the next function but to the file.next method. Because Sphinx does not differentiate between meth/func/class/mod roles, :meth:`next` is not resolved to the nearest next method as one could expect but to the next function, so we have to use :meth:`~SomeClass.next` or :meth:`.next` (local ref markup) to get our links to methods. I tried :meth:`.next` but got a lots of : /home/morph/cpython/py27/Doc/library/stdtypes.rst:2372: WARNING: more than one target found for cross-reference u'next': iterator.next, multifile.MultiFile.next, csv.csvreader.next, dbhash.dbhash.next, mailbox.oldmailbox.next, ttk.Treeview.next, nntplib.NNTP.next, file.next, bsddb.bsddbobject.next, tarfile.TarFile.next, generator.next so I ended up with :meth:`next` but it was still wrong. I've committed 51e11b4937b7 which uses :meth:`~file.next` instead, and it works. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] Sphinx version for Python 2.x docs
On Sat, Jan 14, 2012 at 04:24, Éric Araujo mer...@netwok.org wrote: Hi Sandro, Thanks for getting the ball rolling on this. One style for markup, one Sphinx version to code our extensions against and one location for the documenting guidelines will make our work a bit easier. thanks :) I'm happy to help! During the build process, there are some warnings that I can understand: I assume you mean “can’t”, as you later ask how to fix them. As a yes, indeed general rule, they’re only warnings, so they don’t break the build, only some links or stylings, so I think it’s okay to ignore them *right now*. but I like to get them fixed nonetheless: after all, the current build doesn't show warnings - but I agree it's a non-blocking issue. Doc/glossary.rst:520: WARNING: unknown keyword: nonlocal That’s a mistake I did in cefe4f38fa0e. This sentence should be removed. Do you mean revert this whole hunk: @@ -480,10 +516,11 @@ nested scope The ability to refer to a variable in an enclosing definition. For instance, a function defined inside another function can refer to - variables in the outer function. Note that nested scopes work only for - reference and not for assignment which will always write to the innermost - scope. In contrast, local variables both read and write in the innermost - scope. Likewise, global variables read and write to the global namespace. + variables in the outer function. Note that nested scopes by default work + only for reference and not for assignment. Local variables both read and + write in the innermost scope. Likewise, global variables read and write + to the global namespace. The :keyword:`nonlocal` allows writing to outer + scopes. new-style class Any class which inherits from :class:`object`. This includes all built-in or just The :keyword:`nonlocal` allows writing to outer scopes.? Doc/library/stdtypes.rst:2372: WARNING: more than one target found for cross-reference u'next': Need to use :meth:`.next` to let Sphinx find the right target (more info on request :) it seems what it needed to was :meth:`next` (without the dot). The current page links all 'next' in file.next() to functions.html#next, and using :meth:`next` does that. Doc/library/sys.rst:651: WARNING: unknown keyword: None Should use ``None``. fixed Doc/reference/datamodel.rst:1942: WARNING: unknown keyword: not in Doc/reference/expressions.rst:1184: WARNING: unknown keyword: is not I don’t know if these should work (i.e. create a link to the appropriate language reference section) or abuse the markup (there are “not” and “in” keywords, but no “not in” keyword → use ``not in``). I’d say ignore them. ACK, but I'm willing to fix them if someone tells me how to :) I'm going to prepare the patches and then push - i'll send a heads-up afterward. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] 2.7 now uses Sphinx 1.0
Hello, just a heads-up: documentation for 2.7 branch has been ported to use sphinx 1.0, so now the same syntax can be used for 2.x and 3.x patches, hopefully easying working on both python stacks. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] Documenting Python is moving to devguide
Hi all, (another) heads-up about my current work: I've just pushed the Documenting Python doc section (ftr: http://docs.python.org/documenting/index.html) to devguide. That was possibile now that we use the same sphinx version on all the active branches. It was not a re-editing of the content, that might still be outdated and in need of work, but just a brutal cut paste of the current files. Now that we have a central place, additional editing will be much more easy. The section is still available in the cpython repo, and I'm waiting to remove it because it's better to have some redirections in place from the current urls to the new ones. I've prepared a small set of RewriteRules (attached): I don't know the actual setup of apache for docs.p.o but at least they are a start :) whomever has root access, could please review apply those rules? Once the rewrites are in place, i'll take care of removing the Doc/documenting dir from the active branches. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi RewriteEngine On RewriteRule /documenting/$ /devguide/documenting.html [NE,R=permanent,L] RewriteRule /documenting/index.html /devguide/documenting.html [NE,R=permanent,L] RewriteRule /documenting/intro.html /devguide/documenting.html#introduction[NE,R=permanent,L] RewriteRule /documenting/style.html /devguide/documenting.html#style-guide [NE,R=permanent,L] RewriteRule /documenting/rest.html /devguide/documenting.html#restructuredtext-primer [NE,R=permanent,L] RewriteRule /documenting/markup.html /devguide/documenting.html#additional-markup-constructs[NE,R=permanent,L] RewriteRule /documenting/fromlatex.html /devguide/documenting.html#differences-to-the-latex-markup [NE,R=permanent,L] RewriteRule /documenting/building.html /devguide/documenting.html#building-the-documentation [NE,R=permanent,L] ___ 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] Documenting Python is moving to devguide
Hi again, On Sat, Jan 14, 2012 at 19:09, Sandro Tosi sandro.t...@gmail.com wrote: Hi all, (another) heads-up about my current work: I've just pushed the Documenting Python doc section (ftr: http://docs.python.org/documenting/index.html) to devguide. That was possibile now that we use the same sphinx version on all the active branches. It was not a re-editing of the content, that might still be outdated and in need of work, but just a brutal cut paste of the current files. Now that we have a central place, additional editing will be much more easy. The section is still available in the cpython repo, and I'm waiting to remove it because it's better to have some redirections in place from the current urls to the new ones. I've prepared a small set of RewriteRules (attached): I don't know the actual setup of apache for docs.p.o but at least they are a start :) whomever has root access, could please review apply those rules? Thanks to Georg that applied the rewrites both for 2.7 and 3.2 . Once the rewrites are in place, i'll take care of removing the Doc/documenting dir from the active branches. and so Doc/documenting is gone on all the active branches. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] Sphinx version for Python 2.x docs
Hi all, On Sat, Aug 27, 2011 at 07:47, Georg Brandl g.bra...@gmx.net wrote: One of the main reasons for keeping Sphinx compatibility to 0.6.x was to enable distributions (like Debian) to build the docs for the Python they ship with the version of Sphinx that they ship. This should now be fine with 1.0.x, so since you are ready to do the work of converting the 2.7 Doc sources, it will be accepted. The argument of easier backports is a very good one. Not exactly as quickly as I would, I started to work on upgrading sphinx for 2.7. Currently I've all the preliminary patches at: http://hg.python.org/sandbox/morph/shortlog/5057ce392838 in the 2.7-sphinx branch (they fix one thing at a time, they'll be collapsed once all ready). During the build process, there are some warnings that I can understand: writing output... [100%] whatsnew/index /home/morph/cpython/morph_sandbox/Doc/glossary.rst:520: WARNING: unknown keyword: nonlocal /home/morph/cpython/morph_sandbox/Doc/library/stdtypes.rst:2372: WARNING: more than one target found for cross-reference u'next': iterator.next, multifile.MultiFile.next, csv.csvreader.next, dbhash.dbhash.next, mailbox.oldmailbox.next, ttk.Treeview.next, nntplib.NNTP.next, file.next, bsddb.bsddbobject.next, tarfile.TarFile.next, generator.next /home/morph/cpython/morph_sandbox/Doc/library/stdtypes.rst:2372: WARNING: more than one target found for cross-reference u'next': iterator.next, multifile.MultiFile.next, csv.csvreader.next, dbhash.dbhash.next, mailbox.oldmailbox.next, ttk.Treeview.next, nntplib.NNTP.next, file.next, bsddb.bsddbobject.next, tarfile.TarFile.next, generator.next /home/morph/cpython/morph_sandbox/Doc/library/sys.rst:651: WARNING: unknown keyword: None /home/morph/cpython/morph_sandbox/Doc/library/sys.rst:712: WARNING: unknown keyword: None /home/morph/cpython/morph_sandbox/Doc/reference/datamodel.rst:1942: WARNING: unknown keyword: not in /home/morph/cpython/morph_sandbox/Doc/reference/expressions.rst:1101: WARNING: unknown keyword: not in /home/morph/cpython/morph_sandbox/Doc/reference/expressions.rst:1135: WARNING: unknown keyword: not in /home/morph/cpython/morph_sandbox/Doc/reference/expressions.rst:1176: WARNING: unknown keyword: not in /home/morph/cpython/morph_sandbox/Doc/reference/expressions.rst:1184: WARNING: unknown keyword: is not /home/morph/cpython/morph_sandbox/Doc/reference/expressions.rst:1362: WARNING: unknown keyword: is not /home/morph/cpython/morph_sandbox/Doc/reference/simple_stmts.rst:700: WARNING: unknown keyword: None /home/morph/cpython/morph_sandbox/Doc/reference/simple_stmts.rst:729: WARNING: unknown keyword: None /home/morph/cpython/morph_sandbox/Doc/reference/simple_stmts.rst:729: WARNING: unknown keyword: None writing additional files... genindex py-modindex search download index opensearch Do you know how I can fix them? Thanks Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] [Python-checkins] cpython (2.7): Issue #12042: a queue is only used to retrive results; preliminary patch by
On Thu, Jan 5, 2012 at 23:45, Terry Reedy tjre...@udel.edu wrote: On 1/5/2012 1:51 PM, sandro.tosi wrote: http://hg.python.org/cpython/rev/3353f9747a39 changeset: 74282:3353f9747a39 branch: 2.7 Doc/whatsnew/2.6.rst | 4 ++-- should that have been whatsnew/2.7.rst? The wording correction was in the 2.6 what's new, when describing multiprocessing (which was added in 2.6). -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] FileSystemError or FilesystemError?
On Tue, Aug 23, 2011 at 20:20, Antoine Pitrou solip...@pitrou.net wrote: When reviewing the PEP 3151 implementation (*), Ezio commented that FileSystemError looks a bit strange and that FilesystemError would be a better spelling. What is your opinion? FilesystemError. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] Sphinx version for Python 2.x docs
Hi all, Any chance the version of sphinx used to generate the docs on docs.python.org could be updated? I'd like to discuss this aspect, in particular for the implication it has on http://bugs.python.org/issue12409 . Personally, I do think it has a value to have the same set of tools to build the Python documentation of the currently active branches. Currently, only 2.7 is different, since it still fetches (from svn.python.org... can we fix this too? suggestions welcome!) sphinx 0.6.7 while 3.2/3.3 uses 1.0.7. If you're worried about the time needed to convert the actual 2.7 doc to new sphinx format and all the related changes, I volunteer to do the job (and/or collaborate with whom is already on it), but what I want to understand if it's an acceptable change. I see sphinx more as of an internal, building tool, so freezing it it's like saying don't upgrade gcc or so. Now the delta is just the C functions definitions and some py-specific roles, but during the years it will increase. Keeping it small, simplifying the forward-port of doc patches (not needing to have 2 version between 2.7 and 3.x f.e.) and having a common set of tools for doc building is worth IMHO. What do you think about it? and yes Georg, I'd like to hear your opinion too :) Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] [Python-checkins] cpython (3.2): #5301: add image/vnd.microsoft.icon (.ico) MIME type
Hi, On Sun, Aug 21, 2011 at 10:17, Éric Araujo mer...@netwok.org wrote: Hi, However small the commit was, I think it still was a feature request, so I wonder if it was appropriate for the stable versions. I can see your point: the reason I committed it also on the stable branches is that .ico are already out there (since a long time) and they were currently not recognized. I can call it a bug. Anyhow, if it was not appropriate, just tell me and I'll revert on 2.7 and 3.2 . Thanks for your input! Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] Sphinx version for Python 2.x docs
Hello Chris, On Wed, Aug 17, 2011 at 00:58, Chris Withers ch...@simplistix.co.uk wrote: Hi All, Any chance the version of sphinx used to generate the docs on docs.python.org could be updated? I think what's needed first is to run a pilot: take the current 2.7 doc, update sphinx and look at what breaks, and evaluate if it's fixable in a reasonable amount of time, or it's just too much and so on. Currently no-one has done that yet: would you ? :) That would helps up quite much Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] [Python-checkins] cpython (2.7): Fix closes Issue12722 - link heapq source in the text format in the
On Thu, Aug 11, 2011 at 16:33, Éric Araujo mer...@netwok.org wrote: Hi, IIRC the reason why we don't do it on 2.x is because we don't have the 'source' directive available in Sphinx and therefore we would have to update all the links manually to link to h.p.o instead of s.p.o. In 3.2 and higher, there is a custom source role in Doc/tools/sphinxext/pyspecific.py. For 2.7, I volunteered to change all links manually (sed being, as usual, my friend) but just lacked time. Is there a reason we can't use the same sphinx role in 2.7 too? And also the same sphinx (thus sphinxext) versions on 2.7 and 3.x? that would probably help in keeping the diffs on the documentation smaller. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] [Python-checkins] cpython: #11572: improvements to copy module tests along with removal of old test suite
Hi Jim, On Fri, Aug 5, 2011 at 23:55, Jim Jewett jimjjew...@gmail.com wrote: Why was the old test suite removed? Even if everything is covered by the test file (and that isn't clear from this checkin), I don't see anything wrong with a quick test that doesn't require loading the whole testing apparatus. (I would have no objection to including a comment saying that the majority of the tests are in the test file; I just wonder why they have to be removed entirely.) I see these reasons mainly: - it adds nothing to the stdlib (where it was included): they are tests, so they should be in the test suite - it's unmaintained, since all the work on new tests or any change will happen on the test_copy.py file and not in the copy.py (that's true for any other module) - and also running the tests for a single modules is just a (in this case, I keep using copy: ./python -m test test_copy and it has the advantage of running the whole test suite for that module, not just some random code. I plan to do other changes like this in the next days/weeks, so actually thanks for the question :) since it bring that up to python-dev we others can comment. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] Draft PEP: Simplified Package Layout and Partitioning
Hi, sorry for nitpicking, but... On Wed, Jul 20, 2011 at 05:58, P.J. Eby p...@telecommunity.com wrote: ... For those implementing PEP \302 importer objects: the '\' should be removed, right? Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] Draft PEP: Simplified Package Layout and Partitioning
On Sat, Jul 30, 2011 at 14:57, Éric Araujo mer...@netwok.org wrote: On Wed, Jul 20, 2011 at 05:58, P.J. Eby p...@telecommunity.com wrote: For those implementing PEP \302 importer objects: the '\' should be removed, right? No. Philip used backslashes to prevent the HTML conversion to transform each and every instance of “PEP \d+” to a link, which gets annoying after the few first hundred times. (It was discussed a few months ago probably on web-sig or python-dev for PEP 333 or , if memory serves.) Gaah, sorry for the noise then! (but at least I learnt a new thing!) Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] svn.python.org confusion
On Wed, Jun 29, 2011 at 03:05, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Ned Deily nad at acm.org writes: Could some text be added to the svn browser pages to at least indicate that the repo is no longer being updated with a link to the hg.python.org browser? I'm not sure what to do about the repos themselves if people attempt to do an svn co. Perhaps that should just be disabled totally for python? At least some of the stuff in the SVN repo is still needed, AFAICT. I recently did a build of the Python Windows binary installer, and I understand (from the buildbot instructions) that the best source of some of the external dependencies (bz2, Tcl/Tk, openssl etc.) is still the SVN repo. SVN is also used to fetch third-party tools to build documentation, such as: sphinx, docutils, jinja, and pygments. These locations are also advertised on http://docs.python.org/py3k/documenting/building.html (that contains outdated info, but that's another story). Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] [Python-checkins] cpython (3.2): #11669: rephrase footnote in the Compound Statements page.
Hi Nick, given I'm guilty for this patch, I'd reply :) On Sun, Jun 26, 2011 at 15:55, Nick Coghlan ncogh...@gmail.com wrote: On Sun, Jun 26, 2011 at 6:38 PM, ezio.melotti python-check...@python.org wrote: -.. [#] The exception is propagated to the invocation stack only if there is no - :keyword:`finally` clause that negates the exception. +.. [#] The exception is propagated to the invocation stack unless + there is a :keyword:`finally` clause which happens to raise another + exception. That new exception causes the old one to be lost. I believe the footnote was talking about this case: def f(): ... try: ... raise Exception() ... finally: ... return What exception? ... f() 'What exception?' The new wording doesn't accurately reflect that. I gave my interpretation of the footnote at: http://bugs.python.org/issue11669#msg139092 . Does this clarify it? Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] Some additions to .hgignore
On 2011-06-01, Michael Foord fuzzy...@voidspace.org.uk wrote: That sounds good to me. An issue certainly wouldn't hurt. So be it: http://bugs.python.org/issue12341 :) Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] Some additions to .hgignore
Hi all, following http://docs.python.org/devguide/coverage.html doc you'll end up with several new files/dirs in your checkout: - .coverage, used by coveragepy to save its info - coverage/ , the symlink to coveragepy/coverage - htmlcov/ , the dir where the coverage HTML pages are written I think they should be added to .hgignore so that hg st won't show them. I'm writing here since I don't think an issue is needed for such matter, if that's not the case, I apologize. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] Extending os.chown() to accept user/group names
On Wed, May 25, 2011 at 15:58, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 25 May 2011 09:41:46 -0400 Barry Warsaw ba...@python.org wrote: I think it would be a nice feature, and I can see the conflict. OT1H you want to keep os.chown() a thin wrapper, but OTOH you'd rather not have to add a new, arguably more difficult to discover, function. Given those two choices, I still think I'd come down on adding a new function and shutil.chown() seems an appropriate place for it. +1 for shutil.chown(). and so shutil.chown() be it: http://bugs.python.org/issue12191 Currently, only the function for a single file is implemented, let's look later what to do for a recursive one. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] Extending os.chown() to accept user/group names
Hi all, before opening an issue to track the request, I'd like to ask advice here about this: extend os.chown() to accept even user/group names instead of just uid and gid. On a Unix system, you can call chown command passing either id or names, so it seems (to me at least) natural to expect os.chown() to behave similarly; but that's not the case. I can see os module wants to be a thin wrapper around OS syscalls and chown(2) accepts only uid/gid as input, so what would be best: extend os.chown() or provide a chown() function in shutil module for this purpose? Thanks in advance, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] Status of json (simplejson) in cpython
Hi all, it all started with issue10019. The version we have in cpython of json is simplejson 2.0.9 highly patched (either because it was converted to py3k, and because of the normal flow of issues/bugfixes) while upstream have already released 2.1.13 . Their 2 roads had diverged a lot, and since this blocks any further update of cpython's json from upstream, I'd like to close this gap. This isn't exactly an easy task, and this email is more about a brainstorming on the ways we have to achieve the goal: being able to upgrade json to 2.1.13. Luckily, upstream is receptive for patches, so part of the job is to forward patches written for cpython not already in the upstream code. But how am I going to do this? let's do a brain-dump: - the history goes back at changeset f686aced02a3 (May 2009, wow) when 2.0.9 was merged on trunk - I can navigate from that CS up to tip, and examine the diffs and see if they apply to 2.1.3 and prepare a set of patches to be forwarded - part of those diffs is about py3k conversion, that probably needs to be extended to other part of the upstream code not currently in cpython. For those new code parts, do you have some guides about porting a project to py3k? it would be my first time and other than building it and running it with python3 i don't know what to do :) - once (and if :) I reach the point where I've all the relevant patches applied on 2.1.3 what's the next step? -- take 2.1.3 + patches, copy it on Lib/json + test + Modules and see what breaks? -- what about the doc? (uh luckily I just noticed it's already in the upstream repo, so another thing to sync) - what are we going to do in the long run? how can we assure we'll be having a healthy collaboration with upsteam? f.e. in case a bug is reported (and later on fixed) in cpython? is there a policy for projects present in cpython and also maintained elsewhere? At the end: do you have some suggestions that might this task be successful? advice on the steps above, tips about the merge, something like this. Thanks a lot for your time, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] GPL'd python code vs Python2.6 linked against OpenSSL
On Thu, Mar 10, 2011 at 00:32, Antoine Pitrou solip...@pitrou.net wrote: Also, with the system Python 2.6 shipped on a Mandriva distribution: $ ldd /usr/bin/python linux-vdso.so.1 = (0x7fff8456d000) libpython2.6.so.1.0 = /usr/lib64/libpython2.6.so.1.0 (0x7f1a0b1e2000) libc.so.6 = /lib64/libc.so.6 (0x7f1a0ae76000) libdl.so.2 = /lib64/libdl.so.2 (0x7f1a0ac72000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f1a0aa56000) libutil.so.1 = /lib64/libutil.so.1 (0x7f1a0a853000) libm.so.6 = /lib64/libm.so.6 (0x7f1a0a5d1000) /lib64/ld-linux-x86-64.so.2 (0x7f1a0b583000) $ objdump -p /usr/bin/python | grep NEEDED NEEDED libpython2.6.so.1.0 NEEDED libc.so.6 (just nitpicking) but it's there on a debian system: $ ldd /usr/bin/python linux-vdso.so.1 = (0x77bff000) libpthread.so.0 = /lib/libpthread.so.0 (0x7f9abcb82000) libdl.so.2 = /lib/libdl.so.2 (0x7f9abc97e000) libutil.so.1 = /lib/libutil.so.1 (0x7f9abc77a000) libssl.so.0.9.8 = /usr/lib/libssl.so.0.9.8 (0x7f9abc525000) libcrypto.so.0.9.8 = /usr/lib/libcrypto.so.0.9.8 (0x7f9abc184000) libz.so.1 = /usr/lib/libz.so.1 (0x7f9abbf6c000) libm.so.6 = /lib/libm.so.6 (0x7f9abbcea000) libc.so.6 = /lib/libc.so.6 (0x7f9abb989000) /lib64/ld-linux-x86-64.so.2 (0x7f9abcdc4000) $ objdump -p /usr/bin/python | grep NEEDED NEEDED libpthread.so.0 NEEDED libdl.so.2 NEEDED libutil.so.1 NEEDED libssl.so.0.9.8 NEEDED libcrypto.so.0.9.8 NEEDED libz.so.1 NEEDED libm.so.6 NEEDED libc.so.6 It seems introduced by the patch debian/patches/setup-modules-ssl.diff with description # DP: Modules/Setup.dist: patch to build _hashlib and _ssl extensions statically Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] Support the /usr/bin/python2 symlink upstream
On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski pi...@debian.org wrote: I co-maintain with Matthias a package that provides /usr/bin/python symlink in Debian and I can confirm that it will always point to Python 2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess only accepted PEP can change that) Can you please explain why you NACK this proposed change? Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] Support the /usr/bin/python2 symlink upstream
On Wed, Mar 2, 2011 at 13:56, Piotr Ożarowski pi...@debian.org wrote: [Sandro Tosi, 2011-03-02] On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski pi...@debian.org wrote: I co-maintain with Matthias a package that provides /usr/bin/python symlink in Debian and I can confirm that it will always point to Python 2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess only accepted PEP can change that) Can you please explain why you NACK this proposed change? it encourages people to change /usr/bin/python symlink to point to python3.X which I'm strongly against (how can I tell that upstream author meant python3.X and not python2.X without checking the code?) with 'people' do you mean 'users'? if so, isn't this risk already present? If you, user, change the python symlink (provided by python-minimal in Debian) to something else than what's shipped, it's still a local change, and will never be supported; but with python2 *Debian is free* to decide if python can be pointed to python3, if the time will come. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] [Python-checkins] devguide (hg_transition): patchcheck does work
On Sun, Feb 27, 2011 at 03:17, eric.araujo python-check...@python.org wrote: eric.araujo pushed f325d743c385 to devguide: http://hg.python.org/devguide/rev/f325d743c385 changeset: 331:f325d743c385 branch: hg_transition user: ?ric Araujo mer...@netwok.org date: Sat Feb 26 17:30:51 2011 +0100 summary: patchcheck does work files: patch.rst diff --git a/patch.rst b/patch.rst --- a/patch.rst +++ b/patch.rst @@ -114,15 +114,13 @@ Generation '' -.. XXX [commented out] make patchcheck doesn't work with non-SVN workflow +To perform a quick sanity check on your patch, you can run:: - To perform a quick sanity check on your patch, you can run:: + make patchcheck - make patchcheck - - This will check and/or fix various common things people forget to do for - patches, such as adding any new files needing for the patch to work (do not - that not all checks apply to non-core developers). +This will check and/or fix various common things people forget to do for +patches, such as adding any new files needing for the patch to work (do not (do note Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] [Python-checkins] devguide: List common gotchas people might come across when doing coverage work.
On Sun, Feb 27, 2011 at 06:31, brett.cannon python-check...@python.org wrote: +When writing new tests to increase coverage, do take note of the style of tests +already provided for a module (e.g., whitebox, blackbox, etc.). As +some modules are primarily maintained by a single core developer they may have +a specific preference as to what kind of test is used (e.g., whitebox) and +prefer that other types of tests not be used (e.g., blackbox). When in doubt, +stick with whitebox testing in order to properly exercise the code. Do you think it could be nice to have a reference to what whitebox/blackbox testing is, ie http://en.wikipedia.org/wiki/White-box_testing http://en.wikipedia.org/wiki/Black-box_testing ? Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] [Python-checkins] devguide: Move to using mq for basic usage.
Hi, On Wed, Feb 9, 2011 at 23:19, brett.cannon python-check...@python.org wrote: +project's preference. We present here a very simple solution based on mq_ +(Mercurial Queue) non-core developers. for non-core devs (ok, this is not the last patch applied to the file, but it's still there after the next changes). +This will update the patch to contain all of the changes you have made up to +this point. If you have any you have added or removed, use ``hg add`` or ``hg +remove``, respectively, before running ``hg qrefresh``. If you have any what's missing? This will check and/or fix various common things people forget to do for -patches, such as adding any new files needing for the patch to work. +patches, such as adding any new files needing for the patch to work (do not (do note Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] [Python-checkins] devguide: Add a document discussing the development cycle typically followed for
On Wed, Jan 26, 2011 at 23:20, brett.cannon python-check...@python.org wrote: +The in-development branch is where new functionality and semantic changes new functionalities (dunno if it's plural in english or not)? +occur. Currently this branch is known as the py3k branch. The next minor +release of Python will come from this branch (major releases are once a decade +and so have no specific rules on how they are started). All changes land in this +branch and then trickle down to other branches. + +Once a Final_ release is made from the in-development branch, a branch is made +to represent the minor version of Python and it goes into maintenance mode. +Typically a minor version of Python is under development for about 18 months. + + +Maintenance +--- +The branch currently being maintained for bug fixes. + +The branch under maintenance is the last minor version of Python to be released +as Final_. This means that the latest release of Python was 3.1.2, then the if the latest release ? +branch representing Python 3.1 is in maintenance mode. + +The only changes allowed to occur in a maintenance branch without debate are bug +fixes. +Semantic changes **must** be carefully considered as code out in the world will +have already been developed that will rely on the released semantics. Changes +related to semantics should be discussed on python-dev before being made. + +A branch stays in maintenance mode as long as a new minor release has not been +made. For example, this means that Python 2.6 stayed in maintenance mode until +Python 2.7.0 was released, at which point 2.7 went into maintenance mode and +2.6 went into Security_ mode. As new minor releases occur on a (roughly) 18 +month schedule, a branch stays in mainteance mode for the same amount of time. s/mainteance/maintenance/ + +A micro release of a maintenance branch is made about every six months. +Typically when a new minor release is made one more release of the new-old +version of Python is made. + + +Security + +A branch less than five years old but no longer in maintenance mode. + +The only changes made to a branch that is being maintained for security +purposes are somewhat obviously those related to security, e.g., privilege +escalation. Crashers and other behaviorial issues are **not** considered a s/Crashers/Crashes/ s/behaviorial/behavioral/ +security risk and thus not backported to a branch being maintained for +security. Any releases made for a branch under security maintenance is s/releases/release/ ? s/for/from/ +source-only and done only when actual security patches have been applied to the +branch. + + +Stages +'' + +Based on what stage the in-development version of Python is in, the +responsibilities of a core developer change in regards to commits to the VCS. + + +Pre-alpha +- +This is the stage a branch is in from the last final release until the first +alpha (a1). There are no special restrictions placed on commits beyond those +imposed by the type of branch being worked on (e.g., in-development vs. +maintenance). + + +Alpha +- +Alphas typically serve as a reminder to core developers that they need to start +getting in changes that change semantics or add something to Python as such +things should not be added during a Beta_. Otherwise no new restrictions are in +place while in alpha. + + +Beta + +A branch in beta means that no new additions to Python are accepted. Bugfixes +and the like are still fine. Being in beta can be viewed much like being in RC_ +but without the extra overhead of needing commit reviews. + + +.. _RC: + +Release Candidate (RC) +-- +A branch preparing for an RC release can only have bugfixes applied that have +been reviewed by other core developers. That reviewer should make a post to the +issue related to the change and be mentioned in the commit message. + +You **cannot** skip the peer review during an RC, no matter how small! Even if +it is a simple copy-and-paste change, **everything** requires peer review from +a core developer. + + +Final +- +When a final release is being cut, only the release manager (RM) can make +changes to the branch. diff --git a/index.rst b/index.rst --- a/index.rst +++ b/index.rst @@ -20,6 +20,7 @@ coredev developers committing + devcycle stdlibchanges langchanges @@ -64,6 +65,7 @@ * :ref:`coredev` * :ref:`developers` * :ref:`committing` + * :ref:`devcycle` Proposing changes to Python itself -- Repository URL: http://hg.python.org/devguide ___ Python-checkins mailing list python-check...@python.org http://mail.python.org/mailman/listinfo/python-checkins -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org
Re: [Python-Dev] [Python-checkins] devguide: Move Misc/maintainers.rst here and rename to experts.rst.
Hi, On Thu, Jan 20, 2011 at 04:56, brett.cannon python-check...@python.org wrote: +Unless a name is followed by a '*', you should never assign an issue to +that person, only make them nosy. Names followed by a '*' may be assigned +issues involving the module or topic for which the name has a '*'. isn't last sentence a bit weird? I'm not native but Names followed by a '*' may issues assigned for the modules be a bit better? ok, fairly minor you can also ignore it :) Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] [Python-checkins] devguide: Move Misc/README.Emacs to here.
Hi, On Thu, Jan 20, 2011 at 20:33, brett.cannon python-check...@python.org wrote: +.. + Local Variables: + mode: indented-text + indent-tabs-mode: nil + sentence-end-double-space: t + fill-column: 78 + coding: utf-8 + End: maybe this can be removed now Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] [Python-checkins] devguide: Short doc about where to get tech help related to developing Python.
Hi, On Wed, Jan 19, 2011 at 23:19, brett.cannon python-check...@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 ___ 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] porting python.org
Hi, On Sat, Dec 11, 2010 at 18:19, Georg Brandl g.bra...@gmx.net wrote: Mako (http://www.makotemplates.org/) [Note that Mako requires setuptools to install out-of-the-box. You can also just copy the lib/mako/ tree into your Python's site-packages directory if you prefer not to install setuptools.] Mako is compatible with py3k (via 2to3) since version 0.3 (but later versions has a better support). [1] explains how to have a py3k installation of mako. [1] http://www.makotemplates.org/trac/browser/README.py3k PyYAML (http://pyyaml.org/wiki/PyYAML) PyYAML also supports Python 3 from the homepage, the version introducing py3k support is 3.08 . Just my 2c, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] Sumo
Hello, sorry to interrupt your discussion but.. On Thu, May 27, 2010 at 04:09, Yaniv Aknin ya...@aknin.name wrote: Because scientists, financial analysts, web designers, etc all have different needs. My point is just that a web designer probably doesn't care if he's got numpy, nor does a mathematician care if he has cherrypy onboard. They only care when the tools they need aren't there, which is where sumo can help. Why do we want distributions (whether 'sumo' or domain specific) in the first place? Obviously because we have some pains to alleviate, but I think Linux distributions, particularly Ubuntu, have been coping with similar pains for a while now with good results. I used to be rather informed on the state of Linux distributions circa the end of the 90's. Should I use this distribution or that one? Now I don't care, the answer is always 'Ubuntu, and apt-get it to fit your needs'. please note that the huge bunch of work for Python third-party modules is done in *Debian* and Ubuntu just takes those packages without advertise enough where they come from and who did the work (and not the merchandizing only). I hope you would intuitively grasp what I mean, even if I fail to articulate it well, if you ever used dpkg and apt-get (or equivalents), along with the ability to add sources and the simple distinctions between sources (core vs. universe vs. multiverse), along with eco systems like launchpad and PPAs, etc. To my 1999 self these features of Ubuntu seem like miracles, not so much because Debian and dpkg/apt-get weren't there back then (they were life saving back then too), but because of the whole system's huge support base and centrally-designed decentrally-implemented nature. mh? Debian was not in present in 1999? Debian started in 1993 (dpkg in 1994 and apt-get in 1998) while ubuntu only in mid-2000 as a layer over Debian packages (and hiring several Debian Developers for its core positions). Also, let me remind you that transition to Python 2.6 was a huge mess for Ubuntu, where several packages were just left broken (f.e. failing unit tests were disabled to make the package build...) and only now that Debian started to migrate to 2.6 too, you can see a flow of packages that works for 2.6 too coming to Ubuntu. Debian can be slow, but we care about quality. End of give credit where it's due post :) Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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
