Python-Dev June 2012

python-dev@python.org

123 participants
130 discussions

by Antoine Pitrou

Hello, We only have a x86 Tiger OS X buildbot left. People wanting to see OS X supported may decide to maintain a buildbot that will help us avoid regressions. See http://wiki.python.org/moin/BuildBot Regards Antoine.

8 years, 9 months

Re: [Python-Dev] [Python-checkins] cpython: Issue #15102: find python.exe in OutDir, not SolutionDir.

by Jeremy Kloth

> --- a/PCbuild/pyproject.props > +++ b/PCbuild/pyproject.props > @@ -2,7 +2,7 @@ > <Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> > <PropertyGroup Label="UserMacros"> > <PyDllName>python33$(PyDebugExt)</PyDllName> > - <PythonExe>$(SolutionDir)python$(PyDebugExt).exe</PythonExe> > + <PythonExe>$(OutDir)python$(PyDebugExt).exe</PythonExe> > <KillPythonExe>$(OutDir)kill_python$(PyDebugExt).exe</KillPythonExe> > <externalsDir>..\..</externalsDir> > <sqlite3Dir>$(externalsDir)\sqlite-3.7.12</sqlite3Dir> In order for this change to accurately reflect the OutDir in the x64 builds, all imports of x64.props need to be moved to be before the pyproject.props import statements.

8 years, 9 months

Restricted API versioning

by "Martin v. Löwis"

I've been thinking about extensions to the stable ABI. On the one hand, introducing new API can cause extension modules not to run on older Python versions. On the other hand, the new API may well be stable in itself, i.e. remain available for all coming 3.x versions. As a compromise, I propose that such API can be added, but extension authors must explicitly opt into using it. To define their desired target Python versions, they need to set Py_LIMITED_API to the hexversion of the first Python release they want to support. Objections? The first use case of this are some glitches in the heap type API that Robin Schreiber detected in his GSoC project. E.g. specifying a heap type whose base also is a heap type was not really possible: the type spec would have to contain a pointer to the base, but that is not constant. In addition, if we use multiple interpreters, the base type should be a different object depending on the current interpreter - something that PyType_FromSpec couldn't support at all. So there is a new API function PyType_FromSpecWithBases which covers this case, and this API will only be available in 3.3+. Regards, Martin

8 years, 9 months

Re: [Python-Dev] [Python-checkins] cpython: #4489: Add a shutil.rmtree that isn't suspectible to symlink attacks

by Nick Coghlan

On Sun, Jun 24, 2012 at 2:18 AM, hynek.schlawack <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/c910af2e3c98 > changeset: 77635:c910af2e3c98 > user: Hynek Schlawack <hs(a)ox.cx> > date: Sat Jun 23 17:58:42 2012 +0200 > summary: > #4489: Add a shutil.rmtree that isn't suspectible to symlink attacks > > It is used automatically on platforms supporting the necessary os.openat() and > os.unlinkat() functions. Main code by Martin von Löwis. Unfortunately, this isn't actually having any effect at the moment since the os module APIs changed for the beta release. The "hasattr(os, 'unlinkat')" and "hasattr(os, 'openat')" checks need to become "os.unlink in os.supports_dir_fd" and "os.open in os.supports_dir_fd", and the affected calls need to be updated to pass "dir_fd" as an argument to the normal versions of the functions. At least we know the graceful fallback to the old behaviour is indeed graceful, though :) Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

8 years, 9 months

Re: [Python-Dev] cpython: #15114: the strict mode of HTMLParser and the HTMLParseError exception are

by Antoine Pitrou

On Sat, 23 Jun 2012 15:28:00 +0200 ezio.melotti <python-checkins(a)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? Regards Antoine.

8 years, 9 months

3.3 release plans

by g.brandl-nospam＠gmx.net

Hi all, I've checked in the (hopefully final) update of PEP 398: all PEP scale changes are now final or deferred to 3.4. I also adjusted the release day to be the 26th of June, which leaves us with the following rough plan: - Saturday: last large changes, such as removal of packaging - Sunday: final feature freeze for 3.3; resolve last blockers from bugs.python.org - Monday: ensure build stability for stable buildbots, and as many unstable buildbots as possible - Tuesday: release clone forked off the main repo; tagging and start of binary building cheers, Georg -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

8 years, 9 months

AUTO: Jon K Peck is out of the office (returning 06/30/2012)

by Jon K Peck

I am out of the office until 06/30/2012. I will be out of the office the week of June 25. I expect to have some email access but will likely be delayed in responding. Note: This is an automated response to your message "Python-Dev Digest, Vol 107, Issue 104" sent on 06/23/2012 2:02:24. This is the only notification you will receive while this person is away.

8 years, 9 months

Checking if unsigned int less then zero.

by Dmitriy Tochansky

Hello! Playing with cpython source, I found some strange strings in socketmodule.c: --- if (flowinfo < 0 || flowinfo > 0xfffff) { PyErr_SetString( PyExc_OverflowError, "getsockaddrarg: flowinfo must be 0-1048575."); return 0; } --- --- if (flowinfo < 0 || flowinfo > 0xfffff) { PyErr_SetString(PyExc_OverflowError, "getsockaddrarg: flowinfo must be 0-1048575."); return NULL; } --- The flowinfo variable declared few strings above as unsgined int. Is there any practical sense in this check? Seems like gcc just removes this check. I think any compiler will generate code that checks as unsigned, for example in x86 its JAE/JGE. May be this code is for "bad" compilers or exotic arch? -- Dmitriy

8 years, 9 months

ssh://hg@hg.python.org/cpython unstable?

by Terry Reedy

90% of the way through recloning cpython on Win7, I got Putty Error: Network error: software called connection abort Tortoise hg said abort: stream ended unexpectedly (got 53602 bytes, expected 55236) Two retries give same Putty error almost immdiately, with hg message no suitable response from remote hg Third retry started download, but it failed again after 10 minutes. similar message from hg. Is ssh://hg@hg.python.org/cpython unstable (intermittantly down)? or is something strange happening on my system? (I have previously downloaded multi-gigabyte files, though not today and with perhaps more error tolerant downloaders.) -- Terry Jan Reedy

8 years, 9 months

Re: [Python-Dev] [Python-checkins] cpython: Issue #14769: test_capi now has SkipitemTest, which cleverly checks

by Terry Reedy

On 6/22/2012 6:57 AM, larry.hastings wrote: > http://hg.python.org/cpython/rev/ace45d23628a > changeset: 77567:ace45d23628a > user: Larry Hastings <larry(a)hastings.org> > date: Fri Jun 22 03:56:29 2012 -0700 > summary: > Issue #14769: test_capi now has SkipitemTest, which cleverly checks > for "parity" between PyArg_ParseTuple() and the Python/getargs.c static > function skipitem() for all possible "format units". You sensibly only test printable ascii chars, which are in the contiguous range 32 to 127 inclusive. So it makes no sense to claim otherwise and then deny the wrong claim, or to enlarge the range and then shrink it again. > + This function brute-force tests all** ASCII characters (1 to 127 > + inclusive) as format units, checking to see that With a few exceptions**, test all printable ASCII characters (32 to 127 inclusive) as... > + > + ** Okay, it actually skips some ASCII characters. Some characters ** Some characters ... > + have special funny semantics, and it would be difficult to > + accomodate them here. > + for i in range(1, 128): for i in range(32, 128): > + if (not c.isprintable()) or (c in '()e|$'): if c in '()e|$': tjr

8 years, 9 months

← Newer
1
2
3
4
5
6
7
...
13
Older →

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev June 2012