[Python-Dev] Re: Python standardization

On Fri, Feb 12, 2021, at 12:33, Dan Stromberg wrote: > > What would it take to create an ANSI, ECMA and/or ISO standard for Python? > > It seems to have really helped C. That confuses cause and effect. C was standardized because there sprung up hundreds of vaguely compatible

[Python-Dev] Re: Hygenic macros PEP.

On Tue, Sep 15, 2020, at 23:54, Guido van Rossum wrote: > On Tue, Sep 15, 2020 at 7:31 PM Benjamin Peterson wrote: > > On Tue, Sep 15, 2020, at 20:10, Greg Ewing wrote: > > > Maybe the PEP should propose an AST of its own, which would initially > > > be a third

[Python-Dev] Re: Hygenic macros PEP.

On Tue, Sep 15, 2020, at 20:10, Greg Ewing wrote: > On 16/09/20 12:37 pm, Guido van Rossum wrote: > > IMO if we were to standardize the AST for times immemorial this would > > have to be a separate PEP. > > Perhaps, but a stable AST seems to be a prerequisite for this kind > of feature.

[Python-Dev] Re: Taking over xxlimited for PEP 630

On Tue, Sep 8, 2020, at 08:13, Petr Viktorin wrote: > Hello, > The "xxlimited" module (Modules/xxlimited.c) was added as part of PEP > 384 (Defining a Stable ABI), and is undocumented. As far as I can tell, > it was added partly to test the stable ABI, and partly as an example of > how to

[Python-Dev] Re: PEP 387: backwards compatibility policy

On Mon, Jul 20, 2020, at 13:50, Brett Cannon wrote: > The SC has chosen to accept PEP 387! https://www.python.org/dev/peps/pep-0387/ Thank you, steering council! I am particularly grateful to Brett for pushing this PEP, in its eleventh year of existence, over the finish line.

[Python-Dev] [RELEASE] Python 2.7.18, the end of an era

I'm eudaemonic to announce the immediate availability of Python 2.7.18. Python 2.7.18 is a special release. I refer, of course, to the fact that "2.7.18" is the closest any Python version number will ever approximate e, Euler's number. Simply exquisite! A less transcendent property of Python

[Python-Dev] Re: Python2 as 푣 → 푒

The relevant parties are aware. On Sat, Apr 11, 2020, at 17:17, Mike Miller wrote: > > Unless I've read something wrong, it looks like the final Python 2 release > (2.7.18) should approximate the math constant e: > > >>> import math > >>> math.e > 2.718281828459045 > > Aka: >

[Python-Dev] [RELEASE] Python 2.7.18 release candidate 1

Greetings, 2.7.18 release candidate 1, a testing release for the last release of the Python 2.7 series, is now available for download. The CPython core developers stopped applying routine bugfixes to the 2.7 branch on January 1. 2.7.18 will includes fixes that were made between the release of

[Python-Dev] Re: The Python 2 death march

On Fri, Mar 27, 2020, at 11:49, Sumana Harihareswara wrote: > Benjamin: now that PyCon 2020 has been cancelled, are you considering > releasing 2.7.18 slightly earlier? The plan is to follow the dates in PEP 373. ___ Python-Dev mailing list --

[Python-Dev] Re: Maintenance of multiprocessing module: there are a few stalled issues/patches

On Wed, Feb 12, 2020, at 08:22, mailer@app.tempr.email wrote: > I've just been looking through the multiprocessing module and open > issues and wondered why there were some small bugs/patches not being > fixed/merged. Is this the "normal" patch cycle? Does it take years for > bugs to get

[Python-Dev] Re: Fun with Python 3.8 and Qt

It's known: https://bugs.python.org/issue38007 On Mon, Oct 21, 2019, at 20:11, Kacvinsky, Tom wrote: > Today I discovered the this struct > > typedef struct{ > const char* name; > int basicsize; > int itemsize; > unsigned int flags; > PyType_Slot *slots; /* terminated by

[Python-Dev] [RELEASE] Python 2.7.17

Greetings, I'm wealful to announce the immediate availability of Python 2.7.17, another bugfix release in the Python 2.7 series. Downloads are on python.org: https://www.python.org/downloads/release/python-2717/ No code changes occurred between the 2.7.17 release candidate and the final

[Python-Dev] [RELEASE] Python 2.7.17 release candidate 1

The first release candidate of Python 2.7.17 is now available for download and testing. Python 2.7.17 includes 80 fixes over Python 2.7.16. Downloads may be found on python.org: https://www.python.org/downloads/release/python-2717rc1/ Read the full changelog at:

[Python-Dev] Re: The Python 2 death march

On Wed, Sep 25, 2019, at 17:25, Rob Cliffe via Python-Dev wrote: > > I additionally share the bemusement of some other commentators on this > > thread to the idea of Python 2 "support", which is not something ever > > promised to Python 2 (or 3) users by CPython core developers. Essentially,

[Python-Dev] Re: The Python 2 death march

On Wed, Sep 18, 2019, at 19:23, Kyle Stanley wrote: > Benjamin, what are you thoughts on usage of the "needs backport to 2.7" > label? For most of the PRs I've reviewed I tend to avoid adding it > myself, but I've seen it used periodically. It seems to be used rather > infrequently >

[Python-Dev] Re: The Python 2 death march

On Fri, Sep 13, 2019, at 18:18, Sumana Harihareswara wrote: > Hi. I've joined python-dev to participate in this thread (I don't have > email delivery turned on; I'll be checking back via the web). sorry :) > > Benjamin, I am sorry that I didn't check in with you, and assumed that > January

[Python-Dev] Re: The Python 2 death march

On Tue, Sep 10, 2019, at 15:54, Ned Batchelder wrote: > Maybe I'm not involved enough in the release process, but this seems > confusing to me.  On the same day that the PSF put up a page about the > 1/1/2020 date, we choose April 2020 as the last release?  Why?  I > thought the point was to

[Python-Dev] The Python 2 death march

Hi all, It's finally time to schedule the last releases in Python 2's life. There will be two more releases of Python 2.7: Python 2.7.17 and Python 2.7.18. Python 2.7.17 release candidate 1 will happen on October 5th followed by the final release on October 19th. I'm going to time Python

Re: [Python-Dev] Farewell, Python 3.4

se team that worked on > Python 3.4: > > > Georg Brandl > > > Julien Palard > > > Martin von Löwis > > > Ned Deily > > > Steve Dower > > > Terry Reedy > > > and all the engineers of the Python infrastructure team. > > Specia

Re: [Python-Dev] [RELEASE] Python 2.7.16

On Tue, Mar 5, 2019, at 03:18, Miro Hrončok wrote: > On 04. 03. 19 4:30, Benjamin Peterson wrote: > > Hello all, > > I'm pleased to announce the immediate availability of Python 2.7.16 for > > download at https://www.python.org/downloads/release/python-2716/. > >

[Python-Dev] [RELEASE] Python 2.7.16

Hello all, I'm pleased to announce the immediate availability of Python 2.7.16 for download at https://www.python.org/downloads/release/python-2716/. The only change since the release candidate was a fix for the IDLE icon on macOS. See https://bugs.python.org/issue32129. Refer to the changelog

[Python-Dev] [RELEASE] Python 2.7.16 release candidate 1

I'm pleased to announce the immediate availability of Python 2.7.16 release candidate 1. This is a prerelease for yet another bug fix release in the Python 2.7.x series. It includes over 100 fixes over Python 2.7.15. See the changelog at

[Python-Dev] 2.7.16 release dates

Greetings, I've set the dates for the 2.7.16 release in PEP 373. The release candidate will happen on February 16 with a final release 2 weeks later on March 2 if all goes well. Servus, Benjamin ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

On Thu, Nov 29, 2018, at 08:45, Antoine Pitrou wrote: > > Le 29/11/2018 à 15:36, Benjamin Peterson a écrit : > >> > >> I'd like to point the discussion is asymmetric here. > >> > >> On the one hand, people who don't have access to PyPI would _really_ &

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

On Wed, Nov 28, 2018, at 15:27, Steven D'Aprano wrote: > On Wed, Nov 28, 2018 at 10:43:04AM -0800, Gregory P. Smith wrote: > > > PyPI makes getting more algorithms easy. > > Can we please stop over-generalising like this? PyPI makes getting > more algorithms easy for *SOME* people. (Sorry

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

On Thu, Nov 29, 2018, at 04:54, Antoine Pitrou wrote: > On Thu, 29 Nov 2018 09:52:29 + > Paul Moore wrote: > > [This is getting off-topic, so I'll limit my comments to this one email] > > > > On Thu, 29 Nov 2018 at 03:17, Brett Cannon wrote: > > > We have never really had a discussion

Re: [Python-Dev] Missing functions [Was: Re: Experiment an opt-in new C API for Python? (leave current API unchanged)]

On Wed, Nov 21, 2018, at 06:53, Matěj Cepl wrote: > On 2018-11-19, 11:59 GMT, Stefan Krah wrote: > > In practice people desperately *have* to use whatever is > > there, including functions with underscores that are not even > > officially in the C-API. > > Yes, there are some functions which

Re: [Python-Dev] Rename Include/internals/ to Include/pycore/

On Mon, Oct 29, 2018, at 05:38, Victor Stinner wrote: > Le lun. 29 oct. 2018 à 06:32, Benjamin Peterson a écrit > : > > > My overall approach is to make sure that we don't leak functions by > > > mistakes into the public API or into the stable API anymore. For >

Re: [Python-Dev] Rename Include/internals/ to Include/pycore/

On Sun, Oct 28, 2018, at 14:30, Victor Stinner wrote: > Le dim. 28 oct. 2018 à 21:50, Benjamin Peterson a écrit > : > > I don't think more or less API should be magically included based on > > whether Py_BUILD_CORE is defined or not. If we want to have private > > he

Re: [Python-Dev] Rename Include/internals/ to Include/pycore/

On Sun, Oct 28, 2018, at 09:20, Victor Stinner wrote: > Hi, > > Python C API has no strict separation between the 3 levels of API: > > * core: Py_BUILD_CORE define > * stable: Py_LIMITED_API define (it has a value) > * regular: no define > > IMHO the current design of header files is done

Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs

On Tue, Oct 9, 2018, at 17:14, Barry Warsaw wrote: > On Oct 9, 2018, at 16:21, Steven D'Aprano wrote: > > > > On Tue, Oct 09, 2018 at 10:26:50AM -0700, Guido van Rossum wrote: > >> My feeling is that limiting it to strings is fine, but checking those > >> strings for resembling identifiers is

Re: [Python-Dev] Should assert continue to do a LOAD_GLOBAL on AssertionError?

On Wed, Oct 3, 2018, at 08:59, Steven D'Aprano wrote: > On the bug tracker, there's a discussion about the current behaviour of > the assert statement, where shadowing AssertionError will change the > behaviour of the assertion. > > https://bugs.python.org/issue34880 > > Currently, assert

Re: [Python-Dev] LDLAST variable in configure.ac

On Mon, Oct 1, 2018, at 12:12, Michael Felt wrote: > Hi all, > > Before I submit a patch to increase the default MAXDATA setting for AIX > when in 32-bit mode - I want to know if I can put this LDFLAG setting in > LDLAST, or if I should introduce a new AC_SUBST() variable (e.g., > LDMAXDATA).

Re: [Python-Dev] Stop automerging

On Wed, Sep 12, 2018, at 01:33, Serhiy Storchaka wrote: > 12.09.18 01:34, Miss Islington (bot) пише: > > https://github.com/python/cpython/commit/d13e59c1b512069d90efe7ee9b613d3913e79c56 > > commit: d13e59c1b512069d90efe7ee9b613d3913e79c56 > > branch: master > >

Re: [Python-Dev] Python 2.7 EOL date

I was operating under the optimistic assumption whatever the precise time of 2.7's official demise would only be an amusing piece of trivia for a world of happy Python 3 users. It's still to early to promise exact release dates; that will depend on the day-to-day schedules of the release

Re: [Python-Dev] A Subtle Bug in Class Initializations

This would be a good thing to fix. The only hard part is dealing with thirdparty extensions. Note we also have been working around this problem by putting PyType_Ready calls in various generic code paths of the interpreter when an uninitialized type passes through. On Mon, Aug 6, 2018, at

Re: [Python-Dev] Unicode 11.0.0 released

On Tue, Jun 5, 2018, at 12:17, MRAB wrote: > Unicode 11.0.0 has been released. Will Python 3.7 be updated to it, or > is it too late? https://github.com/python/cpython/pull/7439 will update 3.8. Generally, we've considered updating the Unicode database to be a feature and not backported

Re: [Python-Dev] Python startup time

On Wed, May 2, 2018, at 09:42, Gregory Szorc wrote: > The direction Mercurial is going in is that `hg` will likely become a Rust > binary (instead of a #!python script) that will use an embedded Python > interpreter. So we will have low-level control over the interpreter via the > C API. I'd

Re: [Python-Dev] [RELEASE] Python 2.7.15

API for Python" was my motivation for the PEP 546, but > it seems like he is busy and the TLS PEP doesn't move anymore :-( > https://www.python.org/dev/peps/pep-0543/ > > Victor > > 2018-05-01 6:09 GMT+02:00 Benjamin Peterson <benja...@python.org>: > > Gr

[Python-Dev] [RELEASE] Python 2.7.15

Greetings, I'm pleased to announce the immediate availability of Python 2.7.15, the latest bug fix release in the senescent Python 2.7 series. Source and binary downloads may be found on python.org: https://www.python.org/downloads/release/python-2715/ Bugs should be reported to

[Python-Dev] [RELEASE] Python 2.7.15 release candidate 1

I'm pleased to announce the immediate availability of Python 2.7.15 release candidate 1. Python 2.7.15rc1 is a preview release of the next bug fix release in the Python 2.7.x series. Python 2.7.15rc1 may be downloaded in source and binary forms from

[Python-Dev] 2.7.15 release schedule

Hi all, It's that time yet again: I'm planning to release 2.7.15 release candidate 1 on April 14 and a final release two weeks later on April 28. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] Python 2.7 -- bugfix or security before EOL?

special case. > > > > Will there be a period where Py2.7 is in security-only status before > >> hitting EOL? > >> > > > > https://www.python.org/dev/peps/pep-0373 gives the public status. When > > Benjamin Peterson want to add something, he will. > >

Re: [Python-Dev] How is the GitHub workflow working for people?

On Wed, Feb 21, 2018, at 13:22, Guido van Rossum wrote: > On Wed, Feb 21, 2018 at 9:53 AM, Brett Cannon wrote: > > > > > > > On Wed, 21 Feb 2018 at 09:30 Yury Selivanov > > wrote: > > > >> FWIW I'm extremely happy with the current workflow. The

Re: [Python-Dev] "threading.Lock().locked()" is not documented

On Sat, Feb 3, 2018, at 11:25, Gregory P. Smith wrote: > On Wed, Jan 31, 2018 at 4:46 PM Jesus Cea wrote: > > > https://docs.python.org/3.6/library/threading.html doesn't document > > "threading.Lock().locked()", and it is something quite useful. > > > > In fact, it is used in

Re: [Python-Dev] Python 2.7, long double vs allocator alignment, GCC 8 on x86-64

Yes, changing obmalloc.c's alignment guarantees would definitely be the easiest solution. I think someone just needs to investigate whether it wastes a lot of memory. On Tue, Jan 30, 2018, at 13:22, Gregory P. Smith wrote: > I'm curious if changing the obmalloc.c ALIGNMENT and ALIGNMENT_SHIFT >

Re: [Python-Dev] Drop support for old unsupported FreeBSD and Linux kernels?

+1 to both of your specific proposals. More generally, I think it makes good sense to allow dropping support for a platform in the next major Python release after vendor support for the platform stops. Even we say we support something, it will break quickly without buildbot validation. On

Re: [Python-Dev] Whatever happened to 'nonlocal x = y'?

https://github.com/python/peps/commit/2d2ac2d2b66d4e37e8b930f5963735616bddbbe8 On Sat, Jan 6, 2018, at 08:56, Barry Warsaw wrote: > On Jan 6, 2018, at 11:43, Guido van Rossum wrote: > > > > Maybe we should not delete them outright but add something like "(UPDATE: > > during

Re: [Python-Dev] Whatever happened to 'nonlocal x = y'?

On Fri, Jan 5, 2018, at 01:57, Nathaniel Smith wrote: > Was this just an oversight, or did it get rejected at some point and > no-one remembered to update that PEP? There was an implementation https://bugs.python.org/issue4199. But several years ago, we again reached the conclusion that the

Re: [Python-Dev] Heap allocate type structs in native extension modules?

On Thu, Dec 28, 2017, at 03:29, Erik Bray wrote: > On Tue, Dec 26, 2017 at 3:00 PM, Benjamin Peterson <benja...@python.org> > wrote: > > I imagine Cython already takes care of this? > > This appears to have a distinct purpose, albeit not unrelated to > Cython. The

Re: [Python-Dev] Heap allocate type structs in native extension modules?

I imagine Cython already takes care of this? On Tue, Dec 26, 2017, at 02:16, Hugh Fisher wrote: > I have a Python program which generates the boilerplate code for > native extension modules from a Python source definition. > (http://bitbucket.org/hugh_fisher/fullofeels if interested.) > > The

Re: [Python-Dev] Broken svn lookup?

I turned viewvc off a few months ago because subversion is highly deprecated at this point. In fact, now that Windows build dependencies have moved off, I’m probably going to shut it off for good soon. On Mon, Dec 18, 2017, at 06:55, Victor Stinner wrote: > Hi, > > I was looking at old issues. In

Re: [Python-Dev] Intention to accept PEP 552 soon (deterministic pyc files)

On Wed, Oct 4, 2017, at 07:14, Barry Warsaw wrote: > On Oct 3, 2017, at 13:29, Benjamin Peterson <benja...@python.org> wrote: > > > I'm not sure turning the implementation details of our internal formats > > into APIs is the way to go. > > I still think an API

Re: [Python-Dev] Intention to accept PEP 552 soon (deterministic pyc files)

On Tue, Oct 3, 2017, at 08:03, Barry Warsaw wrote: > Guido van Rossum wrote: > > There have been no further comments. PEP 552 is now accepted. > > > > Congrats, Benjamin! Go ahead and send your implementation for review.Oops. > > Let me try that again. > > While I'm very glad PEP 552 has been

Re: [Python-Dev] Intention to accept PEP 552 soon (deterministic pyc files)

zing them under importlib for a while and just never gotten > around > to sitting down and coming up with a better design that warranted putting > the time into it. :) > > On Fri, 29 Sep 2017 at 09:17 Benjamin Peterson <benja...@python.org> > wrote: > > > Thanks,

Re: [Python-Dev] Intention to accept PEP 552 soon (deterministic pyc files)

Thanks, Guido and everyone who submitted feedback! I guess I know what I'll be doing this weekend. On Fri, Sep 29, 2017, at 08:18, Guido van Rossum wrote: > Let me try that again. > > There have been no further comments. PEP 552 is now accepted. > > Congrats, Benjamin! Go ahead and send your

[Python-Dev] [RELEASE] Python 2.7.14

I'm happy to announce to the immediate availability of Python 2.7.14, yet another bug fix release in the Python 2.7 series. 2.7.14 includes 9 months of conservative bug fixes from the 3.x branch. Downloads of source code and binaries are at:

Re: [Python-Dev] PEP 556: Threaded garbage collection

On Fri, Sep 8, 2017, at 12:13, Antoine Pitrou wrote: > On Fri, 08 Sep 2017 12:04:10 -0700 > Benjamin Peterson <benja...@python.org> wrote: > > I like it overall. > > > > - I was wondering what happens during interpreter shutdown. I see you > > have that list

Re: [Python-Dev] PEP 556: Threaded garbage collection

On Fri, Sep 8, 2017, at 12:24, Larry Hastings wrote: > > > On 09/08/2017 12:04 PM, Benjamin Peterson wrote: > > - Why not run all (Python) finalizers on the thread and not just ones > > from cycles? > > Two reasons: > > 1. Because some code relies on the fin

Re: [Python-Dev] PEP 556: Threaded garbage collection

I like it overall. - I was wondering what happens during interpreter shutdown. I see you have that listed as a open issue. How about simply shutting down the finalization thread and not guaranteeing that finalizers are actually ever run à la Java? - Why not run all (Python) finalizers on the

Re: [Python-Dev] PEP 552: deterministic pycs

Thank you all for the feedback. I've now updated the PEP to specify a 4-word pyc header with a bit field in every case. On Fri, Sep 8, 2017, at 09:43, Nick Coghlan wrote: > On 8 September 2017 at 07:55, Antoine Pitrou wrote: > > On Fri, 8 Sep 2017 07:49:46 -0700 > > Nick

Re: [Python-Dev] PEP 552: deterministic pycs

On Thu, Sep 7, 2017, at 16:58, Gregory P. Smith wrote: > +1 on this PEP. Thanks! > Questions: > > Input from OS package distributors would be interesting. Would they use > this? Which way would it impact their startup time (loading the .py file > vs just statting it. does that even matter?

Re: [Python-Dev] PEP 552: deterministic pycs

On Thu, Sep 7, 2017, at 14:43, Guido van Rossum wrote: > On Thu, Sep 7, 2017 at 2:40 PM, Benjamin Peterson <benja...@python.org> > wrote: > > > > > > > On Thu, Sep 7, 2017, at 14:19, Guido van Rossum wrote: > > > Nice one. > > > > > >

Re: [Python-Dev] PEP 552: deterministic pycs

On Thu, Sep 7, 2017, at 14:54, Antoine Pitrou wrote: > On Thu, 07 Sep 2017 14:32:19 -0700 > Benjamin Peterson <benja...@python.org> wrote: > > > > > > Not sure how common that situation is (certainly the source tree wasn't > > > read-only when you ch

Re: [Python-Dev] PEP 552: deterministic pycs

On Thu, Sep 7, 2017, at 14:19, Guido van Rossum wrote: > Nice one. > > It would be nice to specify the various APIs needed as well. The compileall and py_compile ones? > > Why do you keep the mtime-based format as an option? (Maybe because it's > faster? Did you measure it?) I haven't

Re: [Python-Dev] PEP 552: deterministic pycs

On Thu, Sep 7, 2017, at 14:21, Antoine Pitrou wrote: > On Thu, 07 Sep 2017 14:08:58 -0700 > Benjamin Peterson <benja...@python.org> wrote: > > On Thu, Sep 7, 2017, at 14:00, Antoine Pitrou wrote: > > > On Thu, 07 Sep 2017 13:39:21 -0700 > > > Benjamin

Re: [Python-Dev] PEP 552: deterministic pycs

On Thu, Sep 7, 2017, at 14:19, Freddy Rietdijk wrote: > > The main objection to that model is that it requires modifying source > timestamps, which isn't possible for builds on read-only source trees. > > Why not set the source timestamps of the source trees to say 1 first? If the source-tree

Re: [Python-Dev] PEP 552: deterministic pycs

On Thu, Sep 7, 2017, at 14:00, Antoine Pitrou wrote: > On Thu, 07 Sep 2017 13:39:21 -0700 > Benjamin Peterson <benja...@python.org> wrote: > > Hello, > > I've written a short PEP about an import extension to allow pycs to be > > more deterministic by optional repla

[Python-Dev] PEP 552: deterministic pycs

Hello, I've written a short PEP about an import extension to allow pycs to be more deterministic by optional replacing the timestamp with a hash of the source file: https://www.python.org/dev/peps/pep-0552/ Thanks for reading, Benjamin P.S. I came up with the idea for this PEP while awake.

Re: [Python-Dev] Consolidate stateful runtime globals

On Wed, Sep 6, 2017, at 10:08, Antoine Pitrou wrote: > On Wed, 06 Sep 2017 09:42:29 -0700 > Benjamin Peterson <benja...@python.org> wrote: > > On Wed, Sep 6, 2017, at 03:14, Antoine Pitrou wrote: > > > > > > Hello, > > > > > > I'm a bit c

Re: [Python-Dev] Consolidate stateful runtime globals

On Wed, Sep 6, 2017, at 03:14, Antoine Pitrou wrote: > > Hello, > > I'm a bit concerned about > https://github.com/python/cpython/commit/76d5abc8684bac4f2fc7cccfe2cd940923357351 > > My main gripe is that makes writing C code more tedious. Simple C > global variables such as "_once_registry"

Re: [Python-Dev] PEP 553: Built-in debug()

On Tue, Sep 5, 2017, at 19:57, Steven D'Aprano wrote: > Sorry, are we to interpret this as you asking that the PEP be rejected? > I can't tell whether you are being poetic and actually think the PEP is > a good idea, or whether you have written it to have it rejected and > prevent anyone else

[Python-Dev] removing IRIX support

Since IRIX was EOLed in 2013, I propose support for it be removed in Python 3.7. I will add it to PEP 11. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

[Python-Dev] [RELEASE] Python 2.7.14 release candidate 1

I'm happy to announce the immediate availability of Python 2.7.14 release candidate 1, a testing release for the latest bugfix release in the Python 2.7 series. Downloads of source code and binaries are at https://www.python.org/downloads/release/python-2714rc1/ Please consider testing the

[Python-Dev] 2.7.14 schedule

Hi all, I've set the 2.7.14 release schedule. There will be a release candidate on August 26 with a planned final for September 16. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] Am I allowed to use C++-style // comments?

On Tue, Jul 25, 2017, at 21:59, Devin Jeanpierre wrote: > https://www.python.org/dev/peps/pep-0007/ says two things: > > > Python versions greater than or equal to 3.6 use C89 with several select > > C99 features: > > [...] > > C++-style line comments This section overrides further edicts in

[Python-Dev] On "PEP 546 — Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7"

The reason we're having this conversation at all is probably a matter of timing. If MemoryBIO was in Python 3 when PEP 466 was accepted, it surely would have come along for the ride to 2.7. I believe PEP 466 is generally considered to have produced positive results. PEP 546, carrying no breaking

Re: [Python-Dev] PEP 7 and braces { .... } on if

Modern GCC can defend against these kinds of problems. If I introduce a "goto fail" bug somewhere in Python, I get a nice warning: ../Objects/abstract.c: In function ‘PyObject_Type’: ../Objects/abstract.c:35:5: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] if (o ==

Re: [Python-Dev] Py_SIZE vs PyXXX_GET_SIZE

On Mon, Mar 20, 2017, at 13:18, Antoine Pitrou wrote: > On Mon, 20 Mar 2017 13:26:34 +0200 > Serhiy Storchaka wrote: > > What is the preferable way of getting the size of tuple, list, bytes, > > bytearray: Py_SIZE or PyTuple_GET_SIZE, PyList_GET_SIZE, > >

Re: [Python-Dev] Python FTP Injections Allow for Firewall Bypass (oss-security advisory)

On Thu, Feb 23, 2017, at 20:36, Steven D'Aprano wrote: > I haven't seen any response to the following alleged security > vulnerability. > > I am not qualified to judge the merits of this, but it does seem > worrying that (alledgedly) the Python security team hasn't responded for > over 12

Re: [Python-Dev] Can we use "designated initializer" widely in coremodules?

On Tue, Jan 17, 2017, at 15:34, Paul Moore wrote: > On 17 January 2017 at 20:02, Steve Dower wrote: > > Avoiding header files would be my only request. As Brett says, the C99 > > requirement should not be enforced on all embedders or extenders, so we > > should try and

Re: [Python-Dev] PEP 7 contradiction for comment style

Your assumption is correct. Perhaps the PEP 7 should be partitioned into "< 3.6" and "3.6" sections where applicable. On Mon, Jan 9, 2017, at 12:50, Brett Cannon wrote: > https://bugs.python.org/issue29215 noticed that PEP 7 says "C++-style > line > comments" are allowed, but then later says

[Python-Dev] [RELEASE] Python 2.7.13

: https://bugs.python.org/ 2.7.14 will appear mid-2017. All the best in the new year, Benjamin Peterson 2.7 release manager ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https

Re: [Python-Dev] Cleanup of abstract.h header

I think it looks better. Thank you. On Thu, Dec 15, 2016, at 02:22, Victor Stinner wrote: > Hi, > > I made multiple changes to the Include/abstract.h header file, because > it was inconsistent in different manners: > > * Parameter names of functions of the PyObject_Call family were >

[Python-Dev] [RELEASE] Python 2.7.13 release candidate 1

It is my pleasure to announce the first release candidate of Python 2.7.13, a new bugfix release in the Python 2.7x series. Downloads may be found on python.org: https://www.python.org/downloads/release/python-2713rc1/ Please test the release and report any bugs to

Re: [Python-Dev] Python 2.7.13 release dates

On Wed, Nov 30, 2016, at 10:19, Antoine Pitrou wrote: > On Tue, 29 Nov 2016 23:07:14 -0800 > Benjamin Peterson <benja...@python.org> wrote: > > Okay, now that we're heard from the other side, and I lacking a concrete > > reason to delay the release, I'm putting 2.7

Re: [Python-Dev] Python 2.7.13 release dates

the > > end of 2019, presumably)? I too would like to know the intended use of the > > extra time. > > > > Top-posted from my Windows Phone > > > > -Original Message- > > From: "Benjamin Peterson" <benja...@python.org> > > Sent

Re: [Python-Dev] Python 2.7.13 release dates

less stable depending on the release stage of Python 3. On Mon, Nov 28, 2016, at 20:50, Raymond Hettinger wrote: > > > On Nov 28, 2016, at 10:36 AM, Serhiy Storchaka <storch...@gmail.com> wrote: > > > > On 28.11.16 09:06, Benjamin Peterson wrote: > >> I

[Python-Dev] Python 2.7.13 release dates

I've have just updated PEP 373 to say that Python 2.7.13 release candidate 1 will be released on December 3. The final will follow two weeks later on December 17. If there are delays in the process, the final will likely to pushed into January. Servus, Benjamin

Re: [Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy

On Fri, Sep 23, 2016, at 09:32, Steven D'Aprano wrote: > On Thu, Sep 22, 2016 at 11:47:20PM -0700, Benjamin Peterson wrote: > > > > On Thu, Sep 22, 2016, at 04:44, Victor Stinner wrote: > > > 2016-09-22 8:02 GMT+02:00 Benjamin Peterson <benja...@python.org>: >

Re: [Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy

On Fri, Sep 23, 2016, at 00:04, Victor Stinner wrote: > 2016-09-23 8:47 GMT+02:00 Benjamin Peterson <benja...@python.org>: > > I'm being flippant here because of the triviality of the change. Anyone > > using Py_VA_COPY or Py_MEMCPY can fix their code in a backwards and &g

Re: [Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy

On Thu, Sep 22, 2016, at 04:44, Victor Stinner wrote: > 2016-09-22 8:02 GMT+02:00 Benjamin Peterson <benja...@python.org>: > > Just dump the compat macros in Python 4.0 I think. > > Please don't. Python 3 was so painful because we decided to make > millions of tiny backw

Re: [Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy

On Wed, Sep 21, 2016, at 03:42, Victor Stinner wrote: > I see that the old macro is now an alias to va_copy(). A similar change > was > done for Py_MEMCPY(). Would it make sense to put these old macros in a > new > backward_compat.h header, so maybe one day we can remove them? :-) That's fine

Re: [Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy

On Wed, Sep 21, 2016, at 02:06, Christian Heimes wrote: > On 2016-09-21 05:39, benjamin.peterson wrote: > > https://hg.python.org/cpython/rev/278b21d8e86e > > changeset: 103977:278b21d8e86e > > branch: 3.6 > > parent: 103975:d31b4de433b7 > > user

Re: [Python-Dev] [Python-checkins] cpython (2.7): properly handle the single null-byte file (closes #24022)

On Mon, Sep 19, 2016, at 01:35, Eric V. Smith wrote: > Shouldn't there be a test added for this? In fact, there is one: test_particularly_evil_undecodable in test_compile.py. No has managed to make Python crash by exploiting this particular problem—it's just ASan complaints.

Re: [Python-Dev] Python 3.6 what's new

Thank you. On Mon, Sep 12, 2016, at 16:21, Yury Selivanov wrote: > Hi, > > Elvis and I authored What's New in Python 3.5. We'd like to volunteer > to do the same for 3.6. If there are no objections, we can make the > first editing pass in a couple of weeks. > > Yury >

Re: [Python-Dev] Python 3.7: remove all private C functions from the Python C API?

That seems like a good idea in abstract. However, the boundaries will have to be delineated. Many functions beginning _Py are effectively part of the public API even for "well-behaved" 3rd-party extensions because they are used by magic macros. For example, _Py_Dealloc is used by Py_DECREF.

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On Thu, Sep 8, 2016, at 22:33, Tim Delaney wrote: > On 9 September 2016 at 07:45, Chris Angelico wrote: > > > On Fri, Sep 9, 2016 at 6:22 AM, Victor Stinner > > wrote: > > > A nice "side effect" of compact dict is that the dictionary now > > >

Re: [Python-Dev] (some) C99 added to PEP 7

On Thu, Sep 8, 2016, at 09:09, Chris Barker wrote: > > > - Standard integer types in and > > > > > > Yes, I will clarify we require the fixed-width types. > > > Does this mean that we might be able to have the built-in integer be > based > on int64_t now? so Windows64 and *nix64

Re: [Python-Dev] hg push segfault

On Thu, Sep 8, 2016, at 02:10, Christian Heimes wrote: > Hi, > > About 10 minutes ago I got a couple of remote segfaults from > hg.python.org. They occurred during push and pull operations: > > $ hg push > pushing to ssh://h...@hg.python.org/cpython > remote: bash: line 1: 25019 Segmentation

  1   2   3   4   5   6   7   8   9   10   >