Re: [Python-Dev] Tracker Stats
On Mon, Jun 23, 2014 at 6:52 PM, francis wrote: > >> Hi, >> I added a new "stats" page to the bug tracker: >> http://bugs.python.org/issue?@template=stats > > Thanks Ezio, > > Two questions: > how hard would be to add (or enhance) a chart with the > “open issues type enhancement” and “open issues type bug” > info ? > Not particularly hard, but I won't have time to get back to this project for a while (contributions are welcomed though!). > In the summaries there is a link to “Issues with patch”, > means that the ones not listed there are in “needs patch” > or “new” status? That summary lists all the issues with the "patch" keyword, and the ones not listed simply don't have it. The keyword is added automatically whenever an attachment is added to the issue, so there might be false positives (e.g. if the attachment is a script to reproduce the issue rather than a patch, or if the available patches are outdated). The might also be issues with patches that are not included in the summary (e.g. if someone accidentally removed the keyword), but that shouldn't be very common. From the first graph you can see that out of the 4500+ open issues, about 2000 have a patch. We need more reviewers and committers :) Best Regards, Ezio Melotti > > Regards, > francis > ___ 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] Tracker Stats
On Tue, Jun 24, 2014 at 1:25 AM, A.M. Kuchling wrote: > On Mon, Jun 23, 2014 at 04:12:24PM -0400, R. David Murray wrote: >> The stats graphs are based on the data generated for the >> weekly issue report. I have a patched version of that >> report that adds the bug/enhancement info. > > After PyCon, I started working on a scraper that would produce a bunch > of different lists and charts. My ideas were: > > * pie charts of issues by status and type. > > * list or histogram of open library issues by module, perhaps limited to the > top N modules > We don't have module-specific tags yet (see the core-workflow ML for discussions about that), but I have other scripts that analyze all the patches and divide them by module. I didn't have time to integrate this in the tracker though. > * list of N oldest issues with no subsequent activity (the unreviewed ones) > You can search for issues with only one message: http://bugs.python.org/issue?%40sort0=activity&%40sort1=&%40group0=&%40group1=&%40columns=title%2Cid%2Cactivity%2Cstatus&%40filter=status%2Cmessage_count&status=1&message_count=1&%40pagesize=50&%40startwith=0 > * list of N people with the most open issues assigned to them > And then poke them with a goad until they fix them? :) > The idea is to provide charts that help us direct effort to particular > subsets of bugs. > If someone wants to experiment with and/or improve the tracker stats, this is how it works: 1) The roundup-summary script [0] analyzes the issues once a week and produce the weekly report and a static JSON file [1]; 2) The stats page [2] request the JSON file and uses the data to generate the charts client-side. Now there are two ways to improve it: 1) the easy way is just to use the roundup-summary script to expose more of its data or to find new ones and add them to the JSON file (and possibly to the summary too); 2) the hard way is to decouple the roundup-summary and the stats page and either make another weekly (or daily/hourly) script to generate the JSON file, or a template page that generates the data in real-time. Once the data are in the JSON file is quite easy to use jqPlot [4] to make any kind of charts. Keep in mind that some things are trivial to get out from the DB (e.g. number of issues for each status/type), but other things are a bit more complicated (e.g. things involving specific periods of time) and currently the roundup-summary takes a few minutes to analyze all the issues. I also tried to include just a few useful charts on the stats page -- at first I had several more charts but then I removed them. Feel free to ping me on IRC (#python-dev@Freenode) if you have questions. Best Regards, Ezio Melotti [0]: http://hg.python.org/tracker/python-dev/file/default/scripts/roundup-summary [1]: http://bugs.python.org/@@file/issue.stats.json [2]: http://hg.python.org/tracker/python-dev/file/bbbe6c190a99/html/issue.stats.html#l20 [3]: http://www.jqplot.com/tests/ > --amk ___ 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] Tracker Stats
On Mon, Jul 7, 2014 at 10:01 PM, francis wrote:
> On 06/23/2014 10:12 PM, R. David Murray wrote:
>
>> The stats graphs are based on the data generated for the
>> weekly issue report. I have a patched version of that
>> report that adds the bug/enhancement info. I'll try to dig
>> it up this week; someone ping me if I forget :) It think
>> the patch will need to be updated based on Ezio's changes.
>>
> ping
>
If you just want some numbers you can try this:
>>> import xmlrpclib
>>> x = xmlrpclib.ServerProxy('http://bugs.python.org/xmlrpc', allow_none=True)
>>> open_issues = x.filter('issue', None, dict(status=1)) # 1 == open
>>> len(open_issues)
4541
>>> len(x.filter('issue', open_issues, dict(type=5))) # behavior
1798
>>> len(x.filter('issue', open_issues, dict(type=6))) # enhancement
1557
>>> len(x.filter('issue', open_issues, dict(type=1))) # crash
122
>>> len(x.filter('issue', open_issues, dict(type=2))) # compile error
141
>>> len(x.filter('issue', open_issues, dict(type=3))) # resource usage
103
>>> len(x.filter('issue', open_issues, dict(type=4))) # security
32
>>> len(x.filter('issue', open_issues, dict(type=7))) # performance
83
Best Regards,
Ezio Melotti
___
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] Starting CPython development w/ Docker
On Mon, Apr 20, 2015 at 3:52 PM, Saul Shanabrook wrote: > I started trying some CPythong development a week ago at PyCon and first got > testing working using Docker on my mac. This had the advantage of not having > to worry about installing and dependencies, and also let me test on > different Python versions easily. > > If you are interested in trying it, I laid out all the steps here: > http://www.saulshanabrook.com/cpython-dev-w-docker/ > Thanks for the link! I was just looking into the possibility of dockerizing bugs.python.org and what you wrote looks quite helpful. Best Regards, Ezio Melotti > Saul Shanabrook > ___ 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] Mac popups running make test
On Sun, May 10, 2015 at 5:04 PM, Skip Montanaro wrote: > > ... > I've also seen the Crash Reporter pop up many times, I don't know how to get rid of the popup you mentioned, but Windows had problems with the crash popups for a long time. Eventually it got fixed: https://hg.python.org/cpython/file/default/Lib/test/support/__init__.py#l2202 http://bugs.python.org/issue11732 http://bugs.python.org/issue18948 http://bugs.python.org/issue23314 Perhaps Mac OS has something similar too? Best Regards, Ezio Melotti > > but as far as I could tell, in all cases the test suite output told me it was > expected. Perhaps tests which listen for network connections should also > mention that, at least on Macs? > > Thx, > > Skip > ___ 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
[Python-Dev] bugs.python.org updated
Hi, yesterday I updated the version of Roundup used to run our bugs.python.org instance and 4 other instances (the meta, jython, setuptools, and roundup trackers). If everything went right you shouldn't have noticed anything different :) This update included ~300 changesets from upstream and required an additional ~30 to update our instances and our fork of Roundup. A number of features that we added to our fork over the years have been ported upstream and they have now been removed from our fork, which is now -- except for the github integration -- almost aligned with upstream. If you notice any issue with the bug tracker (/with/, not /in/ -- that's expected!), please report it to the meta tracker ( http://psf.upfronthosting.co.za/roundup/meta/) and/or to me. If there are no reports and everything works fine I still have a few more updates coming up ;) A big thanks to John Rouillard (from the Roundup team) and R. David Murray for the help! Best Regards, Ezio Melotti P.S. Roundup started moving towards Python 3. ___ 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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than
On Thu, Jul 9, 2015 at 3:41 PM, Guido van Rossum wrote: > On Wed, Jul 8, 2015 at 10:19 PM, Serhiy Storchaka > wrote: >> >> On 08.07.15 01:45, Raymond Hettinger wrote: >>> >>> P.S. I don't think python-dev post was necessary or helpful (and I still >>> haven't had a chance to read the whole thread). It would have been >>> sufficient to assign the tracker entry back to me. >> >> >> Well, I'll open new issue and assign it to you for every your commit that >> looks questionable to me. > > > That sounds like a fine solution, and a good conclusion of the thread. > Whenever I have a non-trivial commit to do, I create a patch and upload it to the tracker, with an explanation of the problem and the solution. If after a few days no one commented, I commit it and close the issue. If a problem arises post-commit, people can reopen the issue and comment there. Since the issue number is included in all the commits, it is also easy to find related discussions. Creating an issue after the fact is an acceptable solution too, but I would prefer to see an issue before the commit. FWIW I only consider simple documentation issues and typo/whitespace fixes as "trivial", YMMV. Best Regards, Ezio Melotti > -- > --Guido van Rossum (python.org/~guido) > ___ 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] Use utf-8 charset for tracker summaries?
On Sat, Mar 12, 2016 at 12:09 AM, Terry Reedy wrote:
> The weeky 'Summariy of Python tracker Issues' ('tracker' should be
> capitalized if 'Issues' is) starts with
>
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> Names sometimes have not-ascii chars, and they do not get properly displayed
> for me with Thunderbird on Windows. For instance,
> Raúl Núñez de Arenas (Raúl Núñez de Arenas)
> is transmitted as
> Ra=C3=BAl N=C3=BA=C3=B1ez de= Arenas
> and displayed as
> Raúl Núñez de Arenas
>
This already looks like UTF-8 -- you should be able to verify this by
manually selecting UTF-8 as encoding from the menu.
If the Content-Type still uses us-ascii though, it should be fixed to
specify UTF-8 instead.
Best Regards,
Ezio Melotti
> I am rather sure that this does not happen with email sent to me by the
> tracker itself.
>
> --
> Terry Jan Reedy
>
___
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
[Python-Dev] Deprecation policy
Hi, a couple of years ago I suggested to define and document our deprecation policy in this thread: https://mail.python.org/pipermail/python-dev/2011-October/114199.html I didn't receive many replies and eventually nothing was done. Lately the same issue came up on #python-dev and Larry and Nick suggested me to bring this up again. Nick also suggested to document our deprecation policy in PEP 5 (Guidelines for Language Evolution: http://www.python.org/dev/peps/pep-0005/ ). I'm including below the full text of the original email. Best Regards, Ezio Melotti --- Hi, our current deprecation policy is not so well defined (see e.g. [0]), and it seems to me that it's something like: 1) deprecate something and add a DeprecationWarning; 2) forget about it after a while; 3) wait a few versions until someone notices it; 4) actually remove it; I suggest to follow the following process: 1) deprecate something and add a DeprecationWarning; 2) decide how long the deprecation should last; 3) use the deprecated-remove[1] directive to document it; 4) add a test that fails after the update so that we remember to remove it[2]; Other related issues: PendingDeprecationWarnings: * AFAIK the difference between PDW and DW is that PDW are silenced by default; * now DW are silence by default too, so there are no differences; * I therefore suggest we stop using it, but we can leave it around[3] (other projects might be using it for something different); Deprecation Progression: Before, we more or less used to deprecated in release X and remove in X+1, or add a PDW in X, DW in X+1, and remove it in X+2. I suggest we drop this scheme and just use DW until X+N, where N is >=1 and depends on what is being removed. We can decide to leave the DW for 2-3 versions before removing something widely used, or just deprecate in X and remove in X+1 for things that are less used. Porting from 2.x to 3.x: Some people will update directly from 2.7 to 3.2 or even later versions (3.3, 3.4, ...), without going through earlier 3.x versions. If something is deprecated on 3.2 but not in 2.7 and then is removed in 3.3, people updating from 2.7 to 3.3 won't see any warning, and this will make the porting even more difficult. I suggest that: * nothing that is available and not deprecated in 2.7, will be removed until 3.x (x needs to be defined); * possibly we start backporting warnings to 2.7 so that they are visible while running with -3; Documenting the deprecations: In order to advertise the deprecations, they should be documented: * in their doc, using the deprecated-removed directive (and possibly not the 'deprecated' one); * in the what's new, possibly listing everything that is currently deprecated, and when it will be removed; Django seems to do something similar[4]. (Another thing I would like is a different rending for deprecated functions. Some part of the docs have a deprecation warning on the top of the section and the single functions look normal if you miss that. Also while linking to a deprecated function it would be nice to have it rendered with a different color or something similar.) Testing the deprecations: Tests that fail when a new release is made and the version number is bumped should be added to make sure we don't forget to remove it. The test should have a related issue with a patch to remove the deprecated function and the test. Setting the priority of the issue to release blocker or deferred blocker can be done in addition/instead, but that works well only when N == 1 (the priority could be updated for every release though). The tests could be marked with an expected failure to give some time after the release to remove them. All the deprecation-related tests might be added to the same file, or left in the test file of their module. Where to add this: Once we agree about the process we should write it down somewhere. Possible candidates are: * PEP387: Backwards Compatibility Policy[5] (it has a few lines about this); * a new PEP; * the devguide; I think having it in a PEP would be good, the devguide can then link to it. Best Regards, Ezio Melotti [0]: http://bugs.python.org/issue13248 [1]: deprecated-removed doesn't seem to be documented in the documenting doc, but it was added here: http://hg.python.org/cpython/rev/03296316a892 [2]: see e.g. http://hg.python.org/cpython/file/default/Lib/unittest/test/test_case.py#l1187 [3]: we could also introduce a MetaDeprecationWarning and make PendingDeprecationWarning inherit from it so that it can be used to pending-deprecate itself. Once PendingDeprecationWarning is gone, the MetaDeprecationWarning will become useless and can then be used to meta-deprecate itself. [4]: https://docs.djangoproject.com/en/dev/internals/deprecation/ [5]: http://www.python.org/dev/peps/pep-0387/ ___ Python-Dev mailing list Python-Dev@pyt
Re: [Python-Dev] CLA link from bugs.python.org
Hi, On Sun, May 5, 2013 at 7:45 AM, Ezio Melotti wrote: > Hi, > > On Sun, May 5, 2013 at 4:23 AM, Tim Delaney > wrote: >> It appears there's no obvious link from bugs.python.org to the contributor >> agreement - you need to go via the unintuitive link Foundation -> >> Contribution Forms (and from what I've read, you're prompted when you add a >> patch to the tracker). >> >> I'd suggest that if the "Contributor Form Received" field is "No" in user >> details, there be a link to http://www.python.org/psf/contrib/. >> > > See http://psf.upfronthosting.co.za/roundup/meta/issue461. > This is now done: users who submit(ted) patches without having signed the contributor agreement will get a note in tracker with the link and a short explanation. (Sorry it took me so long to get this fixed.) Best Regards, Ezio Melotti > Best Regards, > Ezio Melotti > >> Tim Delaney >> ___ 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] CLA link from bugs.python.org
On Sun, Feb 16, 2014 at 11:06 AM, Georg Brandl wrote: > Am 16.02.2014 09:40, schrieb Ezio Melotti: >> Hi, >> >> On Sun, May 5, 2013 at 7:45 AM, Ezio Melotti wrote: >>> Hi, >>> >>> On Sun, May 5, 2013 at 4:23 AM, Tim Delaney >>> wrote: >>>> It appears there's no obvious link from bugs.python.org to the contributor >>>> agreement - you need to go via the unintuitive link Foundation -> >>>> Contribution Forms (and from what I've read, you're prompted when you add a >>>> patch to the tracker). >>>> >>>> I'd suggest that if the "Contributor Form Received" field is "No" in user >>>> details, there be a link to http://www.python.org/psf/contrib/. >>>> >>> >>> See http://psf.upfronthosting.co.za/roundup/meta/issue461. >>> >> >> This is now done: users who submit(ted) patches without having signed >> the contributor agreement will get a note in tracker with the link and >> a short explanation. >> (Sorry it took me so long to get this fixed.) > > Thanks, that is a great improvement. (Although I don't think I like the > red background color... ) Agreed, that's why I timemachined it gray: http://hg.python.org/tracker/python-dev/rev/4cdbeb1c74c6#l2.11 > > Georg > > ___ > 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/ezio.melotti%40gmail.com ___ 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] List vs Tuple / Homogeneous vs Heterogeneous / Mutable vs Immutable
Hi, On Thu, Apr 17, 2014 at 10:23 PM, Guido van Rossum wrote: > It's definitely something that should be put in some documentation, see http://bugs.python.org/issue14840 and https://docs.python.org/3/tutorial/datastructures.html#tuples-and-sequences : """ Though tuples may seem similar to lists, they are often used in different situations and for different purposes. Tuples are immutable, and usually contain an heterogeneous sequence of elements that are accessed via unpacking (see later in this section) or indexing (or even by attribute in the case of namedtuples). Lists are mutable, and their elements are usually homogeneous and are accessed by iterating over the list. """ Best Regards, Ezio Melotti > probably > at the point when people have learned enough to be designing their own > programs where this issue comes up -- before they're wizards but well after > they have learned the semantic differences between lists and tuples. > > > On Thu, Apr 17, 2014 at 11:49 AM, Brett Cannon wrote: >> >> >> >> On Thu Apr 17 2014 at 2:43:35 PM, Leandro Pereira de Lima e Silva >> wrote: >>> >>> Hello there! >>> >>> I've stumbled upon this discussion on python-dev about what the choice >>> between using a list or a tuple is all about in 2003: >>> 1. https://mail.python.org/pipermail/python-dev/2003-March/033962.html >>> 2. https://mail.python.org/pipermail/python-dev/2003-March/034029.html >>> >>> There's a vague comment about it on python documentation but afaik there >>> the discussion hasn't made into any PEPs. Is there an understanding about >>> it? >> >> >> Think of tuples like a struct in C, lists like an array. That's just out >> of Guido's head so I don't think we have ever bothered to write it down >> somewhere as an important distinction of the initial design that should be >> emphasized. >> >> ___ >> 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/guido%40python.org >> > > > > -- > --Guido van Rossum (python.org/~guido) > > ___ > 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/ezio.melotti%40gmail.com > ___ 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] this is what happens if you freeze all the modules required for startup
Hi, On Thu, Apr 17, 2014 at 9:09 PM, Brett Cannon wrote: > > > On Thu Apr 17 2014 at 1:34:23 PM, Jurko Gospodnetić > wrote: >> >>Hi. >> >> On 14.4.2014. 23:51, Brett Cannon wrote: >> > Now the question is whether the maintenance cost of having to rebuild >> > Python for a select number of stdlib modules is enough to warrant >> > putting in the effort to make this work. >> >>I would really love to have better startup times in production, but I >> would also really hate to lose the ability to hack around in stdlib >> sources during development just to get better startup performance. >> >>In general, what I really like about using Python for software >> development is the ability to open any stdlib file and easily go poking >> around using stuff like 'import pdb;pdb.set_trace()' or simple print >> statements. Researching mysterious behaviour is generally much much >> MUCH! easier (read: takes less hours/days/weeks) if it ends up leading >> into a stdlib Python module than if it takes you down into the bowels of >> some C module (think zipimport.c *grin*). Not to mention the effect that >> being able to quickly resolve a mystery by hacking on some Python >> internals leaves you feeling very satisfied, while having to entrench >> yourself in those internals for a long time just to find out you've made >> something foolish on your end leaves you feeling exhausted at best. > > > Freezing modules does not affect the ability to use gdb. And as long as you > set the appropriate __file__ values then tracebacks will contain even the > file line and location. > Will the tracebacks only contain the line number or the line of code too? I've seen tracebacks involving importlib,_bootstrap that didn't include the code, and I'm wondering if we will get something similar for all the other modules you are freezing: Traceback (most recent call last): File "/tmp/foo.py", line 7, in import email File "", line 1561, in _find_and_load File "", line 1519, in _find_and_load_unlocked File "", line 1473, in _find_module File "", line 1308, in find_module File "", line 1284, in _get_loader File "", line 1273, in _path_importer_cache File "", line 1254, in _path_hooks TypeError: 'NoneType' object is not iterable Best Regards, Ezio Melotti > -Brett > > ___ > 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/ezio.melotti%40gmail.com > ___ 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] PEP 469: Restoring the iterkeys/values/items() methods
Hi, On Sat, Apr 19, 2014 at 4:14 PM, Steven D'Aprano wrote: > On Sat, Apr 19, 2014 at 11:41:35AM +, Kristján Valur Jónsson wrote: >> It is a signigificant portion of the incompatibility, and seems like >> such a minor concession to compatibility to make. > > I don't think it is a significant portion of incompatibility. Or at > least, I think that the Twisted folks (or Nick, if he wants to speak for > them) have to justify why it's significant. > Assuming this gets included in 3.5 (which will be released around the end of 2015), are they planning to disregard all the previous 3.x releases and then wait a couple more years (so 2018+) for 3.5 to become common? Are they going to support 3.3+ only (with u'...') and have extra cruft for 3.3/3.4 to deal with the missing iter* methods and then remove the cruft once 3.5 is the oldest 3.x release that is supported? What happens if this addition will still not push people to move their code to 3.x and similar requests are made for 3.6+ (and shift what I just said for another 18 months)? Best Regards, Ezio Melotti > > > -- > Steven ___ 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] API and process questions (sparked by Claudiu Popa on 16104
On Mon, Apr 28, 2014 at 6:32 PM, Jim J. Jewett wrote: > (1) Should fixes to a docstring go in with a patch, even if they > aren't related to the changing functionality? > > [...] > > It is best if a commit changes one small thing at a time. > On the other hand, Nick recently posted that the minimal overhead of a > patch commit is about half an hour. > It could be much less. As an example, http://bugs.python.org/issue19943 has been closed 9 minutes after the report, it didn't have a patch and the fix had to be applied/grafted/merged on 3 branches. The time passed between the first commit and the push is less than a minute too. Clearly the time increases if you have to run the test suite or if there is a merge conflict/push race, and further decreases if there is a simple typo-fix on default only and a patch already available. > Is that overhead enough to override the one-issue-per-patch guideline? > That said, if the main fix should go only on default and it has a smaller unrelated fix that should also go on default only, then doing it together is generally OK (for some value of "unrelated" -- the fix should still be small and near the code you touched for the main fix). If the unrelated fix needs to be ported on all the branches (or in general in branches where the main fix shouldn't go), it's better to have two separate patches. If you commit the smaller fix together with the bigger one, and then decide to backport it, you will have to do a null merge and it gets slightly more complicated. Best Regards, Ezio Melotti ___ 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: Remove the redundant and poorly worded warning message.
Hi, On Sun, May 11, 2014 at 12:35 AM, Raymond Hettinger wrote: > > On May 10, 2014, at 2:18 PM, Alex Gaynor wrote: > > I think this change is a considerable usability regression for the > documentation. Right now the warnings about CSPRNGs are hidden in the > introductory paragraph, which users are likely to skip > > > In the past couple of years, we've grown an unfortunate tendency > to fill the docs with big warning boxes If the problem is the scary red boxes, http://bugs.python.org/issue13515 still has a patch to make them less intimidating (and some interesting discussion about it). Best Regards, Ezio Melotti > (the subprocess docs are > an example of implicitly communicating that the module is dangerous > and unusable). > > The preferred form of documentation is to be affirmatively worded, > telling how to use a tool correctly and what its known limitations are. > We save the warnings for cases of actual danger where otherwise > well informed users get tripped-up. > > Tim Peters used to be around to articulate the principle that we don't write > the docs with the assumption that the users are less bright than we are > or that they can't read. > > People writing applications that need to be sure should probably have > a howto guide. I don't think they are well served by filling the module > docs with every possible way a person could make a security mistake). > > If you're writing a secure on-line poker game, you really need to know > a great deal more about security than the warning message can supply. > My understanding is that actual gaming systems use seeded CSPRNGs > rather than urandom() because those systems need to be auditable. > > > Raymond > > > P.S. The docs for the random module had a successful 20 year history > without the redundant big red warning box, so it is not really correct > to say there has been a "considerable usability regression". ___ 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] Summary of Python tracker Issues
Hi, On Sat, Feb 8, 2014 at 1:37 PM, francis wrote: > On 02/07/2014 06:07 PM, Python tracker wrote: >> >> Open issues with patches: 2045 > > > Has somebody done a graphic of that data againsttime? > You can find some charts here (it's still a work in progress though): http://bugs.python.org/issue?@template=stats Best Regards, Ezio Melotti > Regards, > francis > ___ 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
[Python-Dev] Tracker Stats
Hi, I added a new "stats" page to the bug tracker: http://bugs.python.org/issue?@template=stats The page can be reached from the sidebar of the bug tracker: Summaries -> Stats The data are updated once a week, together with the Summary of Python tracker issues. Best Regards, Ezio Melotti ___ 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] Summary of Python tracker Issues
On Fri, Mar 1, 2019 at 5:59 AM Terry Reedy wrote: > > On 2/28/2019 6:54 PM, Glenn Linderman wrote: > > > There seems to be enough evidence that something went wrong somewhere, > > though, and whoever maintains that process should start investigating, > > but it would still be nice to get confirmation from a non-Google email > > recipient whether they did or did not get the Summary messages. > > > > I wonder if there is a way to manually send them, and if the missing two > > weeks of activity can be reported... once the sending problem is > > understood and resolved. > > I posted a note to the core-workflow list, but I don't know if anyone > with power or knowledge still reads it. > The tracker got migrated recently, and that's the most likely cause of the missing reports. We'll look into it and get them back :) > To get a listing, go to the tracker search page, put > 2019-02-09 to 2019-03-01 > in the date box, and change status to don't care. At the moment, this > returns 204 issues. > > -- > Terry Jan Reedy > ___ 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] Summary of Python tracker Issues
On Fri, Mar 1, 2019 at 8:05 AM Ezio Melotti wrote: > > On Fri, Mar 1, 2019 at 5:59 AM Terry Reedy wrote: > > > > On 2/28/2019 6:54 PM, Glenn Linderman wrote: > > > > > There seems to be enough evidence that something went wrong somewhere, > > > though, and whoever maintains that process should start investigating, > > > but it would still be nice to get confirmation from a non-Google email > > > recipient whether they did or did not get the Summary messages. > > > > > > I wonder if there is a way to manually send them, and if the missing two > > > weeks of activity can be reported... once the sending problem is > > > understood and resolved. > > > > I posted a note to the core-workflow list, but I don't know if anyone > > with power or knowledge still reads it. > > > > The tracker got migrated recently, and that's the most likely cause of > the missing reports. > We'll look into it and get them back :) > Ernest promptly fixed the issue so last week report was sent out correctly. I just generated and sent out the two reports that were missing and updated the tracker stats at https://bugs.python.org/issue?@template=stats Note that some values in the report might be a bit off (for example, the list of issues waiting for review doesn't include issues that were closed after the selected period, and the patch count includes issues created before or during the selected period even if a patch was uploaded after the selected period). The issues counts and deltas at the top of the summary should be correct. Let me know if you notice any other problem (and thanks Ned for bringing this to my attention!). Best Regards, Ezio Melotti > > To get a listing, go to the tracker search page, put > > 2019-02-09 to 2019-03-01 > > in the date box, and change status to don't care. At the moment, this > > returns 204 issues. > > > > -- > > Terry Jan Reedy > > ___ 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-committers] PEP 581 (Using GitHub issues for CPython) is accepted
Hello, On Wed, May 15, 2019 at 5:18 PM Paul Moore wrote: > > On Wed, 15 May 2019 at 15:56, Victor Stinner wrote: > > > > Hi Paul, > > Le mer. 15 mai 2019 à 11:40, Paul Moore a écrit : > > > Also, is there an archive of the discussions anywhere? The PEP says > > > discussions happened on Zulip, but I don't follow that and I don't > > > know where I can find an archived copy of the discussions. > > > > Well, the PEP has been discussed a lot at many places since May 2018. > > Thanks for all of these. I appreciate the time you took locating them > for me. But I do have to say that I still can't really follow any > useful "thread of discussion" - it all seems very fragmented, and it's > difficult to see the progress towards consensus. Maybe that's just > because I'm too used to mailing lists :-) > I share the same concerns: 1) the discussion was fragmented between zulip/discuss/github/python-dev/python-committers/sprints/pycons and very difficult to follow, even for interested people (Victor already posted several links but missed a few others); 2) the progress toward consensus was not clear and the approval came somewhat unexpectedly (it was mentioned a couple of weeks ago on https://mail.python.org/pipermail/python-committers/2019-April/006705.html and AFAICT no further discussion took place in public forums since then); In addition: 1) the PEP contains several factual errors. I pointed this out during the core-sprints last year and more recently Berker pointed out some on GitHub: https://github.com/python/peps/pull/1013 ; 2) the "discussions-to" header of the PEP points to the zulip stream. The stream has not been active for 6 months (it got a few new messages today, the previous activity was in Dec 2018); 3) most of the discussions linked by Victor happened last year. Unless I missed some, the only discussions happened this year are the two on Discuss from February (with 3 messages each from a total of 5 authors), and the python-dev thread from March (with 12 messages from 7 authors). One of the two Discuss threads was a inquiry about the process (https://discuss.python.org/t/move-pep-581-discussion/873); 4) Berker is/was writing a competing PEP, in order to address the problems of PEP 581 more effectively since his comments on GitHub haven't been addressed; 5) next week a student is supposed to start working for the PSF on b.p.o and Roundup as part of Google Summer of Code (http://python-gsoc.org/psf_ideas.html); 6) PEP 8016 says "The council should look for ways to use these powers as little as possible. Instead of voting, it's better to seek consensus. Instead of ruling on individual PEPs, it's better to define a standard process for PEP decision making."; To summarize, I feel the approval of this PEP is premature and that consensus was reached in a way that wasn't very transparent, without considering some of the concerns. (This might also be a symptom of a wider problem caused by the fragmentation of the discussions between the old MLs, discuss, zulip, IRC, GitHub PRs and issues, and IRL meetings, but this is a separate topic.) Best Regards, Ezio Melotti > > The PEP 581 has been (first?) discussed at the Language Summit which > > was part of Pycon US 2018 (May 2018). > > Was that written up, or is it all just from people's memories by now? > > > https://github.com/python/peps/pull/681/ > > Ah - I don't really follow this sort of PR discussion, as the github > emails don't tend to have sufficient context on what's being said, so > I (mostly) gave up a long time ago. Also, I tend to assume that > discussions on PRs are mostly about details of wording, and > substantive changes will be dealt with in a wider forum. I wonder if I > should be following PRs on the PEPs repository more closely...? > > > Multiple threads on Discourse: > > > > https://discuss.python.org/t/move-pep-581-discussion/873 > > https://discuss.python.org/t/pep-581-using-github-issues/535 > > https://discuss.python.org/t/what-are-next-steps-for-pep-581/864 > > https://discuss.python.org/t/pep-process-after-pep-8016/558/4 > > > > Thread on python-dev: > > > > https://mail.python.org/pipermail/python-dev/2019-March/156626.html > > > > Threads on python-committers: > > > > https://mail.python.org/pipermail/python-committers/2018-May/005428.html > > https://mail.python.org/pipermail/python-committers/2018-June/005506.html > > https://mail.python.org/pipermail/python-committers/2018-July/005657.html > > I saw these, but didn't get much of a sense of progress towards > agreement. Again, maybe just because they were lots of fragmented > threads and locations. > > > Discussion on
[Python-Dev] PEP 595: Improving bugs.python.org
Hello, Berker and I have been working on a PEP that suggests we keep using and improving bugs.python.org and Roundup instead of switching to GitHub Issues as proposed by PEP 581. The PEP covers: * What are the advantages of Roundup over GitHub issues; * What features are missing in Roundup and how can we add them; * Issues with PEP 581; * Issues with the migration plan proposed by PEP 588; The rendered version of PEP 595 is available at https://www.python.org/dev/peps/pep-0595/ For reference, you can consult PEP 581 and 588 at https://www.python.org/dev/peps/pep-0581/ and https://www.python.org/dev/peps/pep-0588/ The full text of the PEP is include below. We are planning to update the PEP to include the feedback we receive and to update the status of features as we implement them (we also have a Google Summer of Code students working on it). Best Regards, Ezio Melotti PEP: 595 Title: Improving bugs.python.org Author: Ezio Melotti , Berker Peksag Status: Draft Type: Process Content-Type: text/x-rst Created: 12-May-2019 Abstract This PEP proposes a list of improvements to make bugs.python.org more usable for contributors and core developers. This PEP also discusses why remaining on Roundup should be preferred over switching to GitHub Issues, as proposed by :pep:`581`. Motivation == On May 14th, 2019 :pep:`581` has been accepted [#]_ without much public discussion and without a clear consensus [#]_. The PEP contains factual errors and doesn't address some of the issues that the migration to GitHub Issues might present. Given the scope of the migration, the amount of work required, and how it will negatively affect the workflow during the transition phase, this decision should be re-evaluated. Roundup advantages over GitHub Issues = This section discusses reasons why Roundup should be preferred over GitHub Issues and Roundup features that are not available on GitHub Issues. * **Roundup is the status quo.** Roundup has been an integral part of the CPython workflow for years. It is a stable product that has been tested and customized to adapt to our needs as the workflow evolved. It is possible to gradually improve it and avoid the disruption that a switch to a different system would inevitabily bring to the workflow. * **Open-source and Python powered.** Roundup is an open-source project and is written in Python. By using it and supporting it, we also support the Python ecosystem. Several features developed for bpo have also been ported to upstream Roundup over the years. * **Fully customizable.** Roundup can be (and has been) fully customized to fit our needs. * **Finer-grained access control.** Roundup allows the creation of different roles with different permissions (e.g. create, view, edit, etc.) for each individual property, and users can have multiple roles. * **Flexible UI.** While Roundup UI might look dated, it is convenient and flexible. For example, on the issue page, each field (e.g. title, type, versions, status, linked files and PRs, etc.) have appropriate UI elements (input boxes, dropdowns, tables, etc.) that are easy to set and also provide a convenient way to get info about the issue at a glance. The number of fields, their values, and the UI element they use is also fully customizable. GitHub only provides labels. The issue list page presents the issues in a compact and easy to read table with separate columns for different fields. For comparison, Roundup lists 50 issues in a screen, whereas GitHub takes two screens to shows 25 issues. * **Advanced search.** Roundup provides an accurate way to search and filter by using any combination of issue fields. It is also possible to customize the number of results and the fields displayed in the table, and the sorting and grouping (up to two levels). bpo also provides predefined summaries (e.g. "Created by you", "Assigned to you", etc.) and allows the creation of custom search queries that can be conveniently accessed from the sidebar. * **Nosy list autocomplete.** The nosy list has an autocomplete feature that suggests maintainers and experts. The suggestions are automatically updated when the experts index [#]_ changes. * **Dependencies and Superseders.** Roundup allows to specify dependencies that must be addressed before the current issues can be closed and a superseder issue to easily mark duplicates [#]_. The list of dependencies can also be used to create meta-issues that references several other sub-issues [#]_. Improving Roundup = This section lists some of the issues mentioned by :pep:`581` and other desired features and discusses how they can be implemented by improving Roundup and/or our instance. * **REST API support.** A REST API will make integration with other services and the development of n
Re: [Python-Dev] [python-committers] PEP 595: Improving bugs.python.org
On Fri, May 24, 2019, 20:23 Gregory P. Smith wrote: > -cc: committers to avoid crossposting. > +1 (I wanted to include committers, since the announcement about PEP 581 was posted there too, but it's better to keep the discussion here) > I have feedback for roundup as experienced on BPO that should be > represented within PEP 595 if we are going to have a summary of "improving > roundup for BPO" captured in a PEP (presumably already rejected given 581? > But good to have documented regardless so _thank you_ for doing this > writeup even though I realize our plan of record may be demoralizing for > you). > We would like people to re-evaluate the decision, but if that doesn't happen I think the PEP is still useful, since it provides a fair view of Roundup capabilities and discusses things that we will have to take into account if we proceed with the migration -- that's why we decided to go ahead and write the PEP. > > **Flexible UI.** While Roundup UI might look dated, it is convenient > and flexible. > > I wholly disagree with this statement. > > The BPO roundup UI drives me nuts. every. single. time. I have to use it. > It is not optimized for common workflows users actually need to accomplish > when using a bug tracker. Two example usability issues (of many): Users > can't read the latest update to a bug of length because it is hidden within > the *middle* of the scrolling region, they must hunt for it. > This came up in the past, and two solutions have been proposed already: 1) keyboard shortcuts have been added in the issue page to quickly jump to the first/previous/next/last message and to the response box [0]. They support both mnemonic (f/p/n/l/r) and vim-style (h/k/j/l/i) combinations. You can find a summary table in the left sidebar of the issue page, under help -> keyboard shortcuts. 2) a patch to collapse the history by default (so that the last message was at the end of the page) was proposed and merged [1], but it was reverted after a few days because some devs wanted direct access to the history without having to do an extra click every time to expand it. After reading, the text box to add to the discussion is oddly located near > the *top* of the scrolling region so that a user cannot see context of a > bug discussion they are responding to as they type. > This has also been discussed and different people had different opinion. Some suggested to reverse the order of the messages so that the last message is at the top near the reply box (like Twitter does), but other said it's unnatural to read. Some suggested to put the reply box at the bottom; however if the other fields are left at the top you would have to go back up to set them, and if they are moved down you won't easily see them at the top when you open an existing issue. Another solution is duplicating the fields and response box at the top and bottom. What I mean with *flexible* when I wrote the PEP, is that, unlike GitHub (where they decide), we can customize bpo however we want (as long as we agree on what we want -- we could even have per-user settings if we really want to :) I think I last heard discussion on the position of the response box in 2011 (when shortcuts and history collapsing were discussed). Maybe people didn't care enough about it so they didn't bother bringing it up or they didn't know it could be changed. If people do speak up, we can change bpo/Roundup. I file things like this under "User experience design is needed for the > common workflows of all classes of users". > > Roundup needs a modern responsive web interface, not GET/POST request > based interface seen on BPO. As a result of that, roundup *feels* like > is belongs in the Pre-2004 era interface wise by being web form and full > page reload server for everything. A responsive modern "async javascript > requests happen in the background of the UI" system that we all expect of > any web UI is needed. Not just tweaking the existing thing to have a mobile > friendly version of the web form. This includes persistent connections so > that updates to an issue show up live as they happen instead of getting an > error message "someone/something else has updated this issue since you > started typing, the action you wanted to take such as submitting that > comment or editing that field is now invalid and cannot be completed > without a lot of manual work figuring out what happened, cut and pasting, > and fixing things up on the you the users part". > This is a good point and I think it can be done now that Roundup has a REST API. > I'm not going to try proposing a PR to this PEP encapsulating that, I'll > leave that up to anyone willing to wrangle such a PEP. The list archive > has it regardless now. :) &
Re: [Python-Dev] [python-committers] PEP 595: Improving bugs.python.org
On Fri, May 24, 2019, 23:14 Gregory P. Smith wrote: > > > On Fri, May 24, 2019 at 1:48 PM Ezio Melotti > wrote: > >> >> On Fri, May 24, 2019, 20:23 Gregory P. Smith wrote: >> >>> -cc: committers to avoid crossposting. >>> >> >> +1 (I wanted to include committers, since the announcement about PEP 581 >> was posted there too, but it's better to keep the discussion here) >> >> >>> I have feedback for roundup as experienced on BPO that should be >>> represented within PEP 595 if we are going to have a summary of "improving >>> roundup for BPO" captured in a PEP (presumably already rejected given 581? >>> But good to have documented regardless so _thank you_ for doing this >>> writeup even though I realize our plan of record may be demoralizing for >>> you). >>> >> >> We would like people to re-evaluate the decision, but if that doesn't >> happen I think the PEP is still useful, since it provides a fair view of >> Roundup capabilities and discusses things that we will have to take into >> account if we proceed with the migration -- that's why we decided to go >> ahead and write the PEP. >> >> >>> > **Flexible UI.** While Roundup UI might look dated, it is convenient >>> and flexible. >>> >>> I wholly disagree with this statement. >>> >> >>> The BPO roundup UI drives me nuts. every. single. time. I have to use >>> it. It is not optimized for common workflows users actually need to >>> accomplish when using a bug tracker. Two example usability issues (of >>> many): Users can't read the latest update to a bug of length because it is >>> hidden within the *middle* of the scrolling region, they must hunt for it. >>> >> >> This came up in the past, and two solutions have been proposed already: >> 1) keyboard shortcuts have been added in the issue page to quickly jump >> to the first/previous/next/last message and to the response box [0]. They >> support both mnemonic (f/p/n/l/r) and vim-style (h/k/j/l/i) combinations. >> You can find a summary table in the left sidebar of the issue page, under >> help -> keyboard shortcuts. >> 2) a patch to collapse the history by default (so that the last message >> was at the end of the page) was proposed and merged [1], but it was >> reverted after a few days because some devs wanted direct access to the >> history without having to do an extra click every time to expand it. >> >> After reading, the text box to add to the discussion is oddly located >>> near the *top* of the scrolling region so that a user cannot see context of >>> a bug discussion they are responding to as they type. >>> >> >> This has also been discussed and different people had different opinion. >> Some suggested to reverse the order of the messages so that the last >> message is at the top near the reply box (like Twitter does), but other >> said it's unnatural to read. Some suggested to put the reply box at the >> bottom; however if the other fields are left at the top you would have to >> go back up to set them, and if they are moved down you won't easily see >> them at the top when you open an existing issue. Another solution is >> duplicating the fields and response box at the top and bottom. >> > > The two other modern bugtracker UIs I use on a regular basis do this by > having all such non-conversation metainfo in a persistent top and side bar > boxes such that it is always present. Keeping the conversation and > metainfo changes listed in order (latest message at the bottom, metainfo > deltas interspersed in between messages all ordered/grouped by timestamp, > and reply text entry box below that. These two are typically big-screen > engineering UIs (github being one of them), if mobile is desired i expect > these would effectively wind up as a multi-pane UI. There's a third ticket > that I use for non-engineering stuff which does things in reverse order > with the text entry up top and messages in reverse chronological order > below that. This reversal always annoys me; probably because I spend most > of my time in the others so it forces me to do headstands. I don't know if > there is a *right* answer between the two approaches, I just know what I > prefer. But the common theme is keeping new the update UI elements right > next to the most recent entries which is what BPO lacks today. > > What I mean with *flexible* when I wrote the PEP, is that, unlike GitHub >> (where they decide), we can customize bpo however we w
Re: [Python-Dev] PEP 595: Improving bugs.python.org
On Thu, May 23, 2019 at 10:17 PM Ezio Melotti wrote: > > Hello, > Berker and I have been working on a PEP that suggests we keep using > and improving bugs.python.org and Roundup instead of switching to > GitHub Issues as proposed by PEP 581. > > The PEP covers: > * What are the advantages of Roundup over GitHub issues; > * What features are missing in Roundup and how can we add them; > * Issues with PEP 581; > * Issues with the migration plan proposed by PEP 588; > > The rendered version of PEP 595 is available at > https://www.python.org/dev/peps/pep-0595/ > > For reference, you can consult PEP 581 and 588 at > https://www.python.org/dev/peps/pep-0581/ and > https://www.python.org/dev/peps/pep-0588/ > > The full text of the PEP is include below. We are planning to update > the PEP to include the feedback we receive and to update the status of > features as we implement them (we also have a Google Summer of Code > students working on it). > > Best Regards, > Ezio Melotti > > Hello, earlier today I expanded and reworded the "Migration considerations" section and added the feedback I got from the replies. You can find the rendered version of that section (and the rest of the PEP) at https://www.python.org/dev/peps/pep-0595/#migration-considerations The changeset can be found at https://github.com/python/peps/commit/b3f4c8eb09d1987d00785cad385adf7e0394776e The full text of the latest version of the PEP is included below. Best Regards, Ezio Melotti PEP: 595 Title: Improving bugs.python.org Author: Ezio Melotti , Berker Peksag Status: Draft Type: Process Content-Type: text/x-rst Created: 12-May-2019 Abstract This PEP proposes a list of improvements to make bugs.python.org more usable for contributors and core developers. This PEP also discusses why remaining on Roundup should be preferred over switching to GitHub Issues, as proposed by :pep:`581`. Motivation == On May 14th, 2019 :pep:`581` has been accepted [#]_ without much public discussion and without a clear consensus [#]_. The PEP contains factual errors and doesn't address some of the issues that the migration to GitHub Issues might present. Given the scope of the migration, the amount of work required, and how it will negatively affect the workflow during the transition phase, this decision should be re-evaluated. Roundup advantages over GitHub Issues = This section discusses reasons why Roundup should be preferred over GitHub Issues and Roundup features that are not available on GitHub Issues. * **Roundup is the status quo.** Roundup has been an integral part of the CPython workflow for years. It is a stable product that has been tested and customized to adapt to our needs as the workflow evolved. It is possible to gradually improve it and avoid the disruption that a switch to a different system would inevitabily bring to the workflow. * **Open-source and Python powered.** Roundup is an open-source project and is written in Python. By using it and supporting it, we also support the Python ecosystem. Several features developed for bpo have also been ported to upstream Roundup over the years. * **Fully customizable.** Roundup can be (and has been) fully customized to fit our needs. * **Finer-grained access control.** Roundup allows the creation of different roles with different permissions (e.g. create, view, edit, etc.) for each individual property, and users can have multiple roles. * **Flexible UI.** While Roundup UI might look dated, it is convenient and flexible. For example, on the issue page, each field (e.g. title, type, versions, status, linked files and PRs, etc.) have appropriate UI elements (input boxes, dropdowns, tables, etc.) that are easy to set and also provide a convenient way to get info about the issue at a glance. The number of fields, their values, and the UI element they use is also fully customizable. GitHub only provides labels. The issue list page presents the issues in a compact and easy to read table with separate columns for different fields. For comparison, Roundup lists 50 issues in a screen, whereas GitHub takes two screens to shows 25 issues. * **Advanced search.** Roundup provides an accurate way to search and filter by using any combination of issue fields. It is also possible to customize the number of results and the fields displayed in the table, and the sorting and grouping (up to two levels). bpo also provides predefined summaries (e.g. "Created by you", "Assigned to you", etc.) and allows the creation of custom search queries that can be conveniently accessed from the sidebar. * **Nosy list autocomplete.** The nosy list has an autocomplete feature that suggests maintainers and experts. The suggestions are au
Re: [Python-Dev] PEP 595: Improving bugs.python.org
rs; * if we involve regular users we might get better feedback, but there's risk of confusion (afaik the only way to inform users on GitHub Issues is writing another bot that adds messages) and backlash; * doing separate specific tests (e.g. having a read-only repo with all the issues to test search/navigation, and a separate read-write repo to test issue creation) or a "real-world" test; * some specific tests might be easier to setup (e.g. issue creation test using templates), but for others we still need to import some/all the issues; If we agree on testing, I think we need to discuss the options, define and document a list of steps, and start working on it. Best Regards, Ezio Melotti > Regards > > Antoine. ___ 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
[Python-Dev] Re: Long-term deprecation policy
On Wed, Jul 17, 2019 at 2:36 AM Brett Cannon wrote: > > Jeroen Demeyer wrote: > > I have seen multiple discussions where somebody wants to deprecate a > > useless function but somebody else complains that we cannot do that > > because the function in question cannot be removed (because of backwards > > compatibility). See https://bugs.python.org/issue29548... for an > > example. > > We currently have a deprecation policy saying that functions deprecated > > in version N cannot be removed before version N+2. > > Do we have that officially written down anywhere? The closest I know is > https://www.python.org/dev/peps/pep-0387/ but that PEP is still a draft. > > And for me the "official" policy is if you deprecate in N you can remove in > N+1, not N+2. (But all of this is a bit wonky with Python 2.7 still being > alive and not being able to remove anything from the stdlib unless it's > severely broken until 2.7 hits EOL). > See also https://mail.python.org/archives/list/python-dev@python.org/thread/ZUKVACWVX7SQEA7FGZRXALR7PWCLV7K6/ Some things changed since that thread, but some points are still valid. > > That's a reasonable > > policy but some deprecation purists insist that it MUST (instead of MAY) > > be removed in version N+2. Following this reasoning, we cannot deprecate > > something that we cannot remove. > > Personally, I think that this reasoning is flawed: even if we cannot > > remove a function, we can still deprecate it. That way, we send a > > message that the function shouldn't be used anymore. And it makes it > > easier to remove it in the (far) future: if the function was deprecated > > for a while, we have a valid reason to remove it. The longer it was > > deprecated, the less likely it is to be still used, which makes it > > easier to remove eventually. > > So I suggest to embrace such long-term deprecations, where we deprecate > > something without planning in advance when it will be removed. This is > > actually how most other open source projects that I know handle > > deprecations. > > I'd like to know the opinion of the Python core devs here. > > I prefer removal for ease of maintenance (people always want to update code > even if it's deprecated), and to help make sure people who don't read the > docs but discover something via the REPL or something and don't run with > warnings on do not accidentally come to rely on something that's deprecated. > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/PRI2O6G6O6HUVGXD3W2MSCEF4JTW36IB/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GQDFRX3K6DIWYSRZNAW2AIOUCGHSZWA4/
[Python-Dev] Roundup to GitHub Issues migration
As you might know, PEP 581 (Using GitHub Issues for CPython) has been approved. I've been working with Ewa, Ee, the Working Group, the Steering Council, and the GitHub folks to make this happen, and the SC encouraged me to give you all a quick update. This effort is being tracked at <https://github.com/psf/gh-migration/projects/1>: this board reflects the current status of the project. The PEPs (including PEP 588 -- GitHub Issues Migration Plan) haven't been updated yet and might contain outdated information, so please refer to the psf/gh-migration repo for the latest updates. During the next phase I will work with the WG to sort out all the major issues that we might encounter, and then I will once again reach out to you to gather feedback from the wider audience that follows these mailing lists. Best Regards, Ezio Melotti ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QQT7DOKTBKZRFLT6GUJLNQOC3YDLBSLU/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
Hi, On Sat, Feb 23, 2013 at 5:33 AM, daniel.holth wrote: > http://hg.python.org/peps/rev/de69fe61f300 > changeset: 4764:de69fe61f300 > user:Daniel Holth > date:Fri Feb 22 22:33:09 2013 -0500 > summary: > PEP 426: replace implied 'version starts with' with new ~= operator > I haven't seen any discussion about this, but FWIW CSS [0] and JQuery [1] use ^= for this purpose. ^ also indicates the beginning of the string in regular expressions (this is why ^= was chosen for CSS/JQuery). They also use ~= to indicate "attribute contains word" [0][2]. Perl also has a similar-looking operator [3] (=~) used to test a regex match. Best Regards, Ezio Melotti [0]: http://www.w3.org/TR/selectors/#selectors [1]: http://api.jquery.com/attribute-starts-with-selector/ [2]: http://api.jquery.com/attribute-contains-word-selector/ [3]: http://perldoc.perl.org/perlop.html#Binding-Operators ___ 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.3): Don't deadlock on a reentrant call.
Hi, On Fri, Mar 1, 2013 at 2:02 PM, raymond.hettinger wrote: > http://hg.python.org/cpython/rev/1920422626a5 > changeset: 82437:1920422626a5 > branch: 3.3 > parent: 82435:43ac02b7e322 > user:Raymond Hettinger > date:Fri Mar 01 03:47:57 2013 -0800 > summary: > Don't deadlock on a reentrant call. this seems to have broken builds without threads. After this commit I get a compile error: $ ./configure --without-threads --with-pydebug && make -j2 [...] ./python -E -S -m sysconfig --generate-posix-vars Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] Could not import runpy module Exception ignored in: 'garbage collection' Traceback (most recent call last): File "/home/wolf/dev/py/py3k/Lib/runpy.py", line 16, in import imp File "/home/wolf/dev/py/py3k/Lib/imp.py", line 23, in import tokenize File "/home/wolf/dev/py/py3k/Lib/tokenize.py", line 28, in import re File "/home/wolf/dev/py/py3k/Lib/re.py", line 124, in import functools File "/home/wolf/dev/py/py3k/Lib/functools.py", line 22, in from dummy_threading import RLock File "/home/wolf/dev/py/py3k/Lib/dummy_threading.py", line 45, in import threading File "/home/wolf/dev/py/py3k/Lib/threading.py", line 6, in from time import sleep as _sleep ImportError: No module named 'time' Fatal Python error: unexpected exception during garbage collection Current thread 0x: make: *** [pybuilddir.txt] Aborted (core dumped) See also: http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/4006 http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.3/builds/516 (Also having tests for this change would be nice.) Best Regards, Ezio Melotti ___ 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] Introducing Electronic Contributor Agreements
Hi, On Mon, Mar 4, 2013 at 10:46 PM, Terry Reedy wrote: > On 3/4/2013 11:36 AM, Brett Cannon wrote: >> On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin > <mailto:br...@python.org>> wrote: >> >> With this in place I would like to propose that all patches submitted to >> bugs.python.org <http://bugs.python.org> must come from someone who has >> >> signed the CLA before we consider committing it (if you want to be truly >> paranoid we could say that we won't even look at the code w/o a CLA). > > > Either policy could be facilitated by tracker changes. In order to see the > file upload box, one must login and the tracker knows who has a CLA on file > (as indicated by a * suffix on the name). If a file is uploaded by someone > without, a box could popup with the link to the e-form and a message that a > CLA is required. > http://psf.upfronthosting.co.za/roundup/meta/issue461 Best Regards, Ezio Melotti > -- > Terry Jan Reedy > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VC++ 2008 Express Edition now locked away?
Hi, On Wed, Mar 6, 2013 at 12:20 PM, Terry Reedy wrote: > Clicking this link > http://www.microsoft.com/en-us/download/details.aspx?id=14597 > on this Developer Guide page > http://docs.python.org/devguide/setup.html#windows > now returns a > "We are sorry, the page you requested cannot be found." > page with search results. > > The first search result > http://social.msdn.microsoft.com/Forums/nl/Vsexpressinstall/thread/2dc7ae6a-a0e7-436b-a1b3-3597ffac6a97 > suggests that one must first go to http://profile.microsoft.com > which forwards to the live.com login page. Logging in with my un-expired > non-developer account did not make the original link work. > > The mdsn page http://msdn.microsoft.com/en-US/ > has Visual Studio / Download trial, which leads to > https://www.microsoft.com/visualstudio/eng/downloads > which lists 2012 and 2010 but not 2008. > > I suspect that an msdn account is required for most people to get 2008. > > A later link leads to > https://www.dreamspark.com/Product/Product.aspx?productid=34# > which suggests that vc++2008 express is also available to verified degree > students. I don't qualify so I will not try. > I did try a few weeks ago, when I had to download a copy of Windows for a project. Long story short, after 30+ minutes and a number of confirmation emails I reached a point where I had a couple of new accounts on MSDN/Dreamspark, a "purchased" free copy of Windows in my e-cart, and some .exe I had to download in order to download and verify the purchased copy. That's where I gave up. Best Regards, Ezio Melotti > So it would appear that section "1.1.3.3. Windows" of "1. Getting Started" > (setup.rst) needs further revision. > > Or perhaps we could persuade Microsoft to let us distribute it ourselves so > Windows versions of 2.7 do not become increasingly unusable. > > -- > Terry Jan Reedy > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #17385: Fix quadratic behavior in threading.Condition
Hi, On Mon, Mar 11, 2013 at 2:58 AM, raymond.hettinger wrote: > http://hg.python.org/cpython/rev/0f86b51f8f8b > changeset: 82592:0f86b51f8f8b > user:Raymond Hettinger > date:Sun Mar 10 17:57:28 2013 -0700 > summary: > Issue #17385: Fix quadratic behavior in threading.Condition > > files: > Lib/threading.py | 10 -- > Misc/NEWS| 3 +++ > 2 files changed, 11 insertions(+), 2 deletions(-) > > > diff --git a/Lib/threading.py b/Lib/threading.py > --- a/Lib/threading.py > +++ b/Lib/threading.py > @@ -10,6 +10,12 @@ > from time import time as _time > from traceback import format_exc as _format_exc > from _weakrefset import WeakSet > +try: > +from _itertools import islice as _slice > +from _collections import deque as _deque > +except ImportError: > +from itertools import islice as _islice > +from collections import deque as _deque > Shouldn't the one in the 'try' be _islice too? Best Regards, Ezio Melotti ___ 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): #16004: Add `make touch`.
Hi, On Mon, Mar 11, 2013 at 3:28 PM, Antoine Pitrou wrote: > On Mon, 11 Mar 2013 08:14:24 +0100 (CET) > ezio.melotti wrote: >> http://hg.python.org/cpython/rev/da3f4774b939 >> changeset: 82600:da3f4774b939 >> branch: 2.7 >> parent: 82593:3e14aafeca04 >> user:Ezio Melotti >> date:Mon Mar 11 09:14:09 2013 +0200 >> summary: >> #16004: Add `make touch`. > > Shouldn't that be mentioned / explained / documented somewhere? > It doesn't look obvious in which circumstances it could be useful. > It will be documented in http://bugs.python.org/issue15964 (SyntaxError in asdl when building 2.7 with system Python 3). Best Regards, Ezio Melotti > Regards > > Antoine. > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] CANNOT Patch 3.x NEWS [was cpython (2.7): Issue #14707: add news entry\
Hi, On Tue, Mar 12, 2013 at 8:14 AM, Terry Reedy wrote: > On 3/12/2013 1:50 AM, terry.reedy wrote: >> >> http://hg.python.org/cpython/rev/c162e2ff15bd >> changeset: 82624:c162e2ff15bd >> branch: 2.7 >> parent: 82617:cd0191a9b5c9 >> user:Terry Jan Reedy >> date:Tue Mar 12 01:26:28 2013 -0400 >> summary: >>Issue #14707: add news entry >> >> files: >>Misc/NEWS | 3 +++ >>1 files changed, 3 insertions(+), 0 deletions(-) >> >> >> diff --git a/Misc/NEWS b/Misc/NEWS >> --- a/Misc/NEWS >> +++ b/Misc/NEWS >> @@ -944,6 +944,9 @@ >> Documentation >> - >> >> +- Issue #14707: remove doubled words in docs and docstrings >> + reported by Serhiy Storchaka and Matthew Barnett. >> + >> - Issue #16406: combine the pages for uploading and registering to PyPI. >> >> - Issue #16403: Document how distutils uses the maintainer field in > > > The above was easy. When I tried to transplant this patch to 3.2, export and > import, or directly edit 3.2 NEWS with Notepad++ or IDLE, hg makes a 319kb > patch that deletes and add the entire file in chunks. I did not think I > should commit and push that. > What are the exact commands you used? Are your clones up to date (i.e. did you do "hg pull" and "hg up" before "hg graft")? If not, you should pull/update. Does "hg heads ." show you more than one head? If so you should do "hg merge". Is your clone "clean" (i.e. does "hg status" show anything as 'M')? If not, you should do "hg revert -ar 3.2" or "hg up -C 3.2". Once your clone is clean you can just edit Misc/NEWS manually since it's easier than trying to graft the 2 changesets you made on 2.7 to add and edit the Misc/NEWS entry. You can also check with "hg in" and "hg out" if there's something you haven't pulled/pushed yet, but that shouldn't be a problem. > The failure of transplant and import are perhaps understandable because 3.2 > has a gratuitous case difference with /combine/Combine/. > > - Issue #16406: Combine the pages for uploading and registering to PyPI. > > But the inability to make a proper diff from direct edit is something else. > If I add just a single blank line, even that generates a mega patch. Same > with 3.3 NEWS. I also tried deleting the file to make hg regenerate from the > repository database. > > Anyone have any idea what the problem is? Has anything changed with hg, > windows, line endings and this text file in the last few months? I just > pushed patches for about 20 scattered files in Docs, Lib, Modules, and Tools > earlier today, so the problem seems to be specific to NEWS. > Not sure about this, but in the meanwhile you could try what I suggested above -- if that doesn't work we can find some other solution. (If you prefer you can come on #python-dev too.) Best Regards, Ezio Melotti > tjr > ___ 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] CANNOT Patch 3.x NEWS [was cpython (2.7): Issue #14707: add news entry\
Hi,
On Tue, Mar 12, 2013 at 7:19 PM, Terry Reedy wrote:
> On 3/12/2013 2:52 AM, Ezio Melotti wrote:
>> What are the exact commands you used?
>
> Clicks on TortoiseHg HgWorkbench GUI ;-).
>
I wonder if TortoiseHg is doing something wrong here. Maybe you could
try from cmd too.
>> Are your clones up to date (i.e. did you do "hg pull" and "hg up"
>> before "hg graft")?
>
> There were no other pushes between my last de-double patch and this, and I
> am sure I ran my pull + 3*update .bat first. I have run it multiple times
> since.
>
Around the time you pushed on 2.7 I also pushed something, so that
might have created some conflict.
How does your .bat look like? One gotcha of the share extension is
that if you use "hg pull -u" and there's nothing to pull because you
already pulled in one of the shared clones, the update won't be
executed (this is actually normal behaviour of "hg pull", but the
consequences are especially noticeable while using shared clones).
>> Does "hg heads ." show you more than one head?
>
> The DAG window shows the normal one head per branch as appropriate for the
> particular branch display. At the moment, hg heads shows the four commits
> from Eli, 82628 to 82631 as heads plus old 2.6 and 3.1 heads.
>
>> Is your clone "clean" (i.e. does "hg status" show anything as 'M')?
>
> The status window is empty until I edit NEWS and click Refresh, at which
> point M Misc/News shows up with the megadiff.
> Right click/ Revert/yes and the file is reverted.
>
>> Once your clone is clean you can just edit Misc/NEWS manually
>
> Since the graft and import failed (producing no diff), I have been editing
> manually and that is when I get the megadiff. I added a couple of blank
> lines to ACKS and got a normal diff. Now, adding a blank line to 2.7 NEWS
> also gives a blank line.
>
> Could the failed graft have messed up the master copy in my cpython
> repository.
>
That's possible. From "hg help graft":
If a graft merge results in conflicts, the graft process is interrupted so
that the current merge can be manually resolved. Once all conflicts are
addressed, the graft process can be continued with the -c/--continue
option.
This doesn't mean that you copy is messed up though. "hg up -C 3.2"
should restore it.
When I graft/merge and there are conflicts I use kdiff3, and it takes
just a few seconds to solve the conflicts usually (for Misc/NEWS is
ctrl+2, ctrl+3, ctrl+s, alt+f4, that roughly translates too "include
both the conflicting news, save and quit).
> I have tried deleting the NEWS file and reverting the deletion.
> hg update does not restore the file as it apparently thinks I actually want
> the uncommitted deletion.
>
How did you delete it? I assume that if you do it from the TortoiseHG
GUI, it will mark it as "deleted" ('D' in "hg status").
If you do it from cmd/file manager hg should see it as missing ('!' in
"hg status") and you can use "hg revert Misc/NEWS" to restore it.
>> it's easier than trying to graft the 2 changesets you made on 2.7 to
>> add and edit the Misc/NEWS entry.
>
> There was only one 2.7 changeset with only the NEWS patch.
>
I was referring to the one that added the news + the one that fixed
the issue id.
>> You can also check with "hg in" and "hg out" if there's something you
>> haven't pulled/pushed yet, but that shouldn't be a problem.
>
> I tried both and got 'no changes'.
>
>> (If you prefer you can come on #python-dev too.)
>
> I may try that, but I suspect that my registration/nick has expired again
> and last time is was obnoxiously hard to get re-established.
>
There's no need to register your nick for #python-dev (there is for
#python though). You can just fire up your favourite IRC client (or
even http://webchat.freenode.net/) and join.
(Registering the nick shouldn't be difficult though.)
> Terry
>
___
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] CANNOT Patch 3.x NEWS [was cpython (2.7): Issue #14707: add news entry\
On Wed, Mar 13, 2013 at 9:41 AM, Terry Reedy wrote:
> Bottom line: I decided to restart from scratch. I am still not sure if the
> glitch was hg, disk 1, disk 2, or Windows, or some combination.
>
> After making and posting a patch to the tracker today, I tried to annotate a
> file and got an error something like 'cannot find revision -1'. I then
> noticed that there was no dag in the workbench dag window, as if there were
> no revisions. When I looked in .hg/store, the big file seemed to be missing.
Note that with the share extension, the "big file" (which I assume is
the store/ directory) only exists in the "main" clone.
In the shared clones you'll find an .hg/sharedpath file that contains
the path to the original .hg/ that contains the store/ dir with all
the changesets.
> So I wiped, defragmented and compacted, and reloaded TortoiseHg. Tomorrow I
> will re-clone and share the repository. Since this is the second time I have
> re-cloned from python.org, I will follow the advice I read somewhere to make
> a _backup clone that I leave alone until I need it, so I only have to pull
> from now until then when I do.
>
Good idea :)
>> On 3/12/2013 7:34 PM, Ezio Melotti wrote:
>> I wonder if TortoiseHg is doing something wrong here. Maybe you could
>> try from cmd too.
>
> Workbench has a 'command' window for typing hg commands which it should pass
> as is to Windows much as Command Prompt does. I tried some of the things you
> suggested there.
>
>> Around the time you pushed on 2.7 I also pushed something, so that
>> might have created some conflict.
>
> I do not remember seeing that.
>
I pushed on 3.3/default about half an hour after you pushed on 2.7, so
that might have caused a push race, if during that time you were doing
the merges and eventually tried to push after me without having
pulled/updated in the meanwhile. The problem you described doesn't
seem to be related to push races though.
>> How does your .bat look like?
>
> pull -u to cpython + update of each of the three shares, much like written
> in the devguide.
>
It's better to avoid using "hg pull -u", because if there's nothing to
pull the "update" won't be executed. Here it shouldn't be a big
problem, but you could break it if you manually pull something in one
of the shared clones, and then run the .bat. Unless you also have an
explicit "hg up" in the clone where you do "hg pull -u", that clone
won't be updated by the script.
>> That's possible. From "hg help graft":
>> If a graft merge results in conflicts, the graft process is interrupted
>> so
>> that the current merge can be manually resolved. Once all conflicts are
>> addressed, the graft process can be continued with the -c/--continue
>> option.
>
> When merge produces a conflict, a window appears offering options including
> using kdiff3 to resolve. When I tried the graft, the message in the command
> window was just 'aborted', and I do not remember getting the resolve window.
>
What version of HG are you using?
>> When I graft/merge and there are conflicts I use kdiff3, and it takes
>> just a few seconds to solve the conflicts usually (for Misc/NEWS is
>> ctrl+2, ctrl+3, ctrl+s, alt+f4, that roughly translates too "include
>> both the conflicting news, save and quit).
>
> Since I have perhaps never gotten that sequence right, that info will be
> helpful.
>
Glad to help, however I got it the other way around.
The 1st pane is the parent and you can just ignore it; the 2nd pane is
the local copy and the 3rd pane is the one from the previous branch
that you are merging.
The bottom pane will be the resulting file.
For Misc/NEWS (the file that usually conflicts), you want the newest
NEWS entry first, so you do ctrl+3 to get the one you just added, and
ctrl+2 to get the one that was there already. Note that for other
files you usually want to get only one of the versions, usually the
one you have in the 3rd pane, so that sequence only applies to
Misc/NEWS.
Another tip is to use ctrl+q instead of alt+f4.
>> If you do it from cmd/file manager hg should see it as missing ('!' in
>> "hg status") and you can use "hg revert Misc/NEWS" to restore it.
>
> This.
>
> Thanks for trying to help. I will let you know if there are any more
> problems after the re-clone.
>
Sure, and if you find part of the devguide that are not clear let me
know (I also just uploaded a new patch to
http://bugs.python.org/issue14468 to add a few new Mercurial FAQs to
the devguide).
Best Regards,
Ezio Melotti
> I still need to comment on the tcl/tk.dll and tkinter situation, but will
> just mention now that I ran the four test_t files on 3.3a0 (on Windows)
> and they seemed to finish and be ok other than altering the environment.
>
>
> Terry
___
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 (merge default -> default): Merge heads default.
Hi, On Sat, Mar 16, 2013 at 10:08 PM, terry.reedy wrote: > http://hg.python.org/cpython/rev/9a2f4418e65a > changeset: 82699:9a2f4418e65a > parent: 82691:0a15a58ac4a1 > parent: 82695:533a60251b9d > user:Terry Jan Reedy > date:Sat Mar 16 16:08:12 2013 -0400 > summary: > Merge heads default. > > files: > Doc/library/functions.rst | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > You forgot a couple of merges here. If you look at the graph at http://hg.python.org/cpython/graph/9a2f4418e65a you will see that all the heads in the individual branches got merged, but then you forgot to merge 3.2 -> 3.3 -> default (i.e. steps 5 and 6 of http://bugs.python.org/issue14468#msg184130). Serhiy fixed that shortly after: http://hg.python.org/cpython/graph/5da005db8166 At least now that the worst case scenario that doesn't really happen often™[0] happened I can point to some actual graphs that will hopefully clarify why all these merges are necessary :) Best Regards, Ezio Melotti [0]: http://bugs.python.org/issue14468#msg184140 ___ 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 (merge default -> default): Merge heads default.
On Sat, Mar 16, 2013 at 11:48 PM, Terry Reedy wrote: > The FAQ says "... using hg merge 3.3 as usual." Serhiy's commit message > said 'Null merge', which to me is not 'as usual', as there are extra steps > given in the FAQ above. So, do he really do a 'null merge' and is that the > right thing to do in this situation? > It's probably just a matter of terminology. I assume he did a "usual merge" (i.e. "hg merge 3.2; hg ci -m '...';") and call it "null merge" because there was no code that changed. I prefer to use the term "null merge" when I explicitly revert the code before committing, and in this case I would have used "Merge with 3.x.". FWIW I might add http://bugs.python.org/issue15917 at some point, to prevent these situations. Best Regards, Ezio Melotti > I have no doubt the the extra merges are needed ;-). ___ 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 #17385: Fix quadratic behavior in threading.Condition
On Mon, Mar 11, 2013 at 3:14 AM, Ezio Melotti wrote: > Hi, > > On Mon, Mar 11, 2013 at 2:58 AM, raymond.hettinger > wrote: >> http://hg.python.org/cpython/rev/0f86b51f8f8b >> changeset: 82592:0f86b51f8f8b >> user:Raymond Hettinger >> date:Sun Mar 10 17:57:28 2013 -0700 >> summary: >> Issue #17385: Fix quadratic behavior in threading.Condition >> >> files: >> Lib/threading.py | 10 -- >> Misc/NEWS| 3 +++ >> 2 files changed, 11 insertions(+), 2 deletions(-) >> >> >> diff --git a/Lib/threading.py b/Lib/threading.py >> --- a/Lib/threading.py >> +++ b/Lib/threading.py >> @@ -10,6 +10,12 @@ >> from time import time as _time >> from traceback import format_exc as _format_exc >> from _weakrefset import WeakSet >> +try: >> +from _itertools import islice as _slice >> +from _collections import deque as _deque >> +except ImportError: >> +from itertools import islice as _islice >> +from collections import deque as _deque >> > > Shouldn't the one in the 'try' be _islice too? > Also I don't seem to have an _itertools module. Is this something used by the other VMs? > Best Regards, > Ezio Melotti ___ 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 17538: Document XML vulnerabilties
Hi, On Tue, Mar 26, 2013 at 6:53 PM, christian.heimes wrote: > http://hg.python.org/cpython/rev/e87364449954 > changeset: 82973:e87364449954 > branch: 2.7 > parent: 82963:d321885ff8f3 > user:Christian Heimes > date:Tue Mar 26 17:53:05 2013 +0100 > summary: > Issue 17538: Document XML vulnerabilties > > [...] > > diff --git a/Doc/library/xml.rst b/Doc/library/xml.rst > new file mode 100644 > --- /dev/null > +++ b/Doc/library/xml.rst > @@ -0,0 +1,131 @@ > +.. _xml: > + > +XML Processing Modules > +== > + > +.. module:: xml > + :synopsis: Package containing XML processing modules > +.. sectionauthor:: Christian Heimes > +.. sectionauthor:: Georg Brandl > + > + > +Python's interfaces for processing XML are grouped in the ``xml`` package. > + > +.. warning:: > + > + The XML modules are not secure against erroneous or maliciously > + constructed data. If you need to parse untrusted or unauthenticated data > see > + :ref:`xml-vulnerabilities`. > + > +It is important to note that modules in the :mod:`xml` package require that > +there be at least one SAX-compliant XML parser available. The Expat parser is > +included with Python, so the :mod:`xml.parsers.expat` module will always be > +available. > + > +The documentation for the :mod:`xml.dom` and :mod:`xml.sax` packages are the > +definition of the Python bindings for the DOM and SAX interfaces. > + > +The XML handling submodules are: > + > +* :mod:`xml.etree.ElementTree`: the ElementTree API, a simple and lightweight Something is missing here ^ > + > +.. > + > +* :mod:`xml.dom`: the DOM API definition > +* :mod:`xml.dom.minidom`: a lightweight DOM implementation > +* :mod:`xml.dom.pulldom`: support for building partial DOM trees > + > +.. > + > +* :mod:`xml.sax`: SAX2 base classes and convenience functions > +* :mod:`xml.parsers.expat`: the Expat parser binding > + > + > +.. _xml-vulnerabilities: > + > [...] > + > +defused packages > + > + > +`defusedxml`_ is a pure Python package with modified subclasses of all stdlib > +XML parsers that prevent any potentially malicious operation. The courses of > +action are recommended for any server code that parses untrusted XML data. This last sentence doesn't make much sense to me. Is it even correct? > The > +package also ships with example exploits and an extended documentation on > more > +XML exploits like xpath injection. > + > +`defusedexpat`_ provides a modified libexpat and patched replacment s/replacment/replacement/ > +:mod:`pyexpat` extension module with countermeasures against entity expansion > +DoS attacks. Defusedexpat still allows a sane and configurable amount of > entity > +expansions. The modifications will be merged into future releases of Python. > + > +The workarounds and modifications are not included in patch releases as they > +break backward compatibility. After all inline DTD and entity expansion are > +well-definied XML features. s/definied/defined/ > + > + > +.. _defusedxml: <https://pypi.python.org/pypi/defusedxml/> > +.. _defusedexpat: <https://pypi.python.org/pypi/defusedexpat/> > +.. _Billion Laughs: http://en.wikipedia.org/wiki/Billion_laughs > +.. _ZIP bomb: http://en.wikipedia.org/wiki/Zip_bomb > +.. _DTD: http://en.wikipedia.org/wiki/Document_Type_Definition > [...] Best Regards, Ezio Melotti ___ 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] CLA link from bugs.python.org
Hi, On Sun, May 5, 2013 at 4:23 AM, Tim Delaney wrote: > It appears there's no obvious link from bugs.python.org to the contributor > agreement - you need to go via the unintuitive link Foundation -> > Contribution Forms (and from what I've read, you're prompted when you add a > patch to the tracker). > > I'd suggest that if the "Contributor Form Received" field is "No" in user > details, there be a link to http://www.python.org/psf/contrib/. > See http://psf.upfronthosting.co.za/roundup/meta/issue461. Best Regards, Ezio Melotti > Tim Delaney > ___ 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] performance testing recommendations in devguide
Hi, On Wed, May 29, 2013 at 9:00 PM, Eric Snow wrote: > ... > > What would be important to say in the devguide regarding Python > performance and testing it? In the devguide I would only add information that are specific to benchmarking the interpreter. A separate "Benchmarking HOWTO" that covers generic topics could/should be added to docs.python.org. Best Regards, Ezio Melotti > What would you add/subtract from the > above? How important is testing memory performance? How do we avoid > performance regressions? Thanks! > > -eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Misc re.match() complaint
Hi, On Wed, Jul 17, 2013 at 6:15 AM, Stephen J. Turnbull wrote: > > BTW, I suggest that Terry's usage of "string" (to mean "str or bytes" > in 3.x, "unicode or str" in 2.x) be adopted, and Guido's "stringish" > be given expanded meaning, including buffer objects. "string" means "str", "bytes" means "bytes", "bytes-like object" means "any object that supports the buffer protocol" [0] (including bytes). "string and bytes-like object" includes all of them. I don't think we need to introduce new terms. Best Regards, Ezio Melotti [0]: http://docs.python.org/3/glossary.html#term-bytes-like-object > Then we can say > informally that in searching and matching a target is a stringish, the > pattern is a stringish (?) or compiled re, but the group method > returns a string. > > Steve ___ 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] Dash
Hi, On Thu, Jul 18, 2013 at 7:38 PM, Serhiy Storchaka wrote: > What type of dash is preferable in the documentation? The en dash (–) or the > em dash (—)? > Both should be used where appropriate [0]. The em dash is more common, however "--" (commonly used to indicate the em dash in e.g. emails) gets converted to an en dash by Sphinx [1]. I noticed this a while ago, and I started using "---" in the documentation whenever I wanted an em dash. If this is not documented it should be added to the "documenting" page of the devguide, so that people start using the right ones and convert the wrong ones when they come across them. Best Regards, Ezio Melotti [0]: http://en.wikipedia.org/wiki/Dash [1]: https://bitbucket.org/birkenfeld/sphinx/src/default/sphinx/util/smartypants.py#cl-261 ___ 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 (merge 2.7 -> 2.7): Clean merge
t/test_winreg.py| 12 +- > Lib/test/test_zipfile.py | 10 +- > Lib/test/testbz2_bigmem.bz2| Bin > Lib/threading.py | 42 +- > Lib/xml/sax/saxutils.py|8 +- > Misc/ACKS |9 + > Misc/NEWS | 457 ++--- > Misc/RPM/python-2.7.spec |2 +- > Modules/_ctypes/libffi/src/dlmalloc.c |5 + > Modules/_multiprocessing/multiprocessing.c |2 +- > Modules/_sqlite/cursor.c |2 +- > Modules/_sqlite/util.c |8 +- > Modules/_sqlite/util.h |4 +- > Modules/_testcapimodule.c |2 +- > Modules/cPickle.c | 10 +- > Modules/dbmmodule.c|8 +- > Modules/operator.c | 14 +- > Modules/readline.c | 27 +- > Modules/selectmodule.c | 35 +- > Modules/signalmodule.c | 14 +- > Modules/sre.h |4 +- > Objects/dictobject.c |4 + > PCbuild/rt.bat |4 +- > README |2 +- > Tools/scripts/gprof2html.py|2 +- > configure |2 +- > configure.ac |2 +- > setup.py |8 +- > 105 files changed, 1301 insertions(+), 955 deletions(-) > > To avoid these big merges you can do: # check the two heads that you are going to merge and their csids hg heads . # update to the other head (the one you pulled, not the one you committed) hg up csid-of-the-other-head # merge your changes on with the ones you pulled hg merge This will merge the changes you just committed with the ones you pulled, and result in a shorter diff that is easier to read/review/merge. Otherwise pulling and updating before committing will avoid the problem entirely (unless you end up in a push-race). Best Regards, Ezio Melotti ___ 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] When to remove deprecated stuff (was: Deprecating the formatter module)
Hi, On Thu, Aug 15, 2013 at 3:29 PM, R. David Murray wrote: > On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou > wrote: >> On Thu, 15 Aug 2013 11:16:20 +0200 >> Victor Stinner wrote: >> > 2013/8/15 Antoine Pitrou : >> > > We don't have any substantial change in store for an eventual "Python >> > > 4", so it's quite a remote hypothesis right now. >> > >> > I prefered the transition between Linux 2 and Linux 3 (no major >> > change, just a "normal" release except the version), rather than the >> > transition between KDE 3 and KDE 4 (in short, everything was broken, >> > the desktop was not usable). >> > >> > I prefer to not start a list of things that we will make the >> > transition from Python 3 to Python 4 harder. Can't we do small changes >> > between each Python release, even between major versions? >> >> That's exactly what I'm saying. >> But some changes cannot be made without breakage, e.g. the unicode >> transition. Then it makes sense to bundle all breaking changes in a >> single version change. > > A number of us (I don't know how many) have clearly been thinking about > "Python 4" as the time when we remove cruft. This will not cause any > backward compatibility issues for anyone who has paid heed to the > deprecation warnings, but will for those who haven't. The question > then becomes, is it better to "bundle" these removals into the > Python 4 release, or do them incrementally? > A while ago I wrote an email to python-dev about our deprecation policy: http://mail.python.org/pipermail/python-dev/2011-October/114199.html My idea was to turn this into an informational PEP but I didn't receive much feedback. If people are interested I could still do it. Best Regards, Ezio Melotti > If we are going to do them incrementally we should make that decision > soonish, so that we don't end up having a whole bunch happen at once > and defeat the (theoretical) purpose of doing them incrementally. > > (I say theoretical because what is the purpose? To spread out the > breakage pain over multiple releases, so that every release breaks > something?) > > --David ___ 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] When to remove deprecated stuff (was: Deprecating the formatter module)
On Thu, Aug 15, 2013 at 3:40 PM, Brett Cannon wrote: > On Thu, Aug 15, 2013 at 8:36 AM, Antoine Pitrou wrote: > >> > A number of us (I don't know how many) have clearly been thinking about >> > "Python 4" as the time when we remove cruft. This will not cause any >> > backward compatibility issues for anyone who has paid heed to the >> > deprecation warnings, but will for those who haven't. >> >> Which is why we shouldn't silence deprecation warnings. >> > > What we should probably do is have unittest turn deprecations on by > default when running your tests but leave them silent otherwise. > http://bugs.python.org/issue10535 (I put the keys of the time machine back at their usual place) Best Regards, Ezio Melotti > I still think keeping them silent for the benefit of end-users is a good > thing as long as we make it easier for developers to switch on warnings > without thinking about it. > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When to remove deprecated stuff
Hi, On Thu, Aug 22, 2013 at 1:00 PM, Petri Lehtinen wrote: > > Removing some cruft on each release can be very painful for users. > > Django's deprecation policy works like this: They deprecate something > in version A.B. It still works normally in A.B+1, generates a > (silenced) DeprecationWarning in A.B+2, and is finally removed in > A.B+3. I see two problems with this: 1) DeprecationWarnings should be generated as soon as the feature is deprecated (i.e. A.B, not A.B+2). Holding off the warnings is not helping anyone. 2) The deprecation period seems fixed and independent from the feature. IMHO the period should vary depending on what is being deprecated. Little known/used "features" could be deprecated in A.B and removed in A.B+1; common "features" can be deprecated in A.B and removed in A.B+n, with an n >= 2 (or even wait for A+1). > So if I haven't read through the full release notes of each > release nor enabled DeprecationWarnings, I end up having something > broken each time I upgrade Django. > Reading the release notes shouldn't be required -- DeprecationWarnings are already supposed to tell you what to change. If you have good test coverage this should happen automatically (at least with unittest), but even if you don't you should run your code with -Wa before upgrading (or test your code on the new version before upgrading Python/Django/etc. in production). Best Regards, Ezio Melotti > I hope the same will not start happening each time I upgrade Python. > When the removals happen on major version boundaries, it should be > more evident that something will break. Then people can enable > DepreationWarnings and test all the affected code thoroughly with the > new version before upgrading. > > Petri ___ 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] When to remove deprecated stuff
On Thu, Aug 22, 2013 at 4:43 PM, R. David Murray wrote: > On Thu, 22 Aug 2013 16:45:29 +0300, Michael Foord > wrote: >> >> On 22 Aug 2013, at 14:00, Petri Lehtinen wrote: >> > >> > Django's deprecation policy works like this: They deprecate something >> > in version A.B. It still works normally in A.B+1, generates a >> > (silenced) DeprecationWarning in A.B+2, and is finally removed in >> > A.B+3. So if I haven't read through the full release notes of each >> > release nor enabled DeprecationWarnings, I end up having something >> > broken each time I upgrade Django. >> > >> >> So you're still using features deprecated three releases ago, you haven't >> checked for DeprecationWarnings and it's Django making your life difficult? >> >> Why not check for the deprecation warnings? > > Doing so makes very little difference. > > This is my opinion (others obviously differ): > > Putting in one big chunk of effort at a major release boundary is easier > to schedule than putting in a chunk of effort on *every* feature > release. IMHO there is a third (and better option) that you are missing. Assume I'm using A.B, and see some DeprecationWarnings. Now I have at least 1.5 years to fix them before A.B+1 is released, and once that happens there shouldn't be any warnings left so I can upgrade successfully. Once I do, more warnings will pop up, but then again I will have 1.5+ years to fix them. It seems to me that the problem only arises when the developers ignore (or possibly are unaware of) the warnings until it's time to upgrade. > More importantly, having it happen only at the major release > boundary means there's only one hard deadline every ten-ish years, rather > than a hard deadline every 1.5 years. > > [...] > > How does one judge what the optimal amount of change is? > > It would be great if we could figure out how to figure out what the > users want. We more or less have one user opinion so far, from Petri, > based on his experience as a Django user. We developers are also users, > of course, but our opinions are colored by our needs as developers as > well, so we aren't reliable judges. As I see it there are 3 groups: 1) developers writing libraries/frameworks/interpreters; 2) developers using these libraries/frameworks/interpreters; 3) end users using the applications wrote by the developers. The first group is responsible of warning the second group of the things that got deprecated and give them enough time to update their code. The second group is responsible to listen to the warnings and update their code accordingly. The third group is responsible to sit back and enjoy our hard work without seeing warnings/errors. Best Regards, Ezio Melotti > > --David > > PS: When thinking about this, remember that our effective policy for > (the second half of?) Python2 was to hold all the big cruft removal until > Python3. Even some stuff that was originally scheduled to be removed > sooner got left in. So our user base is currently used to things being > pretty stable from a deprecation/backward compatibility standpoint. ___ 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] When to remove deprecated stuff
On Thu, Aug 22, 2013 at 7:45 PM, Donald Stufft wrote: > > On Aug 22, 2013, at 1:34 PM, Ezio Melotti wrote: > >> Hi, >> >> On Thu, Aug 22, 2013 at 1:00 PM, Petri Lehtinen wrote: >>> >>> Removing some cruft on each release can be very painful for users. >>> >>> Django's deprecation policy works like this: They deprecate something >>> in version A.B. It still works normally in A.B+1, generates a >>> (silenced) DeprecationWarning in A.B+2, and is finally removed in >>> A.B+3. >> >> I see two problems with this: >> 1) DeprecationWarnings should be generated as soon as the feature is >> deprecated (i.e. A.B, not A.B+2). Holding off the warnings is not >> helping anyone. >> 2) The deprecation period seems fixed and independent from the >> feature. IMHO the period should vary depending on what is being >> deprecated. Little known/used "features" could be deprecated in A.B >> and removed in A.B+1; common "features" can be deprecated in A.B and >> removed in A.B+n, with an n >= 2 (or even wait for A+1). > > This isn't exactly accurate, it raises a PendingDeprecation warning in A.B, > Deprecation in A.B+1, and removed in A.B+2. > > PendingDeprecation (In Django) was designed to be silent by default > and Deprecation loud by default. That got messed up when Python > silenced Deprecation warnings by default and we've had to resort to > some ugliness to restore that behavior. > So it's not much different from what we do now, except that we basically stopped using PendingDeprecationWarning -> DeprecationWarning and just use DeprecationWarnings from the beginning. I don't see many advantages in keeping the pending deprecation warnings silent for developers, as it just encourages procrastination :) One advantage is that under your scheme, one can assume that what shows up as deprecated (not pending deprecated) will be removed in the next version, so you could focus your work on them first, but this doesn't work for our scheme were a deprecated "feature" might stay there for a couple of versions. Maybe we should introduce a ``.removed_in`` attribute to DeprecationWarnings? We some times mention it in the deprecation message and the docs, but there's no way to get that information programmatically. Best Regards, Ezio Melotti >> >>> So if I haven't read through the full release notes of each >>> release nor enabled DeprecationWarnings, I end up having something >>> broken each time I upgrade Django. >>> >> >> Reading the release notes shouldn't be required -- DeprecationWarnings >> are already supposed to tell you what to change. >> If you have good test coverage this should happen automatically (at >> least with unittest), but even if you don't you should run your code >> with -Wa before upgrading (or test your code on the new version before >> upgrading Python/Django/etc. in production). >> >> Best Regards, >> Ezio Melotti >> >>> I hope the same will not start happening each time I upgrade Python. >>> When the removals happen on major version boundaries, it should be >>> more evident that something will break. Then people can enable >>> DepreationWarnings and test all the affected code thoroughly with the >>> new version before upgrading. >>> >>> Petri >> ___ >> 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/donald%40stufft.io > > > - > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > ___ 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] PEP 457: Syntax For Positional-Only Parameters
On Wed, Oct 9, 2013 at 8:15 AM, Georg Brandl wrote: > > [...] > > Rather, I would try to make as many C functions as possible "regular", See http://bugs.python.org/issue8706 and http://bugs.python.org/issue8350 Best Regards, Ezio Melotti ___ 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
[Python-Dev] Re: Oh look, I've been subscribed to python/issues-test-2 notifications again
Hi Larry! The steering council brought this thread (that I missed) up to my attention. On Thu, Nov 4, 2021 at 8:17 AM Larry Hastings wrote: > > I guess this is part of the migration from bpo to GitHub issues? It is: this is one of the repos that I'm using for testing. In particular I'm using it for quick tests on specific issues, and it saw some more activity during the sprints. The issues-test-bpo repo is updated less frequently and it's supposed to look closer to the final version. > Maybe the initial work could be done in a private repo, to cut down on the > spurious email notifications to literally everybody subscribed to cpython? > Which is a lot of people. > The work is being done in private repos, but in order to showcase my progress to the fellow core devs and triagers, I added these two GitHub teams to the repos so that they could access them. People that don't belong to these two teams are unable to access the repository and shouldn't have received any notification. Unfortunately, with each import I have to destroy and recreate the repo, and add the teams again. I didn't realize this was sending out notification to all core devs and triagers (and apparently not everyone is receiving them, probably due to how they configured their notification settings on GitHub) -- if I knew I would have been more considerate :) In the coming weeks, you will still receive a few more notifications from issues-test-bpo as I reach major milestones and update the repo, but you shouldn't see any more notification from issues-test-2 or the other test repos. If you would like to change your notification settings, see https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications If there are any other issues feel free to ping me directly, and sorry for the noise! --Ezio > > /arry > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/H5KW6GRHIF2VWOGNRH5367WB3K2GPARO/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/Y4EN2IKGWIC3BNI6OCOCUPZYEAEKS7IU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Oh look, I've been subscribed to python/issues-test-2 notifications again
Hi Victor, On Thu, Dec 2, 2021 at 11:48 AM Victor Stinner wrote: > > Hi Ezio, > > What is the status of migrating Python issues to GitHub? You can check the status here: https://github.com/psf/gh-migration/projects/1 > Is it done? Not yet, but we are aiming for mid-January. > If not, what are remaining issues? See https://github.com/psf/gh-migration/issues There are a number of ancillary tools that need to be replaced that I haven't looked into yet, and any help with those would be appreciated. These are not blockers for the migration though, and they might be addressed after the migration happened. --Ezio > > Victor ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/I254N235RMFVF5PYFOTPQSU7LCMYDDIH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: issues-test-2 spam?
Sorry, my mistake (again :) As mentioned in an earlier python-dev thread, I'm working on the bugs.python.org -> GitHub issues migration, and while testing I have to delete and recreate the repo for each iteration. Since the repo is private, in order to get feedback from fellow core-devs and triagers, I was adding both teams to the repo whenever I was recreating it, but it turned out that was sending out email every time, so I stopped adding the two teams. However, I just checked that even after deleting and recreating the repo, there are still 65 people that have access. I just tried deleting them individually and recreating the repo, but they are added back automatically, and apparently get a notification like the ones you have been seeing. Since the python-core team has 110 members and only 65 people are added automatically, I think it might depend on user-specific settings (e.g. if you are a member of the python org and you are following it, you might get automatically subscribed to every new org repo). You can ignore/delete/filter those emails (and the ones from issue-test-bpo), or you can try to unsubscribe/change the notification settings and see if that works even after I delete and recreate the repo. Feel free to ping me directly (either via email or on discord) if you have any issue/question/feedback, and sorry again for the noise. --Ezio On Sun, Dec 26, 2021 at 3:54 AM Steven D'Aprano wrote: > > Apologies if this is the wrong place to raise this (where is the right > place?) but over the last four days, I've received ten subscription > notices for python/issues-test-2 on Github. > > Is anyone else also getting multiple subscription notices? > > > -- > Steve > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/Q37XLFRF2H3OQFV55D7ASILCQ57XO6XE/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/37WWZHAGQVRN354HCQFOEVECQALO472N/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] The GitHub Issues Migration begins today
In about 1 hour from now, bugs.python.org will become read-only, and the migration to GitHub Issues will begin. Throughout the migration it will not be possible to report new issues or comment on existing ones. Once all the issues have been migrated from bpo to GitHub, you will be able to comment using GitHub Issues. bpo will remain available in read-only mode. For live updates, see https://discuss.python.org/t/github-issues-migration-status-update/14573 Best Regards, Ezio Melotti ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GUZI6Y7JTPMYY5BXAE56JGBER5VXOWEG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] GitHub Issues are now live
The migration from bugs.python.org to GitHub is now officially complete, and all the issues have been successfully transferred. You can read the full announcement here: https://discuss.python.org/t/github-issues-are-now-live/14967 Best Regards, Ezio Melotti ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5FJBW6A4J4GTFBM6DD2QHHAS6NUTVPZR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Summary of Python tracker Issues
I merged a PR (https://github.com/python/psf-salt/pull/234) that was supposed to disable it, but apparently it's not enough. I'll double check with Ee (added to cc). There is also a new script to replace the old one that is waiting for reviews (see https://github.com/psf/gh-migration/issues/6 and https://github.com/python/cpython/pull/91738). --Ezio On Sun, May 15, 2022 at 12:14 PM Paul Moore wrote: > > On Fri, 13 May 2022 at 19:54, Brett Cannon wrote: > > > > Can we shut this down or unsubscribe the weekly email? > > My understanding was that it would be updated to get its information > from Github once the transition was complete. Is that not going to > happen now? I'm not particularly bothered, as I only really skimmed > the weekly email so it wouldn't be a great loss. But I agree, it > should either be modified or removed. > > Paul > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/GU3S32Y23AO2WWQ2OMMBU37GYNGOBL4U/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VJLIR5OICUXDNRJEZCFI7IGOKOND5WA5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] global statements outside functions/methods should raise SyntaxError
Python currently accepts global statements at the top level: global foo Beside being a meaningless operation, this might lead unexperienced user to make mistakes like: foo = 5 global foo # make foo global def func(): ... print foo # access the global foo ... func() 5 # it works! "global foo" should raise a SyntaxError, similarly to what already happens with "return": return foo File "", line 1 SyntaxError: 'return' outside function I opened an issue on the tracker (http://bugs.python.org/issue7329) and Benjamin suggested to discuss this here. The test he mentioned is in test_global.py: def test4(self): prog_text_4 = """\ global x x = 2 """ # this should work compile(prog_text_4, "", "exec") It just says that "it should work" but it doesn't say /why/. Any thoughts? ___ 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] Restore the warning about mktemp now that DeprecationWarnings are silenced
I noticed that in the py3k doc 'mktemp' is marked as deprecated since Python 2.3 [1], but the function is still there and doesn't raise any warning. Looking at the source I found out that there is a warning, but it is commented out [2], the reason being because they are "too annoying". There was already a discussion about this on python-dev [3], but now that the DeprecationWarnings are silenced by default [4] the warning could be restored. If the comment can be removed I will fix it in trunk/py3k and possibly in 2.6/3.1 too, if #7319 will be backported. (Brett, are you planning to backport it?) Regards, Ezio [1]: http://docs.python.org/dev/py3k/library/tempfile.html [2]: http://svn.python.org/view?view=rev&revision=29829 [3]: http://mail.python.org/pipermail/python-dev/2008-May/079163.html [4]: http://bugs.python.org/issue7319 ___ 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] Restore the warning about mktemp now that DeprecationWarnings are silenced
On 28/01/2010 8.39, Brett Cannon wrote: On Wed, Jan 27, 2010 at 15:54, Ezio Melotti wrote: I noticed that in the py3k doc 'mktemp' is marked as deprecated since Python 2.3 [1], but the function is still there and doesn't raise any warning. Looking at the source I found out that there is a warning, but it is commented out [2], the reason being because they are "too annoying". There was already a discussion about this on python-dev [3], but now that the DeprecationWarnings are silenced by default [4] the warning could be restored. If the comment can be removed I will fix it in trunk/py3k and possibly in 2.6/3.1 too, if #7319 will be backported. (Brett, are you planning to backport it?) If you mean forward-port to Python 3.1, then yes I am planning to merge it. Since Python 3.2 is not due out for nearly a year I wanted to wait a little while to make sure that the wording in the warnings docs made sense. But if you and others want to start actively turning some warnings on that will simply be too annoying when running the test suite I can do it sooner rather than later. -Brett I mean port it to py3k first and then backport it from trunk to 2.6 and from py3k to 3.1. If you want to wait then it's probably enough to add a note to the ticket and I'll fix it later. Regards, Ezio ___ 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] __file__ is not always an absolute path
In #7712 I was trying to change regrtest to always run the tests in a
temporary CWD (e.g. /tmp/@test_1234_cwd/).
The patches attached to the issue add a context manager that changes the
CWD, and it works fine when I run ./python -m test.regrtest from trunk/.
However, when I try from trunk/Lib/ it fails with ImportErrors (note
that the latest patch by Florent Xicluna already tries to workaround the
problem). The traceback points to "the_package = __import__(abstest,
globals(), locals(), [])" in runtest_inner (in regrtest.py), and a
"print __import__('test').__file__" there returns 'test/__init__.pyc'.
This can be reproduced quite easily:
trunk$ ./python
Python 2.7a2+ (trunk:77941M, Feb 3 2010, 06:40:49)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, sys
>>> os.getcwd()
'/home/wolf/dev/trunk'
>>> import test
>>> test.__file__ # absolute
'/home/wolf/dev/trunk/Lib/test/__init__.pyc'
>>> os.chdir('/tmp')
>>> test.__file__
'/home/wolf/dev/trunk/Lib/test/__init__.pyc'
>>> from test import test_unicode # works
>>> test_unicode.__file__
'/home/wolf/dev/trunk/Lib/test/test_unicode.pyc'
>>>
[21]+ Stopped ./python
trunk$ cd Lib/
trunk/Lib$ ../python
Python 2.7a2+ (trunk:77941M, Feb 3 2010, 06:40:49)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, sys
>>> os.getcwd()
'/home/wolf/dev/trunk/Lib'
>>> import test
>>> test.__file__ # relative
'test/__init__.pyc'
>>> os.chdir('/tmp')
>>> from test import test_unicode # fails
Traceback (most recent call last):
File "", line 1, in
ImportError: cannot import name test_unicode
Is there a reason why in the second case test.__file__ is relative?
___
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] Request for commit access
On 23/03/2010 16.50, Brian Curtin wrote: Hi all, Having been active in bug triage and patch writing/reviewing since late 2009, it was suggested in the python-dev IRC channel that I request commit access to the repository. I'm primarily a Windows user and have worked with many of the other active contributors to diagnose issues and test patches when they don't have direct access to Windows. Brian Curtin p.s. My contributor form in on file as of 2010-01-31. +1 ___ 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] Add -3 and -Wd to the buildbots
Hi, now that the py3k warnings are fixed (see http://bugs.python.org/issue7092) we should run the tests on the trunk buildbots with the -3 flags, in order to check if new warnings are introduced and possibly to uncover other ones. It might be a good idea to add the -Wd flag too, both on trunk and py3k. -Ezio ___ 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] Anyone can do patch reviews (was: Enhanced tracker privileges...)
On Tue, Apr 27, 2010 at 5:16 PM, Barry Warsaw wrote:
> On Apr 27, 2010, at 02:40 PM, exar...@twistedmatrix.com wrote:
>
> >On 01:38 pm, rdmur...@bitdance.com wrote:
>
> >>2) have unit tests that fail before the patch and succeed after
> >
> >This list would make a good addition to one of the cpython development
> >pages. If potential contributors could find this information, then
> >they'd be much more likely to participate by doing reviews.
>
> It would be kind of cool if there were some best practices for running said
> unittest both with and without the patch enabled. Kind of like using
> #ifdefs
> in C but without all the commenting-out-commenting-in error proneness. I
> guess you could do something like
>
>if os.getenv('BUG1234'):
># Patch the frobnicator to not bloviate.
>
>
When I'm writing the patch it's usually easy, I write the tests, see that
they fail, write the fix, see that they pass.
When I'm reviewing the patch, I apply the patch, see that the tests pass,
svn revert the fix, check that they fail.
Most of the patches affect just a couple of files, so applying the whole
patch and then revert is usually trivial and probably easier than having to
deal with two separate files for patch and tests.
___
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] Removing IDLE from the standard library
On 12/07/2010 2.56, "Martin v. Löwis" wrote: As for assigning bugs, I've been told to use the maintainer.rst list, so either the list is wrong, or I've had finger problems. If it's the latter I again say sorry. I see. What copy have you been using specifically? I think I need to remove myself from these lists. Regards, Martin Indeed it's not clear if the names that appear in the maintainers.rst list are supposed to be added only to the nosy list or if it's possible to add them to the "assigned to" field too. A way to avoid confusion is to mark the names that should be added to the "Assigned to" field with a '*', and add the others to the nosy list only. E.g.: unicodedata loewis, lemburg, ezio.melotti* would mean "You can add loewis and lemburg to the nosy list and assign the issue to ezio.melotti". Otherwise we can just decide that those names should just be added to the nosy list and let them assign the issue to themselves if they want to fix it. Best Regards, Ezio Melotti ___ 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] No response to posts
On 01/08/2010 20.43, R. David Murray wrote: On Sun, 01 Aug 2010 21:28:05 +1000, Nick Coghlan wrote: On Sun, Aug 1, 2010 at 5:41 PM, Mark Lawrence wrote: I plucked this figure out of the air thinking that if an issue was going to drop under the radar, this would be the most likely time. I was considering a worst case scenario where several core triage people are at a big Python event, others are on holiday [ shame on you :) ], some looking after the kids, yet more off sick etc. Hum, perhaps 24 hours is too soon, what a bout a week, opinions anybody? Notifications would go to the bugs mailing list and/or #python-dev. But this is hypothetical anyway if the message count of 1 query works. Only one way to find out, let's try it. Perhaps just another number to track in the weekly bug summary? Better, a table section giving the bugids, titles, and URL. Ezio just finished reworking the summary script to be more easily modified, so I bet he would find this easy to add at this point. --David FWIW this morning I added a new version of the roundup-summary script [0] that includes a "Recent issues with no replies" table with bugids, titles and URLs. (I hope Guido doesn't mind if I used the time machine ;) [0]: http://psf.upfronthosting.co.za/roundup/meta/issue284 ___ 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] r83596 - in python/branches/release26-maint: Doc/library/constants.rst
Hi, On 03/08/2010 0.47, georg.brandl wrote: Author: georg.brandl Date: Mon Aug 2 23:47:02 2010 New Revision: 83596 Log: Merged revisions 83567 via svnmerge from svn+ssh://python...@svn.python.org/python/branches/release27-maint r83567 | georg.brandl | 2010-08-02 22:32:03 +0200 (Mo, 02 Aug 2010) | 9 lines Merged revisions 83552 via svnmerge from svn+ssh://python...@svn.python.org/python/branches/py3k r83552 | georg.brandl | 2010-08-02 21:36:36 +0200 (Mo, 02 Aug 2010) | 1 line #9438: clarify that constant names also cannot be assigned as attributes. Modified: python/branches/release26-maint/ (props changed) python/branches/release26-maint/Doc/library/constants.rst Modified: python/branches/release26-maint/Doc/library/constants.rst == --- python/branches/release26-maint/Doc/library/constants.rst (original) +++ python/branches/release26-maint/Doc/library/constants.rst Mon Aug 2 23:47:02 2010 @@ -3,7 +3,6 @@ A small number of constants live in the built-in namespace. They are: - .. data:: False The false value of the :class:`bool` type. @@ -39,16 +38,23 @@ Special value used in conjunction with extended slicing syntax. - .. XXX Someone who understands extended slicing should fill in here. - .. data:: __debug__ This constant is true if Python was not started with an :option:`-O` option. - Assignments to :const:`__debug__` are illegal and raise a :exc:`SyntaxError`. See also the :keyword:`assert` statement. +.. note:: + + The names :data:`None` and :data:`__debug__` cannot be reassigned + (assignments to them, even as an attribute name, raise :exc:`SyntaxError`), + so they can be considered "true" constants. + + .. versionchanged:: 2.7 + Assignments to ``__debug__`` as an attribute became illegal. this shouldn't be here. + + Constants added by the :mod:`site` module - ___ Python-checkins mailing list python-check...@python.org http://mail.python.org/mailman/listinfo/python-checkins Best Regards, Ezio Melotti ___ 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] Windows
On 04/08/2010 11.36, Tim Golden wrote: On 04/08/2010 05:34, Mark Hammond wrote: On 4/08/2010 11:08 AM, Steve Holden wrote: It's a little disappointing to discover that despite the relatively large number of developers who have received MSDN licenses from Microsoft, none if us have the time to make sure that the buildbots are green for the 2.6.6 release. I wonder if anyone can think of a way we can get some Windows skillz into the group that could assist at ties like this. Some brainstorming might find a way through. I never go looking at the buildbots to look for problems - maybe some way of explicitly bringing such failures to peoples attention would be good Agree with that. This page looks hopeful: http://www.python.org/dev/buildbot/ with Atom/RSS feeds and an XML-RPC interface. I've subscribed to the RSS feeed which is -- from my perspective -- quite noisy. One could do something with the xml-rpc according to this: http://buildbot.net/buildbot/docs/0.7.11/#XMLRPC-server but does anyone know how easy it would be use setup a mail notifier to go to a specific Python mailing list on failure? I've looked at mail.python.org and Googled around and I can't see something which already does this, but I'm very happy to be wrong... There seems to be some previous discussion: http://mail.python.org/pipermail/python-dev/2006-October/069617.html but no sign of an outcome. TJG ___ 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/ezio.melotti%40gmail.com FWIW there's also http://code.google.com/p/bbreport/source/checkout We were planning to use bbreport to create weekly summary and mail them to python-dev, but someone should write some code (I could do that but it's quite low in my to-do list) and make it run once a week. Best Regards, Ezio Melotti ___ 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] r83763 - in python/branches/py3k: Doc/library/signal.rst Lib/test/test_signal.py Misc/NEWS Modules/signalmodule.c
SiginterruptTest, ItimerTest)
Is this necessary?
If the tests are marked with a skip decorator they will be skipped
anyway (and also marked as skipped in the output).
if __name__ == "__main__":
Modified: python/branches/py3k/Misc/NEWS
==
--- python/branches/py3k/Misc/NEWS (original)
+++ python/branches/py3k/Misc/NEWS Fri Aug 6 21:27:32 2010
@@ -24,6 +24,9 @@
Extensions
--
+- Issue #9324: Add parameter validation to signal.signal on Windows in order
+ to prevent crashes.
+
- Issue #9526: Remove some outdated (int) casts that were preventing
the array module from working correctly with arrays of more than
2**31 elements.
Modified: python/branches/py3k/Modules/signalmodule.c
==
--- python/branches/py3k/Modules/signalmodule.c (original)
+++ python/branches/py3k/Modules/signalmodule.c Fri Aug 6 21:27:32 2010
@@ -255,8 +255,23 @@
int sig_num;
PyObject *old_handler;
void (*func)(int);
+#ifdef MS_WINDOWS
+int cur_sig, num_valid_sigs = 6;
+static int valid_sigs[] = {SIGABRT, SIGFPE, SIGILL, SIGINT,
+ SIGSEGV, SIGTERM};
+BOOL valid_sig = FALSE;
+#endif
if (!PyArg_ParseTuple(args, "iO:signal",&sig_num,&obj))
return NULL;
+#ifdef MS_WINDOWS
+/* Validate that sig_num is one of the allowable signals */
+for (cur_sig = 0; cur_sig< num_valid_sigs; cur_sig++)
+valid_sig |= (sig_num == valid_sigs[cur_sig]);
+if (!valid_sig) {
+PyErr_SetString(PyExc_ValueError, "signal number out of range");
+return NULL;
+}
+#endif
#ifdef WITH_THREAD
if (PyThread_get_thread_ident() != main_thread) {
PyErr_SetString(PyExc_ValueError,
___
Python-checkins mailing list
python-check...@python.org
http://mail.python.org/mailman/listinfo/python-checkins
Best Regards,
Ezio Melotti
___
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] r83778 - in python/branches/py3k/Lib/test: test_import.py test_sax.py test_sys.py test_urllib.py test_urllib2.py test_xml_etree.py
path):
+try:
+path.encode("utf8")
+except UnicodeEncodeError:
+raise unittest.SkipTest("path is not encodable to utf8")
urlpath = urllib.request.pathname2url(path)
if os.name == "nt" and urlpath.startswith("///"):
urlpath = urlpath[2:]
Modified: python/branches/py3k/Lib/test/test_xml_etree.py
==
--- python/branches/py3k/Lib/test/test_xml_etree.py (original)
+++ python/branches/py3k/Lib/test/test_xml_etree.py Sat Aug 7 12:09:35 2010
@@ -13,6 +13,7 @@
import sys
import cgi
+import unittest
from test import support
from test.support import findfile
@@ -20,6 +21,10 @@
from xml.etree import ElementTree as ET
SIMPLE_XMLFILE = findfile("simple.xml", subdir="xmltestdata")
+try:
+ SIMPLE_XMLFILE.encode("utf8")
+except UnicodeEncodeError:
+raise unittest.SkipTest("filename is not encodable to utf8")
SIMPLE_NS_XMLFILE = findfile("simple-ns.xml", subdir="xmltestdata")
SAMPLE_XML = """\
___
Python-checkins mailing list
python-check...@python.org
http://mail.python.org/mailman/listinfo/python-checkins
Best Regards,
Ezio Melotti
___
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] Summary of Python tracker Issues
Hi, lately I've been working on the new summary of Python tracker issues. This is the result. On 10/08/2010 16.39, Python tracker wrote: ACTIVITY SUMMARY (2010-08-01 - 2010-08-07) This is the period that is considered for the following stats. By default it shows the activity of the last week. (This was supposed to be the report for last week, but it's from Monday to Sunday instead of from Saturday to Friday because I specified the wrong dates.) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues stats: open2640 (+35) closed 18679 (+194) total 21319 (+57) The +35 means that there are 35 more issues opened since the last week. This is not the number of issues that have been created during the last week, but the number of new issues that have been created or reopened that are still open. Also note that 'pending' and 'languishing' are considered as 'open' too. The +194 means that are 194 more issues closed since last week that are still closed. Both the open and closed issues are listed later. The +57 means that overall the tracker has 57 more issues since last week. This also mean that about 25 issues created this week are already closed (i.e. 57 new - (35 still open - 3 older that got reopened) = 25 issues). Open issues with patches: 1112 This is the total number of open issues with the 'patch' keyword. Issues opened (35) == #8821: Range check on unicode repr http://bugs.python.org/issue8821 reopened by pitrou [...] This is the list of *all* the issues created or reopened during the last week *that are still open*. Recent issues with no replies (15) == #9535: Pending signals are inherited by child processes http://bugs.python.org/issue9535 [...] This is the list of the open issues with only 1 message, sorted by creation date. The list is limited to max 15 issues but is not limited to the last week. This means that issues older than a week are included here if less than 15 issues with only 1 message have been created this week. Issues waiting for review (15) == #1474680: pickling files works with protocol=2. http://bugs.python.org/issue1474680 [...] This is the list of issues with 'patch' or 'needs review' keywords or 'patch review' stage that have been active during the last week. The list is limited to max 15 issues. Top issues most discussed (10) == #9079: Make gettimeofday available in time module http://bugs.python.org/issue9079 42 msgs [...] This is the list of issues with activity in the last week sorted by number of message. This list is limited to max 10 issues. Issues closed (154) === #1474680: pickling files works with protocol=2. http://bugs.python.org/issue1474680 closed by alexandre.vassalotti [...] This is the list of *all* the issues closed in the last week *that are still closed*. Since this list might be quite long I put it at the end, to make it easier to reach the other lists. The previous report also had the average and median durations of open issues. While I was refactoring the function that calculated them, I realized that these values are not so useful/clear so I decided to remove them. These values could be added back if they are needed, but it might be more interesting to know how long does it usually take for an issue to be closed, rather than for how long the open issues are around. For more information see http://psf.upfronthosting.co.za/roundup/meta/issue284. Best Regards, Ezio Melotti P.S.: Thanks to R. David Murray that helped me out with the testing and to all the people who provided (and will provide) feedback. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Summary Lists on Issue Tracker
On 11/08/2010 17.59, Mark Dickinson wrote: On Wed, Aug 11, 2010 at 3:21 PM, Tim Golden wrote: Thanks to whoever's been working on the new Summary lists on the Issue Tracker. Ezio Melotti, I assume. Yes :) (see http://psf.upfronthosting.co.za/roundup/meta/issue329) The "Followed by you" / "Created by you" / "Assigned to you" are just what the doctor ordered. Agreed. Now I can get rid of my own equivalent custom searches. :) One niggle: we seem to have lost the simple 'Open Issues' search under 'Summaries' on the left-hand side of the page. I was expecting someone to complain about it. This feels a bit odd, given that it's what's displayed by default when a non-registered user goes to http://bugs.python.org. If that non-registered user then clicks on something else, like 'easy issues', there doesn't seem to be any easy way (that I can see) to go back to the original list of all open issues. There actually is an easy way: the big python logo on the top left of the page. However I understand that this is not so obvious, so I can either add back the 'open issues' link or try to make it more obvious. Of course, as a registered user, I can add my own custom search for that if I want it. But I can't help feeling that non-registered users might miss this. Mark Best Regards, Ezio Melotti ___ 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] Summary of Python tracker Issues
Hi, On 05/11/2010 19.08, Python tracker wrote: ACTIVITY SUMMARY (2010-10-29 - 2010-11-05) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open2514 (+17) closed 19597 (+78) total 22111 (+95) as suggested in recent mails[0][1] I changed these values to represent the deltas with the previous week. Now let's try to keep the "open" delta negative ;) Best Regards, Ezio Melotti [0]: http://mail.python.org/pipermail/python-dev/2010-October/104840.html [1]: http://mail.python.org/pipermail/python-dev/2010-September/104054.html ___ 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] Summary of Python tracker Issues
On 06/11/2010 19.01, Terry Reedy wrote: On 11/6/2010 11:42 AM, R. David Murray wrote: On Sat, 06 Nov 2010 15:38:22 +0100, Georg Brandl wrote: Am 06.11.2010 05:44, schrieb Ezio Melotti: Hi, On 05/11/2010 19.08, Python tracker wrote: ACTIVITY SUMMARY (2010-10-29 - 2010-11-05) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open2514 (+17) This seems wrong. A default search for open issues returns 2452 and it was about the same yesterday just a few hours after the report. That's because the "open" count includes about 25 languishing and 39 pending issues (technically they are still open). closed 19597 (+78) total 22111 (+95) as suggested in recent mails[0][1] I changed these values to represent the deltas with the previous week. Now let's try to keep the "open" delta negative ;) Since there were more issues closed than opened I think it really was. Anyway, we are down 300 from the 2750 peak. That is a worthy goal, however the difference between the "open" and "closed" deltas is already quite an achievement and shows that our triage works. Yes, even if having a negative delta would be best, having the "closed" delta higher than then "open" one is still very good. So congrats to everyone who worked and works to make this possible. Agreed. We did have negative open deltas for several weeks running in October. Kudos to everyone involved, and lets do it some more :) I'm looking forward to making a non-trivial dent in the open count during the bug weekend on the 20th/21st. Best Regards, Ezio Melotti ___ 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] r86530 - python/branches/py3k/Doc/howto/unicode.rst
Hi,
On 19/11/2010 18.10, alexander.belopolsky wrote:
Author: alexander.belopolsky
Date: Fri Nov 19 17:09:58 2010
New Revision: 86530
Log:
Issue #4153: Updated Unicode HOWTO.
Modified:
python/branches/py3k/Doc/howto/unicode.rst
Modified: python/branches/py3k/Doc/howto/unicode.rst
==
--- python/branches/py3k/Doc/howto/unicode.rst (original)
+++ python/branches/py3k/Doc/howto/unicode.rst Fri Nov 19 17:09:58 2010
[...]
-Python 2.x's Unicode Support
-
+Python's Unicode Support
+
Now that you've learned the rudiments of Unicode, we can look at Python's
Unicode features.
@@ -265,7 +263,7 @@
UnicodeDecodeError: 'utf8' codec can't decode byte 0x80 in position 0:
unexpected code byte
>>> b'\x80abc'.decode("utf-8", "replace")
-'\ufffdabc'
+'�abc'
Apparently 'make latex' and 'make all-pdf' don't like this char.
>>> b'\x80abc'.decode("utf-8", "ignore")
'abc'
[...]
Best Regards,
Ezio Melotti
___
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] Re-enable warnings in regrtest and/or unittest
I would like to re-enable by default warnings for regrtest and/or unittest. The reasons are: 1) these tools are used mainly by developers and they (should) care about warnings; 2) developers won't have to remember that warning are silenced and how to enable them manually; 3) developers won't have to enable them manually every time they run the tests; 4) some developers are not even aware that warnings have been silenced and might not notice things like DeprecationWarnings until the function/method/class/etc gets removed and breaks their code; 5) another developer tool -- the --with-pydebug flag -- already re-enables warnings when it's used; If this is fixed in unittest it won't be necessary to patch regrtest. If it's fixed in regrtest only the core developers will benefit from this. This could be fixed checking if any warning flags (-Wx) are passed to python. If no flags are passed the default will be -Wd, otherwise the behavior will be the one specified by the flag. This will allow developers to use `python -Wi` to ignore errors explicitly. Best Regards, Ezio Melotti ___ 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] Re-enable warnings in regrtest and/or unittest
On 22/11/2010 19.45, Michael Foord wrote: On 22/11/2010 17:35, Łukasz Langa wrote: Am 22.11.2010 18:14, schrieb Ezio Melotti: I would like to re-enable by default warnings for regrtest and/or unittest. +1 Especially in regrtest it could help manage stdlib quality (currently we have a horde of ResourceWarnings, zipfile mostly). I would even be +1 on making warnings errors for regrtest but that seems to be unpopular on #python-dev. As I said on IRC I think it makes sense to turn them into errors once we fixed/silenced all the ones that we have now. That would help keeping the number of warning to 0. Enabling it for regrtest makes sense. For unittest I still think it is a choice that should be left to developers. If we consider that most of the developers want to see them, I'd prefer to have the warnings by default rather than having to use -Wd explicitly every time I run the tests (keep in mind that many developers out there don't even know/remember that now they should use -Wd). Michael Best regards, Łukasz Langa ___ 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/fuzzyman%40voidspace.org.uk ___ 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] r87815 - peps/trunk/pep-3333.txt
On Fri, Jan 7, 2011 at 4:39 PM, phillip.eby wrote:
> Author: phillip.eby
> Date: Fri Jan 7 16:39:27 2011
> New Revision: 87815
>
> Log:
> More bytes I/O fixes
>
>
> Modified:
> peps/trunk/pep-.txt
>
> Modified: peps/trunk/pep-.txt
>
> ==
> --- peps/trunk/pep-.txt (original)
> +++ peps/trunk/pep-.txt Fri Jan 7 16:39:27 2011
> @@ -310,9 +310,9 @@
> elif not headers_sent:
> # Before the first output, send the stored headers
> status, response_headers = headers_sent[:] = headers_set
> - sys.stdout.write('Status: %s\r\n' % status)
> + sys.stdout.buffer.write('Status: %s\r\n' % status)
> for header in response_headers:
> - sys.stdout.write('%s: %s\r\n' % header)
> + sys.stdout.buffer.write('%s: %s\r\n' % header)
>
Also note that .buffer might not be available in some cases (i.e. when
sys.stdout has been replaced with other objects).
> sys.stdout.write('\r\n')
>
> sys.stdout.buffer.write(data)
> ___
> Python-checkins mailing list
> python-check...@python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
___
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] Finding buildbot failures
On 25/02/2011 20.10, Vinay Sajip wrote: What's the easiest way of finding which tests failed on buildbot builds? I mean, is there anything easier than using the Web interface to browse to failing builds and then looking at the stdio output in a browser? You can try bbreport (http://code.google.com/p/bbreport/wiki/Screenshots): hg clone https://bbreport.googlecode.com/hg/ bbreport cd bbreport python bbreport --help python bbreport 3.x (There is some issue with hg revision numbers that I haven't fixed yet, but the above command should work fine) Best Regards, Ezio Melotti Thanks, Vinay Sajip ___ 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/ezio.melotti%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] (2.7): Use simpler assert in basic example.
On 11/03/2011 4.45, Nick Coghlan wrote: On Thu, Mar 10, 2011 at 4:36 PM, ezio.melotti wrote: http://hg.python.org/cpython/rev/9adc4792db9a changeset: 68356:9adc4792db9a branch: 2.7 user:Ezio Melotti date:Thu Mar 10 23:35:39 2011 +0200 summary: Use simpler assert in basic example. Please don't. Now the new methods are available, using assertTrue() on supported expressions is actively throwing away data, and the docs shouldn't recommend it *anywhere*. I agree with you, but Raymond wants to keep the example as simple as possible and asked me to change it back. If using assertIn() at this point in the docs is a genuine problem, find an alternative test example that isn't better written using one of the more specific methods. That would be best. Can you come up with a different example that only uses assertEqual/assertTrue/assertRaises? Best Regards, Ezio Melotti Cheers, Nick. files: Doc/library/unittest.rst diff --git a/Doc/library/unittest.rst b/Doc/library/unittest.rst --- a/Doc/library/unittest.rst +++ b/Doc/library/unittest.rst @@ -130,13 +130,13 @@ def test_choice(self): element = random.choice(self.seq) - self.assertIn(element, self.seq) + self.assertTrue(element in self.seq) def test_sample(self): with self.assertRaises(ValueError): random.sample(self.seq, 20) for element in random.sample(self.seq, 5): - self.assertIn(element, self.seq) + self.assertTrue(element in self.seq) if __name__ == '__main__': unittest.main() -- Repository URL: http://hg.python.org/cpython ___ Python-checkins mailing list python-check...@python.org http://mail.python.org/mailman/listinfo/python-checkins ___ 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 (3.1): #2650: Refactor re.escape to use enumerate().
On 27/03/2011 0.03, Georg Brandl wrote: On 26.03.2011 20:19, "Martin v. Löwis" wrote: Am 26.03.2011 20:00, schrieb Terry Reedy: On 3/26/2011 2:17 PM, Georg Brandl wrote: "Refactor" doesn't sound like it belongs in the 3.1 branch... -for i in range(len(pattern)): -c = pattern[i] +for i, c in enumerate(pattern): I would call thin 'Replace obsolete idiom in' rather than 'Refactor'. So are you criticizing the replacement or the mislabeling? No - I believe he is critizing that a stylistic change is done in a maintenance branch. It's not a bug fix, AFAICT, so it should not have been done. Exactly, and two changesets before that there was another commit "Refactor the tests for re.escape" that was by far larger than this one, and not as easily reviewed as this one. In the end, this kind of change in a bugfix branch has zero gain, but a nonzero risk of gratuitous breakage. If it is necessary for future fixes or ease of merging bugfixes, I'd at least expect a note of that in the commit message justifying the breach of policy for a barely-maintenance branch. Hi, these commits are part of #2650[0]. First, I refactored the existing tests[1] and added a few more tests[2] to have better coverage. Tests are usually ported to maintenance branches as well (because they could uncover bugs and also make merging easier), so I started working on 3.1. Then I refactored the function[3], and since the refactoring was trivial and I had extensive tests to make sure that the behavior was unchanged I included the refactoring in 3.1 too. FWIW I've been porting most of the commits that I do on 3.2 on 3.1 too (i.e. I'm considering both of them maintenance branches), and merging 3 branches rather than 2 doesn't make much difference with mercurial. [0]: http://bugs.python.org/issue2650 [1]: http://hg.python.org/cpython/rev/1402c719b7cf [2]: http://hg.python.org/cpython/rev/9147f7ed75b3 [3]: http://hg.python.org/cpython/rev/ed02db9921ac Best Regards, Ezio Melotti Georg ___ 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/ezio.melotti%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devguide: Add a table of contents to the FAQ.
On 30/03/2011 23.20, Antoine Pitrou wrote: On Tue, 29 Mar 2011 21:00:22 +0200 ezio.melotti wrote: http://hg.python.org/devguide/rev/f722956afeac changeset: 405:f722956afeac user:Ezio Melotti date:Tue Mar 29 22:00:13 2011 +0300 summary: Add a table of contents to the FAQ. Could it be collapsed by default? I don't think there's an easy way to collapse it by default. In most of the cases I anyway check the FAQ for something specific. Having a list at the top provides an overview of the questions and also an easy way to locate and jump to the right answer. It's quite long, and redundant with the sidebar. The list is indeed redundant, but the sidebar is not really usable here. Best Regards, Ezio Melotti thanks Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please revert autofolding of tracker edit form
Hi, On 31/03/2011 19.52, Terry Reedy wrote: On 3/31/2011 9:59 AM, Antoine Pitrou wrote: Le jeudi 31 mars 2011 à 23:48 +1000, Nick Coghlan a écrit : On Thu, Mar 31, 2011 at 10:16 PM, Antoine Pitrou wrote: It would be nice if someone with UI design experience was interested in maintaining/improving the tracker. The challenge is the same as with any UI designer involvement in open source stuff though: they really need to be given the freedom to do proper workflow analysis and come up with something that *works*, but in practice things tend to get derailed into endless bikeshed arguments, since *everyone* has an opinion on the UI design of the tools they have to use. Well, obviously they have, since they are users and are directly impacted by any changes. The line this draws is between clean-sheet design and iterative improvement. Clearly it would be difficult to try to sell us a wholesale change in how the issue tracker organizes things. Here is my proposal for a redesign based on an analysis of my usage ;-). You can add your proposal to http://wiki.python.org/moin/DesiredTrackerFeatures There you can find several suggestions and discussions about possible changes to the tracker (it's similar to python-ideas ML, but it's about the tracker and it's on a wiki page). Bugs and concrete suggestions should be submitted to the meta-tracker (http://psf.upfronthosting.co.za/roundup/meta/) or discussed on the tracker-discuss mailing list. I have a 1600x1050 (or thereabouts), 20" (measured) diagonal, 17" across screen. The left column has a 7/8" margin, 2 3/8" text area, and 1" gutter. These could be shrunk to say, 1/4, 2, 1/4, saving 1 3/8". The comment box is 8 1/2", message boxes are wider, but the extra width is not used if one uses hard returns in the comment box. In any case, the message boxes could be narrowed by 1 1/8". This would allow a right column of 1/4+2+1/4". Except for title, comment, and file boxes, we then stack the classification and process boxes in the right column. The nosy box would be last so it can list one name per line. It would end with an [ add me ] button. It should also have a box for adding people (as with Assigned To). Having to look up tracker names in Assigned To and retype exactly in the nosy list is an error-prone nuisance. Putting all these boxes to the side leaves them visible for those who want them but out of the way and ignorable for those who do not. You can also use the "(list)" link to open a popup and search for users to add to the nosy instead of copying them from the "Assigned To" list by hand. (I know that popup are not the most usable thing and that the search has some limitation (e.g. it's case sensitive), but that's the best we have right now, and works fairly well for me.) Also one of the design goal is to keep the interface as simple as possible, so we try to avoid adding more things unless they are really useful. Having an expanded list of names doesn't sound too useful to me. I would be nice is both the left and right columns had buttons to hide and show. This would help people accessing issues from smaller screens, as with a netbook. The title is not really classification and belongs at the very top. It could even go in the 1 1/8" top bar, which is currently mostly empty, along with the issue number. I would like to try putting the comment box after the last (most recent) comment, as that is the message one most ofter responds to. Having to now scroll up and down between comment box and last message(s) is often of a nuisance. This summer I plan to participate again to GSOC and work on the bug tracker (if my proposal gets accepted). There are already a few things I want to improve and I also have some patches ready that just need to be updated and applied. In the meanwhile you can use http://wiki.python.org/moin/DesiredTrackerFeatures to list the things that you would like to see, so that they don't get lost in the archives of python-dev. Best Regards, Ezio Melotti ___ 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] Issue Tracker
On 26/04/2011 22.32, Ethan Furman wrote: Okay, I finally found a little time and got roundup installed and operating. Only major complaint at this point is that the issue messages are presented in top-post format (argh). Does anyone know off the top of one's head what to change to put roundup in bottom-post (chronological) format? TIA! ~Ethan~ See line 309 of http://svn.python.org/view/tracker/instances/python-dev/html/issue.item.html?view=markup If you have other questions about Roundup see https://lists.sourceforge.net/lists/listinfo/roundup-users Best Regards, Ezio Melotti ___ 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: test.support: add requires_mac_ver() function
Hi,
On 01/06/2011 13.28, victor.stinner wrote:
http://hg.python.org/cpython/rev/35212b113730
changeset: 70574:35212b113730
user:Victor Stinner
date:Wed Jun 01 12:28:04 2011 +0200
summary:
test.support: add requires_mac_ver() function
I would expect this to be a decorator, similar to requires_IEEE_754 and
requires_zlib.
Add also linux_version() to __all__.
For consistency, this should be a decorator too, possibly named
requires_linux_ver().
A requires_windows(_ver) sounds like a useful addition too, given the
number of tests that are specific to Windows.
files:
Lib/test/support.py | 22 +-
Lib/test/test_math.py | 7 ---
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/Lib/test/support.py b/Lib/test/support.py
--- a/Lib/test/support.py
+++ b/Lib/test/support.py
@@ -37,7 +37,8 @@
"Error", "TestFailed", "ResourceDenied", "import_module",
"verbose", "use_resources", "max_memuse", "record_original_stdout",
"get_original_stdout", "unload", "unlink", "rmtree", "forget",
-"is_resource_enabled", "requires", "find_unused_port", "bind_port",
+"is_resource_enabled", "requires", "linux_version", "requires_mac_ver",
+"find_unused_port", "bind_port",
"IPV6_ENABLED", "is_jython", "TESTFN", "HOST", "SAVEDCWD", "temp_cwd",
"findfile", "sortdict", "check_syntax_error", "open_urlresource",
"check_warnings", "CleanImport", "EnvironmentVarGuard",
"TransientResource",
@@ -299,6 +300,25 @@
except ValueError:
return 0, 0, 0
+def requires_mac_ver(*min_version):
+"""Raise SkipTest if the OS is Mac OS X and the OS X version if less than
+min_version.
+
+For example, support.requires_linux_version(10, 5) raises SkipTest if the
This should be requires_mac_ver
+version is less than 10.5.
+"""
+if sys.platform != 'darwin':
+return
+version_txt = platform.mac_ver()[0]
+try:
+version = tuple(map(int, version_txt.split('.')))
+except ValueError:
+return
+if version< min_version:
+min_version_txt = '.'.join(map(str, min_version))
+raise unittest.SkipTest("Mac OS X %s or higher required, not %s"
+% (min_version_txt, version_txt))
+
HOST = 'localhost'
def find_unused_port(family=socket.AF_INET, socktype=socket.SOCK_STREAM):
diff --git a/Lib/test/test_math.py b/Lib/test/test_math.py
--- a/Lib/test/test_math.py
+++ b/Lib/test/test_math.py
@@ -2,6 +2,7 @@
# Should not do tests around zero only
from test.support import run_unittest, verbose, requires_IEEE_754
+from test import support
import unittest
import math
import os
@@ -669,10 +670,10 @@
self.assertTrue(math.isnan(math.log2(NAN)))
@requires_IEEE_754
-@unittest.skipIf(sys.platform == 'darwin'
- and platform.mac_ver()[0].startswith('10.4.'),
- 'Mac OS X Tiger log2() is not accurate enough')
def testLog2Exact(self):
+# log2() is not accurate enough on Mac OS X Tiger (10.4)
+support.requires_mac_ver(10, 5)
+
# Check that we get exact equality for log2 of powers of 2.
actual = [math.log2(math.ldexp(1.0, n)) for n in range(-1074, 1024)]
expected = [float(n) for n in range(-1074, 1024)]
Best Regards,
Ezio Melotti
___
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): Fixup repr for dict_proxy objects.
Hi, On Thu, Jun 30, 2011 at 2:51 AM, raymond.hettinger < python-check...@python.org> wrote: > http://hg.python.org/cpython/rev/9a0b6c07b488 > changeset: 71086:9a0b6c07b488 > branch: 2.7 > parent: 71055:cdfcd00873cd > user:Raymond Hettinger > date:Thu Jun 30 00:44:36 2011 +0100 > summary: > Fixup repr for dict_proxy objects. > This was already fixed in a slightly different way in 3.x. Unless there's a valid reason to have two different implementations of dict_proxy.__repr__ in 2.x and 3.x, I would suggest to pick the best one and use it on all the branches. See also http://bugs.python.org/issue5587 Best Regards, Ezio Melotti ___ 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 (merge 3.2 -> default): Merge with 3.2.
Hi,
On 14/07/2011 15.57, ezio.melotti wrote:
http://hg.python.org/cpython/rev/ac1c3291a689
changeset: 71325:ac1c3291a689
parent: 71321:f45823977d4b
parent: 71324:530ba6c7e578
user:Ezio Melotti
date:Thu Jul 14 15:57:12 2011 +0300
summary:
Merge with 3.2.
files:
Lib/test/test_cgi.py | 8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Lib/test/test_cgi.py b/Lib/test/test_cgi.py
--- a/Lib/test/test_cgi.py
+++ b/Lib/test/test_cgi.py
@@ -155,7 +155,13 @@
cgi.logfp = None
cgi.logfile = "/dev/null"
cgi.initlog("%s", "Testing log 3")
-self.addCleanup(cgi.logfp.close)
+def log_cleanup():
+"""Restore the global state of the log vars."""
+cgi.logfile = ''
+cgi.logfp.close()
+cgi.logfp = None
+cgi.log = cgi.initlog
It was suggested (on #python-dev) to move this function to the cgi
module itself, but since I'm not familiar with it I just added it
here in order to fix a failure in the test.
The cgi module has two global vars (logfile and logfp) and a global
function (log) that is initialized to initlog and then reassigned to
either dolog or nolog (a dummy function that does nothing) in
initlog itself[0].
If someone thinks the log_cleanup function should be moved to the
cgi.py module and/or the code be refactored a bit, he can do it or
open an issue.
[0]: http://hg.python.org/cpython/file/ac1c3291a689/Lib/cgi.py#l50
Best Regards,
Ezio Melotti
+self.addCleanup(log_cleanup)
cgi.log("Testing log 4")
def test_fieldstorage_readline(self):
___
Python-checkins mailing list
python-check...@python.org
http://mail.python.org/mailman/listinfo/python-checkins
___
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] r88867 - in tracker/instances/python-dev: extensions/pydevutils.py html/file.item.html html/issue.item.html html/msg.item.html
On 23/07/2011 9.55, Nick Coghlan wrote: On Sat, Jul 23, 2011 at 8:34 AM, ezio.melotti wrote: Author: ezio.melotti Date: Sat Jul 23 00:34:53 2011 New Revision: 88867 Log: #267: remove the remove button from the issue page, move it to the msg/file page, and add a button to add back removed messages/files. Thank you! (I accidentally deleted one of RDM's comments just the other day) You are welcome! (That was actually one of the reasons that made me look at that issue again) Now restoring messages and files that got deleted should be trivial, and deleting them accidentally (almost) impossible. Messages and files can be deleted/restored from their pages. Links to these pages can be found in the history of the issue. For messages and files that are still linked to the issue, the "(view)" and "edit" links can also be used. Best Regards, Ezio Melotti Cheers, Nick. ___ 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] Convention on functions that shadow existing stdlib functions
Hi, On 27/07/2011 16.35, Eli Bendersky wrote: > 1. In the documentation of test.support mention explicitly that it's code > for CPython's internal use only, and these APIs aren't guaranteed to be > stable. There is a top-level note at http://docs.python.org/dev/library/test.html, but it won't be visible by people who arrive at an anchor point. I think officially documenting test.support is a mistake. There is no guarantee that APIs are stable or will even continue to exist. Docstrings are sufficient for own our purposes. Initially I was *for* documenting, but this thing with showing up in the index is a compelling counter-point. "The basic version makes entries in the general index; if no index entry is desired, you can give the directive option flag :noindex:." (http://docs.python.org/documenting/markup.html#information-units) Best Regards, Ezio Melotti > 2. Some functions like unlink and rmtree are obviously redundant, and shadow > frequently used Python stdlib functions, so I would either kill them > completely or at least rename them appropriately. They are not redundant, since they provide slightly different semantics (for example, they silence errors that happen when the path doesn't exist). Sure, but I'm still leery of two functions with the same name doing acting slightly differently. Eli ___ 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: fix doc typo for library/test.rst
Hi,
On 27/07/2011 20.31, eli.bendersky wrote:
http://hg.python.org/cpython/rev/8989aa5b357c
changeset: 71532:8989aa5b357c
user:Eli Bendersky
date:Wed Jul 27 20:29:59 2011 +0300
summary:
fix doc typo for library/test.rst
files:
Doc/library/test.rst | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Doc/library/test.rst b/Doc/library/test.rst
--- a/Doc/library/test.rst
+++ b/Doc/library/test.rst
@@ -447,7 +447,7 @@
Module and package deprecation messages are suppressed during this import
if *deprecated* is ``True``.
- This function will raise :exc:`unittest.SkipTest` is the named module
+ This function will raise :exc:`unittest.SkipTest` if the named module
Actually I think this is no longer true. import_fresh_module raises an
ImportError if *name* can't be imported, or returns None if the fresh
module is not found.
Its use case is to enable or block accelerations for modules that
optionally provide one. All the modules that currently use
import_fresh_module are (afaik) always available (json, warnings,
heapq), so raising SkipTest when the module is missing is not useful now.
It returns None in the case an acceleration is missing, so e.g. in
"cjson = import_fresh_module('json', fresh=['_json'])" cjson will be
None and it will be possible to do things like @skipUnless(cjson,
'requires _json'). Here raising an ImportError will defeat (part of)
the purpose of the function, i.e. avoiding:
try:
import _json
except ImportError:
_json = None
and raising a SkipTest when the accelerations are missing is not an
option if there are other tests (e.g. the tests for the Python
implementation).
These changes come from http://hg.python.org/cpython/rev/c1a12a308c5b .
Before the change import_fresh_module was still returning the module
(e.g. json) even when the acceleration (fresh=['_json']) was missing,
and the C tests were run twice using the same pure-python module used
for the Py ones.
The typo and the wrong doc is also on 2.7.
Best Regards,
Ezio Melotti
cannot be imported.
Example use::
___
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: Modernize modulefinder module and tests a bit.
Hi,
On 29/07/2011 15.35, eric.araujo wrote:
http://hg.python.org/cpython/rev/1521d9837d16
changeset: 71569:1521d9837d16
user:Éric Araujo
date:Thu Jul 28 23:35:29 2011 +0200
summary:
Modernize modulefinder module and tests a bit.
The tests don’t use an internal distutils function anymore, and use
regular assertEqual with sorted lists instead of a convoluted manual
diff.
files:
Lib/modulefinder.py | 15 ++
Lib/test/test_modulefinder.py | 48 +++---
2 files changed, 31 insertions(+), 32 deletions(-)
diff --git a/Lib/modulefinder.py b/Lib/modulefinder.py
--- a/Lib/modulefinder.py
+++ b/Lib/modulefinder.py
@@ -1,6 +1,5 @@
"""Find modules used by a script, using introspection."""
-from __future__ import generators
import dis
import imp
import marshal
@@ -9,8 +8,6 @@
import types
import struct
-READ_MODE = "rU"
-
# XXX Clean up once str8's cstor matches bytes.
LOAD_CONST = bytes([dis.opname.index('LOAD_CONST')])
IMPORT_NAME = bytes([dis.opname.index('IMPORT_NAME')])
@@ -29,8 +26,7 @@
# A Public interface
def AddPackagePath(packagename, path):
-paths = packagePathMap.get(packagename, [])
-paths.append(path)
+paths = packagePathMap.setdefault(packagename, []).append(path)
I'm assuming that packagePathMap is a dict that might contain or not a
*packagename* key that maps to a list of paths.
Now, unless I'm missing something, the old code assigned to *paths* the
list of paths or [] if it wasn't there, and then appended *path* to it.
AFAICS, the new code introduced two changes:
1) the packagename key is added to the dict if it was missing -- and
this seems reasonable;
2) append is now on the same line, it returns None, and None is
assigned to *paths* -- and this seems wrong;
packagePathMap[packagename] = paths
Also this is not necessary anymore if you use setdefault.
replacePackageMap = {}
@@ -106,14 +102,14 @@
[...]
Best Regards,
Ezio Melotti
___
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: Fix closes Issue11281 - smtplib.STMP gets source_address parameter, which adds
ame and source_address has the s/has/have/? Also I prefer 'arguments' rather than 'parameters', the smtplib doc uses both, but 'arguments' seems to be used more. + same meaning as that of SMTP client.To specify a Unix socket, you must use Missing space after the '.' (there should be two spaces, but here a single space is used consistently so it's fine). + an absolute path for *host*, starting with a '/'. Authentication is supported, using the regular SMTP mechanism. When using a Unix socket, LMTP generally don't support or require any authentication, but your diff --git a/Lib/smtplib.py b/Lib/smtplib.py --- a/Lib/smtplib.py +++ b/Lib/smtplib.py @@ -215,7 +215,8 @@ [...] Best Regards, Ezio Melotti ___ 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 11/08/2011 0.02, Sandro Tosi wrote: On Wed, Aug 10, 2011 at 21:55, Terry Reedy wrote: Latest version of the `heapq Python source code -<http://svn.python.org/view/python/branches/release27-maint/Lib/heapq.py?view=markup>`_ +<http://svn.python.org/view/*checkout*/python/branches/release27-maint/Lib/heapq.py?content-type=text%2Fplain>`_ Should links be to the hg repository instead of svn? Is svn updated from hg? I thought is was (mostly) historical read-only. I made the same remark to Senthil on IRC, and came out that web frontend for hg.p.o doesn't allow for a nice way to specify a branch (different than 'default'), it's something like hg.python.org/cpython//path/to/file.py which is almost always outdated :) hg.python.org/cpython/2.7/path/to/file.py should work just fine. 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. Best Regards, Ezio Melotti What do we use to provide the web part of hg.p.o? maybe we can just ask the developers of this tool to provide (or advertize) a proper way to select a branch. If some can provide me some info, I can do the "ask the devs" part. Cheers, ___ 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 24/08/2011 5.31, Nick Coghlan wrote: On Wed, Aug 24, 2011 at 5:19 AM, Steven D'Aprano wrote: (Nor do we write filingsystem, governmentsystem, politicalsystem or schoolsystem. This is English, not German.) Personally, I think 'filesystem' is a portmanteau in the process of coming into existence (as evidenced by usage like 'FHS' standing for 'Filesystem Hierarchy Standard'). However, the two word form is still useful at times, particularly for disambiguation of acronyms (as evidenced by usage like 'NFS' and 'GFS' for 'Network File System' and 'Google File System'). The Wikipedia article on the topic mixes and matches the two forms, but overall does favour the two word form. Since I tend to use the one word 'filesystem' form myself (ditto for 'filename'), I'm +1 for FilesystemError, but I'm only -0 for FileSystemError (so I expect that will be the option chosen, given other responses). This pretty much summarizes my thoughts. I saw the wiki article using both and since I consider 'filesystem' a single word I was wondering if anyone else preferred FilesystemError. I'm totally fine with FileSystemError too though, if most people prefer it. Best Regards, Ezio Melotti Regards, Nick. ___ 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] PEP 393 Summer of Code Project
On Wed, Aug 24, 2011 at 11:37 PM, Terry Reedy wrote: > On 8/24/2011 1:45 PM, Victor Stinner wrote: > >> Le 24/08/2011 02:46, Terry Reedy a écrit : >> > > I don't think that using UTF-16 with surrogate pairs is really a big >> problem. A lot of work has been done to hide this. For example, >> repr(chr(0x10)) now displays '\U0010' instead of two characters. >> Ezio fixed recently str.is*() methods in Python 3.2+. >> > > I greatly appreciate that he did. The * (lower,upper,title) methods > apparently are not fixed yet as the corresponding new tests are currently > skipped for narrow builds. There are two reasons for this: 1) the str.is* methods get the string and return True/False, so it's enough to iterate on the string, combine the surrogates, and check if the result islower/upper/etc. Methods like lower/upper/etc, afaiu, currently get only a copy of the string, and modify that in place. The current macros advance to the next char during reading and writing, so it's not possible to use them to read/write from/to the same string. We could either change the macros to not advance the pointer [0] (and do it manually in the other functions like is*) or change the function to get the original string too. 2) I'm on vacation. Best Regards, Ezio Melotti [0]: for lower/upper/title it should be possible to modify the string in place, because these operations never converts a non-BMP char to a BMP one (and vice versa), so if two surrogates are read, two surrogates will be written after the transformation. I'm not sure this will work with all the methods though (e.g. str.translate). ___ 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] PEP 393 Summer of Code Project
On Fri, Aug 26, 2011 at 1:54 AM, Guido van Rossum wrote: > On Wed, Aug 24, 2011 at 3:06 AM, Terry Reedy wrote: > > Excuse me for believing the fine 3.2 manual that says > > "Strings contain Unicode characters." (And to a naive reader, that > implies > > that string iteration and indexing should produce Unicode characters.) > > The naive reader also doesn't know the difference between characters, > code points and code units. It's the advanced, Unicode-aware reader > who is confused by this phrase in the docs. It should say code units; > or perhaps code units for narrow builds and code points for wide > builds. For UTF-16/32 (i.e. narrow/wide), talking about "code units"[0] should be correct. Also note that: * for both, every "code unit" has a specific "codepoint" (including lone surrogates), so it might be OK to talk about "codepoints" too, but * only for wide builds every "codepoints" is represented by a single, 32-bits "code unit". In narrow builds, non-BMP chars are represented by a "code unit sequence" of two elements (i.e. a "surrogate pair"). Since "code unit" refers to the *minimal* bit combination, in UTF-8 characters that needs 2/3/4 bytes, are represented with a "code unit sequence" made of 2/3/4 "code units" (so in UTF-8 "code units" and "code points" overlaps only for the ASCII range). > With PEP 393 we can unconditionally say code points, which is > much better. We should try to remove our use of "characters" -- or > else we should *define* our use of the term "characters" as "what the > Unicode standard calls code points". > Character usually works fine, especially for naive readers. Even Unicode-aware readers often confuse between the several terms, so using a simple term and pointing to a more accurate description sounds like a better idea to me. Note that there's also another important term[1]: """ *Unicode Scalar Value*. Any Unicode * code point<http://unicode.org/glossary/#code_point> * except high-surrogate and low-surrogate code points. In other words, the ranges of integers 0 to D7FF16 and E00016 to 1016 inclusive. """ For example the UTF codecs produce sequences of "code units" (of 8, 16, 32 bits) that represent "scalar values"[2][3]: Chapter 3 [4] says: """ 3.9 Unicode Encoding Forms The Unicode Standard supports three character encoding forms: UTF-32, UTF-16, and UTF-8. Each encoding form maps the Unicode code points U+..U+D7FF and U+E000..U+10 to unique code unit sequences. [...] D76 Unicode scalar value: Any Unicode code point except high-surrogate and low-surrogate code points. • As a result of this definition, the set of Unicode scalar values consists of the ranges 0 to D7FF and E000 to 10, inclusive. D77 Code unit: The minimal bit combination that can represent a unit of encoded text for processing or interchange. [...] D79 A Unicode encoding form assigns each Unicode scalar value to a unique code unit sequence. """ On the other hand, Python Unicode strings are not limited to scalar values, because they can also contain lone surrogates. I hope this helps clarify the terminology a bit and doesn't add more confusion, but if we want to use the Unicode terms we should get them right. (Also note that I might have misunderstood something, even if I've been careful with the terms and I double-checked and quoted the relevant parts of the Unicode standard.) Best Regards, Ezio Melotti [0]: From the chapter 3 [4], D77 Code unit: The minimal bit combination that can represent a unit of encoded text for processing or interchange. • Code units are particular units of computer storage. Other character encoding standards typically use code units defined as 8-bit units—that is, octets. The Unicode Standard uses 8-bit code units in the UTF-8 encoding form, 16-bit code units in the UTF-16 encoding form, and 32-bit code units in the UTF-32 encoding form. [1]: http://unicode.org/glossary/#unicode_scalar_value [2]: Apparently Python 3 raises an error while encoding lone surrogates in UTF-8, but it doesn't for UTF-16 and UTF-32. >From the chapter 3 [4], D91: "Because surrogate code points are not Unicode scalar values, isolated UTF-16 code units in the range 0xD800..0xDFFF are ill-formed." D92: "Because surrogate code points are not included in the set of Unicode scalar values, UTF-32 code units in the range 0xD800..0xDFFF are ill-formed." I think this should be fixed. [3]: Note that I'm talking about codecs used to encode/decode Unicode strings to/from bytes here, it's perfectly fine for Python itself to represent lone surrogates in its *internal* representations, regardless of what encoding it's using. [4]: Chapter 3: http://www.unicode.org/versions/Unicode6.0.0/ch03.pdf ___ 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] PEP 393 Summer of Code Project
On Fri, Aug 26, 2011 at 5:59 AM, Guido van Rossum wrote:
> On Thu, Aug 25, 2011 at 7:28 PM, Isaac Morland
> wrote:
> > On Thu, 25 Aug 2011, Guido van Rossum wrote:
> >
> >> I'm not sure what should happen with UTF-8 when it (in flagrant
> >> violation of the standard, I presume) contains two separately-encoded
> >> surrogates forming a valid surrogate pair; probably whatever the UTF-8
> >> codec does on a wide build today should be good enough.
>
Surrogates are used and valid only in UTF-16.
In UTF-8/32 they are invalid, even if they are in pair (see
http://www.unicode.org/versions/Unicode6.0.0/ch03.pdf ). Of course Python
can/should be able to represent them internally regardless of the build
type.
>>Similarly for
> >> encoding to UTF-8 on a wide build if one managed to create a string
> >> containing a surrogate pair. Basically, I'm for a
> >> garbage-in-garbage-out approach (with separate library functions to
> >> detect garbage if the app is worried about it).
> >
> > If it's called UTF-8, there is no decision to be taken as to decoder
> > behaviour - any byte sequence not permitted by the Unicode standard must
> > result in an error (although, of course, *how* the error is to be
> reported
> > could legitimately be the subject of endless discussion).
>
What do you mean? We use the "strict" error handler by default and we can
specify other handlers already.
> There are
> > security implications to violating the standard so this isn't just
> > legalistic purity.
>
> You have a point. The security issues cannot be seen separate from all
> the other issues. The folks inside Google who care about Unicode often
> harp on this. So I stand corrected. I am fine with codecs treating
> code points or code point sequences that the Unicode standard doesn't
> like (e.g. lone surrogates) the same way as more severe errors in the
> encoded bytes (lots of byte sequences already aren't valid UTF-8).
Codecs that use the official names should stick to the standards. For
example s.encode('utf-32') should either produce a valid utf-32 byte string
or raise an error if 's' contains invalid characters (e.g. surrogates).
We can have other internal codecs that are based on the UTF-* encodings but
allow the representation of lone surrogates and even expose them if we want,
but they should have a different name (even 'utf-*-something' should be ok,
see http://bugs.python.org/issue12729#msg142053 from "Unicode says you can't
put surrogates or noncharacters in a UTF-anything stream.").
> I
> just hope this doesn't require normal forms or other expensive
> operations; I hope it's limited to rejecting invalid use of surrogates
> or other values that are not valid code points (e.g. 0, or >= 2**21).
>
I think there shouldn't be any normalization done automatically by the
codecs.
>
> > Hmmm, doesn't look good:
> >
> > Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49)
> > [GCC 4.2.1 (Apple Inc. build 5646)] on darwin
> > Type "help", "copyright", "credits" or "license" for more information.
> >>>>
> >>>> '\xed\xb0\x80'.decode ('utf-8')
> >
> > u'\udc00'
> >>>>
> >
> > Incorrect! Although this is a narrow build - I can't say what the wide
> > build would do.
>
The UTF-8 codec used to follow RFC 2279 and only recently has been updated
to RFC 3629 (see http://bugs.python.org/issue8271#msg107074 ). On Python
2.x it still produces invalid UTF-8 because changing it is backward
incompatible. In Python 2 UTF-8 can be used to encode every codepoint from
0 to 10, and it always works. If we change it now it might start
raising errors for an operation that never raised them before (see
http://bugs.python.org/issue12729#msg142047 ).
Luckily this is fixed in Python 3.x.
I think there are more codepoints/byte sequences that should be rejected
while encoding/decoding though, in both UTF-8 and UTF-16/32, but I haven't
looked at them yet (I would be happy to fix these for 3.3 or even 2.7/3.2
(if applicable), so if you find mismatches with the Unicode standard and
report an issue, feel free to assign it to me).
Best Regards,
Ezio Melotti
>
> > For reasons of practicality, it may be appropriate to provide easy access
> to
> > a CESU-8 decoder in addition to the normal UTF-8 decoder, but it must not
> be
> > called UTF-8. Other variations may also find use if provided.
> >
> > See UTF-8 RFC: http://www.ietf.org/rfc/rfc3629.txt
> >
> > And CESU-8 technical report: http://www.unicode.org/reports/tr26
Re: [Python-Dev] Should we move to replace re with regex?
On Sat, Aug 27, 2011 at 1:57 AM, Guido van Rossum wrote: > On Fri, Aug 26, 2011 at 3:54 PM, "Martin v. Löwis" > wrote: > > [...] > > Among us, some are more "regex gurus" than others; you know > > who you are. I guess the PSF would pay for the review, if that > > is what it would take. > > Makes sense. I noticed Ezio seems quite in favor of regex. Maybe he knows > more? > Matthew has always been responsive on the tracker, usually fixing reported bugs in a matter of days, and I think he's willing to keep doing so once the regex module is included. Even if I haven't yet tried the module myself (I'm planning to do it though), it seems quite popular out there (the download number on PyPI apparently gets reset for each new release, so I don't know the exact total), and apparently people are already using it as a replacement of re. I'm not sure it's worth doing an extensive review of the code, a better approach might be to require extensive test coverage (and a review of tests). If the code seems well written, commented, documented (I think proper rst documentation is still missing), and tested (both with unittest and out in the wild), and Matthew is willing to maintain it, I think we can include it. We will get familiar with the code once we start contributing to it and fixing bugs, as it already happens with most of the other modules. See also the "New regex module for 3.2?" thread ( http://mail.python.org/pipermail/python-dev/2010-July/101606.html ). Best Regards, Ezio Melotti > > -- > --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>) > ___ 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] Should we move to replace re with regex?
On Sun, Aug 28, 2011 at 3:48 AM, Terry Reedy wrote: > > These are reasons why both Ezio and I suggested on the tracker adding regex > without deleting re. (I personally would not mind just replacing re with > regex, but then I have no legacy re code to break. So I am not suggesting > that out of respect for those who do.) > I would actually prefer to replace re. Before doing that we should make a list of all the differences between the two modules (possibly in the PEP). On the regex page on PyPI there's already a list that can be used for this purpose [0]. For bug fixes it *shouldn't* be a problem if the behavior changes. New features shouldn't bring any backward-incompatible behavioral changes, and, as far as I understand, Matthew introduced the NEW flag [1], to avoid problems when they do. I think re should be kept around only if there are too many incompatibilities left and if they can't be fixed in regex. Best Regards, Ezio Melotti [0]: http://pypi.python.org/pypi/regex/0.1.20110717 [1]: "The NEW flag turns on the new behaviour of this module, which can differ from that of the 're' module, such as splitting on zero-width matches, inline flags affecting only what follows, and being able to turn inline flags off." ___ 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
