[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] 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] 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] 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] 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: 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] 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/
[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/
Re: [Python-Dev] PEP 595: Improving bugs.python.org
etter 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
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 automat
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 want (as long as we >> agree on wha
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. :) > Thanks a lot for the feedback, I'll update the PEP
[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 new to
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 Zulip Chat: > > > > https://python.zulipchat.com/#narrow/stream
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] 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
[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] Use utf-8 charset for tracker summaries?
On Sat, Mar 12, 2016 at 12:09 AM, Terry Reedy <tjre...@udel.edu> 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
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 gu...@python.org wrote: On Wed, Jul 8, 2015 at 10:19 PM, Serhiy Storchaka storch...@gmail.com 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] Mac popups running make test
On Sun, May 10, 2015 at 5:04 PM, Skip Montanaro skip.montan...@gmail.com 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
Re: [Python-Dev] Starting CPython development w/ Docker
On Mon, Apr 20, 2015 at 3:52 PM, Saul Shanabrook s.shanabr...@gmail.com 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] Tracker Stats
On Mon, Jul 7, 2014 at 10:01 PM, francis franci...@email.de 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] Tracker Stats
On Mon, Jun 23, 2014 at 6:52 PM, francis franci...@email.de 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 a...@amk.ca 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_countstatus=1message_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
[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
Hi, On Sat, Feb 8, 2014 at 1:37 PM, francis franci...@email.de 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
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 raymond.hettin...@gmail.com wrote: On May 10, 2014, at 2:18 PM, Alex Gaynor alex.gay...@gmail.com 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] API and process questions (sparked by Claudiu Popa on 16104
On Mon, Apr 28, 2014 at 6:32 PM, Jim J. Jewett jimjjew...@gmail.com 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] PEP 469: Restoring the iterkeys/values/items() methods
Hi, On Sat, Apr 19, 2014 at 4:14 PM, Steven D'Aprano st...@pearwood.info 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] List vs Tuple / Homogeneous vs Heterogeneous / Mutable vs Immutable
Hi, On Thu, Apr 17, 2014 at 10:23 PM, Guido van Rossum gu...@python.org 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 bcan...@gmail.com wrote: On Thu Apr 17 2014 at 2:43:35 PM, Leandro Pereira de Lima e Silva leandro...@cpti.cetuc.puc-rio.br 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 bcan...@gmail.com wrote: On Thu Apr 17 2014 at 1:34:23 PM, Jurko Gospodnetić jurko.gospodne...@pke.hr 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 module import email File frozen importlib._bootstrap, line 1561, in _find_and_load File frozen importlib._bootstrap, line 1519, in _find_and_load_unlocked File frozen importlib._bootstrap, line 1473, in _find_module File frozen importlib._bootstrap, line 1308, in find_module File frozen importlib._bootstrap, line 1284, in _get_loader File frozen importlib._bootstrap, line 1273, in _path_importer_cache File frozen importlib._bootstrap, 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] CLA link from bugs.python.org
Hi, On Sun, May 5, 2013 at 7:45 AM, Ezio Melotti ezio.melo...@gmail.com wrote: Hi, On Sun, May 5, 2013 at 4:23 AM, Tim Delaney timothy.c.dela...@gmail.com 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 g.bra...@gmx.net wrote: Am 16.02.2014 09:40, schrieb Ezio Melotti: Hi, On Sun, May 5, 2013 at 7:45 AM, Ezio Melotti ezio.melo...@gmail.com wrote: Hi, On Sun, May 5, 2013 at 4:23 AM, Tim Delaney timothy.c.dela...@gmail.com 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
[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@python.org https://mail.python.org/mailman/listinfo
Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters
On Wed, Oct 9, 2013 at 8:15 AM, Georg Brandl g.bra...@gmx.net 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
Re: [Python-Dev] When to remove deprecated stuff
Hi, On Thu, Aug 22, 2013 at 1:00 PM, Petri Lehtinen pe...@digip.org 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 rdmur...@bitdance.com wrote: On Thu, 22 Aug 2013 16:45:29 +0300, Michael Foord fuzzy...@voidspace.org.uk wrote: On 22 Aug 2013, at 14:00, Petri Lehtinen pe...@digip.org 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 don...@stufft.io wrote: On Aug 22, 2013, at 1:34 PM, Ezio Melotti ezio.melo...@gmail.com wrote: Hi, On Thu, Aug 22, 2013 at 1:00 PM, Petri Lehtinen pe...@digip.org 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] When to remove deprecated stuff (was: Deprecating the formatter module)
Hi, On Thu, Aug 15, 2013 at 3:29 PM, R. David Murray rdmur...@bitdance.com wrote: On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 15 Aug 2013 11:16:20 +0200 Victor Stinner victor.stin...@gmail.com wrote: 2013/8/15 Antoine Pitrou solip...@pitrou.net: 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 br...@python.org wrote: On Thu, Aug 15, 2013 at 8:36 AM, Antoine Pitrou solip...@pitrou.netwrote: 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] [Python-checkins] cpython (merge 2.7 - 2.7): Clean merge
+ 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] Misc re.match() complaint
Hi, On Wed, Jul 17, 2013 at 6:15 AM, Stephen J. Turnbull step...@xemacs.org 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] performance testing recommendations in devguide
Hi, On Wed, May 29, 2013 at 9:00 PM, Eric Snow ericsnowcurren...@gmail.com 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] CLA link from bugs.python.org
Hi, On Sun, May 5, 2013 at 4:23 AM, Tim Delaney timothy.c.dela...@gmail.com 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] [Python-checkins] cpython (2.7): Issue 17538: Document XML vulnerabilties
Hi, On Tue, Mar 26, 2013 at 6:53 PM, christian.heimes python-check...@python.org wrote: http://hg.python.org/cpython/rev/e87364449954 changeset: 82973:e87364449954 branch: 2.7 parent: 82963:d321885ff8f3 user:Christian Heimes christ...@cheimes.de 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 christ...@python.org +.. sectionauthor:: Georg Brandl ge...@python.org + + +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] [Python-checkins] cpython: Issue #17385: Fix quadratic behavior in threading.Condition
On Mon, Mar 11, 2013 at 3:14 AM, Ezio Melotti ezio.melo...@gmail.com wrote: Hi, On Mon, Mar 11, 2013 at 2:58 AM, raymond.hettinger python-check...@python.org wrote: http://hg.python.org/cpython/rev/0f86b51f8f8b changeset: 82592:0f86b51f8f8b user:Raymond Hettinger pyt...@rcn.com 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 (merge default - default): Merge heads default.
Hi, On Sat, Mar 16, 2013 at 10:08 PM, terry.reedy python-check...@python.org wrote: http://hg.python.org/cpython/rev/9a2f4418e65a changeset: 82699:9a2f4418e65a parent: 82691:0a15a58ac4a1 parent: 82695:533a60251b9d user:Terry Jan Reedy tjre...@udel.edu 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 tjre...@udel.edu 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] 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 tjre...@udel.edu 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] 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 tjre...@udel.edu 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 tjre...@udel.edu 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 tjre...@udel.edu 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] cpython (2.7): #16004: Add `make touch`.
Hi, On Mon, Mar 11, 2013 at 3:28 PM, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 11 Mar 2013 08:14:24 +0100 (CET) ezio.melotti python-check...@python.org wrote: http://hg.python.org/cpython/rev/da3f4774b939 changeset: 82600:da3f4774b939 branch: 2.7 parent: 82593:3e14aafeca04 user:Ezio Melotti ezio.melo...@gmail.com 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] cpython: Issue #17385: Fix quadratic behavior in threading.Condition
Hi, On Mon, Mar 11, 2013 at 2:58 AM, raymond.hettinger python-check...@python.org wrote: http://hg.python.org/cpython/rev/0f86b51f8f8b changeset: 82592:0f86b51f8f8b user:Raymond Hettinger pyt...@rcn.com 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] VC++ 2008 Express Edition now locked away?
Hi, On Wed, Mar 6, 2013 at 12:20 PM, Terry Reedy tjre...@udel.edu 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] Introducing Electronic Contributor Agreements
Hi, On Mon, Mar 4, 2013 at 10:46 PM, Terry Reedy tjre...@udel.edu wrote: On 3/4/2013 11:36 AM, Brett Cannon wrote: On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin br...@python.org 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] [Python-checkins] cpython (3.3): Don't deadlock on a reentrant call.
Hi, On Fri, Mar 1, 2013 at 2:02 PM, raymond.hettinger python-check...@python.org wrote: http://hg.python.org/cpython/rev/1920422626a5 changeset: 82437:1920422626a5 branch: 3.3 parent: 82435:43ac02b7e322 user:Raymond Hettinger pyt...@rcn.com 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 exec_prefix Consider setting $PYTHONHOME to prefix[:exec_prefix] 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 module import imp File /home/wolf/dev/py/py3k/Lib/imp.py, line 23, in module import tokenize File /home/wolf/dev/py/py3k/Lib/tokenize.py, line 28, in module import re File /home/wolf/dev/py/py3k/Lib/re.py, line 124, in module import functools File /home/wolf/dev/py/py3k/Lib/functools.py, line 22, in module from dummy_threading import RLock File /home/wolf/dev/py/py3k/Lib/dummy_threading.py, line 45, in module import threading File /home/wolf/dev/py/py3k/Lib/threading.py, line 6, in module 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] [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 python-check...@python.org wrote: http://hg.python.org/peps/rev/de69fe61f300 changeset: 4764:de69fe61f300 user:Daniel Holth dho...@fastmail.fm 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] hg.python.org Mercurial upgrade
On Wed, Jan 23, 2013 at 9:43 PM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 23 Jan 2013 20:41:11 +0100 Amaury Forgeot d'Arc amaur...@gmail.com wrote: 2013/1/22 Antoine Pitrou solip...@pitrou.net I've upgraded the Mercurial version on hg.python.org. If there any problems, don't hesitate to post here. I've noticed a display glitch with the hg viewer: http://hg.python.org/cpython/rev/6df0b4ed8617#l2.8 There is a [#14591] link which causes the rest of the line to be shifted. Indeed. This is not because of the upgrade, but because of a new regexp Ezio asked me to insert in the Web UI configuration :-) FWIW this was an attempt to fix the links to issues in http://hg.python.org/cpython/. AFAIU the interhg extension used here to turn #12345 to links affects at least 3 places: 1) the description of each changeset in the shortlog page (e.g. http://hg.python.org/cpython/); 2) the description at the top of the rev page (e.g. http://hg.python.org/cpython/rev/6df0b4ed8617); 3) the code in the diff/rev/annotate and possibly other pages (e.g. http://hg.python.org/cpython/rev/6df0b4ed8617#l2.6); With the previous solution, case 1 was broken, but links for cases 2-3 worked fine. The problem is that in 1 the description is already a link, so the result ended up being something like 'a href=rev/...Issue a href=b.p.o/12345#12345/a is now fixed/a'. With the new solution 1-2 work (the links are added/moved at the end), but it's glitched for case 3. Unless interhg provides a way to limit the replacement only to specific places and/or use different replacements for different places, we will either have to live with these glitches or come up with a proper fix done at the right level. 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] hg.python.org Mercurial upgrade
On Thu, Jan 24, 2013 at 4:29 AM, Chris Jerdonek chris.jerdo...@gmail.com wrote: On Wed, Jan 23, 2013 at 6:16 PM, Ezio Melotti ezio.melo...@gmail.com wrote: On Wed, Jan 23, 2013 at 9:43 PM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 23 Jan 2013 20:41:11 +0100 Amaury Forgeot d'Arc amaur...@gmail.com wrote: 2013/1/22 Antoine Pitrou solip...@pitrou.net I've upgraded the Mercurial version on hg.python.org. If there any problems, don't hesitate to post here. I've noticed a display glitch with the hg viewer: http://hg.python.org/cpython/rev/6df0b4ed8617#l2.8 There is a [#14591] link which causes the rest of the line to be shifted. Indeed. This is not because of the upgrade, but because of a new regexp Ezio asked me to insert in the Web UI configuration :-) FWIW this was an attempt to fix the links to issues in http://hg.python.org/cpython/. AFAIU the interhg extension used here to turn #12345 to links affects at least 3 places: 1) the description of each changeset in the shortlog page (e.g. http://hg.python.org/cpython/); 2) the description at the top of the rev page (e.g. http://hg.python.org/cpython/rev/6df0b4ed8617); 3) the code in the diff/rev/annotate and possibly other pages (e.g. http://hg.python.org/cpython/rev/6df0b4ed8617#l2.6); With the previous solution, case 1 was broken, but links for cases 2-3 worked fine. The problem is that in 1 the description is already a link, so the result ended up being something like 'a href=rev/...Issue a href=b.p.o/12345#12345/a is now fixed/a'. With the new solution 1-2 work (the links are added/moved at the end), but it's glitched for case 3. Unless interhg provides a way to limit the replacement only to specific places and/or use different replacements for different places, we will either have to live with these glitches or come up with a proper fix done at the right level. How does the above relate to this issue? http://bugs.python.org/issue15919 This is exactly the problem I fixed. I added a few more comments on the issue and closed it. Best Regards, Ezio Melotti --Chris ___ 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 Fri, Nov 30, 2012 at 11:52 PM, Brett Cannon br...@python.org wrote: On Fri, Nov 30, 2012 at 4:07 PM, R. David Murray rdmur...@bitdance.comwrote: On Fri, 30 Nov 2012 14:38:12 -0500, Brett Cannon br...@python.org wrote: Do we have a graph of the historical trend of the number of bugs (or at least the historical details stored somewhere)? I think we have had a net Not really. Ezio made one by hand once, but there is nothing automated. The one I made can be found here: https://docs.google.com/spreadsheet/ccc?key=0AplyAWXqkvHUdFF0SkVrT3VKcnRBZXNrR1hleHowWnc I now updated it with the latest data. On the Sheet 2 you can find additional graphs that show the releases of Python together with the data. Only final releases are included, alphas, betas and rcs are not included. The spreadsheet is a bit messy because I was experimenting with different kind of graphs and trying to work around some limitations of Google Docs, but it should be good enough. The historical details are stored only in the mailing list archives, as far as I know. In theory I think you could re-calculate them from the Roundup DB, but for various reasons the numbers would probably come out slightly different. Still, getting the data from the DB would be better than parsing the emails, since for one reason and another there are missing Friday reports, and reports that were issued on non-Friday dates. One option I was considering is having the weekly report script append the result on a file and make it available on bugs.python.org, or even use it to generate graphs directly. This is something I considered and planned to implement for a long time, but haven't done it yet. decrease in open bugs the last couple of weeks and it would be neat to see an absolute and relative graph of the overall trend since Python 3.3.0 was released. Also might make a nice motivator to try to close issues faster. =) Otherwise is the code public for this somewhere? I assume it's making an Yes. It is in the software repository for our roundup instances: http://hg.python.org/tracker/python-dev/file/default/scripts/roundup-summary (Be warned that that isn't the location from which the script is executed, so it is possible for what is actually running to get out of sync with what is checked in at that location.) XML-RPC call or something every week to get the results, but if I decide to Nope, it talks directly to the DB. And as you will see, it is more than a bit gnarly. I think I could also download the csv file and parse that to get whatever data I wanted. To figure out when an issue was closed you need to access its history, and that's not available through XML-RPC/csv IIRC. You should be able to figure out when the issue got created though. Anyway, it's probably easier to implement something like what I mentioned earlier. do a little App Engine app to store historical data and do a graph I would rather not have to figure all of this out from scratch. =) Although I could I guess also parse the email if I wanted to ignore all other emails. I'm not sure how one would go about integrating the above with an App Engine app. I suspect that not quite enough information is available through the XML-RPC interface to replicate that script, but maybe you could manage just the open-close counting part of it. I haven't looked at what it would take. It really depends on what statistics I cared about (e.g. there are less than 4000 bugs while there are less than 25,000 closed bugs). If I just did high-level statistics it wouldn't be bad, but if I try to track every issue independently that might be annoying (and actually cost money for me, although I already personally pay for py3ksupport.appspot.com so I can probably piggyback off of that app's quota). We will see if this ever goes anywhere. =) Another somehow related project/experiment I've been working on is collecting stats about the patches available on the tracker. I put together a temporary page that allows you to enter the name of a module (or any file/path) and get a list of issues with patches that affect the specified module(s): http://wolfprojects.altervista.org/issues.html FTR this is based on the word done by anatoly (see links on the page). I'm planning to eventually integrate this in the tracker too, but lately I don't have too much time, so there's no ETA. 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: Add a few entries to whatsnew/3.3.rst.
On Wed, Sep 26, 2012 at 6:02 PM, Walter Dörwald wal...@livinglogic.de wrote: On 26.09.12 16:43, ezio.melotti wrote: http://hg.python.org/cpython/rev/36f61661f71e changeset: 79194:36f61661f71e user:Ezio Melotti ezio.melo...@gmail.com date:Wed Sep 26 17:43:23 2012 +0300 summary: Add a few entries to whatsnew/3.3.rst. [...] + +A new :data:`~html.entities.html5` dictionary that maps HTML5 named character +references to the equivalent Unicode character(s) (e.g. ``html5['gt;'] == ''``) +has been added to the :mod:`html.entities` module. The dictionary is now also +used by :class:`~html.parser.HTMLParser`. Is there a reason why the trailing ';' is included in the entity names? Yes, to quote http://bugs.python.org/issue3#msg163706: The problem is that the standard allows some charref to end without a ';', but not all of them. So both Eacuteric and Eacute;ric will be parsed as Éric, but only alpha;centauri will result in αcentauri -- alphacentauri will be returned unchanged. To preserve this I included them both, in the same way they are listed at http://www.w3.org/TR/html5/named-character-references.html. This is also explained at http://docs.python.org/dev/library/html.entities.html#html.entities.html5. Best Regards, Ezio Melotti Servus, Walter ___ 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): #15437, #15439: merge Doc/ACKS.txt with Misc/ACKS and modify Doc/about.rst
On Fri, Sep 14, 2012 at 2:22 AM, Chris Jerdonek chris.jerdo...@gmail.com wrote: On Thu, Sep 13, 2012 at 4:00 PM, ezio.melotti python-check...@python.org wrote: http://hg.python.org/cpython/rev/76dd082d332e changeset: 79022:76dd082d332e branch: 2.7 parent: 79014:8f847f66a49f user:Ezio Melotti ezio.melo...@gmail.com date:Fri Sep 14 01:58:33 2012 +0300 summary: #15437, #15439: merge Doc/ACKS.txt with Misc/ACKS and modify Doc/about.rst accordingly. I also contributed to this. :) Yes, with all these ACKS and names I forgot to mention yours in the commit message :) Thanks again for writing the script that automatically merged all the names! Best Regards, Ezio Melotti --Chris ___ 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 Sat, Aug 25, 2012 at 2:07 PM, mar...@v.loewis.de wrote:
Zitat von francis franci...@email.de:
Is there a easy way to automate this?:
- Get a list the waiting for review issues
Not exactly this precise list; instead, a list of issues with a patch:
s=xmlrpclib.ServerProxy(http://bugs.python.org,allow_none=True)
s.filter('issue',dict(keywords=2,status=1})
The other conditions need to be queried separately (although you
could search for both keywords in a single query).
[...]
In addition, you might want to check the Roundup XML-RPC docs:
http://roundup.sourceforge.net/docs/xmlrpc.html
and the source of the script that generates the summary:
http://hg.python.org/tracker/python-dev/file/default/scripts/roundup-summary
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] Print policy for deprecated modules
On Sun, Jul 22, 2012 at 12:18 PM, anatoly techtonik techto...@gmail.com wrote: What is a print policy for deprecated modules? new module is deprecated in 2.6, but 2.7.3 doesn't print any warnings. Is it a bug? python -Wd -c import new In theory this should show a warning, but for some reason it doesn't. Reading the messages on http://bugs.python.org/issue1247765 it seems that there wasn't a clear consensus about the deprecation schedule, so that might be the reason. If the warning is missing just because no one remembered to add it, I guess it can still be fixed on 2.7, but for 2.6 is too late now. FWIW you get a warning if you use the -3 flag: $ python -Wd -3 -c import new -c:1: DeprecationWarning: The 'new' module has been removed in Python 3.0; use the 'types' module instead. ___ 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: #15114: the strict mode of HTMLParser and the HTMLParseError exception are
On Sat, Jun 23, 2012 at 3:29 PM, Antoine Pitrou solip...@pitrou.net wrote: On Sat, 23 Jun 2012 15:28:00 +0200 ezio.melotti python-check...@python.org wrote: + .. deprecated-removed:: 3.3 3.5 + The *strict* argument and the strict mode have been deprecated. + The parser is now able to accept and parse invalid markup too. + What if people want to accept only valid markup? The problem with the strict mode is that is not really strict. Originally the parser was trying to work around some common errors (e.g. missing quotes around attribute values), but was giving up when other markup errors were encountered. When the non-strict mode was introduced, the old behavior was called strict and left unchanged for backward compatibility, even thought it wasn't strict enough to be used for validation and it was happy to parse some broken markup (but not other). At the same time the non-strict mode was able to accept some markup errors but not others, and sometimes parsing valid markup yielded different results in strict and non-strict modes. Then HTML5 was announced, with specific algorithms to parse both valid and invalid markup, so I improved the non-strict mode to 1) be able to parse everything; 2) try to be as close as the HTML5 standard as possible (I don't claim HTML5 conformance though). Now parsing a valid HTML page should give the same result in strict and non-strict mode, so the strict mode is now only useful if you want HTMLParseErrors for an arbitrary subset of markup errors. As someone already suggested, I should write a blog post explaining all this, but I'm still working on ironing out the last things in the code, so the blog post has yet to reach the top of my todo list. 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] outdated info on download pages for older versions
On 02/05/2012 19.33, Michael Foord wrote: On 2 May 2012, at 16:55, Terry Reedy wrote: I would send the above to webmas...@python.org (should be at the bottom of pages). We develop CPython but do not directly manage the website. Not true. The download pages are administered by the release managers not the web team. For the record, the best way of contacting the web team (such as it is) is the pydotorg-www mailing list. There are precious few people (even fewer than there are in the web team...) responding to emails on the webmaster alias. :-) Michael I'm pretty sure that several core devs are able (and possibly willing) to help out with the website, but AFAIU they have to request commit right for a separate repo where the website lives or report issues via mail. Is there any practical reason why the repo for the website is not on hg with all the other repos (cpython/devguide/peps/etc.) except that no one ported it yet? 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] Changes in html.parser may cause breakage in client code
Hi,
On 26/04/2012 22.10, Vinay Sajip wrote:
Following recent changes in html.parser, the Python 3 port of Django I'm working
on has started failing while parsing HTML.
The reason appears to be that Django uses some module-level data in html.parser,
for example tagfind, which is a regular expression pattern. This has changed
recently (Ezio changed it in ba4baaddac8d).
html.parser doesn't use any private _name, so I was considering part of
the public API only the documented names. Several methods are marked
with an # internal comment, but that's not visible unless you go read
the source code.
Now tagfind (and other such patterns) are not marked as private (though not
documented), but should they be? The following script (tagfind.py):
import html.parser as Parser
data = 'select name=stuff'
m = Parser.tagfind.match(data, 1)
print('%r - %r' % (Parser.tagfind.pattern, data[1:m.end()]))
gives different results on 3.2 and 3.3:
$ python3.2 tagfind.py
'[a-zA-Z][-.a-zA-Z0-9:_]*' - 'select'
$ python3.3 tagfind.py
'([a-zA-Z][-.a-zA-Z0-9:_]*)(?:\\s|/(?!))*' - 'select'
The trailing space later causes a mismatch with the end tag, and leads to the
errors. Django's use of the tagfind pattern is in a subclass of HTMLParser, in
an overridden parse_startag method.
Django shouldn't override parse_starttag (internal and undocumented),
but just use handle_starttag (public and documented).
I see two possible reasons why it's overriding parse_starttag:
1) Django is working around an HTMLParser bug. In this case the bug
could have been fixed (leading to the breakage of the now-useless
workaround), and now you could be able to use the original
parse_starttag and have the correct result. If it is indeed working
around a bug and the bug is still present, you should report it upstream.
2) Django is implementing an additional feature. Depending on what
exactly the code is doing you might want to open a new feature request
on the bug tracker. For example the original parse_starttag sets a
self.lasttag attribute with the correct name of the last tag parsed.
Note however that both parse_starttag and self.lasttag are internal and
shouldn't be used directly (but lasttag could be exposed and documented
if people really think that it's useful).
Do we need to indicate more strongly that data like tagfind are private? Or has
the change introduced inadvertent breakage, requiring a fix in Python?
I'm not sure that reverting the regex, deprecate all the exposed
internal names, and add/use internal _names instead is a good idea at
this point. This will cause more breakage, and it would require an
extensive renaming. I can add notes to the documentation/docstrings and
specify what's private and what's not though.
OTOH, if this specific fix is not released yet I can still do something
to limit/avoid the breakage.
Best Regards,
Ezio Melotti
Regards,
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/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Clean-up the SQLite introduction.
Hi,
On Tue, Apr 17, 2012 at 8:48 PM, raymond.hettinger
python-check...@python.org wrote:
http://hg.python.org/cpython/rev/d229032dc213
changeset: 76387:d229032dc213
branch: 2.7
user: Raymond Hettinger pyt...@rcn.com
date: Tue Apr 17 22:48:06 2012 -0400
summary:
Clean-up the SQLite introduction.
files:
Doc/library/sqlite3.rst | 52 ++--
1 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/Doc/library/sqlite3.rst b/Doc/library/sqlite3.rst
--- a/Doc/library/sqlite3.rst
+++ b/Doc/library/sqlite3.rst
@@ -23,7 +23,7 @@
:file:`/tmp/example` file::
The filename here should be updated too.
import sqlite3
- conn = sqlite3.connect('/tmp/example')
+ conn = sqlite3.connect('example.db')
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] PendingDeprecationWarning
Hi, On Thu, Mar 22, 2012 at 3:13 PM, Terry Reedy tjre...@udel.edu wrote: My impression is that the original reason for PendingDeprecationWarning versus DeprecationWarning was to be off by default until the last release before removal. But having DeprecationWarnings on by default was found to be too obnoxious and it too is off by default. So do we still need PendingDeprecationWarnings? My impression is that it is mostly not used, as it is a nuisance to remember to change from one to the other. The deprecation message can always indicate the planned removal time. I searched the Developer's Guide for both deprecation and DeprecationWarning and found nothing. See http://mail.python.org/pipermail/python-dev/2011-October/114199.html 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] PEP 414
[quoting Armin from Reddit] Because in all honesty, because string wrappers make a codebase horrible to work with. I will have to continue maintaining 2.x versions for at least another four or five years. The idea if having to use string wrappers for that long makes me puke. Reading this led me to think the following: * 2.5 is now available basically everywhere, and it was released almost 5 years ago (Sep 2006); * if it takes the same time for 3.3, it will be widespread after 4-5 years (i.e. 2016-2017) [0]; * if you want to target a Python 3 version that is widespread [1], you will want to support 3.1/3.2 too in the meanwhile; * therefore you will have to use the hook on 3.1/3.2; * in 2016-2017 you'll finally be able to drop 3.1/3.2 and use only 3.3 without hooks; * in 2016-2017 you'll also stop maintaining the 2.x version (according to that quote); * if you are not maintaining 2.x anymore, you won't need u'' -- right when you could finally stop using the hook; Now, if the hook doesn't get in the way (AFAIU you just have to install it and it will do its work automatically), wouldn't it be better to use it in 3.3 too (especially considering that you will probably have to use it already for 3.1/3.2)? If my reasoning is correct, by the time you will be able to use u without problems you will have to start phasing it out because you won't need to support 2.x anymore. Is this hook available somewhere? How difficult is the installation? Does it strip the u automatically or is there a further step that developers should do before testing on 3.1/3.2? Best Regards, Ezio Melotti [0]: ISTM that people think once you decide to switch to 3.x, there's really no reason to pick an older release, just pick the latest (3.3). While this might be true for single developers that install it by hand, I don't think it's the same for distros and I expect for 3.x the same time span between release and widespread availability that we have with 2.x (i.e. 4-5 years). However this is just an assumption, if you have more accurate information that can show that the time span will indeed be shorter for 3.x (e.g. 2-3 year), feel free to prove me wrong. [1]: I think most projects still support 2.5, some support even older versions, some support only newer ones, but 2.5 as minimum support version seems a good average to me. Targeting the same use base seems reasonable to me (albeit not strictly necessary). I know that this was just a comment on Reddit and was not in the PEP, but it smacks of you throwing all your toys out of the pram. It certainly wasn't a reasoned response to my point. And some of that toys-pram attitude bleeds through into the language of the PEP, leading others to make the criticisms that they have. A PEP is supposed to be balanced, reasonable and thought through. It's not supposed to gloss over things in a hand-wavy sort of way - there's still uncertainty in my mind, for example, whether the 3.2 hook will be a 2to3-style tool that runs over a chunk of the whole project's codebase between editing and running a test, or whether it's an import-time hook which only kicks in on files that have just been edited in a development session. Which of these it is might affect crucially the experience of someone wanting to support 3.2 and 3.3 and 2.6+ - but that clearly isn't you, and you don't seem to have much sympathy or patience with that constituency - we're all stick-in-the-muds who want to work with Ubuntu LTS, rather than people subject to constraints imposed by employers, clients, projects we depend on etc. In contrast, Nick made a more reasonable case when commenting ion my preference for unicode_literals (on this list, not on Reddit), by reminding me about how unicode_literals changes the semantics of string literals, and this increases the cognitive burden on developers. I'm not whinging about the PEP in this post - I've said elsewhere that I wasn't opposed to it. I'm just trying to respond to your apparent bewilderment at some of the reaction to the PEP. I have confidence that with your continued input and Nick's input, the wording of the PEP can be made such that it doesn't ruffle quite so many feathers. I'm looking forward to seeing the updates. Regards, 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] PEP 414
Hi Ezio, Am 02.03.2012 um 10:33 schrieb Ezio Melotti: Reading this led me to think the following: * 2.5 is now available basically everywhere, and it was released almost 5 years ago (Sep 2006); * if it takes the same time for 3.3, it will be widespread after 4-5 years (i.e. 2016-2017) [0]; * if you want to target a Python 3 version that is widespread [1], you will want to support 3.1/3.2 too in the meanwhile; * therefore you will have to use the hook on 3.1/3.2; * in 2016-2017 you'll finally be able to drop 3.1/3.2 and use only 3.3 without hooks; * in 2016-2017 you'll also stop maintaining the 2.x version (according to that quote); * if you are not maintaining 2.x anymore, you won't need u'' -- right when you could finally stop using the hook; I don't think you can compare 2.5 and 3.2 like that. Although 3.2 is/will be shipped with some distributions, it never has, and never will have, the adoption of 2.5 that was mainstream for a quite long time. But I don't think the adoption of 3.2 will affect the decisions that distros will take about 3.3. Even in the unlikely case that e.g. Debian/RHEL make Python 3.3 available as soon as it's released, not everyone will immediately upload to the latest Debian or RHEL version. The point is that regardless the current Python 3 situation, it will take a few years before 3.3 will be widely available on most of the machine. For example I work on a server where I have 3.1. When/if it will be updated it will probably get 3.2, not 3.3 -- and this might happen in a couple of years. If I want 3.3 I will probably have to wait another couple of years. Other people might have to wait less time, others more. 3.3 is the IMHO the first 3.x release that brings really cool stuff to the table and might be the tipping point for people to start embracing Python 3 – despite the fact that Ubuntu LTS will alas ship 3.2 for the next 10 years. I hope for some half-official back port there. :) I heard this about 3.1 and 3.2 too, and indeed they are both perfectly valid releases. The fact that 3.3 is even cooler doesn't mean that 3.1/3.2 are not cool. (I'm perfectly fine with the aforementioned server and 3.1, and currently I don't miss anything that is new in 3.2/3.3.) 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] PEP 414 - Unicode Literals for Python 3
On 28/02/2012 14.19, Antoine Pitrou wrote: Le mardi 28 février 2012 à 22:14 +1000, Nick Coghlan a écrit : If you're using separate branches, then your Python 2 code isn't being made forward compatible with Python 3. Yes, it avoids making your Python 2 code uglier, but it means maintaining two branches in parallel until you drop Python 2 support. IMO, maintaining two branches shouldn't be much more work than maintaining hacks so that a single codebase works with two different programming languages. +10 For every CPython bug that I fix I first apply the patch on 2.7, then on 3.2 and then on 3.3. Most of the time I don't even need to change anything while applying the patch to 3.2, sometimes I have to do some trivial fixes. This is also true for another personal 12kloc project* where I'm using the two-branches approach. For me, the costs of having two branches are: 1) a one-time conversion when the Python3-compatible branch is created (can be done easily with 2to3); 2) merging the fix I apply to the Python2 branch (and with modern DVCS this is not really an issue). With the shared code base approach, the costs are: 1) a one-time conversion to fix the code base and make it run on both 2.x and 3.x; 2) keep using and having to deal with hacks in order to keep it running. With the first approach, you also have two clean and separate code bases, with no hacks; when you stop using Python 2, you end up with a clean Python 3 branch. The one-time conversion also seems easier in the first case. (Note: there are also other costs -- e.g. releasing -- that I haven't considered because they don't affect me personally, but I'm not sure they are big enough to make the two-branches approach worse.) You've once again raised the barrier to entry: either people contribute two patches, or they accept that their patch may languish until someone else writes the patch for the other version. Again that's wrong. If you cleverly use 2to3 to port between branches, patches only have to be written against the 2.x version. After the initial conversion of the code base, the fixes are mostly trivial, so people don't need to write two patches (most of the patches we get for CPython are either against 2.7 or 3.2, and sometimes they even apply clearly to both). Using 2to3 to generate the 3.x code automatically for every change applied to the 2.x branch (or to convert everything when a new package is installed) sounds wrong to me. I wouldn't trust generated code even if 2to3 was a better tool. That said, I successfully used the shared code base approach with print_function, unicode_literals, and a couple of try/except for the imports for a few one-file scripts (for 2.7/3.2) that I wrote recently. TL;DR the two-branches approach usually works better (at least IME) than the shared code base approach, doesn't necessarily require more work, and doesn't need ugly hacks to work. * in this case all the string literals I had were already text (rather than bytes) and even without using unicode_literals they worked out of the box when I moved the code to 3.x. There was however a place where it didn't work, and that turned out to be a bug even in Python 2 because I was mixing bytes and text. 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] PEP 414 - Unicode Literals for Python 3
is making the patch work on one of the branch in the first place. Once it works, porting it to the other branches is just a mechanical step that doesn't really take much. The problems during the porting arise when the two codebases diverged. (Also keep in mind that we are not actually merging from 2.x to 3.x in CPython, otherwise it would be even easier.) This, to me, is the single big advantage of the single codebase approach, and the productivity improvements outweigh code purity issues which are, in the grand scheme of things, not all that large. ISTM that the amount of time is pretty much the same, so I don't see this as a point of favor of the single codebase approach. I might be wrong (I don't have much experience with the single codebase approach), but having to deal with 2+ branches never bothered me (I might be biased though, since I was already used to maintaining 3-4 branches with Python). Another advantage is DRY: you don't have to worry about forgetting to merge some changes from 2.x to 3.x. Haven't we all been there one time or another? I know I have, though I try not to make a habit of it ;-) I don't think it never happened to me, but I see how this could happen, especially in the first period after the second branch is introduced. Your DVCS should warn you about this though, so, at worst, you'll end up having to merge someone else's commit. After the initial conversion of the code base, the fixes are mostly trivial, so people don't need to write two patches (most of the patches we get for CPython are either against 2.7 or 3.2, and sometimes they even apply clearly to both). Fixes may be trivial, but new features might not always be so. True, but especially if the feature is complicated, I would rather spend a bit more time and have to clean, separate versions than a single version that tries to work on both. Best Regards, Ezio Melotti Regards, 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/archive%40mail-archive.com
Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3
On 18/02/2012 0.04, Nick Coghlan wrote: On Fri, Feb 17, 2012 at 4:29 AM, Ezio Melottiezio.melo...@gmail.com wrote: I'm assuming that eventually the module will be removed (maybe for Python 4?), and I don't expect nor want to seen it removed in the near future. If something gets removed it should be deprecated first, and it's usually better to deprecate it sooner so that the developers have more time to update their code. Not really - as soon as we programmatically deprecate something, it means anyone with a strict warnings policy (or with customers that have such a policy) has to update their code *now*. (Previously it was even worse than that, which is why deprecation warnings are no longer displayed by default). The ones with a strict warning policy should be ready to deal with this situation. A possible solution (that I already proposed a while ago) would be to reuse the 2to3 framework to provide fixers that could be used for these mechanical updates between 3.x releases. For example I wrote a 2to3 fixer to replace all the deprecate unittest methods (fail*, some assert*) with the correct ones, but this can't be used to fix them while moving from 3.1 to 3.2. For things that we have no intention of deprecating in 3.x, but will likely ditch in a hypothetical future Python 4000, we'll almost certainly do exactly what we did with Pyk: later in the 3.x series, add a -4 command line switch and a sys.py4kwarning flag to trigger conditional deprecation warnings. I think Guido mentioned somewhere that this hypothetical Python 4000 will most likely be backward compatible, so we would still need a regular deprecation period. So, assuming things continue as they have for the first couple of decades of Python's existence, we can probably start worrying about it some time around 2020 :) What bothers me most is that a valid mechanism to warn users who cares about things that will be removed is being hindered in several ways. DeprecationWarnings were first silenced (and this is fine as long as the developers are educated to enable warnings while testing), now discouraged (because people are still able to make them visible and also to turn them into errors), and on the tracker there's even a discussion about making the deprecation notes in the doc less visible (because the red boxes are too scary). See also http://mail.python.org/pipermail/python-dev/2011-October/114199.html 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] folding cElementTree behind ElementTree in 3.3
On 14/02/2012 9.58, Stefan Behnel wrote: Nick Coghlan, 14.02.2012 05:44: On Tue, Feb 14, 2012 at 2:25 PM, Eli Bendersky wrote: With the deprecation warning being silent, is there much to lose, though? Yes, it creates problems for anyone that deliberately converts all warnings to errors when running their test suites. This forces them to spend time switching over to a Python version dependent import of either cElementTree or ElementTree that could have been spent doing something actually productive instead of mere busywork. If I'm writing code that imports cElementTree on 3.3+, and I explicitly turn on DeprecationWarnings (that would otherwise be silenced) to check if I'm doing something wrong, I would like Python to tell me You don't need to import that anymore, just use ElementTree.. If I'm also converting all the warnings to errors, it's probably because I really want my code to do the right thing and spending 1 minute to add/change two line of code to fix this won't probably bother me too much. Regular users won't even notice the warning, unless they stumble upon the note in the doc or enable the warnings (and eventually when the module is removed). And, of course, even people that *don't* convert warnings to errors when running tests will have to make the same switch when the module is eventually removed. When the module is eventually removed and you didn't warn them in advance, the situation is going to turn much worse, because their code will suddenly stop working once they upgrade to the newer version. I don't mind keeping the module and the warning around for a few versions and give enough time for everyone to update their imports, but if eventually the module is removed I don't want all these developers to come and say why you removed cElementTree without saying anything and broke all my code?. I'm -1 on emitting a deprecation warning just because cElementTree is being replaced by a bare import. That's an implementation detail, just like cElementTree should have been an implementation detail in the first place. In all currently maintained CPython releases, importing cElementTree is the right thing to do for users. From 3.3 the right thing will be importing ElementTree, and at some point in the future that will be the only way to do it. These days, other Python implementations already provide the cElementTree module as a bare alias for ElementTree.py anyway, without emitting any warnings. Why should CPython be the only one that shouts at users for importing it? I would watch this from the opposite point of view. Why should the other Python implementation have a to keep around a dummy module due to a CPython implementation detail? If we all go through a deprecation process we will eventually be able to get rid of this. Best Regards, Ezio Melotti Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3
On 16/02/2012 19.55, Antoine Pitrou wrote: On Thu, 16 Feb 2012 19:32:24 +0200 Ezio Melottiezio.melo...@gmail.com wrote: If I'm writing code that imports cElementTree on 3.3+, and I explicitly turn on DeprecationWarnings (that would otherwise be silenced) to check if I'm doing something wrong, I would like Python to tell me You don't need to import that anymore, just use ElementTree.. If I'm also converting all the warnings to errors, it's probably because I really want my code to do the right thing and spending 1 minute to add/change two line of code to fix this won't probably bother me too much. But then you're going from a cumbersome situation (where you have to import cElementTree and then fallback on regular ElementTree) to an even more cumbersome one (where you have to first check the Python version, then conditionally import cElementTree, then fallback on regular ElementTree). This is true if you need to support Python =3.2, but on the long run this won't be needed anymore and a plain import ElementTree will be enough. When the module is eventually removed and you didn't warn them in advance, the situation is going to turn much worse, because their code will suddenly stop working once they upgrade to the newer version. Why would we remove the module? It seems supporting it should be mostly trivial (it's an alias). I'm assuming that eventually the module will be removed (maybe for Python 4?), and I don't expect nor want to seen it removed in the near future. If something gets removed it should be deprecated first, and it's usually better to deprecate it sooner so that the developers have more time to update their code. As I proposed on the tracker though, we could even delay the deprecation to 3.4 (by that time they might not need to support 3.2 anymore). I would watch this from the opposite point of view. Why should the other Python implementation have a to keep around a dummy module due to a CPython implementation detail? I don't know, but they already have this module, and it certainly costs them nothing to keep it. There will also be a cost if people keep importing cElementTree and fall back on ElementTree on failure even when this won't be necessary anymore. This also means that more people will have to fix their code if/when the module will be removed if they kept using cElementTree. They can also find cElementTree in old code/tutorial and figure out that it's better to use the C one because is faster and keep doing so because the only warning that would stop them is hidden in the doc. I think the problem with the DeprecationWarnings being too noisy was fixed by silencing them; if they are still too noisy then we need a better mechanism to warn people who care (and going to check the doc every once in a while to see if some new doc warning has been added doesn't strike me as a valid solution). 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] PEP 407: New release cycle and introducing long-term support versions
community would be valuable before making a final decision. [...] 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] order of Misc/ACKS
Hi, On 11/11/2011 10.39, Eli Bendersky wrote: The PS: at the top of Misc/ACKS says: PS: In the standard Python distribution, this file is encoded in UTF-8 and the list is in rough alphabetical order by last names. However, the last 3 names in the list don't appear to be part of that alphabetical order. Is this somehow intentional, or just a mistake? Only the last two are out of place, and should be fixed. The 'Å' in Peter Åstrand sorts after 'Z'. See http://mail.python.org/pipermail/python-dev/2010-August/102961.html for a discussion about the order of Misc/ACKS. Best Regards, Ezio Melotti 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 (2.7): Inline the advisory text on how to use the shelve module.
On 04/11/2011 22.21, Eric V. Smith wrote: On 11/4/2011 4:08 PM, raymond.hettinger wrote: - .. note:: + Like file objects, shelve objects should closed explicitly to assure + that the peristent data is flushed to disk. Missing be there, I think: should be closed. Eric. And on the next line it should be 'persistent'. 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): Add a button to the code examples in the doc to show/hide the prompts and
Hi Éric,
On 31/10/2011 19.19, Éric Araujo wrote:
Hi Ezio,
http://hg.python.org/cpython/rev/18bbfed9aafa
user:Ezio Melottiezio.melo...@gmail.com
summary:
Add a button to the code examples in the doc to show/hide the prompts and
output.
Looks cool! I hope this will stop our use of two or three different
styles for Python code in the docs (doctest-compatible vs.
source-file-style vs. copy-paste-ready) and ultimately help make them
doctest-compatible.
My main concern about this is that it works only with the HTML doc and
now with the pdf/chm, so converting the examples would make the
situation a bit worse for the pdf/chm users (and also for js-less
users). I think in the examples we should just use what make more sense
-- either copy/paste from an interpreter session when the output is
relevant, copy only the source when it's not, and avoid the hybrid
style (i.e. include the '' and the output but omit the '...').
Nonetheless I think most of the users use the HTML doc, so it should be
an improvement for them :)
+$(document).ready(function() {
+/* Add a [] button on the top-right corner of code samples to hide
+ * the and ... prompts and the output and thus make the code
+ * copyable. */
I think it would be more user-friendly if the button/trigger would use
real English text like “Hide prompts”/“Show prompts” rather than symbols.
I thought about that and ended up adding a title= with a more accurate
description, while leaving the button short and unobtrusive. A bigger
button might interfer/overlap with the code if the code contains long
lines and/or if the window is too narrow. I expect that people will
anyway try it out as soon as they notice it and learn quickly what it does.
In a couple of years this whole script could be replaced with a couple
of lines of CSS using the CSS3 user-select property (so that only the
code and not the rest is actually copied), but at the moment the support
for it is still a bit lacking and inconsistent.
Best Regards,
Ezio Melotti
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] [Python-checkins] r88914 - tracker/instances/python-dev/html/issue.item.js
Hi,
On 26/10/2011 12.39, Berker Peksağ wrote:
Hi,
I think this is shorter than $(document).ready();
$(function() {
// ...
});
See:
http://stackoverflow.com/questions/3528509/document-readyfunction-vs-function/3528528#3528528
Thanks a lot for the review, I didn't know about this shortcut!
However I think I'll just leave $(document).ready(...); because, even if
longer, is more explicit and readable.
Best Regards,
Ezio Melotti
--Berker
___
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] Deprecation policy
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@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] r88904 - tracker/instances/python-dev/html/issue.item.js
Hi, On 07/10/2011 10.02, ezio.melotti wrote: Author: ezio.melotti Date: Fri Oct 7 09:02:07 2011 New Revision: 88904 Log: #422: add keyword shortcuts to navigate through the messages and to reply. I added keyboard shortcut to navigate through the messages in the tracker (yes, keyboard, not keyword, that's a typo :). There are two groups of shortcuts available: * mnemonics: f: first message; p: previous message; n: next message; l: last message; r: reply (jumps on the comment field and focuses it); * vim-style: h: left (first message); k: up (previous message); j: down (next message); l: right (last message); i: insert-mode (jumps on the comment field and focuses it); esc: normal-mode (unfocus the field and re-enables the commands); The two groups don't conflict with each other, so all the keys always work. The shortcuts don't require key combinations like ctrl+f/alt+f -- 'f' is enough. The shortcuts are available only in the issue page, and not in the main page with the list of issues. The shortcuts use javascript, so they won't work if js is disabled. The issue is tracked here: http://psf.upfronthosting.co.za/roundup/meta/issue422 If you have any problem/feedback reply either there or here. A few notes about the change: * The 'end' key doesn't jump to the last message anymore. The normal browser behavior (i.e. go to the end of the page) is now restored. Use 'l' (last) to jump to the last message. * The patch conflicts with the browser 'find-as-you-type' if the first letter is a shortcut. If you are using the find-as-you-type, use ctrl+f instead. * f/l *always* jump to the first/last message, regardless of the position of the page. p/n use an index that does *not* change when you scroll, and do nothing on the first/last message respectively. If you are at the second-last message, scroll to the top, and hit 'n', you will still jump to the last message. If you are at the last message, scroll to the top, and hit 'n' the page won't scroll (you can use 'l' instead). * I added the shortcuts to the left sidebar but I plan to move them to the devguide eventually. * It might be useful to add a shortcut to submit. 's' would be a good candidate, but it might be hit accidentally (an are you sure? popup might solve this). ctrl+enter/ctrl+s might be better, but they might conflict with the browser commands. * While replying (i.e. while writing in the comment textarea), the shortcuts are disabled. You can hit ESC to unfocus the textarea and then use them. You can then press 'r' again to continue editing. 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] Hg tips (was Re: [Python-checkins] cpython (merge default - default): Merge heads.)
Tip 1 -- merging heads: A while ago Éric suggested a nice tip to make merges easier and since I haven't seen many people using it and now I got a chance to use it again, I think it might be worth showing it once more: # so assume you just committed some changes: $ hg ci Doc/whatsnew/3.3.rst -m 'Update and reorganize the whatsnew entry for PEP 393.' # you push them, but someone else pushed something in the meanwhile, so the push fails $ hg push pushing to ssh://h...@hg.python.org/cpython searching for changes abort: push creates new remote heads on branch 'default'! (you should pull and merge or use push -f to force) # so you pull the other changes $ hg pull -u pulling from ssh://h...@hg.python.org/cpython searching for changes adding changesets adding manifests adding file changes added 4 changesets with 5 changes to 5 files (+1 heads) not updating, since new heads added (run 'hg heads' to see heads, 'hg merge' to merge) # and use hg heads . to see the two heads (yours and the one you pulled) in the current branch $ hg heads . changeset: 72521:e6a2b54c1d16 tag: tip user:Victor Stinner victor.stin...@haypocalc.com date:Thu Sep 29 04:02:13 2011 +0200 summary: Fix hex_digit_to_int() prototype: expect Py_UCS4, not Py_UNICODE changeset: 72517:ba6ee5cc9ed6 user:Ezio Melotti ezio.melo...@gmail.com date:Thu Sep 29 08:34:36 2011 +0300 summary: Update and reorganize the whatsnew entry for PEP 393. # here comes the tip: before merging you switch to the other head (i.e. the one pushed by Victor), # if you don't switch, you'll be merging Victor changeset and in case of conflicts you will have to review # and modify his code (e.g. put a Misc/NEWS entry in the right section or something more complicated) $ hg up e6a2b54c1d16 6 files updated, 0 files merged, 0 files removed, 0 files unresolved # after the switch you will merge the changeset you just committed, so in case of conflicts # reviewing and merging is much easier because you know the changes already $ hg merge 1 files updated, 0 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) # here everything went fine and there were no conflicts, and in the diff I can see my last changeset $ hg di diff --git a/Doc/whatsnew/3.3.rst b/Doc/whatsnew/3.3.rst [...] # everything looks fine, so I can commit the merge and push $ hg ci -m 'Merge heads.' $ hg push pushing to ssh://h...@hg.python.org/cpython searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 2 changesets with 1 changes to 1 files remote: buildbot: 2 changes sent successfully remote: notified python-check...@python.org of incoming changeset ba6ee5cc9ed6 remote: notified python-check...@python.org of incoming changeset e7672fe3cd35 This tip is not only useful while merging, but it's also useful for python-checkins reviews, because the merge mail has the same diff of the previous mail rather than having 15 unrelated changesets from the last week because the committer didn't pull in a while. Tip 2 -- extended diffs: If you haven't already, enable git diffs, adding to your ~/.hgrc the following two lines: [diff] git = True (this is already in the devguide, even if 'git = on' is used there. The mercurial website uses git = True too.) More info: http://hgtip.com/tips/beginner/2009-10-22-always-use-git-diffs/ Tip 3 -- extensions: I personally like the 'color' extension, it makes the output of commands like 'hg diff' and 'hg stat' more readable (e.g. it shows removed lines in red and added ones in green). If you want to give it a try, add to your ~/.hgrc the following two lines: [extensions] color = If you find operations like pulling, updating or cloning too slow, you might also want to look at the 'progress' extension, which displays a progress bar during these operations: [extensions] progress = Tip 4 -- porting from 2.7 to 3.2: The devguide suggests: hg export a7df1a869e4a | hg import --no-commit - but it's not always necessary to copy the changeset number manually. If you are porting your last commit you can just use 'hg export 2.7' (or any other branch name): * using the one-dir-per-branch setup: wolf@hp:~/dev/py/2.7$ hg ci -m 'Fix some bug.' wolf@hp:~/dev/py/2.7$ cd ../3.2 wolf@hp:~/dev/py/3.2$ hg pull -u ../2.7 wolf@hp:~/dev/py/3.2$ hg export 2.7 | hg import --no-commit - * using the single-dir setup: wolf@hp:~/dev/python$ hg branch 2.7 wolf@hp:~/dev/python$ hg ci -m 'Fix some bug.' wolf@hp:~/dev/python$ hg up 3.2 # here you might enjoy the progress extension wolf@hp:~/dev/python$ hg export 2.7 | hg import --no-commit - And then you can check that everything is fine, and commit on 3.2 too. Of course it works the other way around (from 3.2 to 2.7) too. I hope you'll find these tips useful. Best Regards, Ezio Melotti On Thu, Sep 29, 2011 at 8:36 AM, ezio.melotti python-check...@python.orgwrote: http
Re: [Python-Dev] [Python-checkins] cpython (3.2): Issue #7732: Don't open a directory as a file anymore while importing a
On 23/09/2011 20.11, Éric Araujo wrote: Hi Victor, diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -10,6 +10,10 @@ Core and Builtins - +- Issue #7732: Don't open a directory as a file anymore while importing a + module. Ignore the direcotry if its name matchs the module name (e.g. Typo: direcotry Typo: matchs ___ 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: Issue #1172711: Add 'long long' support to the array module.
On 21/09/2011 21.08, Michael Foord wrote: On 21/09/2011 18:02, Stephen J. Turnbull wrote: Georg Brandl writes: I don't think so. skip if not reads pretty well for me, while I always have to think twice about unless -- may be a non-native- speaker thing. FWIW, speaking as one native speaker, I'm not sure about that. do ... if not condition doesn't bother me, whether I think of the condition as an exception or as the normal state of affairs. I find do ... unless condition to be quite awkward if the condition is a normal state. I'm not a big fan of skipUnless, but there you go. I find skip if not readable too and always have to work out what skipUnless means. It's probably just that if and if not are such Python idioms and unless isn't. I don't find it too readable in other contexts (e.g. failUnless), but I probably got used to skipUnless with the idiom: try: import foo except ImportError: foo = None @skipUnless(foo, 'requires foo') ... FWIW in Lib/test/support.py we have a skip_unless_symlink, but the other two skipUnless have more readable names: requires_zlib and requires_IEEE_754. In Lib/test/ skipUnless is used about 250 times, skipIf about 100. Best Regards, Ezio Melotti Michael ___ 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 #12567: Fix curses.unget_wch() tests
Hi,
On Tue, Sep 6, 2011 at 11:08 AM, victor.stinner
python-check...@python.orgwrote:
http://hg.python.org/cpython/rev/786668a4fb6b
changeset: 72301:786668a4fb6b
user:Victor Stinner vstin...@wyplay.com
date:Tue Sep 06 10:08:28 2011 +0200
summary:
Issue #12567: Fix curses.unget_wch() tests
Skip the test if the function is missing. Use U+0061 (a) instead of U+00E9
(é)
because U+00E9 raises a _curses.error('unget_wch() returned ERR') on some
buildbots. It's maybe because of the locale encoding.
files:
Lib/test/test_curses.py | 6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Lib/test/test_curses.py b/Lib/test/test_curses.py
--- a/Lib/test/test_curses.py
+++ b/Lib/test/test_curses.py
@@ -265,14 +265,16 @@
stdscr.getkey()
def test_unget_wch(stdscr):
-ch = '\xe9'
+if not hasattr(curses, 'unget_wch'):
+return
This should be a skip, not a bare return.
+ch = 'a'
curses.unget_wch(ch)
read = stdscr.get_wch()
read = chr(read)
if read != ch:
raise AssertionError(%r != %r % (read, ch))
Why not just assertEqual?
-ch = ord('\xe9')
+ch = ord('a')
curses.unget_wch(ch)
read = stdscr.get_wch()
if read != ch:
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] Should we move to replace re with regex?
On Sun, Aug 28, 2011 at 7:28 AM, Guido van Rossum gu...@python.org wrote: Are you volunteering? (Even if you don't want to be the only maintainer, it still sounds like you'd be a good co-maintainer of the regex module.) My name is listed in the experts index for 're' [0], and that should make me already co-maintainer for the module. [...] 4) add documentation for the module and the (public) functions in Doc/library (this should be done anyway). Does regex have a significany public C interface? (_sre.c doesn't.) Does it have a Python-level interface beyond what re.py offers (apart from the obvious new flags and new regex syntax/semantics)? I don't think it does. Explaining the new syntax/semantics is useful for developers (e.g.what \p and \X are supposed to match), but also for users, so it's fine to have this documented in Doc/library/re.rst (and I don't think it's necessary to duplicate it in the README/PEP/Wiki). This will ensure that the general quality of the code is good, and when someone actually has to work on the code, there's enough documentation to make it possible. That sounds like a good description of a process that could lead to acceptance of regex as a re replacement. So if we want to get this done I think we need Matthew for 1) (unless someone else wants to do it and have him review the result). If making a diff with the current re is doable and makes sense, we can use the rietveld instance on the bug tracker to make the review for 2). The same could be done with a diff that replaces the whole module though. 3) will follow after 2), and 4) is not difficult and can be done when we actually replace re (it's probably enough to reorganize a bit and convert to rst the page on PyPI). Best Regards, Ezio Melotti [0]: http://docs.python.org/devguide/experts.html#stdlib ___ 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 tjre...@udel.edu 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
Re: [Python-Dev] Should we move to replace re with regex?
On Sat, Aug 27, 2011 at 4:56 AM, Antoine Pitrou solip...@pitrou.net wrote: On Sat, 27 Aug 2011 04:37:21 +0300 Ezio Melotti ezio.melo...@gmail.com wrote: 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), Isn't this precisely what a review is supposed to assess? This can be done without actually knowing and understanding every single function in the module (I got the impression that someone wants this kind of review, correct me if I'm wrong). 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. I'm not sure it's a good idea for a module with more than 1 lines of C code (and 4000 lines of pure Python code). This is several times the size of multiprocessing. The C code looks very cleanly written, but it's still a big chunk of algorithmically sophisticated code. Even unicodeobject.c is 10k+ lines of C code and I got familiar with (parts of) it just by fixing bugs in specific functions. I took a look at the regex code and it seems clear, with enough comments and several small functions that are easy to follow and understand. multiprocessing requires good knowledge of a number of concepts and platform-specific issues that makes it more difficult to understand and maintain (but maybe regex-related concepts seems easier to me because I'm already familiar with them). I think it would be good to: 1) have some document that explains the general design and main (internal) functions of the module (e.g. a PEP); 2) make a review on rietveld (possibly only of the diff with re, to limit the review to the new code only), so that people can ask questions, discuss and understand the code; 3) possibly update the document/PEP with the outcome of the rietveld review(s) and/or address the issues discussed (if any); 4) add documentation for the module and the (public) functions in Doc/library (this should be done anyway). This will ensure that the general quality of the code is good, and when someone actually has to work on the code, there's enough documentation to make it possible. Best Regards, Ezio Melotti Another interesting question is whether it's easy to port to the PEP 393 string representation, if it gets accepted. 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] PEP 393 Summer of Code Project
On Fri, Aug 26, 2011 at 5:59 AM, Guido van Rossum gu...@python.org wrote:
On Thu, Aug 25, 2011 at 7:28 PM, Isaac Morland ijmor...@uwaterloo.ca
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/
Thanks for the links! I also like the term supplemental character (a
code point = 2**16). And I note that they talk about characters were
we've just agreed that we should say code points...
--
--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 Sat, Aug 27, 2011 at 1:57 AM, Guido van Rossum gu...@python.org wrote: On Fri, Aug 26, 2011 at 3:54 PM, Martin v. Löwis mar...@v.loewis.de 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] PEP 393 Summer of Code Project
On Wed, Aug 24, 2011 at 11:37 PM, Terry Reedy tjre...@udel.edu 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 gu...@python.org wrote: On Wed, Aug 24, 2011 at 3:06 AM, Terry Reedy tjre...@udel.edu 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 pointhttp://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] FileSystemError or FilesystemError?
On 24/08/2011 5.31, Nick Coghlan wrote: On Wed, Aug 24, 2011 at 5:19 AM, Steven D'Apranost...@pearwood.info 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] [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 Reedytjre...@udel.edu 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/last cset id on a given branch/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] [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 Araujomer...@netwok.org
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
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] 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 Benderskyeli...@gmail.com
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
