Re: [Python-Dev] understanding ubuntu's patches to cpython

On 11/16/2014 11:23 PM, Buck Evan wrote: This particular patch caused virtualenv issue #118 and a subsequent workaround: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/python2.7/trusty/view/head:/debian/patches/distutils-install-layout.diff#L281

Re: [Python-Dev] Can Python Be Built Without Distutils

On 01/23/2015 06:30 PM, Cyd Haselton wrote: > Related to my earlier question regarding building Python on Android > and an undefined reference to dlopen error...I have the following > question: Is it possible to build and install Python without having > to build and install...or use...distutils? >

Re: [Python-Dev] libffi embedded in CPython

On 03/11/2015 06:27 PM, Brett Cannon wrote: > On Mon, Dec 22, 2014 at 4:49 PM Jim J. Jewett wrote: > >> >> >> On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote: >>> ... http://bugs.python.org/issue23085 ... >>> is there any reason any more for libffi being included in CPython? >> >> >> Pau

Re: [Python-Dev] Some data points for the "annual release cadence" concept

On 12.06.2018 18:23, Guido van Rossum wrote: So, to summarize, we need something like six for C? there is https://github.com/encukou/py3c ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe

Re: [Python-Dev] Some data points for the "annual release cadence" concept

On 12.06.2018 14:38, Nick Coghlan wrote: Since we last seriously discussed potential release cadence changes back in 2012 (with PEPs 407 and 413 [2,3]), that means JEE joins GCC switching to an annual release cadence from GCC 5 back in 2015 (see [4]), no, GCC is doing yearly releases since 2001

Re: [Python-Dev] Computed Goto dispatch for Python 2

On 05/28/2015 02:17 AM, Parasa, Srinivas Vamsi wrote: > Hi All, > > This is Vamsi from Server Scripting Languages Optimization team at Intel > Corporation. > > Would like to submit a request to enable the computed goto based dispatch in > Python 2.x (which happens to be enabled by default in Py

Re: [Python-Dev] Keeping competitive with Go (was Re: Computed Goto dispatch for Python 2)

On 05/28/2015 06:13 PM, Barry Warsaw wrote: > Go seems to be popular where I work. It is replacing Python in a number of > places, although Python (and especially Python 3) is still a very important > part of our language toolbox. > > There are several reasons why Go is gaining popularity. Singl

Re: [Python-Dev] Sorry folks, minor hiccup for Python 3.5.0rc1

On 08/11/2015 02:56 AM, Larry Hastings wrote: > On 08/10/2015 05:55 PM, Larry Hastings wrote: >> I yanked the tarballs off the release page as soon as I suspected something. >> I'm rebuilding the tarballs and the docs now. If you grabbed the tarball as >> soon as it appeared, it's slightly out of

Re: [Python-Dev] Profile Guided Optimization active by-default

The current pgo target just uses a very specific task to train for the feedback. For my Debian/Ubuntu builds I'm using the testsuite minus some problematic tests to train. Otoh I don't know if this is the best way to do it, however it gave better results at some time in the past. What I would like

Re: [Python-Dev] buildbot's are needlessly compiling -O0

Am 24.11.2013 08:13, schrieb Gregory P. Smith: > our buildbots are setup to configure --with-pydebug which also > unfortunately causes them to compile with -O0... this results in a python > binary that is excruciatingly slow and makes the entire test suite run take > a long time. > > given that no

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

Am 17.02.2014 00:25, schrieb Larry Hastings: > And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? Matthias ___ Python-Dev mailing list Python-Dev@pytho

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

Am 19.02.2014 00:46, schrieb Larry Hastings: > On 02/18/2014 03:38 PM, Matthias Klose wrote: >> Am 17.02.2014 00:25, schrieb Larry Hastings: >>> And my local branch will remain private until 3.4.0 final ships! >> sorry, but this is so wrong. Is there *any* reason why to kee

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

Am 19.02.2014 01:05, schrieb Larry Hastings: > On 02/18/2014 03:56 PM, Matthias Klose wrote: >> Am 19.02.2014 00:46, schrieb Larry Hastings: >>> On 02/18/2014 03:38 PM, Matthias Klose wrote: >>>> Am 17.02.2014 00:25, schrieb Larry Hastings: >>>>> And my

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

Am 19.02.2014 22:18, schrieb Nick Coghlan: > and the Ubuntu 14.04 deadline restricts our ability to add a 3rd rc. well, I think it would be wrong to restrict that for only that reason. I did object to delay the release cycle a second time for completing a feature. If the release has to be delaye

Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?

Am 04.03.2014 15:52, schrieb Brett Cannon: > I have also filed http://bugs.python.org/issue20851 to make sure the > devguide covers running tests from a tarball. If the way the release has > been handled has still bugged you enough it can be discussed at the > language summit, but it would be the f

Re: [Python-Dev] Where is our official policy of what platforms we do support?

Am 14.05.2014 17:08, schrieb Brett Cannon: > On Wed May 14 2014 at 11:02:50 AM, R. David Murray > wrote: > >> On Wed, 14 May 2014 11:31:15 -0300, "Joao S. O. Bueno" < >> jsbu...@python.org.br> wrote: >>> +1 for an official policy that comes with a "permanent maintainer for >>> this platform requi

Re: [Python-Dev] use cases for "python-config" versus "pkg-config python"

Am 02.06.2014 20:11, schrieb Michael Haubenwallner: > Hi, > > following up myself with a patch proposal: > > On 05/28/2014 04:51 PM, Michael Haubenwallner wrote: >> Stumbling over problems on AIX (Modules/python.exp not found) building >> libxml2 as python module >> let me wonder about the inten

Re: [Python-Dev] [RELEASE] Python 3.8.0a1 is now available for testing

On 06.02.19 13:23, Petr Viktorin wrote: > FWIW, we're preparing to rebuild all Fedora packages with the 3.8 > alphas/betas, > so everything's tested when 3.8.0 is released: > https://fedoraproject.org/wiki/Changes/Python3.8 > > That should cover the main Python projects, too. well, the real chal

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On 13.02.19 17:20, Victor Stinner wrote: > Hi, > > I'm a (strong) supporter of providing a "python" command which would > be the latest Python version! This very much depends on what is working with the latest Python version, and what amount of third party packages your distro has to support. It

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On 13.02.19 16:24, Petr Viktorin wrote: > PEP 394 says: > >> This recommendation will be periodically reviewed over the next few >> years, and updated when the core development team judges it >> appropriate. As a point of reference, regular maintenance releases >> for the Python 2.7 series will co

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On 16.02.19 00:15, Gregory P. Smith wrote: > On Thu, Feb 14, 2019 at 9:29 AM Barry Warsaw wrote: > >> On Feb 13, 2019, at 23:08, Matěj Cepl wrote: >> >>> Is this relevant to the discussion at hand? We are talking about >>> the binary /usr/bin/python3 which will be surely be provided >>> even by

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On 16.02.19 18:25, Nick Coghlan wrote: > While Matthias is still personally reluctant to add the alias for > Debian/Ubuntu, the *only* thing preventing aliasing /usr/bin/python to > /usr/bin/python3 right now on the Fedora & RHEL side of things is PEP > 394, and Guido objected strongly when Petr la

Re: [Python-Dev] Testing cross-compiled python (windows arm32) from build bot

On 18.03.19 21:10, Paul Monson via Python-Dev wrote: > Hello, > > For windows arm32 I would like to be able run tests in the buildbot. > Windows arm32 programs built with MSVC are always cross-compiled. > This means I need to build cpython on x86/x64 and then deploy the build > artifacts and run

Re: [Python-Dev] PEP-582 and multiple Python installations

On 02.04.19 18:10, Steve Dower wrote: > On 02Apr2019 0817, Calvin Spealman wrote: >> (I originally posted this to python-ideas, where I was told none of this >> PEP's >> authors subscribe so probably no one will see it there, so I'm posting it >> here >> to raise the issue where it can get seen a

Re: [Python-Dev] Use C extensions compiled in release mode on a Python compiled in debug mode

On 24.04.19 18:02, Victor Stinner wrote: > Hum, I found issues with libpython: C extensions are explicitly linked > to libpython built in release mode. So a debug python loading a C > extension may load libpython in release mode, whereas libpython in > debug mode is already loaded. > > When Python

Re: [Python-Dev] Use C extensions compiled in release mode on a Python compiled in debug mode

On 24.04.19 01:44, Victor Stinner wrote: > Hi, > > Two weeks ago, I started a thread "No longer enable Py_TRACE_REFS by > default in debug build", but I lost myself in details, I forgot the > main purpose of my proposal... > > Let me retry from scratch with a more explicit title: I would like to

Re: [Python-Dev] Use C extensions compiled in release mode on a Python compiled in debug mode

On 25.04.19 08:31, Nathaniel Smith wrote: > You don't necessarily need rpath actually. The Linux loader has a > bug/feature where once it has successfully loaded a library with a given > soname, then any future requests for that soname within the same process > will automatically return that same l

Re: [Python-Dev] Use C extensions compiled in release mode on a Python compiled in debug mode

eu. 25 avr. 2019 à 12:53, Victor Stinner a écrit : >> Le jeu. 25 avr. 2019 à 09:30, Matthias Klose a écrit : >>> the purpose of python-config here is not clear. Whether it's intended to be >>> used >>> for linking extensions, or embedded interpreters. Current

Re: [Python-Dev] Use C extensions compiled in release mode on a Python compiled in debug mode

On 25.04.19 13:14, Victor Stinner wrote: > Le jeu. 25 avr. 2019 à 09:34, Matthias Klose a écrit : >> there's a simple solution: apt install python3-numpy-dbg cython3-dbg ;) So >> depending on the package maintainer, you already have that available, but it >> is

[Python-Dev] Re: Speeding up CPython

On 10/20/20 2:53 PM, Mark Shannon wrote: > I'd love to hear your thoughts on this. a VM needs a separate backend for each architecture (maybe even OS) - which architectures do you include into your proposal? what's your estimate for a new port? - do you plan for a fall-back to a slow non-VM

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

On 11/16/20 6:46 PM, Barry Warsaw wrote: > That’s what I was going to suggest. I’m not doing any Debian or Ubuntu work > these days, but Matthias Klose should be watching both lists, and should be > able to handle the Debuntu stack. why is this dependency needed? The tzdata package

[Python-Dev] Re: Can lib2to3 and 2to3 be deprecated yet?

On 12/10/20 10:58 AM, Victor Stinner wrote: > Hi, > > I vaguely recall that PEP 617 "New PEG parser for CPython" was > supposed to deprecate the lib2to3 module and the 2to3 program. > > I see that lib2to3/__init__.py contains a PendingDeprecationWarning in > Python 3.9. Can it be converted into a

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

On 1/13/21 12:28 AM, Victor Stinner wrote: > Since documentation changes are backported to 3.8 and 3.9 stable > branches, if we increase the minimum required Sphinx version in > master, I would prefer to also increase it in 3.8 and 3.9 branches. > > I would prefer to not have to check manually if

[Python-Dev] Re: Move support of legacy platforms/architectures outside Python

On 2/21/21 9:24 PM, Gregory P. Smith wrote: > On Sun, Feb 21, 2021 at 10:15 AM Christian Heimes > wrote: > >> On 21/02/2021 13.47, glaub...@debian.org wrote: >>> Rust doesn't keep any user from building Rust for Tier 2 or Tier 3 >> platforms. There is no separate configure guard. All platforms th

[Python-Dev] Re: Move support of legacy platforms/architectures outside Python

On 2/21/21 7:12 PM, Christian Heimes wrote: > On 21/02/2021 13.47, glaub...@debian.org wrote: >> Rust doesn't keep any user from building Rust for Tier 2 or Tier 3 >> platforms. There is no separate configure guard. All platforms that Rust can >> build for, are always enabled by default. No one i

[Python-Dev] Re: Move support of legacy platforms/architectures outside Python

On 2/21/21 1:13 PM, Victor Stinner wrote: > In short, I propose to move maintenance of the legacy platforms/archs > outside Python: people are free to continue support them as patches. > Concrete example: Christian Heimes proposed to drop support for 31-bit > s390 Linux: > https://bugs.python.org

[Python-Dev] Re: NOTE: Python 3.9.3 contains an unintentional ABI incompatibility leading to crashes on 32-bit systems

On 4/4/21 4:44 AM, Terry Reedy wrote: > On 4/3/2021 7:15 PM, Miro Hrončok wrote: >> On 03. 04. 21 21:44, Łukasz Langa wrote: >>> The memory layout of PyThreadState was unintentionally changed in the recent >>> 3.9.3 bugfix release. This leads to crashes on 32-bit systems when importing >>> binary e

[Python-Dev] Re: NOTE: Python 3.9.3 contains an unintentional ABI incompatibility leading to crashes on 32-bit systems

On 4/4/21 2:49 PM, Stephen J. Turnbull wrote: > Matthias Klose writes: > > > Looking at the failing CI tests triggered by these builds, yes I > > see that 32bit archs have the ABI change. > > I'm not sure precisely what you mean by that, but if you mean that

[Python-Dev] How to fix the incorrect shared library extension on linux for 3.2 and newer?

This is http://bugs.python.org/issue16754, affecting Linux systems only, and only those which don't provide static libraries. PEP 3149 did change the SO macro to include the ABI tag, although the SO macro is used to search for shared system libraries too. E.g. searching for the jpeg library search

[Python-Dev] backporting the _sysconfigdata.py module to 2.7

I'd like to backport issue13150, the _sysconfigdata.py module to 2.7. My motivation is not the improved startup time, but the ability to cross-build extension modules using distutils/setuptools. The basic idea is to use the python interpreter of the build machine (the machine you build on), and th

Re: [Python-Dev] [RELEASE] Python 2.7.4 release candidate 1

Am 25.03.2013 01:30, schrieb Benjamin Peterson: > 2.7.4 will be the latest maintenance release in the Python 2.7 series. I hope it's not (and in the IDLE thread you say so otherwise too). Matthias ___ Python-Dev mailing list Python-Dev@python.org ht

Re: [Python-Dev] The end of 2.7

Am 07.04.2013 20:02, schrieb Guido van Rossum: > But perhaps we could change the focus for 2.7 development a bit: > instead of fixing bugs (or bickering about whether something is a bug > fix or a new feature) we could limit changes to ensuring that it works > on newer platforms. Martin mentioned t

Re: [Python-Dev] Mysterious Python pyc file corruption problems

Am 15.05.2013 22:58, schrieb Barry Warsaw: > I am looking into a particularly vexing Python problem on Ubuntu that > manifests in several different ways. I think the problem is the same one > described in http://bugs.python.org/issue13146 and I sent a message on the > subject to the ubuntu-deve

Re: [Python-Dev] Request for CPython 3.5.3 release

On 03.07.2016 06:09, Nick Coghlan wrote: > On 2 July 2016 at 16:17, Ludovic Gasc wrote: >> Hi everybody, >> >> I fully understand that AsyncIO is a drop in the ocean of CPython, you're >> working to prepare the entire 3.5.3 release for December, not yet ready. >> However, you might create a 3.5.2.

Re: [Python-Dev] release cadence

On 05.07.2016 21:11, Brett Cannon wrote: > On Tue, 5 Jul 2016 at 10:45 Barry Warsaw wrote: > >> On Jul 04, 2016, at 10:31 AM, Nick Coghlan wrote: >> >>> While we liked the "consistent calendar cadence that is some multiple >>> of 6 months" idea, several of us thought 12 months was way too short >

Re: [Python-Dev] C99

On 06.08.2016 00:27, Brett Cannon wrote: > On Fri, 5 Aug 2016 at 15:17 Guido van Rossum wrote: > >> I want it to list specific versions that are known to be good right >> now, so we can point fingers appropriately when a regression happens. >> > > OK, then we could pin it to MSVC 2016, gcc 6.1,

Re: [Python-Dev] Python 2.7.13 release dates

On 28.11.2016 20:38, Larry Hastings wrote: > On 11/28/2016 10:42 AM, Guido van Rossum wrote: >> Perhaps (un)related, is the release schedule for 3.5.3 set yet? (I'm holding >> off putting a new version of typing.py on typeshed until that's out.) > > Not set in stone, but I have a rough plan. I wa

Re: [Python-Dev] Python 2.7.13 release dates

same here. https://wiki.debian.org/DebianStretch shows the final Debian release freeze for 2016-02-05, which would be a bit close for a 2.7.13 release. On 29.11.2016 15:12, Steve Dower wrote: > I would much rather keep it in December, as I've already made scheduling > decisions around the planned

Re: [Python-Dev] cpython: Revert unintended merge

On 04.12.2016 00:19, Martin Panter wrote: > On 3 December 2016 at 22:15, Steve Dower wrote: >> On 03Dec2016 1312, Serhiy Storchaka wrote: >>> >>> On 03.12.16 22:13, steve.dower wrote: https://hg.python.org/cpython/rev/a60767015bed changeset: 105436:a60767015bed user:S

Re: [Python-Dev] [python-committers] Should I delay 3.5.3 and 3.4.6 by two weeks?

On 19.12.2016 06:26, Larry Hastings wrote: > > > Python 3.6.0 final just slipped by two weeks. I scheduled 3.5.3 and 3.4.6 to > ship about a month after 3.6.0 did, to "let the dust settle" around the > release. I expect a flood of adoption of 3.6, and people switching will find > bugs, and mayb

Re: [Python-Dev] Help requested with Python 2.7 performance regression

On 01.03.2017 18:51, Antoine Pitrou wrote: > As for the high level: what if the training set used for PGO in Xenial > has become skewed or inadequate? running the testsuite ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailma

[Python-Dev] Re: Accepting PEP 602 -- Annual Release Cycle for Python

On 30.10.19 20:26, Brett Cannon wrote: This was discussed on https://discuss.python.org I appreciate that you are informing the python-dev ML. However this discussion was never announced on the ML. I assume this is a kind of thing that makes the ML obsolete and forces everyone into discourse

[Python-Dev] Re: Accepting PEP 602 -- Annual Release Cycle for Python

On 30.10.19 22:22, Barry Warsaw wrote: On Oct 30, 2019, at 12:50, Matthias Klose wrote: On 30.10.19 20:26, Brett Cannon wrote: This was discussed on https://discuss.python.org I appreciate that you are informing the python-dev ML. However this discussion was never announced on the ML. I

[Python-Dev] Re: [bpo-22699] Cross-compiling and fixing sysconfig

distutils is pretty indifferent to whether it's building native or cross. The idea is to run the host python with the target's sysconfig to provide the tools needed for cross compilation. Yes, there are problems if third-party modules are using the sys module to reason about the target architectur

[Python-Dev] Re: How to customize CPython to a minimal set

On 7/20/20 10:30 AM, Huang, Yang wrote: > > Hi, all > > There is a request to run python in a Linux-based embedded resource > constrained system with sqlite3 support. > > So many features are not required, like posixmodule, signalmodule, hashtable > ... > But seems there are some dependencies

[Python-Dev] Re: PEP 632: Deprecate distutils module

On 9/4/20 1:28 PM, Steve Dower wrote: > Hi all. > > setuptools has recently adopted the entire codebase of the distutils module, > so > that they will be able to make improvements directly without having to rely on > patching the standard library. As a result, we can now move forward with > offic

Re: [Python-Dev] PEP 382: Namespace Packages

Martin v. Löwis schrieb: > I propose the following PEP for inclusion to Python 3.1. > Please comment. > > Regards, > Martin > > Abstract > > > Namespace packages are a mechanism for splitting a single Python > package across multiple directories on disk. In current Python > versions, an

Re: [Python-Dev] Tools

Barry Warsaw schrieb: > Someone (I'm sorry, I forgot who) asked me at Pycon about stripping out > Demos and Tools. I'm happy to remove the two I wrote - Tools/world and > Tools/pynche - from the distribution and release them as separate > projects (retaining the PSF license). Should I remove the

Re: [Python-Dev] [Distutils] request for comments - standardization of python's purelib and platlib

On 14.08.2009 10:02, Tarek Ziadé wrote: On Thu, Aug 13, 2009 at 9:22 PM, Brett Cannon wrote: On Thu, Aug 13, 2009 at 11:23, Jan Matejek wrote: Hello, I'm cross-posting this to distributi...@freedesktop and python-dev, because the topic is relevant to both groups and should be solved in co

Re: [Python-Dev] PEP 3147, __pycache__ directories and umask

On 23.03.2010 02:28, Ben Finney wrote: Antoine Pitrou writes: Barry Warsaw python.org> writes: When Python is being installed, either by a from-source 'make install' or by the distro packager, then you'd expect the umask not to be insane. In the latter case, it's a bug and in the former ca

[Python-Dev] autoconf update to 2.65 and cleanup

configure is still generated by 2.61; would it be possible to update to 2.65? The cr_lf issue mentioned in [1] seems to be resolved, ac_cr is now defined as ac_cr=`echo X | tr X '\015'` Proposing to - fix some quoting in help strings and code snippets (#8509) - update to autoconf 2.65 (#85

Re: [Python-Dev] pybuildbot.identify?

On 19.05.2010 18:09, Bill Janssen wrote: The PPC buildbots are running pretty well, now that I've opened a few more ports, but I'd like to find this script "pybuildbot.identify" that they keep complaining about, and install it. I've poked around the Python sources, but haven't found it. Anyone

Re: [Python-Dev] versioned .so files for Python 3.2

On 25.06.2010 22:12, James Y Knight wrote: On Jun 25, 2010, at 4:53 AM, Scott Dial wrote: On 6/24/2010 8:23 PM, James Y Knight wrote: On Jun 24, 2010, at 5:53 PM, Scott Dial wrote: If the package has .so files that aren't compatible with other version of python, then what is the motivation f

Re: [Python-Dev] versioned .so files for Python 3.2

On 26.06.2010 02:19, Nick Coghlan wrote: On Sat, Jun 26, 2010 at 6:12 AM, James Y Knight wrote: However, then you have to also consider python packages made up of multiple distro packages -- like twisted or zope. Twisted includes some C extensions in the core package. But then there are other t

Re: [Python-Dev] versioned .so files for Python 3.2

On 24.06.2010 22:46, Barry Warsaw wrote: On Jun 24, 2010, at 02:28 PM, Barry Warsaw wrote: On Jun 24, 2010, at 01:00 PM, Benjamin Peterson wrote: 2010/6/24 Barry Warsaw: On Jun 24, 2010, at 10:58 AM, Benjamin Peterson wrote: 2010/6/24 Barry Warsaw: Please let me know what you think. I'm

Re: [Python-Dev] FHS compliance of Python installation

On 25.06.2010 02:54, Ben Finney wrote: James Y Knight writes: Really, python should store the .py files in /usr/share/python/, the .so files in /usr/lib/x86_64- linux-gnu/python2.5-debug/, and the .pyc files in /var/lib/python2.5- debug. But python doesn't work like that. +1 So who's going

Re: [Python-Dev] FHS compliance of Python installation

On 26.06.2010 22:30, C. Titus Brown wrote: On Sat, Jun 26, 2010 at 10:25:28PM +0200, Matthias Klose wrote: On 25.06.2010 02:54, Ben Finney wrote: James Y Knight writes: Really, python should store the .py files in /usr/share/python/, the .so files in /usr/lib/x86_64- linux-gnu/python2.5

Re: [Python-Dev] versioned .so files for Python 3.2

On 25.06.2010 20:58, Brett Cannon wrote: On Fri, Jun 25, 2010 at 01:53, Scott Dial Placing .so files together does not simplify that install process in any way. You will still have to handle such packages in a special way. You must still compile the package multiple times for each relevant versi

Re: [Python-Dev] versioned .so files for Python 3.2

On 07.07.2010 20:40, Barry Warsaw wrote: Getting back to this after the US holiday. Thanks for running these numbers Scott. I've opened a bug in the Python tracker and attached my latest patch: http://bugs.python.org/issue9193 The one difference from previous versions of the patch is that the

Re: [Python-Dev] versioned .so files for Python 3.2

On 15.07.2010 01:59, Barry Warsaw wrote: PEP 384 describes a change to ``PyModule_Create()`` where ``3`` is passed as the API version if the extension was complied with ``Py_LIMITED_API``. This should be formalized into an official macro called ``PYTHON_ABI_VERSION`` to mirror ``PYTHON_API_VERSI

Re: [Python-Dev] versioned .so files for Python 3.2

On 16.07.2010 15:43, Daniel Stutzbach wrote: On Fri, Jul 16, 2010 at 5:40 AM, Matthias Klose wrote: 2) As PEP 3147 defines a non-configurable name for .pyc files, this PEP should define a non-configurable way for the tag. The tag should include all information which currently

Re: [Python-Dev] versioned .so files for Python 3.2

On 26.07.2010 22:53, Ralf Schmitt wrote: Barry Warsaw writes: That's fine, but it's not the way Debian/Ubuntu works today. PEP 3149 adoption will definitely remove significant complication for deploying multiple Python versions at the same time on those systems. You're just moving that compl

Re: [Python-Dev] Python-3 transition in Arch Linux

On 04.11.2010 21:12, "Martin v. Löwis" wrote: To clarify (but I dont speak for the rest of #python, just myself), I think the move was premature, but I don't use Arch and I don't know what typical Arch users expect. The reason I think it's premature is that 'python2' just doesn't work everywhere,

Re: [Python-Dev] Question about GDB bindings and 32/64 bits

On 26.11.2010 05:11, Jesus Cea wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have installed GDB 7.2 32 bits and 32 bits buildslaves are green. Nevertheless 64 bits buildslaves are failing test_gdb. Is there any expectation that a 32 bits GDB be able to debug a 64 bits python?. If not,

Re: [Python-Dev] PEP 384 final review

On 29.11.2010 00:40, "Martin v. Löwis" wrote: I have now completed http://www.python.org/dev/peps/pep-0384/ Benjamin has volunteered to rule on this PEP. Please comment with any changes you want to see, or speak in favor or against this PEP. I looked at a diff with r84330 from the py3k branc

Re: [Python-Dev] PEP 384 final review

On 29.11.2010 14:14, Éric Araujo wrote: Hello, Please comment with any changes you want to see, or speak in favor or against this PEP. How to get a diff between py3k and this branch? I used svn diff svn://svn.python.org/python/branches/p...@84330 svn://svn.python.org/python/branches/pep-03

Re: [Python-Dev] PEP 384 accepted

On 03.12.2010 00:25, Tarek Ziadé wrote: 2010/12/2 "Martin v. Löwis": No, only the ones that didn't cause backwards incompatibilities, and broke existing packages. This is impossible. I can point you to some third party project that can break if you touch some distutils internals, like setuptoo

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

On 02.03.2011 16:54, Nick Coghlan wrote: > /tangent > > Does this discussion remind anyone else of the bash/dash switch for > /usr/bin/sh in Ubuntu? > > The distro itself coped fine, but 3rd party shell scripts that used > bash extensions were a whole different story. > > (No, I'm not sure what

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

On 04.03.2011 08:44, Kerrick Staley wrote: [looking at version 88755 of the draft] +1 on anything what is said about python2 (still remembering the unsuccessful proposal from one of the Chicago language summits). I do not like the vagueness about the python link. Sounds like "It may point to th

Re: [Python-Dev] Capsule Summary of Some Packaging/Deployment Technology Concerns

Jeff Rush writes: > I was in a Packaging BoF yesterday and, although not very relevant to the > packager bootstrap thread, Guido has asked me to post some of the concerns. We did address many topics on both days, I added the following topics which were addressed on the Friday BoF only, see http:/

Re: [Python-Dev] Capsule Summary of Some Packaging/Deployment Technology Concerns

Phillip J. Eby writes: > >7. Many wanted to ability to install files anywhere in the install tree and > > not just under the Python package. Under distutils this was possible > > but > > it was removed in setuptools for security reasons. > > It wasn't security, it was manageability. Egg

Re: [Python-Dev] what version of bsddb to use/accept for 2.6/3.0

[CCing Clint] 4.7.25 generally looks fine, except for sparc (afaics); I asked the Debian bsddb maintainer to have a look at the sparc problems. At least on sparc, there's no difference between 4.6 and 4.7. I usually try to run the buildbots with the recent software in the distribution, as this is

Re: [Python-Dev] Python 2.5.3: call for patches

Martin v. Löwis schrieb: > Within a few weeks, we will release Python 2.5.3. This will be the last > bug fix release of Python 2.5, afterwards, future releases of 2.5 will > only include security fixes, and no binaries (for Windows or OSX) will > be provided anymore (from python.org). > > In princ

Re: [Python-Dev] Python 2.5.3: call for patches

Martin v. Löwis schrieb: >> I would like to apply fixes for some CVE's which are addressed in 2.5 but not >> yet in 2.4. this would include >> >> CVE-2007-4965 >> CVE-2008-1679 >> CVE-2008-1721 >> CVE-2008-2315 >> CVE-2008-3144 >> CVE-2008-1887 >> CVE-2008-4864 > > Can you identify the revisions t

[Python-Dev] Module/Setup.dist maintainance

I was experimenting with profiled builds and building more extensions as builtins instead of loadable modules, noticing that Module/Setup.dist is not kept updated. Currently only the section above the *shared* line is really used for the build, but everything else doesn't seem to be updated (extens

Re: [Python-Dev] cpython (3.1): - rename configure.in to configure.ac

On 15.03.2012 11:31, Antoine Pitrou wrote: On Wed, 14 Mar 2012 23:27:24 +0100 matthias.klose wrote: http://hg.python.org/cpython/rev/55ab7a272f0a changeset: 75659:55ab7a272f0a branch: 3.1 parent: 75199:df3b2b5db900 user:Matthias Klose date:Wed Mar 14 23:10:15 2012

Re: [Python-Dev] Debian wheezy, amd64: make not finding files for bz2 and other packages

On 05.05.2012 16:13, Antoine Pitrou wrote: > On Sat, 05 May 2012 16:04:40 +0200 > Christian Heimes wrote: >> Am 05.05.2012 15:39, schrieb Antoine Pitrou: >>> On Sat, 05 May 2012 15:31:24 +0200 >>> Christian Heimes wrote: Am 05.05.2012 12:36, schrieb Antoine Pitrou: > > Hello, > >

Re: [Python-Dev] cross-compiling patches

On 30.06.2012 23:17, Antoine Pitrou wrote: > > Hello, > > I think these patches are premature (they break compilation on OS X, > and they break ctypes configure on my Linux box). that was unrelated. fixed last night. > Furthermore, they > were committed post-beta, which means they should probab

Re: [Python-Dev] What's New in Python 3.3

On 09.08.2012 01:04, Victor Stinner wrote: > Does Python 3.3 support cross-compilation? There are two new option > for configure: --host and --build, but it's not mentioned in What's > New in Python 3.3. it does work, but it is only tested for the linux -> linux case. the mingw and macosx cross bu

Re: [Python-Dev] Stdlib and timezones, again

On 30.09.2012 20:18, Gregory P. Smith wrote: > On Sun, Sep 30, 2012 at 8:33 AM, Benjamin Peterson wrote: > >> 2012/9/30 Xavier Morel : >>> But at worst, an outdated unicode database will be missing data right? >>> >>> Doesn't an outdated timezone db have the risk of returning *incorrect* >> data?

Re: [Python-Dev] Stdlib and timezones, again

On 01.10.2012 00:50, Gregory P. Smith wrote: > On Sun, Sep 30, 2012 at 3:17 PM, Matthias Klose wrote: > >> On 30.09.2012 20:18, Gregory P. Smith wrote: >>> On Sun, Sep 30, 2012 at 8:33 AM, Benjamin Peterson >> wrote: >>> >>>> 2012/9/30 Xavier

Re: [Python-Dev] Stdlib and timezones, again

On 01.10.2012 00:51, Lennart Regebro wrote: > On Mon, Oct 1, 2012 at 12:17 AM, Matthias Klose wrote: > >>> priority: >>> 1) api call supplying tz data to the process. >>> 2) pytzdata module if it exists >>> 3) tz data from the underlying operating

Re: [Python-Dev] Stdlib and timezones, again

On 01.10.2012 01:07, Chris Angelico wrote: > On Mon, Oct 1, 2012 at 8:17 AM, Matthias Klose wrote: >> On 30.09.2012 20:18, Gregory P. Smith wrote: >>> priority: >>> 1) api call supplying tz data to the process. >>> 2) pytzdata module if it exists >>&g

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

On 16.10.2012 17:58, David Malcolm wrote: > On Tue, 2012-10-16 at 10:59 +0200, Stefan Krah wrote: >> Charles-François Natali wrote: >>> Well, so I guess all committers will have to use the same >>> Linux/FreeBSD/whatever distribution then? >>> AFAICT there's no requirement regarding the mercurial

Re: [Python-Dev] Handling support for newer OS features at run time

Am 27.11.2012 23:49, schrieb Trent Nelson: > I don't think we've currently got the ability to do this, right? > Is there a precedent set anywhere else? I suspect it's not as > much of an issue on *NIX platforms as you'll typically compile > from source. Windows, not so much. > >

Re: [Python-Dev] Handling support for newer OS features at run time

Am 28.11.2012 06:37, schrieb Gregory P. Smith: > On Tue, Nov 27, 2012 at 3:19 PM, Trent Nelson wrote: > >> On Tue, Nov 27, 2012 at 03:09:12PM -0800, Matthias Klose wrote: >>> Am 27.11.2012 23:49, schrieb Trent Nelson: >>>> I don't think we've

[Python-Dev] mingw32 port

[No, I'm not interested in the port myself] patches for a mingw32 port are floating around on the web and the python bug tracker, although most of them as a set of patches in one issue addressing several things, and which maybe outdated for the trunk. at least for me re-reading a big patch in a ne

Re: [Python-Dev] cpython (2.7): - Issue #17086: Backport the patches from the 3.3 branch to cross-build

Am 03.02.2013 22:20, schrieb Gregory P. Smith: > On Thu, Jan 31, 2013 at 11:14 PM, Antoine Pitrou wrote: > >> On Fri, 1 Feb 2013 11:00:24 +1000 >> Nick Coghlan wrote: >>> On Fri, Feb 1, 2013 at 9:50 AM, Antoine Pitrou >> wrote: On Thu, 31 Jan 2013 23:52:27 +0100 (CET) matthias.klose w

Re: [Python-Dev] cpython (2.7): - Issue #17086: Backport the patches from the 3.3 branch to cross-build

Am 05.02.2013 07:13, schrieb Terry Reedy: > On 2/4/2013 3:04 PM, Matthias Klose wrote: > >> - the 2.7 branch is the only branch which doesn't have expected release >> dates on the calendar. > > Which calendar? I see 2.7.4, 3.2.4 (its final release), and 3.3.1

[Python-Dev] license issues with profiler.py and md5.h/md5c.c

A Debian user pointed out (http://bugs.debian.org/293932), that the current license for the Python profiler is not conforming to the DFSG (Debian free software guidelines). http://www.python.org/doc/current/lib/node829.html states "This permission is explicitly restricted to the copying and m

  1   2   >