Re: [Python-Dev] A new warning category?

[Stephen J. Turnbull]

Brett Cannon writes:

 > As one of the co-authors of the PEP I say no.

Procedural question: Doesn't authorship disqualify you from BDF1P, so
you can't pronounce?

(Benevolent Dictator for One PEP)

___
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 10094

[Victor Stinner]

Le jeudi 14 octobre 2010 19:58:22, Barry Warsaw a écrit :
> On Oct 14, 2010, at 07:38 PM, Antoine Pitrou wrote:
> >There doesn't seem to be anything really mysterious, actually. The
> >exception message says it all :)
> 
> Yep.  Looks like Ubuntu 10.10 added UBUNTU_MENUPROXY to the default
> environment and that's what's killing it.  I'll bet those Ubuntu buildbots
> are not running Maverick.

Why does urllib test unset this variable? Is it related to an HTTP proxy?

-- 
Victor Stinner
http://www.haypocalc.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] Issue 10094

[Senthil Kumaran]

On Fri, Oct 15, 2010 at 11:19:44AM +0200, Victor Stinner wrote:

> Why does urllib test unset this variable? Is it related to an HTTP proxy?

It does that *temporarily* using EnvironVarGuard to see if the PROXY
related environment variables are correctly retrieved by a method.


-- 
Senthil

Drawing on my fine command of language, I said nothing.
___
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] A new warning category?

[Michael Foord]

 On 15/10/2010 08:22, Stephen J. Turnbull wrote:

Brett Cannon writes:

  >  As one of the co-authors of the PEP I say no.

Procedural question: Doesn't authorship disqualify you from BDF1P, so
you can't pronounce?
I think Brett meant co-authorship of the *moratorium* PEP (which is 
already accepted).


At least that was how I read what Brett wrote.

All the best,

Michael


(Benevolent Dictator for One PEP)

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



--

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.

___
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] A new warning category?

[Nick Coghlan]

On Fri, Oct 15, 2010 at 7:44 PM, Michael Foord
 wrote:
>  On 15/10/2010 08:22, Stephen J. Turnbull wrote:
>>
>> Brett Cannon writes:
>>
>>  >  As one of the co-authors of the PEP I say no.
>>
>> Procedural question: Doesn't authorship disqualify you from BDF1P, so
>> you can't pronounce?
>
> I think Brett meant co-authorship of the *moratorium* PEP (which is already
> accepted).

That's the way I took it as well.

The other factor here is that the moratorium was largely to help other
implementations get back up to speed with CPython as they dealt with
the transition to 3.x. Adding a new warning type isn't the kind of
moving target that something like PEP 380 would be.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Stable build slaves authority

[Georg Brandl]

Am 14.10.2010 18:55, schrieb Antoine Pitrou:
> On Thu, 14 Oct 2010 08:07:46 +0200
> Georg Brandl  wrote:
>> 
>> Very nice.  http://www.python.org/dev/buildbot/stable/ is completely
>> green at the moment -- which means that I can now indeed take failures
>> seriously in the future.  Previously, two of four "stables" for py3k
>> were not even connected for ages (and yes, I should have complained
>> earlier.  As we progress into the beta stage, I will take buildbot
>> failures and release blockers more seriously).
> 
> For the record, I've setup one of the stable buildbots ("AMD64 Gentoo
> Wide") to test wide unicode buils.
> Also, one of the unstable buildbots ("x86 debian parallel") now runs
> its tests with -OO, at Georg's request.

Excellent, thanks!

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2010-10-08 - 2010-10-15)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues stats:
  open2554 (+34)
  closed 19344 (+63)
  total  21898 (+65)

Open issues with patches: 1065 


Issues opened (34)
==

#7140: imp.new_module does not function correctly if the module is re
http://bugs.python.org/issue7140  reopened by benjamin.peterson

#10052: Python/dtoa.c:158: #error "Failed to find an exact-width 32-bi
http://bugs.python.org/issue10052  opened by akitada

#10053: Don’t close fd when FileIO.__init__ fails
http://bugs.python.org/issue10053  opened by ocean-city

#10058: Unclear PyString_AsStringAndSize return value
http://bugs.python.org/issue10058  opened by Nikratio

#10060: python.exe crashes or hangs on help() modules when bad modules
http://bugs.python.org/issue10060  opened by devplayer

#10064: link to page with documentation bugs
http://bugs.python.org/issue10064  opened by techtonik

#10066: xmlrpclib does not handle some non-printable characters proper
http://bugs.python.org/issue10066  opened by gyorkop

#10070: 2to3 wishes for already-2to3'ed files
http://bugs.python.org/issue10070  opened by hfuru

#10071: Should not release GIL while running RegEnumValue
http://bugs.python.org/issue10071  opened by ocean-city

#10072: ftplib documentation is unclear
http://bugs.python.org/issue10072  opened by rafe.kettler

#10073: calendar.isleap() not checking parameter type
http://bugs.python.org/issue10073  opened by shadikka

#10076: Regex objects became uncopyable in 2.5
http://bugs.python.org/issue10076  opened by Michael.Shields

#10077: Python 3.1: site error is not logged
http://bugs.python.org/issue10077  opened by haypo

#10079: idlelib for Python 3 with Guilherme Polo GSoC enhancements
http://bugs.python.org/issue10079  opened by Bruce.Sherwood

#10080: Py_Initialize crashes when stdout has been redirected with fre
http://bugs.python.org/issue10080  opened by Mitchell.Stokes

#10084: SSL support for asyncore
http://bugs.python.org/issue10084  opened by pitrou

#10086: test_sysconfig failure with site-packages
http://bugs.python.org/issue10086  opened by hfuru

#10087: HTML calendar is broken
http://bugs.python.org/issue10087  opened by belopolsky

#10089: Add support for arbitrary -X options
http://bugs.python.org/issue10089  opened by pitrou

#10090: python -m locale fails on OSX
http://bugs.python.org/issue10090  opened by belopolsky

#10092: calendar does not restore locale properly
http://bugs.python.org/issue10092  opened by belopolsky

#10093: Warn when files are not explicitly closed
http://bugs.python.org/issue10093  opened by pitrou

#10094: test_urllib.py fails in py3k r85440 with RuntimeError
http://bugs.python.org/issue10094  opened by barry

#10098: intermittent failure in test_os
http://bugs.python.org/issue10098  opened by pitrou

#10104: test_socket failures on Debian unstable
http://bugs.python.org/issue10104  opened by pitrou

#10107: Quitting IDLE on Mac doesn't save unsaved code
http://bugs.python.org/issue10107  opened by Bruce.Sherwood

#10108: ExpatError not property wrapped
http://bugs.python.org/issue10108  opened by leos

#10109: itertools.product with infinite iterator cause MemoryError.
http://bugs.python.org/issue10109  opened by falsetru

#10110: Queue doesn't recognize it is full after shrinking maxsize
http://bugs.python.org/issue10110  opened by jaraco

#10111: Minor problems with PyFileObject documentation (Doc/c-api/file
http://bugs.python.org/issue10111  opened by pebolle

#10112: Use -Wl,--dynamic-list=x.list, not -Xlinker -export-dynamic
http://bugs.python.org/issue10112  opened by jankratochvil

#10114: compile() doesn't support the PEP 383 (surrogates)
http://bugs.python.org/issue10114  opened by haypo

#10115: accept4 can fail with errno 90
http://bugs.python.org/issue10115  opened by pitrou

#10116: Sporadic failures in test_urllibnet
http://bugs.python.org/issue10116  opened by ixokai



Most recent 15 issues with no replies (15)
==

#10114: compile() doesn't support the PEP 383 (surrogates)
http://bugs.python.org/issue10114

#10112: Use -Wl,--dynamic-list=x.list, not -Xlinker -export-dynamic
http://bugs.python.org/issue10112

#10111: Minor problems with PyFileObject documentation (Doc/c-api/file
http://bugs.python.org/issue10111

#10110: Queue doesn't recognize it is full after shrinking maxsize
http://bugs.python.org/issue10110

#10109: itertools.product with infinite iterator cause MemoryError.
http://bugs.python.org/issue10109

#10092: calendar does not restore locale properly
http://bugs.python.org/issue10092

#10090: python -m locale fails on OSX
http://bugs.python.org/issue10090

#10077: Python 3.1: site error is not logged
http://bugs.python.org/issue10077

#10064: link to page with documentation bugs
http://bugs.python.org/issue10064

#10058: Unclear PyString_AsSt

Re: [Python-Dev] Buildbot for AIX

[Sébastien Sablé]

Hi Martin,

I finally got the authorization to run some buildbot slaves on our AIX 
servers.


I made some tests with a buildbot script as close as possible to what 
you already use. Here is a patch that show the kind of modifications I 
had to do in order to get the buildbot slave to correctly run on AIX.


It is also necessary to apply the patch provided in issue 9862 so that 
the tests won't hang forever.


It also would help if the corrections provided in the following issues 
could be commited: 4499, 678250, 730467.


Could you please take a look at those modifications in master.cfg, 
provide me some password for the bot slaves and apply the corrections in 
those issues?


Once this is done, I can run 2 buildbot slaves for AIX 6.1 and AIX 5.3 
with build plans for gcc and xlc.


I can't guarantee that those bots will run forever, and I may have to 
ask to schedule them only at night if the activity it generates on the 
server appears to be too high.
But I think it could greatly help to improve the state of Python on AIX 
(which is far from perfect at the moment).


regards

--
Sébastien Sablé



Le 20/09/2010 21:21, "Martin v. Löwis" a écrit :

Also could you provide me the master.cfg file (with obfuscated
passwords) that is used by the Python buildbot master or tell me if it
is in subversion somewhere?


Attached!

Regards,
Martin


--- master.cfg.orig	2010-10-15 15:38:47.0 +0200
+++ master.cfg.new	2010-10-15 16:58:54.0 +0200
@@ -27,7 +27,8 @@
 # tuple of bot-name and bot-password. These correspond to values given to the
 # buildslave's mktap invocation.
 c['slaves'] = [
-XXX
+BuildSlave("sable-aix61", "bot1passwd", max_builds=1),
+BuildSlave("sable-aix53", "bot2passwd", max_builds=1),
 ]
 
 
@@ -80,6 +81,7 @@
 
 class UnixBuild(factory.GNUAutoconf):
 configureFlags = ["--with-pydebug", "--with-computed-gotos"]
+configureEnv = {}
 def __init__(self, source, parallel):
 compile = ['make', 'all']
 test = ["make", "buildbottest"]
@@ -88,6 +90,7 @@
 test = ["make", "buildbottest", "TESTOPTS="+parallel]
 factory.GNUAutoconf.__init__(self, source,
  configureFlags = self.configureFlags,
+ configureEnv = self.configureEnv,
  compile=compile,
  test = None)
 # XXX(nnorwitz): reduced timeout, no test should take longer than 10m
@@ -99,6 +102,21 @@
 class WideUnixBuild(UnixBuild):
 configureFlags = ["--with-pydebug", "--with-computed-gotos", "--with-wide-unicode"]
 
+class Aix5GccUnixBuild(UnixBuild):
+configureFlags = ["--with-pydebug", "--with-computed-gotos", "--disable-ipv6", "--with-gcc"]
+
+class Aix5XlcUnixBuild(UnixBuild):
+configureFlags = ["--with-pydebug", "--without-computed-gotos", "--disable-ipv6"]
+configureEnv = {'CC': 'xlc', 'OPT': "-O2 -qmaxmem=18000"}
+
+class Aix6GccUnixBuild(UnixBuild):
+configureFlags = ["--with-pydebug", "--with-computed-gotos", "--with-gcc"]
+configureEnv = {'CC': 'gcc'}
+
+class Aix6XlcUnixBuild(UnixBuild):
+configureFlags = ["--with-pydebug", "--without-computed-gotos"]
+configureEnv = {'CC': 'xlc', 'OPT': "-O2 -qmaxmem=18000"}
+
 class CygwinBuild(UnixBuild):
 def __init__(self, source, parallel):
 UnixBuild.__init__(self, source)
@@ -175,35 +193,39 @@
 STABLE=".stable"
 UNSTABLE=".unstable"
 
-builders = [("sparc solaris10 gcc", "loewis-sun", UnixBuild,STABLE),
-("amd64 gentoo", "norwitz-amd64", UnixBuild,STABLE),
-("x86 gentoo", "norwitz-x86", UnixBuild,UNSTABLE),
-#("g4 osx.4", "psf-g4", UnixBuild,STABLE),
-#("alpha Tru64 5.1", "norwitz-tru64", UnixBuild,UNSTABLE),
-("i386 Ubuntu", "klose-ubuntu-i386", UnixBuild,UNSTABLE),
-("ia64 Ubuntu", "klose-debian-ia64", UnixBuild,STABLE),
-("sparc Debian", "klose-debian-sparc", UnixBuild,STABLE),
-("alpha Debian", "klose-debian-alpha", UnixBuild,UNSTABLE),
-#("MIPS Debian", "klose-debian-mips", UnixBuild,UNSTABLE),
-#("PPC64 Debian", "klose-debian-ppc64", UnixBuild,UNSTABLE),
-#("S-390 Debian", "klose-debian-s390", UnixBuild,UNSTABLE),
-#("x86 mvlgcc", "loewis-linux", UnixBuild,UNSTABLE),
-("x86 XP-4", "bolen-windows", WindowsBuild,STABLE),
-("x86 FreeBSD", "bolen-freebsd", UnixBuild,UNSTABLE),
-("x86 Windows7", "bolen-windows7", WindowsBuild,UNSTABLE),
-("x86 FreeBSD 7.2", "bolen-freebsd7", UnixBuild,UNSTABLE),
-("x86 Ubuntu", "bolen-ubuntu", UnixBuild,UNSTABLE),
-	("ARMv7Thumb Ubuntu", "klose-linux-arm", UnixBuild,UNSTABLE),
-	("ARMv4 Debian", "klose-linux-armeabi", UnixBuild,UNSTABLE),
-	#("x86 FreeBSD 2", "werven-freebsd", UnixBuild,UNSTABLE),
-#("x86 Gentoo", "murray-gentoo", UnixBuild, UNSTABLE),
-#("x86 Gentoo wide", 

Re: [Python-Dev] Buildbot for AIX

[Sridhar Ratnakumar]

On 2010-09-20, at 7:41 AM, Sébastien Sablé wrote:

> Le 17/09/2010 15:05, Antoine Pitrou a écrit :
>> Following on Martin's comments, you might also want to share things
>> with the ActiveState guys who, AFAIK, maintain an AIX version of Python
>> (but you have been the most active AIX user on the bug tracker lately;
>> perhaps they are keeping their patches to themselves).
> 
> I tried to find some source package or subversion repository on their web 
> site, but they only distribute binary versions.
> Also it is only the "Business Edition" that supports AIX and it is clearly 
> sold with a proprietary license.
> 
> So I doubt they would share their patches related to AIX, but I can always 
> ask.

Hi Sébastien,

We definitely like to share our core Python patches for AIX 5.1/5.2 and other 
platforms. We have, in the past, submitted a few of them already in the Python 
bug tracker.  As not all of them have been submitted (for lack of time), I 
uploaded them all here for your access,
http://gist.github.com/628519

Please do send us any patches you may have for building Python 3 on AIX.

-srid
___
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] A new warning category?

[Brett Cannon]

On Fri, Oct 15, 2010 at 03:27, Nick Coghlan  wrote:
> On Fri, Oct 15, 2010 at 7:44 PM, Michael Foord
>  wrote:
>>  On 15/10/2010 08:22, Stephen J. Turnbull wrote:
>>>
>>> Brett Cannon writes:
>>>
>>>  >  As one of the co-authors of the PEP I say no.
>>>
>>> Procedural question: Doesn't authorship disqualify you from BDF1P, so
>>> you can't pronounce?
>>
>> I think Brett meant co-authorship of the *moratorium* PEP (which is already
>> accepted).
>
> That's the way I took it as well.

And that is the way to take it. =)

>
> The other factor here is that the moratorium was largely to help other
> implementations get back up to speed with CPython as they dealt with
> the transition to 3.x. Adding a new warning type isn't the kind of
> moving target that something like PEP 380 would be.

Exactly. This is especially true if the other VMs use warnings.py
which will take care of all the details for them.

-Brett

>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> 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/brett%40python.org
>
___
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] Locked-in defect? 32-bit hash values on 64-bit builds

[Raymond Hettinger]

After rereading http://bugs.python.org/issue9778 , I'm growing concerned
about an impending ABI freeze before the core devs find time to fix the 
32-bit hash limitation.

ISTM, the use of 64-bit builds is growing in popularity.  It was be a bummer
to have a locked-in an effective size limit for dictionaries and sets because
the API only supports 32-bit hash values.

The thread seems to show agreement that the hash values should be
Py_ssize_t but the chance to fix it will be lost unless core devs get 
more time to work on the problem or unless the ABI freeze is deferred.


Raymond___
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] Locked-in defect? 32-bit hash values on 64-bit builds

[Benjamin Peterson]

2010/10/15 Raymond Hettinger :
> After rereading http://bugs.python.org/issue9778 , I'm growing concerned
> about an impending ABI freeze before the core devs find time to fix the
> 32-bit hash limitation.
> ISTM, the use of 64-bit builds is growing in popularity.  It was be a bummer
> to have a locked-in an effective size limit for dictionaries and sets
> because
> the API only supports 32-bit hash values.
> The thread seems to show agreement that the hash values should be
> Py_ssize_t but the chance to fix it will be lost unless core devs get
> more time to work on the problem or unless the ABI freeze is deferred.

I think the panic is a bit of an overreaction. PEP 384 has still not
been accepted, and I haven't seen a final decision about freezing the
ABI in 3.2.



-- 
Regards,
Benjamin
___
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] Locked-in defect? 32-bit hash values on 64-bit builds

[skip]

Raymond> ... but the chance to fix it will be lost unless core devs get
Raymond> more time to work on the problem or unless the ABI freeze is
Raymond> deferred.

+1

Skip
___
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] Locked-in defect? 32-bit hash values on 64-bit builds

[Barry Warsaw]

On Oct 15, 2010, at 12:40 PM, Benjamin Peterson wrote:

>2010/10/15 Raymond Hettinger :
>> After rereading http://bugs.python.org/issue9778 , I'm growing concerned
>> about an impending ABI freeze before the core devs find time to fix the
>> 32-bit hash limitation.
>> ISTM, the use of 64-bit builds is growing in popularity.  It was be a bummer
>> to have a locked-in an effective size limit for dictionaries and sets
>> because
>> the API only supports 32-bit hash values.
>> The thread seems to show agreement that the hash values should be
>> Py_ssize_t but the chance to fix it will be lost unless core devs get
>> more time to work on the problem or unless the ABI freeze is deferred.
>
>I think the panic is a bit of an overreaction. PEP 384 has still not
>been accepted, and I haven't seen a final decision about freezing the
>ABI in 3.2.

Yes, but there's less than a month left before 3.2 beta 1, and then it *will*
be too late, at least for this release.

-Barry


signature.asc
Description: PGP signature
___
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] Fwd: [Python-ideas] stats module Was: minmax() function ...

[Raymond Hettinger]

Hello guys.  If you don't mind, I would like to hijack your thread :-)

ISTM, that the minmax() idea is really just an optimization request.
A single-pass minmax() is easily coded in simple, pure-python,
so really the discussion is about how to remove the loop overhead
(there isn't much you can do about the cost of the two compares
which is where most of the time would be spent anyway).

My suggestion is to aim higher.   There is no reason a single pass
couldn't also return min/max/len/sum and perhaps even other summary
statistics like sum(x**2) so that you can compute standard deviation 
and variance.

A few years ago, Guido and other python devvers supported a
proposal I made to create a stats module, but I didn't have time
to develop it.  The basic idea was that python's batteries should
include most of the functionality available on advanced student
calculators.  Another idea behind it was that we could invisibility
do-the-right-thing under the hood to help users avoid numerical
problems (i.e. math.fsum(s)/len(s) is a more accurate way to
compute an average because it doesn't lose precision when
building-up the intermediate sums).

I think the creativity and energy of this group is much better directed
at building a quality stats module (perhaps with some R-like capabilities).
That would likely be a better use of energy than bike-shedding 
about ways to speed-up a trivial piece of code that is ultimately
constrained by the cost of the compares per item.

my-two-cents,


Raymond
___
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] Locked-in defect? 32-bit hash values on 64-bit builds

[Raymond Hettinger]

On Oct 15, 2010, at 10:40 AM, Benjamin Peterson wrote:

> I think the panic is a bit of an overreaction. PEP 384 has still not
> been accepted, and I haven't seen a final decision about freezing the
> ABI in 3.2.

Not sure where the "panic" seems to be.
I just want to make sure the ABI doesn't get frozen
before hash functions are converted to Py_ssize_t.

Even if the ABI is nor frozen at 3.2 as Martin has proposed,
it would still be great to get this in for 3.2

Fortunately, this doesn't affect everyday users, it only
arises for very large datasets.  When it does kick-in though
(around 2**32 entries), the degradation is not small, it
is close to catastrophic, making dicts/set unusable
where O(1) lookups become O(n) with a *very* large n.


Raymond


___
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] Fixing zipfile.BadZipfile to zipfile.BadZipFile

[Boštjan Mejak]

I am very glad you're reorganizing the Standard Library. Thumbs up! I
hope everything will comply to PEP 8 after you're done.

Since you're reorganizing, I have my own contribution. I have attached
a patch. The issue7351  was not
accepted at the time, so I hope you'll accept this fix now.

My point is that every class name in the module zipfile is like this:
- LargeZipFile
- ZipFile
- PyZipFile
.

.

.

So apply my patch to make the class name BadZipfile consistent to
other class names in the zipfile module and let it be named
BadZipFile. Thank you.



Best regards,

Boštjan Mejak


zipfile-patch.diff
Description: Binary data
___
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] Locked-in defect? 32-bit hash values on 64-bit builds

[Reid Kleckner]

On Fri, Oct 15, 2010 at 4:10 PM, Raymond Hettinger
 wrote:
>
> On Oct 15, 2010, at 10:40 AM, Benjamin Peterson wrote:
>
>> I think the panic is a bit of an overreaction. PEP 384 has still not
>> been accepted, and I haven't seen a final decision about freezing the
>> ABI in 3.2.
>
> Not sure where the "panic" seems to be.
> I just want to make sure the ABI doesn't get frozen
> before hash functions are converted to Py_ssize_t.
>
> Even if the ABI is nor frozen at 3.2 as Martin has proposed,
> it would still be great to get this in for 3.2
>
> Fortunately, this doesn't affect everyday users, it only
> arises for very large datasets.  When it does kick-in though
> (around 2**32 entries), the degradation is not small, it
> is close to catastrophic, making dicts/set unusable
> where O(1) lookups become O(n) with a *very* large n.

Just to be clear, hashing right now just uses the C long type.  The
only major platform where sizeof(long) < sizeof(Py_ssize_t) is 64-bit
Windows, right?  And the change being proposed is to make tp_hash
return a Py_ssize_t instead of a long, and then make all the clients
of tp_hash compute with Py_ssize_t instead of long?

Reid
___
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] Fwd: [Python-ideas] stats module Was: minmax() function ...

[geremy condra]

On Fri, Oct 15, 2010 at 1:00 PM, Raymond Hettinger
 wrote:
> Hello guys.  If you don't mind, I would like to hijack your thread :-)
>
> ISTM, that the minmax() idea is really just an optimization request.
> A single-pass minmax() is easily coded in simple, pure-python,
> so really the discussion is about how to remove the loop overhead
> (there isn't much you can do about the cost of the two compares
> which is where most of the time would be spent anyway).
>
> My suggestion is to aim higher.   There is no reason a single pass
> couldn't also return min/max/len/sum and perhaps even other summary
> statistics like sum(x**2) so that you can compute standard deviation
> and variance.

+1 from me. Here's a normal cdf and chi squared cdf approximation I
use for randomness testing. They may need to refined for inclusion,
but you're welcome to use them if you'd like.

from math import sqrt, erf

def normal_cdf(x, mu=0, sigma=1):
"""Approximates the normal cumulative distribution"""
return (1/2) * (1 + erf((x+mu)/(sigma*sqrt(2

def chi_squared_cdf(x, k):
"""Approximates the cumulative chi-squared statistic with k degrees
of freedom."""
numerator = 1 - (2/(9*k)) - ((x/k)**(1/3))
denominator = (1/3) * sqrt(2/k)
return normal_cdf(numerator/denominator)

> A few years ago, Guido and other python devvers supported a
> proposal I made to create a stats module, but I didn't have time
> to develop it.  The basic idea was that python's batteries should
> include most of the functionality available on advanced student
> calculators.  Another idea behind it was that we could invisibility
> do-the-right-thing under the hood to help users avoid numerical
> problems (i.e. math.fsum(s)/len(s) is a more accurate way to
> compute an average because it doesn't lose precision when
> building-up the intermediate sums).

Can you give some other examples? Sage does some of this and I
frequently find it annoying, actually, but I'm not sure if you're
referring to the same things there.

Geremy Condra
___
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] Fwd: [Python-ideas] stats module Was: minmax() function ...

[Steven D'Aprano]

On Sat, 16 Oct 2010 07:00:16 am Raymond Hettinger wrote:
> Hello guys.  If you don't mind, I would like to hijack your thread
> :-)

Please do :)


> A few years ago, Guido and other python devvers supported a
> proposal I made to create a stats module, but I didn't have time
> to develop it.
[...] 
> I think the creativity and energy of this group is much better
> directed at building a quality stats module (perhaps with some R-like
> capabilities).

+1

Are you still interested in working on it, or is this a subtle hint that 
somebody else should do so?


-- 
Steven D'Aprano
___
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] Fwd: [Python-ideas] stats module Was: minmax() function ...

[sunqiang]

On Sat, Oct 16, 2010 at 8:05 AM, geremy condra  wrote:
> On Fri, Oct 15, 2010 at 1:00 PM, Raymond Hettinger
>  wrote:
>> Hello guys.  If you don't mind, I would like to hijack your thread :-)
>>
>> ISTM, that the minmax() idea is really just an optimization request.
>> A single-pass minmax() is easily coded in simple, pure-python,
>> so really the discussion is about how to remove the loop overhead
>> (there isn't much you can do about the cost of the two compares
>> which is where most of the time would be spent anyway).
>>
>> My suggestion is to aim higher.   There is no reason a single pass
>> couldn't also return min/max/len/sum and perhaps even other summary
>> statistics like sum(x**2) so that you can compute standard deviation
>> and variance.
>
> +1 from me. Here's a normal cdf and chi squared cdf approximation I
> use for randomness testing. They may need to refined for inclusion,
> but you're welcome to use them if you'd like.
>
> from math import sqrt, erf
>
> def normal_cdf(x, mu=0, sigma=1):
>        """Approximates the normal cumulative distribution"""
>        return (1/2) * (1 + erf((x+mu)/(sigma*sqrt(2
>
> def chi_squared_cdf(x, k):
>        """Approximates the cumulative chi-squared statistic with k degrees
> of freedom."""
>        numerator = 1 - (2/(9*k)) - ((x/k)**(1/3))
>        denominator = (1/3) * sqrt(2/k)
>        return normal_cdf(numerator/denominator)
>
>> A few years ago, Guido and other python devvers supported a
>> proposal I made to create a stats module, but I didn't have time
>> to develop it.  The basic idea was that python's batteries should
>> include most of the functionality available on advanced student
>> calculators.  Another idea behind it was that we could invisibility
>> do-the-right-thing under the hood to help users avoid numerical
>> problems (i.e. math.fsum(s)/len(s) is a more accurate way to
>> compute an average because it doesn't lose precision when
>> building-up the intermediate sums).
>
> Can you give some other examples? Sage does some of this and I
> frequently find it annoying, actually, but I'm not sure if you're
> referring to the same things there.
have seen a blog post[1]  several months ago from reddit[2], maybe it
worth a reading.
[1]: 
http://www.johndcook.com/blog/2010/06/07/math-library-functions-that-seem-unnecessary/
[2]: 
http://www.reddit.com/r/programming/comments/ccbja/math_library_functions_that_seem_unnecessary/

> Geremy Condra
> ___
> 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/sunqiang%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

[Python-Dev] PPC Tiger is back up

[Bill Janssen]

I've moved the OS X buildbot parc-tiger-1 (PPC Tiger) to new hardware, a
MDD dual-G4 PowerMac with more memory.  Should move considerably faster.

Enjoy!

Bill
___
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