Re: [Python-Dev] Cut/Copy/Paste items in IDLE right click context menu

2012-11-03 Thread Nick Coghlan 
On Sat, Nov 3, 2012 at 1:10 PM, Terry Reedy  wrote:
> [snip reasons]
> OK, I am convinced an info PEP would be a good idea.

Unless anyone objects, I'm happy to be BDFL-delegate for such a PEP. I
mainly want to ensure we clearly fence off "IDLE-the-application",
with (in effect) a 6 month release cycle synchronised across versions,
from the rest of the standard library.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
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): Issue #15814: Use hash function that is compatible with the equality

2012-11-03 Thread Nick Coghlan 
On Sat, Nov 3, 2012 at 3:07 AM, stefan.krah  wrote:
> +# equality-hash invariant
> +x = ndarray(list(range(12)), shape=[12], format='B')
> +a = memoryview(nd)
> +
> +y = ndarray(list(range(12)), shape=[12], format='b')
> +b = memoryview(nd)
> +
> +z = ndarray(list(bytes(chr(x), 'latin-1') for x in range(12)),
> +shape=[12], format='c')
> +c = memoryview(nd)
> +
> +if (a == b):
> +self.assertEqual(hash(a), hash(b))
> +
> +if (a == c):
> +self.assertEqual(hash(a), hash(c))
> +
> +if (b == c):
> +self.assertEqual(hash(b), hash(c))

These checks could do with a comment explaining why the if statements
are needed (I'm assuming something to do with memory order).

Cheers,
Nick.


-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
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): Issue #15814: Use hash function that is compatible with the equality

2012-11-03 Thread Stefan Krah 
Nick Coghlan  wrote:
> > +if (b == c):
> > +self.assertEqual(hash(b), hash(c))
> 
> These checks could do with a comment explaining why the if statements
> are needed (I'm assuming something to do with memory order).

The checks aren't needed; they were supposed to spell out the equality-hash
relationship. But that isn't obvious, so I'll add a comment or remove them.


Stefan Krah


___
Python-Dev mailing list
[email protected]
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): Issue #15814: Use hash function that is compatible with the equality

2012-11-03 Thread Antoine Pitrou 
On Sat, 3 Nov 2012 10:59:23 +0100
Stefan Krah  wrote:
> Nick Coghlan  wrote:
> > > +if (b == c):
> > > +self.assertEqual(hash(b), hash(c))
> > 
> > These checks could do with a comment explaining why the if statements
> > are needed (I'm assuming something to do with memory order).
> 
> The checks aren't needed; they were supposed to spell out the equality-hash
> relationship.

Better use assertEqual(), then.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
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 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-11-03 Thread Maciej Fijalkowski 
On Fri, Nov 2, 2012 at 8:42 PM, Brett Cannon  wrote:
> Issue filed for the performance issue: http://bugs.python.org/issue16390
>
> With that change and running on tip of Mako on my laptop now reports 1.25x
> slower which is much better than it was. This performance issue might also
> explain why all of the regex compilation benchmarks are worse under Python
> 3.3 by a decent margin.
>
> On Fri, Nov 2, 2012 at 2:16 PM, Philip Jenvey  wrote:
>>
>> lru_cache on re._compile_typed

I would like to warn you about modifying benchmarks like this (or
frameworks). Why is it relevant anyway?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using Wiki for Python development coordination

2012-11-03 Thread Paul Boddie 
On Saturday 03 November 2012 12:29:57 anatoly techtonik wrote:
> I don't have access to modify the front page.
> http://wiki.python.org/moin/FrontPage

Yes, access was restricted a while ago because of spamming.

> To me it lacks one more section concerning help with core development
> infrastructure.
>
> Python Core Development
>
> Python Website 
>
>
> The entrypoint for everything concerning the language
>
>
> Bug Tracker 
>
>
> Roundup and code review services we use
>
>
> Package Index 
>
>
> Some building blocks for your own projects (including frameworks for
> database, GUI, Web programming)

I'll admit that the current content is just a reformatted version of what was 
there before, but tidied up and making better use of vertical space, and it 
could be improved. Certainly, there isn't a core development section, so 
perhaps I'll just add what you suggest. I know how you dislike the Moin 
markup, Anatoly. ;-)

Paul
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using Wiki for Python development coordination

2012-11-03 Thread anatoly techtonik 
On Sat, Nov 3, 2012 at 5:54 PM, Paul Boddie  wrote:
>
>
> I'll admit that the current content is just a reformatted version of what was
> there before, but tidied up and making better use of vertical space, and it
> could be improved. Certainly, there isn't a core development section, so
> perhaps I'll just add what you suggest.

Thanks! That brings visibility of that rather critical section up to the highest
point possible. =)

> I know how you dislike the Moin
> markup, Anatoly. ;-)

Yes, I even think about further enhancing "Using this Wiki" part to
erase references to Moin help pages. They are a little bit misleading
to me and if somebody needs help on Moin - there is a side menu. I'd
like to change it from:


Feel free to add more useful stuff (see HelpContents and HelpOnEditing
to learn how), but do us a favour and do tests in the WikiSandBox if
you're not accustomed to Wiki technologies. If you're new to Wikis,
please read WikiWikiWeb.

 See WikiGuidelines for details of the policies and rules governing this Wiki.

 See SiteImprovements for a discussion of improvements to this Wiki
and other related sites.

 See RecentChanges for a history, available in RSS format. To see
pages which need writing, take a look at DesiredPages.

To report problems or to help out, please contact the python.org maintainers.


to


This Wiki is community place to gather and organize all things about
Python. Feel free to exercise your editorial skills and expertise to
improve it into a useful knowledge base and up-to-date reference on
different matters.

There are some WikiGuidelines if you feel lost. SiteImprovements
contains TODO list with various tasks you can help with. Check
RecentChanges frequently to read the news (also available in RSS).

In case of emergency please contact the python.org maintainers, or pop
up in pydotorg-www to say "help".

___
Python-Dev mailing list
[email protected]
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 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

2012-11-03 Thread Brett Cannon 
I'm not modifying any benchmark or framework. At best I will replace Mako
0.7.2 with Mako 0.7.3 in the benchmark suite since no one is historically
recording the mako_v2 benchmark yet and it should be running with the
newest version until we set it in stone.


On Sat, Nov 3, 2012 at 10:48 AM, Maciej Fijalkowski wrote:

> On Fri, Nov 2, 2012 at 8:42 PM, Brett Cannon  wrote:
> > Issue filed for the performance issue: http://bugs.python.org/issue16390
> >
> > With that change and running on tip of Mako on my laptop now reports
> 1.25x
> > slower which is much better than it was. This performance issue might
> also
> > explain why all of the regex compilation benchmarks are worse under
> Python
> > 3.3 by a decent margin.
> >
> > On Fri, Nov 2, 2012 at 2:16 PM, Philip Jenvey 
> wrote:
> >>
> >> lru_cache on re._compile_typed
>
> I would like to warn you about modifying benchmarks like this (or
> frameworks). Why is it relevant anyway?
>
___
Python-Dev mailing list
[email protected]
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 #16218: skip test if filesystem doesn't support required encoding

2012-11-03 Thread Antoine Pitrou 
On Sat,  3 Nov 2012 13:37:48 +0100 (CET)
andrew.svetlov  wrote:
> http://hg.python.org/cpython/rev/95d1adf144ee
> changeset:   80187:95d1adf144ee
> user:Andrew Svetlov 
> date:Sat Nov 03 14:37:37 2012 +0200
> summary:
>   Issue #16218: skip test if filesystem doesn't support required encoding
> 
> files:
>   Lib/test/test_cmd_line_script.py |  7 ++-
>   1 files changed, 6 insertions(+), 1 deletions(-)
> 
> 
> diff --git a/Lib/test/test_cmd_line_script.py 
> b/Lib/test/test_cmd_line_script.py
> --- a/Lib/test/test_cmd_line_script.py
> +++ b/Lib/test/test_cmd_line_script.py
> @@ -366,7 +366,12 @@
>  def test_non_utf8(self):
>  # Issue #16218
>  with temp_dir() as script_dir:
> -script_basename = '\udcf1\udcea\udcf0\udce8\udcef\udcf2'
> +script_basename = '\u0441\u043a\u0440\u0438\u043f\u0442'

Why exactly did you change the tested name here?

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
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: Revert PEP 430 to Final.

2012-11-03 Thread Chris Jerdonek 
On Sun, Oct 28, 2012 at 5:07 AM, nick.coghlan
 wrote:
>
> http://hg.python.org/peps/rev/1ccf682bdfc9
> changeset:   4575:1ccf682bdfc9
> user:Nick Coghlan 
> date:Sun Oct 28 22:06:46 2012 +1000
> summary:
>   Revert PEP 430 to Final.
> ...
> -To help ensure future stability even of links to the in-development version,
> -the ``/dev/`` subpath will be redirected to the appropriate version specific
> -subpath (currently ``/3.4/``).
> ...
>  * ``http://docs.python.org/x/*``
>  * ``http://docs.python.org/x.y/*``
> +* ``http://docs.python.org/dev/*``
>  * ``http://docs.python.org/release/x.y.z/*``
>  * ``http://docs.python.org/devguide``
> ...
> +The ``/dev/`` URL means the documentation for the default branch in source
> +control.

I noticed on an older issue in the tracker that the following deep,
in-development link is broken:

http://docs.python.org/dev/2.6/library/multiprocessing.html

(in comment http://bugs.python.org/issue4711#msg78151 )

Can something be done to preserve those deep links, or is it not worth
worrying about?  I'm not sure how prevalent such links are or when
they were valid (and when they stopped working, assuming they once
did).

--Chris
___
Python-Dev mailing list
[email protected]
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: Revert PEP 430 to Final.

2012-11-03 Thread Chris Jerdonek 
On Sat, Nov 3, 2012 at 11:18 AM, Terry Reedy  wrote:
>
> On 11/3/2012 1:36 PM, Chris Jerdonek wrote:
>>
>> I noticed on an older issue in the tracker that the following deep,
>> in-development link is broken:
>>
>> http://docs.python.org/dev/2.6/library/multiprocessing.html
>>
>> (in comment http://bugs.python.org/issue4711#msg78151 )
>>
>> Can something be done to preserve those deep links, or is it not worth
>> worrying about?  I'm not sure how prevalent such links are or when
>> they were valid (and when they stopped working, assuming they once
>> did).
>
>
> I'd say not bother. The message was posted 2008-12-11 and the link was
> already obsolete when Ezio answered 2009-07-01, when he gave a permanent
> one. Fortunately, the OP gave a .png screenshot showing the problem.
>
> Any doc link in the tracker becomes obsolete in a sense as soon as the
> problem noted is fixed. So tracker messages should state the problem
> independently of the link. (After the docs are rebuilt tonight,
> http://docs.python.org/library/multiprocessing.html
> will no longer exhibit the problem either ;-).

Though this link will still exhibit it (which may be what it would redirect to):

http://docs.python.org/2.6/library/multiprocessing.html

So a doc link in the tracker won't become obsolete if we wait long
enough to fix the issue. :)

--Chris
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com