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

I should quickly mention that future workflow-related stuff in regards to https://www.python.org/dev/peps/pep-0512 and the move to GitHub (e.g. CI), happens on the core-workflow mailing list. On Mon, 4 Jul 2016 at 15:35 Steve Dower wrote: > On 04Jul2016 0822, Kevin Ollivier wrote: > > On 7/4/16,

Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

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 > >as it makes for too many entries in third party

Re: [Python-Dev] Breaking up the stdlib (Was: release cadence)

On Tue, 5 Jul 2016 at 13:02 Paul Moore wrote: > On 5 July 2016 at 19:01, Petr Viktorin wrote: > > There are people who want to cut out what they don't need – to build > > self-contained applications (pyinstaller, Python for Android), or to > > eliminate unnecessary dependencies (python3-tkinter)

Re: [Python-Dev] Breaking up the stdlib (Was: release cadence)

On Tue, 5 Jul 2016 at 18:16 Nick Coghlan wrote: > On 6 July 2016 at 07:04, Brett Cannon wrote: > > Realizing that all of these are just proposals with no solid plan behind > > them, they are all predicated on moving to GitHub, and none of these are > > directly promoting r

Re: [Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules

On Sat, 9 Jul 2016 at 06:52 Nick Coghlan wrote: > I'm in the process of trying to disentangle > http://bugs.python.org/issue27137 which points out some of the > behavioural differences that arise when falling back from the original > C implementation of functools.partial to the pure Python emulat

Re: [Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules

On Mon, 11 Jul 2016 at 09:06 Paul Moore wrote: > On 11 July 2016 at 14:11, Steven D'Aprano wrote: > > But generalising this to all possibly mismatches between a C class > > implementation and a Python function implementation doesn't necessarily > > follow. Raymond's general point about simplicit

Re: [Python-Dev] Python CFG Basic blocks

On Mon, 11 Jul 2016 at 14:02 Obiesie ike-nwosu via Python-Dev < python-dev@python.org> wrote: > Hi, > > I am looking into how the python compiler generates basic blocks during > the CFG generation process and my expectations from CFG theory seems to be > at odds with how the python compiler actual

Re: [Python-Dev] Status of Python 3.6 PEPs?

On Tue, 12 Jul 2016 at 02:27 Victor Stinner wrote: > Hi, > > I see many PEPs accepted for Python 3.6, or stil in draft status, but > only a few final PEPs. What is happening? > > [SNIP] > > "PEP 519 -- Adding a file system path protocol" > https://www.python.org/dev/peps/pep-0519/ > => accept

Re: [Python-Dev] PEP487: Simpler customization of class creation

On Thu, 14 Jul 2016 at 11:05 Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/14/2016 11:47 AM, Guido van Rossum wrote: > > > If you intend a PR as a base for discussion you can add a comment > > saying e.g. "Don't merge yet". If you call out @gvanrossum, GitHub > >

Re: [Python-Dev] PEP 467: next round

On Mon, 18 Jul 2016 at 14:35 Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > > On Mon, Jul 18, 2016 at 5:01 PM, Jonathan Goble > wrote: > >> full(), despite its use in numpy, is also unintuitive to me (my first >> thought is that it would indicate whether an object has room for mo

Re: [Python-Dev] PEP 467: next round

On Mon, 18 Jul 2016 at 15:49 Random832 wrote: > On Mon, Jul 18, 2016, at 17:34, Alexander Belopolsky wrote: > > On Mon, Jul 18, 2016 at 5:01 PM, Jonathan Goble > > wrote: > > > > > full(), despite its use in numpy, is also unintuitive to me (my first > > > thought is that it would indicate wheth

[Python-Dev] The devguide is now hosted on GitHub

https://github.com/python/devguide I have also moved all issues over as well and hooked up Read The Docs so that there's a mirror which is always up-to-date (vs. docs.python.org/devguide which is on a cronjob). ___ Python-Dev mailing list Python-Dev@pyth

Re: [Python-Dev] The devguide is now hosted on GitHub

It's in the README of the repo, but it's http://cpython-devguide.readthedocs.io/ On Fri, 22 Jul 2016 at 14:09 Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/22/2016 04:04 PM, Brett Cannon wrote: > > https://github.com/python/devguide &

Re: [Python-Dev] The devguide is now hosted on GitHub

F to pay for a gold membership for the account (currently it's just my personal free account). -Brett > > On Fri, Jul 22, 2016, at 13:04, Brett Cannon wrote: > > https://github.com/python/devguide > > > > I have also moved all issues over as well and hooked up Read The

Re: [Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

On Sat, 23 Jul 2016 at 05:27 Ronald Oussoren wrote: > [SNIP] > > What is the best way forward after that? As before this is a change in > behavior that, unsurprisingly, few core devs appear to be comfortable with > evaluating, combined with new functionality that will likely see little use > be

Re: [Python-Dev] Status of the Argument Clinic DSL

On Thu, 4 Aug 2016 at 09:14 Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > What is the current status of the Argument Clinic DSL? The clinic > preprocessor was released [1] with Python 3.4 with a promise [2] "that > signature metadata for programmatic introspection will be added

Re: [Python-Dev] Status of the Argument Clinic DSL

On Thu, 4 Aug 2016 at 15:47 Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > > On Thu, Aug 4, 2016 at 2:19 PM, Larry Hastings wrote: > >> AFAIK the Clinic DSL can handle all of Python's C extensions. I have no >> plans to "revise the whole approach"; if someone else does I haven't

Re: [Python-Dev] C99

Where did we finally land on this discussion? Do we want to update PEP 7 to say that starting in 3.6 we may use C99 features common to all supported compilers and list what those compilers are (i.e. gcc, clang, and MSVC)? On Wed, 8 Jun 2016 at 01:28 Victor Stinner wrote: > I guess that as usual,

Re: [Python-Dev] C99

ng window of support based on what was available at the time of release for Python instead of the "what was available Aug 2016" static specification that you said you wanted. > > On Fri, Aug 5, 2016 at 3:15 PM, Brett Cannon wrote: > > > > > > On Fri, 5 Aug 2016 at

Re: [Python-Dev] C99

the current/last Python is/was released (e.g. whatever version of MSVC Steve uses to build the binaries for 3.5 or 3.6 in our current case)? > > On Fri, Aug 5, 2016 at 2:04 PM, Brett Cannon wrote: > > Where did we finally land on this discussion? Do we want to update PEP 7 > to >

Re: [Python-Dev] C99

On Sat, 6 Aug 2016 at 10:16 Ned Deily wrote: > On Aug 6, 2016, at 00:04, Guido van Rossum wrote: > > Different question. What features are we actually talking about? Is it > > possible to enumerate them? > > > > The only thing I'm aware of is declarations following non-declarations > > in the sa

Re: [Python-Dev] libmpdec already uses and compiles with -std=c99 -pedantic everywhere

On Sun, 7 Aug 2016 at 08:24 Stefan Krah wrote: > > The following C99 features are supported by any buildbot compiler > (including > obscure ones on snakebite): > > - stdint.h > > - static inline functions in header files > > - extern inline functions (not really necessary for CPython) > >

Re: [Python-Dev] Review request: issue 10910, pyport.h causes trouble for C++ extensions on BSDs

On Mon, 8 Aug 2016 at 08:10 tdsmith wrote: > Hi python-dev! I'm a maintainer for Homebrew, a third-party package > manager for OS X, where I'm the resident parseltongue. > > Issue 10910 is related to problems building CPython extension modules > with C++ code on BSDs. As I understand it, pyport.h

Re: [Python-Dev] New calling convention to avoid temporarily tuples when calling functions

I just wanted to say I'm excited about this and I'm glad someone is taking advantage of what Argument Clinic allows for and what I know Larry had initially hoped AC would make happen! I should also point out that Serhiy has a patch for faster keyword argument parsing thanks to AC: http://bugs.pyth

Re: [Python-Dev] Changing the licence of statistics.py

Are you the sole author of the statistics module prior to contributing it, Steve? On Sat, Aug 13, 2016, 21:21 Steven D'Aprano wrote: > I'm the author of statistics.py, and for historical reasons it was > originally included in the standard library under the Apache licence. > > I now wish to chan

Re: [Python-Dev] {RELEASE] Python 3.6.0a4 is now available

Please don't cross-post as it means anyone replying to your email will now split the conversation as not everyone will be subscribed to all of the mailing lists you sent this to. I have stripped out all but python-dev for my reply. On Wed, 17 Aug 2016 at 09:47 Philipp A. wrote: > hi, i already p

Re: [Python-Dev] {RELEASE] Python 3.6.0a4 is now available

On Wed, 17 Aug 2016 at 10:58 Philipp A. wrote: > Brett Cannon schrieb am Mi., 17. Aug. 2016 um > 19:15 Uhr: > >> Please don't cross-post as it means anyone replying to your email will >> now split the conversation as not everyone will be subscribed to all of the >

Re: [Python-Dev] Failures in test_site.py - how to debug?

On Fri, 19 Aug 2016 at 09:47 Chris Angelico wrote: > On Sat, Aug 20, 2016 at 2:25 AM, Steve Dower > wrote: > > On 19Aug2016 0910, Chris Angelico wrote: > >> > >> On Sat, Aug 20, 2016 at 1:26 AM, Steve Dower > >> wrote: > >>> > >>> Check any .pth files you can find. I suspect mpl_toolkits has so

Re: [Python-Dev] Failures in test_site.py - how to debug?

On Fri, 19 Aug 2016 at 14:11 Chris Angelico wrote: > On Sat, Aug 20, 2016 at 5:33 AM, Brett Cannon wrote: > >> Hmmm. So the question is, what is this test testing? > > > > > > It's making sure people who work on the modules that are imported during > &g

Re: [Python-Dev] Supported versions of OpenSSL

On Mon, 29 Aug 2016 at 09:34 Cory Benfield wrote: > > > On 29 Aug 2016, at 04:09, M.-A. Lemburg wrote: > > > > On 28.08.2016 22:40, Christian Heimes wrote: > >> ... > >> I like to reduce the maintenance burden and list of supported OpenSSL > >> versions ASAP. OpenSSL has deprecated 0.9.8 and 1.0

[Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

For quick background for those that don't remember, part of PEP 523 proposed adding a co_extra field to code objects along with making the frame evaluation function pluggable ( https://www.python.org/dev/peps/pep-0523/#expanding-pycodeobject). The idea was that things like JITs and debuggers could

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

n Mon, Aug 29, 2016 at 3:28 PM, Christian Heimes > wrote: > > On 2016-08-29 23:38, Brett Cannon wrote: > >> That means we still want to find a solution to attach arbitrary data to > >> code objects without sacrificing performance. One proposal is what's in > >

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

iple use-cases. -Brett > > On Mon, Aug 29, 2016 at 11:38 PM, Brett Cannon wrote: > > For quick background for those that don't remember, part of PEP 523 > proposed > > adding a co_extra field to code objects along with making the frame > > evaluation function

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Mon, Aug 29, 2016, 17:06 Terry Reedy wrote: > On 8/29/2016 5:38 PM, Brett Cannon wrote: > > > who objected to the new field did either for memory ("it adds another > > pointer to the struct that won't be typically used"), or for conceptual > > reasons (&

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Tue, 30 Aug 2016 at 09:08 Antoine Pitrou wrote: > On Mon, 29 Aug 2016 21:38:19 + > Brett Cannon wrote: > > For quick background for those that don't remember, part of PEP 523 > > proposed adding a co_extra field to code objects along with making the > &

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Tue, 30 Aug 2016 at 01:20 Maciej Fijalkowski wrote: > On Tue, Aug 30, 2016 at 3:00 AM, Brett Cannon wrote: > > > > > > On Mon, Aug 29, 2016, 17:06 Terry Reedy wrote: > >> > >> On 8/29/2016 5:38 PM, Brett Cannon wrote: > >> > >> > w

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Tue, 30 Aug 2016 at 10:32 Antoine Pitrou wrote: > On Tue, 30 Aug 2016 17:14:31 + > Brett Cannon wrote: > > > > Depends on what vmprof chooses to do. Since the data is designed to be > > disposable it could decide it should always take precedence and overwrite >

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Tue, 30 Aug 2016 at 10:49 Antoine Pitrou wrote: > On Tue, 30 Aug 2016 17:35:35 + > Brett Cannon wrote: > > > > > > Perhaps a list would work indeed. Realistically, if there are at most > > > 2-3 users of the field at any given time (and most probably

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Tue, 30 Aug 2016 at 11:56 Serhiy Storchaka wrote: > On 30.08.16 21:20, Antoine Pitrou wrote: > > On Tue, 30 Aug 2016 18:12:01 + > > Brett Cannon wrote: > >>> Why not make it always a list? List objects are reasonably cheap in > >>>

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On Tue, 30 Aug 2016 at 14:21 Guido van Rossum wrote: > I'm happy to present PEP 526 for your collective review: > https://www.python.org/dev/peps/pep-0526/ (HTML) > https://github.com/python/peps/blob/master/pep-0526.txt (source) > > There's also an implementation ready: > https://github.com/ilev

Re: [Python-Dev] Supported versions of OpenSSL

I think it's time for this thread to stop as everyone seems to be talking in circles. Christian said he's going to write a PEP so let's wait for that before discussing this any further so we have a concrete proposal to focus around. On Wed, 31 Aug 2016 at 05:04 Nick Coghlan wrote: > On 31 August

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

; > code objects > > > > On Wed, Aug 31, 2016 at 4:55 AM, Serhiy Storchaka > > wrote: > > > On 30.08.16 21:20, Antoine Pitrou wrote: > > >> > > >> On Tue, 30 Aug 2016 18:12:01 + > > >> Brett Cannon wrote: > > >>>> &

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Fri, 2 Sep 2016 at 15:11 Chris Angelico wrote: > On Sat, Sep 3, 2016 at 7:56 AM, Brett Cannon wrote: > > On Fri, 2 Sep 2016 at 13:31 Dino Viehland via Python-Dev > > wrote: > >> > >> So it looks like both list and tuple are about within 5% of using > co

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Fri, 2 Sep 2016 at 17:37 MRAB wrote: > On 2016-09-02 23:45, Brett Cannon wrote: > > > > > > On Fri, 2 Sep 2016 at 15:11 Chris Angelico > <mailto:ros...@gmail.com>> wrote: > > > > On Sat, Sep 3, 2016 at 7:56 AM, Brett Cannon > <mailt

[Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

Below is the `co_extra` section of PEP 523 with the update saying that users are expected to put a tuple in the field for easier simultaneous use of the field. Since the `co_extra` discussions do not affect CPython itself I'm planning on landing the changes stemming from the PEP probably on Monday

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On Sat, 3 Sep 2016 at 16:43 Yury Selivanov wrote: > > > On 2016-09-03 4:15 PM, Christian Heimes wrote: > > On 2016-09-04 00:03, Yury Selivanov wrote: > >> > >> On 2016-09-03 12:27 PM, Brett Cannon wrote: > >>> Below is the `co_extra` section of PEP 52

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On Sat, 3 Sep 2016 at 16:55 Yury Selivanov wrote: > > > On 2016-09-03 4:13 PM, Chris Angelico wrote: > > On Sun, Sep 4, 2016 at 8:03 AM, Yury Selivanov > wrote: > >> On 2016-09-03 12:27 PM, Brett Cannon wrote: > >>> Below is the `co_extra` section

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On Sat, 3 Sep 2016 at 17:27 Yury Selivanov wrote: > > On 2016-09-03 5:19 PM, Brett Cannon wrote: > > > > > > On Sat, 3 Sep 2016 at 16:43 Yury Selivanov > <mailto:yselivanov...@gmail.com>> wrote: > > > > > > > > On 2016-09-03 4:

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

Great, thanks! On Sat, Sep 3, 2016, 17:59 Guido van Rossum wrote: > Brett, I have not followed everything here but I have no problem with > tweaks at this level as long as you are happy with it. > > --Guido (mobile) > > On Sep 3, 2016 5:39 PM, "Brett Cannon" wro

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On Sat, Sep 3, 2016, 17:45 Yury Selivanov wrote: > > > > > But without that new API (basically what Christian proposed) you'd > > need > > to iterate over the list in order to find the object that belongs to > > Pyjion. > > > > > > Yes. > > Yeah, which means the same for my opcode

Re: [Python-Dev] Commits to migrated repos no longer sent to Python-checkins

On Wed, 7 Sep 2016 at 14:24 Emanuel Barry wrote: > The repos which used to send to Python-checkins no longer do so since their > respective migrations (devguide, peps). I don't know who's responsible for > that, so I figured I'd post here. > If people want those back on then that could be arrang

Re: [Python-Dev] Commits to migrated repos no longer sent to Python-checkins

could simply subscribe to the GitHub repos and get the notifications for > free :) > Yep, you can always watch the projects as well. I just didn't suggest it as people have so far told me they viewed it as overkill when they just wanted commits. -Brett > > > -Emanuel > &g

Re: [Python-Dev] PEP 529: Change Windows filesystem encoding to UTF-8

On Thu, 8 Sep 2016 at 09:06 Chris Barker wrote: > On Wed, Sep 7, 2016 at 10:37 AM, Guido van Rossum > wrote: > >> And apart from Python, few shell commands that work on >> Unix make much sense on Windows, > > > Does the (optional) addition of bash to Windows 10 have any impact on this? > > It'll

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

On Fri, 9 Sep 2016 at 01:58 Antoine Pitrou wrote: > On Thu, 8 Sep 2016 14:20:53 -0700 > Victor Stinner wrote: > > 2016-09-08 13:36 GMT-07:00 Guido van Rossum : > > > IIUC there's one small thing we might still want to change somewhere > > > after 3.6b1 but before 3.6rc1: the order is not preserv

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

On Fri, 9 Sep 2016 at 10:28 Victor Stinner wrote: > 2016-09-09 10:17 GMT-07:00 Guido van Rossum : > > - keyword args are ordered > > - the namespace passed to a metaclass is ordered by definition order > > - ditto for the class __dict__ > > Maybe we should define exactly "ordered" somewhere the l

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

In general I support cleaning up our C API to more clearly delineate the boundaries of what people can rely on and what they shouldn't. Could we go farther and do the same separation of the base and limited API at the header level instead of interleaving through #ifndef? On Sun, Sep 11, 2016, 01:

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

On Mon, 12 Sep 2016 at 15:46 Ethan Furman wrote: > On 09/12/2016 09:27 AM, Gregory P. Smith wrote: > > > For the regular dict (non kwargs or namespace __dict__) use case I would > actually like to /see disorder preserved during iteration/. > > > > If we don't, we will eventually to find ourselves

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

On Mon, 12 Sep 2016 at 16:52 Tim Delaney wrote: > On 10 September 2016 at 03:17, Guido van Rossum wrote: > >> I've been asked about this. Here's my opinion on the letter of the law in >> 3.6: >> >> - keyword args are ordered >> - the namespace passed to a metaclass is ordered by definition order

Re: [Python-Dev] Can CPython on GitHub use the "Merge" button on pull requests (now that they support "squash and merge")?

On Tue, 13 Sep 2016 at 13:56 Ben Hoyt wrote: > I noticed in [PEP 512 - Document steps to commit a pull request]( > https://www.python.org/dev/peps/pep-0512/#document-steps-to-commit-a-pull-request) > it says that CPython on GitHub won't be able to use GitHub's "Merge" button > on pull requests, b

Re: [Python-Dev] OpenIndiana and Solaris support

On Mon, 26 Sep 2016 at 15:38 Guido van Rossum wrote: > Thanks for the reality check Trent! I think if enough people with core > committer bits want to keep supporting Solaris / Illumos / OpenIndiana > / other variants that's fine, but I don't think that just having some > VMs to test on is enough

Re: [Python-Dev] Have I got my hg dependencies correct?

On Thu, 20 Oct 2016 at 04:48 Skip Montanaro wrote: > I've recently run into a problem building the math and cmath modules > for 2.7. (I don't rebuild very often, so this problem might have been > around for awhile.) My hg repos look like this: > > * My cpython repo pulls from https://hg.python.or

Re: [Python-Dev] Recent changes to PyCodeObject

I know you got your answer to why the change occurred, but a patch to update any outdated comments would be appreciated. :) On Thu, 17 Nov 2016 at 07:55 Ned Batchelder wrote: > On 11/17/16 10:09 AM, Cody Piersall wrote: > > On Wed, Nov 16, 2016 at 6:18 PM, Ned Batchelder > wrote: > >> When I ad

[Python-Dev] Checking over the devguide before the GitHub migration

With Python 3.6.0 quickly approaching it means the GitHub migration should also be happening sometime soon (basically as soon as all pieces are in place and we're sure we won't be doing an emergency 3.6.1 release, so probably either this month or next). While we wait for that to occur, if people wa

[Python-Dev] New core-workflow issue tracker

I have created https://github.com/python/core-workflow to track plans and ideas for our workflow. Discussions will continue on the core-workflow mailing list, but since there are things to plan and this sort of thing doesn't really belong on bugs.python.org I figured a separate tracker would be bes

[Python-Dev] Blockers on GitHub migration and open windows to migrate

[sending this independently to python-dev and core-workflow] I have promised Ned that we will not migrate before 3.6.0 is released and not for a week following in case an emergency 3.6.1 is necessary. I also promised Larry we wouldn't migrate the week before 3.5.3 is released. That means the windo

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

I have updated the porting HOWTO to drop recommending unicode_literals and also to mention running optional type checkers like mypy and pytype twice (once under Python 2 and again under Python 3). On Fri, 16 Dec 2016 at 11:25 Guido van Rossum wrote: > I am beginning to think that `from __future_

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

On Mon, 19 Dec 2016 at 06:29 Terry Reedy wrote: > On 12/19/2016 12:26 AM, 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 a

Re: [Python-Dev] PySlice_GetIndicesEx annd stable ABI: bikeshedding

On Wed, 21 Dec 2016 at 06:52 Serhiy Storchaka wrote: > [SNIP] > Let's start bikeshedding. What are your ideas about names and the order > of arguments of two following functions? > > 1. Takes a slice object, returns it's start, stop and step as Py_ssize_t > values. Can fail. > start, stop, step

Re: [Python-Dev] Python related issue

In the bug it was suggested you post to python-list for help. Have you done that? (this is python-dev, not python-list). On Thu, 22 Dec 2016 at 14:39 Manish Singh wrote: > Hi All, > > Please see below issue. Please reply on bug > http://bugs.python.org/issue28968 > > > [ Issue ] > I have used xm

Re: [Python-Dev] Document C API that is not part of the limited API

On Tue, 27 Dec 2016 at 12:15 Ronald Oussoren wrote: > > > On 27 Dec 2016, at 20:04, Serhiy Storchaka wrote: > > > > From the documentation: > > > > https://docs.python.org/3/c-api/stable.html > > > >In the C API documentation, API elements that are not part of the > limited API are marked as

[Python-Dev] PEP 7 contradiction for comment style

https://bugs.python.org/issue29215 noticed that PEP 7 says "C++-style line comments" are allowed, but then later says "Never use C++ style // one-line comments." I'm assuming we are sticking with allowing C++-style comments and the "never" link just needs an addendum to say that only applies to cod

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

> 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 "Never use C++ style // > > one-line > > comments." I'm assumi

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

On Mon, 16 Jan 2017 at 22:34 INADA Naoki wrote: > Hi. > > --- > This discussion is started in http://bugs.python.org/issue29259, and > there is separated issue at http://bugs.python.org/issue29260 . > But I want to see more comments, before issue 29259 is committed. > --- > > Since Python 3.6, so

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

On Tue, 17 Jan 2017 at 18:36 Nathaniel Smith wrote: > On Tue, Jan 17, 2017 at 4:48 PM, INADA Naoki > wrote: > > On Wed, Jan 18, 2017 at 8:48 AM, Larry Hastings > wrote: > >> > >> On 01/17/2017 12:02 PM, Steve Dower wrote: > >> > >> Avoiding header files would be my only request. As Brett says,

[Python-Dev] Update on the GitHub migration

The last blocker is updating issues on bugs.python.org when a commit is made that references an issue (Maciej is working on it, although as usual I'm sure help is welcome). Once that's in then it will be time to choose a date to stop commits and do the conversion. Once that's done it will be a bunc

Re: [Python-Dev] Hello World

In case you haven't already done so, Ramsey, please consider reading https://cpython-devguide.readthedocs.io if you want to contribute to the project. You can also subscribe to the core-mentorship mailing list which is specifically for people who want to help out but haven't done to previously. On

Re: [Python-Dev] Investigating Python memory footprint of one real Web application

On Mon, 23 Jan 2017 at 04:27 INADA Naoki wrote: > On Mon, Jan 23, 2017 at 8:33 PM, Victor Stinner > wrote: > > 2017-01-23 12:25 GMT+01:00 INADA Naoki : > >> I gave advice to use 'List[User]' instead of List[User] to the team of > >> the project, > >> if the team think RAM usage or boot speed is

Re: [Python-Dev] re performance

On Fri, 27 Jan 2017 at 13:26 MRAB wrote: > On 2017-01-27 17:03, Łukasz Langa wrote: > > > >> On Jan 26, 2017, at 5:16 PM, MRAB >> > wrote: > > > >>> So, it seems as if regex already uses a better algorithm although I > >>> couldn't find any reference to any reg

Re: [Python-Dev] Generator objects and list comprehensions?

On Sun, 29 Jan 2017 at 16:39 Craig Rodrigues wrote: > On Thu, Jan 26, 2017 at 4:09 AM, Ivan Levkivskyi > wrote: > > > > Concerning list/set/dict comprehensions, I am much more in favor of making > comprehensions simply equivalent to for-loops (more or less like you > proposed using yield from).

[Python-Dev] modules people want installed automatically (was: Re: re performance)

On Mon, 30 Jan 2017 at 06:27 Barry Warsaw wrote: > On Jan 30, 2017, at 12:38 PM, Nick Coghlan wrote: > > >I think there are 3 main candidates that could fit that bill: > > > >- requests > >- setuptools > >- regex > > Actually, I think pkg_resources would make an excellent candidate. The > setupt

Re: [Python-Dev] modules people want installed automatically (was: Re: re performance)

when available, so I don't think it's appropriate to bring the name into the stdlib. On Mon, Jan 30, 2017, 10:28 Barry Warsaw, wrote: > On Jan 30, 2017, at 06:14 PM, Brett Cannon wrote: > > >What functionality are you after here from pkg_resources? If it's the > >r

[Python-Dev] Heads up: possible double-comments on bpo for commits

I've activated the webhook for receiving comments on issues when a commit lands mentioning an issue, so if you see a commit from our hg integration and another from GitHub, understand that's why (mention issues as "bpo " in commit messages if you want to see it in action). If it becomes too muc

[Python-Dev] GitHub migration scheduled for Friday

To let the non-core devs know, the GitHub migration will be happening this Friday. For those of you who use the current GitHub mirror to create patches, do be aware that the hashes will most likely be changing so don't expect your checkout to work past Thursday (you can always generate a patch and

Re: [Python-Dev] GitHub migration scheduled for Friday

On Tue, 7 Feb 2017 at 11:17 Jim F.Hilliard wrote: > That's great, congratulations! I believe this change will make it way > easier for people to get involved! > > A small question, since people can now submit new issues via pulls instead > of going to bugs.python.org, what will be the purpose of

Re: [Python-Dev] GitHub migration scheduled for Friday

On Tue, 7 Feb 2017 at 23:38 Victor Stinner wrote: > 2017-02-08 8:35 GMT+01:00 Victor Stinner : > > I'm sure the patch author would appreciate it, but I don't think we > > need to require it as we have gone this long without it. > > I know that different people have different expectation on GitHub

Re: [Python-Dev] GitHub migration scheduled for Friday

On Wed, 8 Feb 2017 at 12:33 Terry Reedy wrote: > On 2/8/2017 2:38 AM, Victor Stinner wrote: > > > I know that different people have different expectation on GitHub. I > > would like to take the opportunity of migrating to Git to use the > > "author" and "committer" fields. If the author is set to

Re: [Python-Dev] GitHub migration scheduled for Friday

On Wed, 8 Feb 2017 at 13:33 Victor Stinner wrote: > 2017-02-08 21:32 GMT+01:00 Terry Reedy : > > Many patches have multiple authors. Does the 'author' field allow that? > > Often, the committer adds missing chunks or rewrites the work with > various > > degrees of editing. Sometimes a read a pat

Re: [Python-Dev] GitHub migration scheduled for Friday

On Wed, 8 Feb 2017 at 15:04 Victor Stinner wrote: > 2017-02-08 23:42 GMT+01:00 Brett Cannon : > > Don't forget we are doing squash merges, > > Ah, I didn't know. Why not using merges? > Because other core devs wanted a linear history. This preference was very str

[Python-Dev] CPython is now on GitHub

[this is a duplicate of what I just sent python-committers; rendered version at https://paper.dropbox.com/doc/CPython-workflow-changes-mx1k8G6M0rg5JLy80F1r6 ] # CPython workflow changes After more than two years, our new GitHub workflow is ready to accept changes (you can look back to my first “[v

Re: [Python-Dev] bugs.python.org access problems

On Fri, 10 Feb 2017 at 16:06 Antoine Pitrou wrote: > On Fri, 10 Feb 2017 16:15:46 -0500 > Terry Reedy wrote: > > > Today I have been getting the following for about 1/3 of access > > attempts (with Firefox). > > ''' > > Secure Connection Failed > > > > An error occurred during a connection to b

Re: [Python-Dev] bugs.python.org access problems

I emailed the infrastructure team and Mark Mangoba replied back saying it's because the SSL cert is from StartCom which is in the process of being distrusted. They should have a new cert hopefully sometime today. On Sat, 11 Feb 2017 at 11:01 Brett Cannon wrote: > On Fri, 10 Feb 2017

Re: [Python-Dev] bugs.python.org access problems

ite up on Chrome I don't get the brief error page anymore. -Brett > > > Best regards, > Mark > > On Sat, Feb 11, 2017 at 11:09 AM, Brett Cannon wrote: > > I emailed the infrastructure team and Mark Mangoba replied back saying > it's because the SSL

Re: [Python-Dev] [Python-checkins] [python/cpython] 4538dd: Fix bpo-29528 Use a secure variable to stop spam (...

On Mon, 13 Feb 2017 at 07:10 Barry Warsaw wrote: > On Feb 11, 2017, at 08:11 PM, Andrew M. Kuchling wrote: > > >Are we planning to include the diffs in python-checkins e-mail, or are > >they gone for good? > > > >(While they made the list's messages and digests larger, I liked > >having the diffs

[Python-Dev] Update on labels to be used on GitHub

We now have two sets of labels for representing cherry-picking statuses: "backport to N.M" and "cherry-pick for N.M". The former are to help keep track of what branches a PR should be cherry-picked *to* and can be removed once the PR for a cherry-pick has been created (you can add a comment like "c

Re: [Python-Dev] Update on labels to be used on GitHub

On Mon, 13 Feb 2017 at 14:43 Victor Stinner wrote: > 2017-02-13 21:08 GMT+01:00 Brett Cannon : > > We now have two sets of labels for representing cherry-picking statuses: > > "backport to N.M" and "cherry-pick for N.M". The former are to help keep > &

Re: [Python-Dev] Update on labels to be used on GitHub

On Tue, 14 Feb 2017 at 10:13 MRAB wrote: > On 2017-02-14 17:58, Victor Stinner wrote: > > 2017-02-14 18:43 GMT+01:00 Zachary Ware : > >> To propose another color for the bikeshed, what about having labels > >> for each branch along with "needs backport" and "cherry-pick" labels? > > > > Oh right,

Re: [Python-Dev] cgi.FieldStorage with multipart/form-data tries to decode binary file as UTF-8 if "filename=" not specified

On Wed, 15 Feb 2017 at 08:14 Ben Hoyt wrote: > I posted this on StackOverflow [1], but I'm posting it here as well, as I > believe this is a bug (or at least quirk) in cgi.FieldStorage where you > can't access a file upload properly if "filename=" is not present in the > MIME part's Content-Dispo

Re: [Python-Dev] Translated Python documentation

On Fri, 24 Feb 2017 at 03:50 INADA Naoki wrote: > > Where should these translated docs live and how does one make it clear to > > users reading them that doc bugs shouldn't be submitted to the main bug > > tracker/github repo? > > > > We setup github page. See https://python-doc-ja.github.io/py3

Re: [Python-Dev] Split Misc/NEWS into individual files

On Wed, 22 Feb 2017 at 13:30 Ned Deily wrote: > On Feb 22, 2017, at 07:27, Victor Stinner > wrote: > > > [...]My idea is not new, it's already discussed in the Python > core-workflow: > > https://github.com/python/core-workflow/issues/6 > > > > I'm opening a thread on python-dev because Misc/NEW

Re: [Python-Dev] attributes of Python code objects

On Sun, 26 Feb 2017 at 02:20 Xavier de Gaye wrote: > In PR 218 [1], INADA Naoki wrote: > > I think attributes of Python's code object is implementation detail, > even > > though PyPy follows. > > But it's not big problem until there are some Python implementation > > having different code imp

<    7   8   9   10   11   12   13   14   15   16   >