[Python-Dev] Roundup to GitHub Issues migration

2021-06-20 Thread Ezio Melotti
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

2019-07-19 Thread Ezio Melotti
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

2019-06-02 Thread Ezio Melotti
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

2019-05-28 Thread Ezio Melotti
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

2019-05-24 Thread Ezio Melotti
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

2019-05-24 Thread Ezio Melotti
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

2019-05-23 Thread Ezio Melotti
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

2019-05-15 Thread Ezio Melotti
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

2019-03-05 Thread Ezio Melotti
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

2019-02-28 Thread Ezio Melotti
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

2017-09-27 Thread Ezio Melotti
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?

2016-03-11 Thread Ezio Melotti
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

2015-07-18 Thread Ezio Melotti
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

2015-05-11 Thread Ezio Melotti
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

2015-04-21 Thread Ezio Melotti
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

2014-07-07 Thread Ezio Melotti
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

2014-06-23 Thread Ezio Melotti
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

2014-06-23 Thread Ezio Melotti
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

2014-06-20 Thread Ezio Melotti
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

2014-05-15 Thread Ezio Melotti
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.

2014-05-10 Thread Ezio Melotti
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

2014-04-28 Thread Ezio Melotti
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

2014-04-19 Thread Ezio Melotti
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

2014-04-18 Thread Ezio Melotti
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

2014-04-18 Thread Ezio Melotti
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

2014-02-16 Thread 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.)

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

2014-02-16 Thread Ezio Melotti
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

2014-01-25 Thread Ezio Melotti
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

2013-10-09 Thread Ezio Melotti
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

2013-08-22 Thread Ezio Melotti
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

2013-08-22 Thread Ezio Melotti
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

2013-08-22 Thread Ezio Melotti
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)

2013-08-15 Thread Ezio Melotti
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)

2013-08-15 Thread Ezio Melotti
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

2013-08-12 Thread Ezio Melotti
 +
   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

2013-07-18 Thread Ezio Melotti
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

2013-05-30 Thread Ezio Melotti
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

2013-05-04 Thread Ezio Melotti
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

2013-03-28 Thread Ezio Melotti
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

2013-03-19 Thread Ezio Melotti
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.

2013-03-16 Thread Ezio Melotti
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.

2013-03-16 Thread Ezio Melotti
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\

2013-03-13 Thread Ezio Melotti
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\

2013-03-12 Thread Ezio Melotti
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\

2013-03-12 Thread Ezio Melotti
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`.

2013-03-11 Thread Ezio Melotti
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

2013-03-10 Thread Ezio Melotti
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?

2013-03-06 Thread Ezio Melotti
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

2013-03-05 Thread Ezio Melotti
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.

2013-03-01 Thread Ezio Melotti
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

2013-02-22 Thread Ezio Melotti
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

2013-01-23 Thread Ezio Melotti
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

2013-01-23 Thread Ezio Melotti
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

2012-11-30 Thread Ezio Melotti
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.

2012-09-26 Thread Ezio Melotti
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

2012-09-13 Thread Ezio Melotti
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

2012-08-25 Thread Ezio Melotti
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

2012-07-22 Thread Ezio Melotti
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

2012-06-23 Thread Ezio Melotti
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

2012-05-02 Thread Ezio Melotti

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

2012-04-26 Thread Ezio Melotti

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.

2012-04-17 Thread Ezio Melotti
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

2012-03-27 Thread Ezio Melotti
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

2012-03-02 Thread Ezio Melotti

[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

2012-03-02 Thread Ezio Melotti

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

2012-02-28 Thread Ezio Melotti

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

2012-02-28 Thread Ezio Melotti
 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

2012-02-17 Thread Ezio Melotti

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

2012-02-16 Thread Ezio Melotti

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

2012-02-16 Thread Ezio Melotti

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

2012-01-17 Thread Ezio Melotti
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

2011-11-11 Thread Ezio Melotti

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.

2011-11-04 Thread Ezio Melotti

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

2011-10-31 Thread Ezio Melotti

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

2011-10-26 Thread Ezio Melotti

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

2011-10-24 Thread 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
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

2011-10-07 Thread Ezio Melotti

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.)

2011-09-29 Thread Ezio Melotti
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

2011-09-23 Thread Ezio Melotti

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.

2011-09-21 Thread Ezio Melotti

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

2011-09-08 Thread Ezio Melotti
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?

2011-08-29 Thread Ezio Melotti
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?

2011-08-27 Thread Ezio Melotti
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?

2011-08-27 Thread Ezio Melotti
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

2011-08-26 Thread Ezio Melotti
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?

2011-08-26 Thread Ezio Melotti
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

2011-08-25 Thread Ezio Melotti
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

2011-08-25 Thread Ezio Melotti
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?

2011-08-23 Thread Ezio Melotti

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

2011-08-10 Thread Ezio Melotti

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.

2011-07-30 Thread Ezio Melotti

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

2011-07-30 Thread Ezio Melotti
 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

2011-07-27 Thread Ezio Melotti

  
  
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

2011-07-27 Thread Ezio Melotti

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


Re: [Python-Dev] [Python-checkins] r88867 - in tracker/instances/python-dev: extensions/pydevutils.py html/file.item.html html/issue.item.html html/msg.item.html

2011-07-23 Thread Ezio Melotti

On 23/07/2011 9.55, Nick Coghlan wrote:

On Sat, Jul 23, 2011 at 8:34 AM, ezio.melotti
python-check...@python.org  wrote:

Author: ezio.melotti
Date: Sat Jul 23 00:34:53 2011
New Revision: 88867

Log:
#267: remove the remove button from the issue page, move it to the msg/file 
page, and add a button to add back removed messages/files.

Thank you! (I accidentally deleted one of RDM's comments just the other day)


You are welcome! (That was actually one of the reasons that made me look 
at that issue again)


Now restoring messages and files that got deleted should be trivial, and 
deleting them accidentally (almost) impossible.
Messages and files can be deleted/restored from their pages.  Links to 
these pages can be found in the history of the issue.  For messages and 
files that are still linked to the issue, the (view) and edit links 
can also be used.


Best Regards,
Ezio Melotti



Cheers,
Nick.



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [Python-checkins] cpython (merge 3.2 - default): Merge with 3.2.

2011-07-14 Thread Ezio Melotti

  
  
Hi,

On 14/07/2011 15.57, ezio.melotti wrote:

  http://hg.python.org/cpython/rev/ac1c3291a689
changeset:   71325:ac1c3291a689
parent:  71321:f45823977d4b
parent:  71324:530ba6c7e578
user:Ezio Melotti ezio.melo...@gmail.com
date:Thu Jul 14 15:57:12 2011 +0300
summary:
  Merge with 3.2.

files:
  Lib/test/test_cgi.py |  8 +++-
  1 files changed, 7 insertions(+), 1 deletions(-)


diff --git a/Lib/test/test_cgi.py b/Lib/test/test_cgi.py
--- a/Lib/test/test_cgi.py
+++ b/Lib/test/test_cgi.py
@@ -155,7 +155,13 @@
 cgi.logfp = None
 cgi.logfile = "/dev/null"
 cgi.initlog("%s", "Testing log 3")
-self.addCleanup(cgi.logfp.close)
+def log_cleanup():
+"""Restore the global state of the log vars."""
+cgi.logfile = ''
+cgi.logfp.close()
+cgi.logfp = None
+cgi.log = cgi.initlog


It was suggested (on #python-dev) to move this function to the cgi
module itself, but since I'm not familiar with it I just added it
here in order to fix a failure in the test.

The cgi module has two global vars (logfile and logfp) and a global
function (log) that is initialized to initlog and then reassigned to
either dolog or nolog (a dummy function that does nothing) in
initlog itself[0].

If someone thinks the log_cleanup function should be moved to the
cgi.py module and/or the code be refactored a bit, he can do it or
open an issue.

[0]: http://hg.python.org/cpython/file/ac1c3291a689/Lib/cgi.py#l50

Best Regards,
Ezio Melotti


  
+self.addCleanup(log_cleanup)
 cgi.log("Testing log 4")
 
 def test_fieldstorage_readline(self):


  
  
  
  ___
Python-checkins mailing list
python-check...@python.org
http://mail.python.org/mailman/listinfo/python-checkins



  

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [Python-checkins] cpython (2.7): Fixup repr for dict_proxy objects.

2011-06-29 Thread Ezio Melotti
Hi,

On Thu, Jun 30, 2011 at 2:51 AM, raymond.hettinger 
python-check...@python.org wrote:

 http://hg.python.org/cpython/rev/9a0b6c07b488
 changeset:   71086:9a0b6c07b488
 branch:  2.7
 parent:  71055:cdfcd00873cd
 user:Raymond Hettinger pyt...@rcn.com
 date:Thu Jun 30 00:44:36 2011 +0100
 summary:
  Fixup repr for dict_proxy objects.



This was already fixed in a slightly different way in 3.x.  Unless there's a
valid reason to have two different implementations of dict_proxy.__repr__ in
2.x and 3.x, I would suggest to pick the best one and use it on all the
branches.
See also http://bugs.python.org/issue5587

Best Regards,
Ezio Melotti
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [Python-checkins] cpython: test.support: add requires_mac_ver() function

2011-06-01 Thread Ezio Melotti

Hi,

On 01/06/2011 13.28, victor.stinner wrote:

http://hg.python.org/cpython/rev/35212b113730
changeset:   70574:35212b113730
user:Victor Stinnervictor.stin...@haypocalc.com
date:Wed Jun 01 12:28:04 2011 +0200
summary:
   test.support: add requires_mac_ver() function


I would expect this to be a decorator, similar to requires_IEEE_754 and 
requires_zlib.



Add also linux_version() to __all__.


For consistency, this should be a decorator too, possibly named 
requires_linux_ver().
A requires_windows(_ver) sounds like a useful addition too, given the 
number of tests that are specific to Windows.



files:
   Lib/test/support.py   |  22 +-
   Lib/test/test_math.py |   7 ---
   2 files changed, 25 insertions(+), 4 deletions(-)


diff --git a/Lib/test/support.py b/Lib/test/support.py
--- a/Lib/test/support.py
+++ b/Lib/test/support.py
@@ -37,7 +37,8 @@
  Error, TestFailed, ResourceDenied, import_module,
  verbose, use_resources, max_memuse, record_original_stdout,
  get_original_stdout, unload, unlink, rmtree, forget,
-is_resource_enabled, requires, find_unused_port, bind_port,
+is_resource_enabled, requires, linux_version, requires_mac_ver,
+find_unused_port, bind_port,
  IPV6_ENABLED, is_jython, TESTFN, HOST, SAVEDCWD, temp_cwd,
  findfile, sortdict, check_syntax_error, open_urlresource,
  check_warnings, CleanImport, EnvironmentVarGuard, 
TransientResource,
@@ -299,6 +300,25 @@
  except ValueError:
  return 0, 0, 0

+def requires_mac_ver(*min_version):
+Raise SkipTest if the OS is Mac OS X and the OS X version if less than
+min_version.
+
+For example, support.requires_linux_version(10, 5) raises SkipTest if the


This should be requires_mac_ver


+version is less than 10.5.
+
+if sys.platform != 'darwin':
+return
+version_txt = platform.mac_ver()[0]
+try:
+version = tuple(map(int, version_txt.split('.')))
+except ValueError:
+return
+if version  min_version:
+min_version_txt = '.'.join(map(str, min_version))
+raise unittest.SkipTest(Mac OS X %s or higher required, not %s
+% (min_version_txt, version_txt))
+
  HOST = 'localhost'

  def find_unused_port(family=socket.AF_INET, socktype=socket.SOCK_STREAM):
diff --git a/Lib/test/test_math.py b/Lib/test/test_math.py
--- a/Lib/test/test_math.py
+++ b/Lib/test/test_math.py
@@ -2,6 +2,7 @@
  #  Should not do tests around zero only

  from test.support import run_unittest, verbose, requires_IEEE_754
+from test import support
  import unittest
  import math
  import os
@@ -669,10 +670,10 @@
  self.assertTrue(math.isnan(math.log2(NAN)))

  @requires_IEEE_754
-@unittest.skipIf(sys.platform == 'darwin'
- and platform.mac_ver()[0].startswith('10.4.'),
- 'Mac OS X Tiger log2() is not accurate enough')
  def testLog2Exact(self):
+# log2() is not accurate enough on Mac OS X Tiger (10.4)
+support.requires_mac_ver(10, 5)
+
  # Check that we get exact equality for log2 of powers of 2.
  actual = [math.log2(math.ldexp(1.0, n)) for n in range(-1074, 1024)]
  expected = [float(n) for n in range(-1074, 1024)]



Best Regards,
Ezio Melotti
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Issue Tracker

2011-04-26 Thread Ezio Melotti

On 26/04/2011 22.32, Ethan Furman wrote:
Okay, I finally found a little time and got roundup installed and 
operating.


Only major complaint at this point is that the issue messages are 
presented in top-post format (argh).


Does anyone know off the top of one's head what to change to put 
roundup in bottom-post (chronological) format?


TIA!

~Ethan~


See line 309 of 
http://svn.python.org/view/tracker/instances/python-dev/html/issue.item.html?view=markup
If you have other questions about Roundup see 
https://lists.sourceforge.net/lists/listinfo/roundup-users


Best Regards,
Ezio Melotti
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] devguide: Add a table of contents to the FAQ.

2011-03-31 Thread Ezio Melotti

On 30/03/2011 23.20, Antoine Pitrou wrote:

On Tue, 29 Mar 2011 21:00:22 +0200
ezio.melottipython-check...@python.org  wrote:

http://hg.python.org/devguide/rev/f722956afeac
changeset:   405:f722956afeac
user:Ezio Melotti
date:Tue Mar 29 22:00:13 2011 +0300
summary:
   Add a table of contents to the FAQ.

Could it be collapsed by default?


I don't think there's an easy way to collapse it by default.
In most of the cases I anyway check the FAQ for something specific.  
Having a list at the top provides an overview of the questions and also 
an easy way to locate and jump to the right answer.



  It's quite long, and redundant with the sidebar.


The list is indeed redundant, but the sidebar is not really usable here.

Best Regards,
Ezio Melotti


thanks

Antoine.



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


  1   2   >