Re: [Python-Dev] Removal of install_misc command from distutils

For referencing, the commit was https://github.com/python/cpython/commit/ef158c3ced3fce39e43f54e8d149dc2714e3456e#diff-ef2e84716aa6196aa0ebf0691e608986 and the issue was https://bugs.python.org/issue29218 . On Thu, 5 Jul 2018 at 11:27 Alexander Belopolsky < alexander.belopol...@gmail.com> wrote:

Re: [Python-Dev] PEP 484

On Wed, 4 Jul 2018 at 22:07 Greg Ewing wrote: > Shawn Chen wrote: > > The PEP 484 is proposing a type hint which can annotate the type of each > > parameters. How ever code written in this format can not be run for > > python3.5 and below. > > You're a bit late. Parameter annotations have been a

Re: [Python-Dev] Tone it down on Twitter?

While I agree with Antoine that the wording by Serhiy on Twitter was unnecessary, the tone in responses here are also unnecessary. As has been discussed both here on this mailing list and at the PyCon US language summit, reacting to actual or perceived rudeness with more rudeness is not reasonable

Re: [Python-Dev] Tone it down on Twitter?

On Wed, 4 Jul 2018 at 11:54 Mark Lawrence wrote: > On 04/07/18 16:48, Stefan Krah wrote: > > > > Apparently I have made it into "club of three who don't care much about > > opinions of others" for the crime of a single +0.5 for PEP-572 without > > participating in the discussion at all (neither d

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

On Fri, Jul 6, 2018, 16:32 Guido van Rossum, wrote: > On Fri, Jul 6, 2018 at 4:19 PM Terry Reedy wrote: > >> Since Guido, the first respondent, did not immediately shoot the idea >> down, I intend to flesh it out and make it more concrete. >> > > Maybe I should have shot it down. The term is ent

Re: [Python-Dev] PEP 575, 576, 579 and 580

On Sat, Jul 7, 2018, 08:17 INADA Naoki, wrote: > > IMO, mailing lists are a terrible way to do software design, but a good > > way to gather requirements as it makes less likely that someone will be > > forgotten. > > > > Agreed. There are several topics we should discuss for these PEPs. > Maili

Re: [Python-Dev] Time for 3.4.9 and 3.5.6

On Sun, Jul 8, 2018, 18:30 Eric V. Smith, wrote: > On 7/8/2018 8:35 PM, Terry Reedy wrote: > > On 7/8/2018 1:05 PM, Ivan Pozdeev via Python-Dev wrote: > >> I'll use this opportunity to remind you that 3.4 build is broken -- it > >> can't be built from start to installer with the instructions give

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

On Mon, 9 Jul 2018 at 12:05 Guido van Rossum wrote: > I think this is worth a try. > How far do we want to go with this? Update the docs? Update the grammar and/or code? I think the former is probably good enough for now to see if it takes, and if it does then we can talk about updating code to

Re: [Python-Dev] Question about PEP 484

On Mon, 16 Jul 2018 at 10:32 Adam Cataldo via Python-Dev < python-dev@python.org> wrote: > > > > > > *Hi Folks,Cc: Rebecca, pytypeThis is Adam Cataldo; I’m the engineering > manager for the Python team at Google. Rebecca Chen, our lead pytype > contributor, and I

Re: [Python-Dev] Fuzzing the Python standard library

On Tue, 17 Jul 2018 at 15:41 Nathaniel Smith wrote: > On Tue, Jul 17, 2018 at 9:44 AM, Jussi Judin wrote: > > * Exceptions that are something else than the documented ones. These > usually indicate an internal implementation issue. For example one would > not expect an UnicodeDecodeError from ne

Re: [Python-Dev] Tests failing on Windows with TESTFN

On Wed, 25 Jul 2018 at 15:16 Tim Golden wrote: > I'm just easing back into core development work by trying to get a > stable testing environment for Python development on Windows. > > One problem is that certain tests use support.TESTFN (a local directory > constructed from the pid) for output fi

Re: [Python-Dev] Tests failing on Windows with TESTFN

On Sat, Jul 28, 2018, 15:13 eryk sun, wrote: > On Sat, Jul 28, 2018 at 9:17 PM, Jeremy Kloth > wrote: > > > > *PLEASE*, don't use tempfile to create files/directories in tests. It > > is unfriendly to (Windows) buildbots. The current approach of > > directory-per-process ensures no test turds

Re: [Python-Dev] Testing C API

On Sun, Jul 29, 2018, 06:44 Serhiy Storchaka, wrote: > 29.07.18 15:39, Steve Dower пише: > > On 29Jul2018 1253, Serhiy Storchaka wrote: > >> The benefit is that it will be easier to run all C API tests at once, > >> and only them, and it will be clearer what C API is covered by tests. > >> The di

Re: [Python-Dev] Let's change to C API!

On Tue, 31 Jul 2018 at 10:32 Antoine Pitrou wrote: > > Well, I tried to subscribe to capi-sig, but I didn't get a > confirmation e-mail. > I subscribed yesterday without issue. I would email postmaster to try and find out what happened. -Brett > > Regards > > Antoine. > > > On Tue, 31 Jul 201

Re: [Python-Dev] test_zlib.py suggestion

Open an issue as this will surely get forgotten otherwise, then people can discuss on the issue how to handle this. On Wed, 1 Aug 2018 at 08:40 Michael wrote: > I have a build_bot running (yeah me!), and was surprised to see > test_zlib fail on AIX. > > There is not an issue with test_zlib, but

Re: [Python-Dev] [PEP 576/580] Comparing PEP 576 and 580

On Wed, 1 Aug 2018 at 07:47 Terry Reedy wrote: > On 8/1/2018 6:17 AM, Jeroen Demeyer wrote: > > On 2018-07-31 11:12, INADA Naoki wrote: > >> Any PEP won't be accepted in few month, because we don't have flow to > >> accept PEPs for now. > > > > Is that certain? I haven't been following the proces

Re: [Python-Dev] New _Py_InitializeFromConfig() function (PEP 432)

On Tue, 31 Jul 2018 at 15:16 Victor Stinner wrote: > Hi, > > I finished my work on the _PyCoreConfig structure: it's a C structure > in Include/pystate.h which has many fields used to configure Python > initialization. In Python 3.6 and older, these parameters were scatted > around the code, and

[Python-Dev] Using Cython for the stdlib (was: Let's change to C API!)

[new thread as this no longer has anything to do with Victor's proposal] On Tue, 31 Jul 2018 at 13:42 Stefan Behnel wrote: > Antoine Pitrou schrieb am 31.07.2018 um 09:45: > > On Tue, 31 Jul 2018 09:27:03 +0200 > > Jeroen Demeyer wrote: > >> On 2018-07-31 08:58, Antoine Pitrou wrote: > >>> I th

Re: [Python-Dev] Problem in importing python packages under python 3.6 environment

This mailing list is for the discussion of the development *of* Python, not its use. Your best bet for help is either a site like Stack Overflow or another mailing list like python-tutor or python-list. On Thu, 9 Aug 2018 at 08:30 Poornima .D. wrote: > Hi All, > > > I have limited knowledge on p

Re: [Python-Dev] unsolicited removal request

Chances are, Andrew click the unsubscribe link from an email reply that Abdur-Rahmaan made (this happens to me semi-regularly). On Mon, 20 Aug 2018 at 09:34 Abdur-Rahmaan Janhangeer wrote: > no idea, a mail popped up in my inbox ... > > > Abdur-Rahmaan Janhangeer > https://github.com/Abdur-rahma

Re: [Python-Dev] Starting to use gcc-8 on upstream Python project CI

So is the request simply to use gcc 8 instead of what Travis uses as the default gcc? IOW change https://github.com/python/cpython/blob/28853a249b1d0c890b7e9ca345290bb8c1756446/.travis.yml#L71 somehow to use gcc8 specifically? Since it's only used for the code coverage build I don't think anyone w

Re: [Python-Dev] New Subscriber

Hi, Kevin! This mailing list is actually about the development *of* Python, not *with* it. To have a discussion about GUI programming with Python is probably python-list is a better place to discuss this. On Sat, 1 Sep 2018 at 10:37 Kevin Kowitski via Python-Dev < python-dev@python.org> wrote: >

Re: [Python-Dev] New Subscriber

gt; Sent from my iPhone > > On Sep 1, 2018, at 1:48 PM, Brett Cannon wrote: > > Hi, Kevin! This mailing list is actually about the development *of* > Python, not *with* it. To have a discussion about GUI programming with > Python is probably python-list is a better place to disc

Re: [Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?

On Wed, 5 Sep 2018 at 04:56 Paul Moore wrote: > On Wed, 5 Sep 2018 at 12:24, Antoine Pitrou wrote: > > For some reason it seems to be located in a hidden directory > > (".github/appveyor.yml"). Not the most intuitive decision IMHO. > > Travis' own config file ".travis.yml" is still at repositor

Re: [Python-Dev] Official citation for Python

On Sun, 9 Sep 2018 at 20:55 Terry Reedy wrote: > On 9/9/2018 11:39 PM, Jacqueline Kazil wrote: > > Terry -- For clarification, the format question was not a style > > question. It was a reference to the one versus many that I wrote in the > > explainer. > > I don't know what you mean by this. > >

Re: [Python-Dev] Official citation for Python

On Sun, 16 Sep 2018 at 15:23 Jacqueline Kazil wrote: > RE: Why cite Python…. > > I would say that in this paper — > http://conference.scipy.org/proceedings/scipy2015/pdfs/jacqueline_kazil.pdf, > where we introduced a new library, we should have cited Python, because the > library was based in Pyt

Re: [Python-Dev] Communication channels

> Some core developers are also active on Twitter. Some ideas were first > > discussed on Twitter. You may want to follow some of them. Incomplete > > list of core devs that I follow: > > > > * Barry Warsaw: https://twitter.com/pumpichank > > * Brett Cannon: https://

Re: [Python-Dev] PEP 544 status (forked off "Petr Viktorin as BDFL-Delegate for PEP 580")

I think whatever governance we end up with would have named you BDFL-delegate anyway, Guido, so I think you're just taking the time machine for a spin again. ;) On Wed, 3 Oct 2018 at 09:40, Guido van Rossum wrote: > The process for PEP 544 is off-topic for that thread so I'm starting a new > one

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

I'm also fine with saying that keys in **kwargs that are not proper identifiers is an implementation detail. On Thu, 4 Oct 2018 at 02:20, Serhiy Storchaka wrote: > 04.10.18 11:56, Steven D'Aprano пише: > > While keyword arguments have to be identifiers, using **kwargs allows > > arbitrary string

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

On Wed, 3 Oct 2018 at 19:39, Benjamin Peterson wrote: > > > 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. >

Re: [Python-Dev] Some PRs to merge?

Of those 49 PRs, 18 are by core developers themselves, so 31 PRs are by external contributors that seem ready to be merged. There was a discussion at one point on core-workflow about changing the default "needs" label for PRs by core devs which in this instance would help with providing a search f

Re: [Python-Dev] Python Language Governance Proposals

On Tue, 23 Oct 2018 at 13:20, Jeroen Demeyer wrote: > What is the timeframe for the installation of the new governance? In > other words, when will it be possible to review PEPs? > PEP 8001 outlines the voting for the governance models which includes a planned schedule for that vote. After that

Re: [Python-Dev] PEP 543-conform TLS library

In case you never received a reply, you can try emailing Christian and Cory directly for an answer. On Fri, 26 Oct 2018 at 13:20, Mathias Laurin wrote: > Hello Python Dev, > > > I posted the following to python-ideas but here may be > a more suitable place. I apologize if cross posting > bother

Re: [Python-Dev] Get a running instance of the doc for a PR.

On Sun, 4 Nov 2018 at 14:49, Steven D'Aprano wrote: > On Sun, Nov 04, 2018 at 05:05:07PM +0100, Stephane Wirtel wrote: > > > >If I am making doc patches, shouldn't I be doing that *before* I > > >submit the PR? How else will I know that my changes haven't broken the > > >docs? > > > > You can use

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

On Wed, 14 Nov 2018 at 16:09, Gregory P. Smith wrote: > It seems like the discussion so far is: >> >> Victor: "I know people when people hear 'new API' they get scared and >> think we're going to do a Python-3-like breaking transition, but don't >> worry, we're never going to do that." >> Nathani

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

On Fri, 16 Nov 2018 at 10:11, Paul Moore wrote: > On Fri, 16 Nov 2018 at 17:49, Brett Cannon wrote: > > And Just to be clear, I totally support coming up with a totally > stripped-down C API as I have outlined above as that shouldn't be > controversial for any VM that wan

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

On Mon., Nov. 19, 2018, 14:04 Neil Schemenauer On 2018-11-19, Antoine Pitrou wrote: > > There are important use cases for the C API where it is desired to have > > fast type-specific access to Python objects such as tuples, ints, > > strings, etc. This is relied upon by modules such as _json and

Re: [Python-Dev] bpo-34532 status

To provide context, https://bugs.python.org/issue34532 is about making the Python launcher on Windows not return an error condition when using `py -0` (and probably `py --list` and `py --list-paths`). On Tue, 20 Nov 2018 at 08:29, Brendan Gerrity wrote: > Just wanted to check on bpo-34532/pr#903

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

Are we getting to the point that we want a compresslib like hashlib if we are going to be adding more compression algorithms? On Wed, 28 Nov 2018 at 08:44, Antoine Pitrou wrote: > On Wed, 28 Nov 2018 10:28:19 + > Jonathan Underwood wrote: > > Hi, > > > > I have for sometime maintained the P

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

On Wed, 28 Nov 2018 at 13:29, 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 for shout

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

On Thu, 29 Nov 2018 at 14:12, Andrew Svetlov wrote: > Neither http.client nor http.server doesn't support compression > (gzip/compress/deflate) at all. > I doubt if we want to add this feature: for client better to use requests > or, well, aiohttp. > The same for servers: almost any production re

Re: [Python-Dev] getting merge rights back on github

This is being dealt with. On Sun, 2 Dec 2018 at 08:28, Chris Withers wrote: > Hi All, > > It's been quite a long time since I last used my python commit rights, > and it appears they've evaporated in the move to GitHub. > > I'd like to get back into helping out, particularly with unittest.mock >

Re: [Python-Dev] [PyPI] Email verification

I've reported this to infrastructure@. On Wed., Dec. 5, 2018, 12:05 PyPI Someone, perhaps you, has added this email address (Python-dev@python.org) > to their PyPI account. > > If you wish to proceed with this request, click this link to verify your > email address >

Re: [Python-Dev] Compilation of "except FooExc as var" adds useless store

On Sun, 6 Jan 2019 at 10:26, Guido van Rossum wrote: > On Sun, Jan 6, 2019 at 9:40 AM Paul G wrote: > >> I am not familiar enough with the compiler logic, but would it be >> possible to optimize this away by detecting whether the bound name has >> already been deleted during the body of the exce

Re: [Python-Dev] Return type of datetime subclasses added to timedelta

On Sun, 6 Jan 2019 at 11:00, Paul Ganssle wrote: > I did address this in the original post - the assumption that the subclass > constructor will have the same arguments as the base constructor is baked > into many alternate constructors of datetime. I acknowledge that this is a > breaking change,

Re: [Python-Dev] AMD64 Windows8.1 Refleaks 3.x buildbot is back to green!

Thanks for tracking that down! Been bugging me as well and the one time I tried to figure it out I got no where, so kudos for sticking with it! On Wed, 9 Jan 2019 at 09:13, Victor Stinner wrote: > Hi, > > The "AMD64 Windows 8.1 Refleaks 3.x" buildbot (which hunts reference > leaks and memory lea

Re: [Python-Dev] Adding test.support.safe_rmpath()

On Thu, Feb 14, 2019 at 7:26 AM Giampaolo Rodola' wrote: > > > On Thu, Feb 14, 2019 at 4:03 PM Tim Golden wrote: > >> On 14/02/2019 14:56, Giampaolo Rodola' wrote: >> > >> > >> > On Thu, Feb 14, 2019 at 3:25 PM Eric Snow > > > wrote: >> > >> > On Thu, Feb

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

On Thu, Feb 14, 2019 at 7:50 AM Victor Stinner wrote: > Le jeu. 14 févr. 2019 à 14:38, Matthias Klose a écrit : > > Debian's concern about pointing python to python3 is that it will break > software > > after an upgrade. The current state seems is still the same that Debian > doesn't > > want t

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

On Thu, Feb 14, 2019 at 10:21 AM Gustavo Carneiro wrote: > > > On Thu, 14 Feb 2019 at 15:52, Victor Stinner wrote: > >> Le jeu. 14 févr. 2019 à 14:38, Matthias Klose a écrit : >> > Debian's concern about pointing python to python3 is that it will break >> software >> > after an upgrade. The cu

Re: [Python-Dev] new binary wheels PEP idea

Unfortunately you're still posted to the wrong list, Alexander. You want to mail distutils-...@python.org where packaging discussions occur. On Tue, Feb 19, 2019 at 8:19 AM Alexander Revin wrote: > Hi all, > > I have an idea regarding Python binary wheels on non-glibc platforms, > and it seems t

Re: [Python-Dev] Making PyInterpreterState an opaque type

On Tue, Feb 19, 2019 at 12:45 PM Steve Dower wrote: > On 19Feb2019 1141, Barry Warsaw wrote: > > Steve Dower wrote on 2/16/19 14:34:> > >> This is mostly about being able to assign blame when things break, so > >> I'm totally okay with extension modules that want to play with internals > >> decla

Re: [Python-Dev] Making PyInterpreterState an opaque type

On Thu, Feb 21, 2019 at 6:01 AM Armin Rigo wrote: > Hi, > > On Tue, 19 Feb 2019 at 13:12, Victor Stinner wrote: > > Please don't use &PyTuple_GET_ITEM() or _PyTuple_ITEMS(). It prevents > > to use a more efficient storage for tuple. Something like: > > > https://pythoncapi.readthedocs.io/optimiz

Re: [Python-Dev] Can I get a review for PR 10437?

While more reviewers never hurt, Victor has left at least one comment on the PR. On Thu, Feb 28, 2019 at 7:59 AM Kevin Adler wrote: > This PR has been open for nearly 3 months without any comment. Can I > please get someone to review it? > > PR link: https://github.com/python/cpython/pull/10437

Re: [Python-Dev] Addendum to PEP 530

Open an issue at https://github.com/python/steering-council/issues if you want the steering council to consider something. On Mon, Mar 4, 2019 at 9:38 AM Serhiy Storchaka wrote: > PEP 530 introduced support for asynchronous comprehensions. > > Comprehensions are implemented as local functions. T

[Python-Dev] PEPs from non-core devs now need a sponsor

The steering council has implemented a new idea called sponsors to the PEP process (added in https://github.com/python/peps/commit/c58d32c33bd06eb386d3f33963a1434510528f68). The thinking is that to help make sure PEPs from non-core developers receive appropriate guidance through the PEP process, a

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

On Mon, Mar 4, 2019 at 10:13 PM Jeroen Demeyer wrote: > Does this apply to existing draft PEPs or only new ones? > Only new ones; this is not retroactive. -Brett > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailm

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

On Tue, Mar 5, 2019 at 5:33 AM Jeroen Demeyer wrote: > On 2019-03-05 14:05, Calvin Spealman wrote: > > I'm worried this creates a gatekeeping perception that will scare away > > contributors. > It might, but if people are not prepared properly for the PEP process then it's best to spare them and

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

On Tue, Mar 5, 2019 at 3:36 AM Victor Stinner wrote: > Hi, > > Le mar. 5 mars 2019 à 02:53, Brett Cannon a écrit : > > The steering council has implemented a new idea called sponsors to the > PEP process (...). The thinking is that to help make sure PEPs from > non-co

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

On Tue, Mar 5, 2019 at 11:59 AM Jeroen Demeyer wrote: > On 2019-03-05 18:14, Steve Dower wrote: > > However, if you don't have > > *a single* core developer on board from python-ideas, chances are the > > whole team is going to reject the proposal. > > Sure, I couldn't agree more. But this is som

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

to be explicitly rejected either. I personally am happy to sponsor such PEPs as I'm sure several other core devs are as well. On Mon, Mar 4, 2019 at 5:43 PM Brett Cannon wrote: > The steering council has implemented a new idea called sponsors to the PEP > process (added in > https://git

Re: [Python-Dev] Loading modules from a folder

This mailing list is actually for the development *of* Python, not *with* Python. You can try asking your question on Stack Overflow, python tutor, or python-list. On Thu, Mar 7, 2019 at 9:28 AM Mani Sarkar wrote: > Hi, > > I have seen multiple ways to load modules from a folder. > > Say I have

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

with PythonLabs leaving CNRI, so > clearly we couldn’t continue running infra off of their systems. > > 10/2005 - we move to Subversion > > 9/2006 - we begin to discuss moving off of the SF bug tracker. I believe > that Thomas Wouters, Martin von Loewis, Brett Cannon (big surprise! :

[Python-Dev] PEP 12 updated with templates for header fields and sections

https://github.com/python/peps/blob/master/pep-0012.rst now has a complete list of header fields along with format clues for easier copy-and-paste use in creating a new PEP. There is also a section template with one-liner explanations for what each section is for so people don't accidentally leave

Re: [Python-Dev] PEP 12 updated with templates for header fields and sections

ves or most "useful" > threads? The PEP author would be free to decide which threads are > important or not ;-) > > The status quo (Post History header) is fine, if I really want to find > these discussions, I'm able to find them from dates :-) > > Victor > &g

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

On Fri, Mar 8, 2019 at 5:46 AM Richard Damon wrote: > On 3/8/19 8:09 AM, Alex Walters wrote: > > I'm confused about this. Didn't you need someone with merge permissions > already to merge a pep into the pep repo? Isn't this just adding a layer > of paperwork to something that was already the ca

Re: [Python-Dev] Initial updates to PEP 1 for Steering Council based governance

On Thu, Mar 14, 2019 at 10:02 AM Victor Stinner wrote: > Hi, > > Le lun. 11 mars 2019 à 13:26, Nick Coghlan a écrit : > > This is the smallest change to PEP 1 that we consider potentially > viable: handling all PEPs through the BDFL-Delegate model, with the > Steering Council's primary involveme

[Python-Dev] Rejecting PEP 473: Adding structured data to built-in exceptions

The steering council felt the PEP was too broad and not focused enough. Discussions about adding more attributes to built-in exceptions can continue on the issue tracker on a per-exception basis (and obviously here for any broader points, e.g. performance implications as I know that has come up bef

[Python-Dev] Reject PEP 472: Support for indexing with keyword arguments

The idea never seemed to gain any traction over its near 5 years in existence as a PEP. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/

[Python-Dev] Deferring PEP 536 -- Final Grammar for Literal String Interpolation

The steering council decided to defer PEP 536 until an implementation is available. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/arch

[Python-Dev] Rejecting PEP 542 -- Dot Notation Assignment In Function Header

The steering council has decided to reject PEP 542 as the idea never seemed to gain traction. Thanks to Markus Meskanen for taking the time to write the PEP. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/pytho

Re: [Python-Dev] Reject PEP 472: Support for indexing with keyword arguments

exts and I got some positive reactions here and there, but as you said > it does not seem to provide a lot of added value. > > > On Fri, 15 Mar 2019 at 21:50, Brett Cannon wrote: > >> The idea never seemed to gain any traction over i

Re: [Python-Dev] Is XML serialization output guaranteed to be bytewise identical forever?

On Tue, Mar 19, 2019 at 6:15 AM Serhiy Storchaka wrote: > 19.03.19 13:53, Ned Batchelder пише: > > Option 4 is misleading. Is anyone here really offering to "fix the > > tests in third-party modules"? Option 4 is actually, "do nothing, and > > let a multitude of projects figure out how to fix t

Re: [Python-Dev] Remove tempfile.mktemp()

On Tue, Mar 19, 2019 at 10:22 AM Guido van Rossum wrote: > On Tue, Mar 19, 2019 at 10:14 AM Giampaolo Rodola' > wrote: > >> >> On Tue, 19 Mar 2019 at 17:47, Sebastian Rittau >> wrote: >> >>> Am 19.03.19 um 17:23 schrieb Giampaolo Rodola': >>> > @Sebastian >>> >> If there are valid use cases for

Re: [Python-Dev] Can I submit more support of standard library for VxWorks after 3.8.0 beta1?

On Mon, Mar 18, 2019 at 7:22 PM Xin, Peixing wrote: > Hi, Experts: > > > > Seeing from the Python 3.8.0 schedule( > https://www.python.org/dev/peps/pep-0569/#schedule), new features will > not be allowed to submit after 3.8.0 beta1. For VxWorks RTOS platform > supporting CPython, we are using bpo

Re: [Python-Dev] Removing PendingDeprecationWarning

On Fri, Mar 22, 2019 at 12:41 AM Victor Stinner wrote: > Hi, > > I agree to make PendingDeprecationWarning an alias to > DeprecationWarning. I never liked "PendingDeprecationWarning" name, > it's way too long to type :-D > > Le ven. 22 mars 2019 à 03:45, Inada Naoki a > écrit : > > I want to sto

Re: [Python-Dev] Removing PendingDeprecationWarning

On Fri, Mar 22, 2019 at 10:37 AM Inada Naoki wrote: > On Sat, Mar 23, 2019 at 2:26 AM Brett Cannon wrote: > > > > > > We can't do that as it will break code. Think of code which is having > warnings raise exceptions and that are purposefully catching > P

Re: [Python-Dev] Removing PendingDeprecationWarning

On Fri, Mar 22, 2019 at 6:19 PM Inada Naoki wrote: > On Sat, Mar 23, 2019 at 3:02 AM Brett Cannon wrote: > > > >> > >> There might be some small troubles. But it was small enough for > >> Python minor versions, I think. > > > > > > I

Re: [Python-Dev] BDFL-Delegate appointments for several PEPs

On Sun, Mar 24, 2019 at 2:03 PM Terry Reedy wrote: > On 3/24/2019 8:21 AM, Nick Coghlan wrote: > > > We'll be announcing those appointments as we go, so I'm happy to > > report that I will be handling the BDFL-Delegate responsibilities for > > the following PEPs: > > Where do we discuss these? >

Re: [Python-Dev] Removing PendingDeprecationWarning

On Wed, Mar 27, 2019 at 3:26 AM Inada Naoki wrote: > On Mon, Mar 25, 2019 at 10:11 PM Inada Naoki > wrote: > > > > C, Rust, Java, Ruby, PHP, don't have PendingDeprecation. > > Programmers only need Deprecation. Why programmers need > PendingDeprecation > > only in Python? > > > > Any comments a

Re: [Python-Dev] New Python Initialization API

On Wed, Mar 27, 2019 at 12:39 PM Steve Dower wrote: > On 27Mar2019 1048, Victor Stinner wrote: > > Since November 2017, I'm refactoring the Python Initialization code to > > cleanup the code and prepare a new ("better") API to configure Python > > Initialization. I just fixed the last issues that

[Python-Dev] Rejecting PEP 502

https://www.python.org/dev/peps/pep-0502/ Thanks to Mike G. Miller for the informational PEP, but since the PEP was written with an opinionated voice and the details of the PEP aren't critical as they should be captured by PEP 498 anyway, we didn't think it was worth trying to touch the PEP up to

[Python-Dev] Please take your time reading PEPs (was: PEP 578: Python Runtime Audit Hooks)

On Thu, Mar 28, 2019 at 5:03 PM Victor Stinner wrote: > Hi, > > I read quickly the PEP > I would like to encourage everyone to read PEPs so that they never feel the need to write those words ever again. ;) PEPs are never decided in less than 24 hours, so there is no rush to read a PEP as quickl

Re: [Python-Dev] Deprecating "instance method" class

On Fri, Apr 5, 2019 at 11:30 AM Jeroen Demeyer wrote: > On 2019-04-05 17:46, Guido van Rossum wrote: > > This API is doing no harm, it's not a maintenance > > burden > > What if the following happens? > > 1. For some reason (possibly because of this thread), people discover > instancemethod and s

Re: [Python-Dev] Deprecating "instance method" class

On Fri, Apr 5, 2019 at 1:11 PM Jeroen Demeyer wrote: > On 2019-04-05 21:58, Brett Cannon wrote: > > Then we can consider improving the documentation if there are > > performance implications. > > Sure, we could write in the docs something like "Don't use this, th

Re: [Python-Dev] No longer enable Py_TRACE_REFS by default in debug build

On Wed, Apr 10, 2019 at 12:30 PM Nathaniel Smith wrote: > On Wed, Apr 10, 2019, 04:04 Victor Stinner wrote: > >> Le mar. 9 avr. 2019 à 22:16, Steve Dower a >> écrit : >> > What are the other changes that would be required? >> >> I don't know. >> >> > And is there another >> > way to get the sam

Re: [Python-Dev] PEP 590 discussion

On Thu, Apr 11, 2019 at 5:06 AM Jeroen Demeyer wrote: > Petr, > > I realize that you are in a difficult position. You'll end up > disappointing either me or Mark... > > I don't know if the steering council or somebody else has a good idea to > deal with this situation. > Our answer was "ask Petr

Re: [Python-Dev] Proposal: dict.with_values(iterable)

On Fri, Apr 12, 2019 at 8:35 AM Serhiy Storchaka wrote: > 12.04.19 16:44, Inada Naoki пише: > > When creating many dicts with same keys, dict need to > > lookup internal hash table while inserting each keys. > > > > It is costful operation. If we can reuse existing keys of dict, > > we can skip

Re: [Python-Dev] Concurrent.futures: no type discovery for PyCharm

On Sat, Apr 20, 2019 at 2:10 PM Inada Naoki wrote: > "import typing" is slow too. > But is it so slow as to not do the right thing here and use the 'typing' module as expected? If you have so much work you need to launch some threads or processes to deal with it then a single import isn't going

Re: [Python-Dev] Please merge : bpo-34848

The "awaiting merge" was originally created to help with this. On Fri., May 3, 2019, 08:51 Miro Hrončok, wrote: > On 03. 05. 19 14:24, Victor Stinner wrote: > > Does someone know how I can list pull requests which has been approved > but not > > merged yet? > > Add review:approved to the search

Re: [Python-Dev] PEP 580/590 discussion

On Thu, May 9, 2019 at 11:31 AM Petr Viktorin wrote: > PEP 590 is on its way to be accepted, with some details still to be > discussed. I've rejected PEP 580 so we can focus on one place. > > Here are things we discussed on GitHub but now seem to agree on: > > * The vectorcall function's kwname a

Re: [Python-Dev] Online Devguide mostly not working

It's working for me, so it was probably just a hiccup. On Sun, May 12, 2019 at 6:19 AM Jeff Allen wrote: > Is it suspicious that in the detailed log we see: > > 'canonical_url': 'http://devguide.python.org/', > > ? I guess this comes from project admin configuration at RTD, additional > to your

Re: [Python-Dev] [python-committers] PEP 581 (Using GitHub issues for CPython) is accepted

On Wed, May 15, 2019 at 8:18 AM Paul Moore wrote: > On Wed, 15 May 2019 at 15:56, Victor Stinner wrote: > > > > Hi Paul, > > Le mer. 15 mai 2019 à 11:40, Paul Moore a écrit : > > > Also, is there an archive of the discussions anywhere? The PEP says > > > discussions happened on Zulip, but I don

Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

On Wed, May 15, 2019 at 5:38 AM Victor Stinner wrote: > Le mer. 15 mai 2019 à 11:31, Christian Heimes a > écrit : > > What are the next step? Will there be another PEP that explores how we > > are going to deal with migration, workflow changes, and how we plan to > > map current BPO features to

Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

On Wed, May 15, 2019 at 9:53 AM Steve Dower wrote: > On 15May2019 0240, Paul Moore wrote: > > On Wed, 15 May 2019 at 09:51, Antoine Pitrou > wrote: > >> > >> On Tue, 14 May 2019 18:11:14 -0700 > >> Barry Warsaw wrote: > >> > >>> As the BDFL-Delegate for PEP 581, and with the unanimous backing o

Re: [Python-Dev] Consolidating channel of record [was: 581 (Using GitHub issues for CPython) is accepted]

On Wed, May 15, 2019 at 1:10 PM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: [SNIP] > > While I'm here, is there a place where general Pythonistas can bring > matters to the attention of the Council? > https://github.com/python/steering-council is where we're asking people

Re: [Python-Dev] Parser module in the stdlib

On Thu., May 16, 2019, 15:56 Steve Dower, wrote: > On 16May2019 1548, Pablo Galindo Salgado wrote: > > > Will the folks using forks be happy to switch to the stdlib version? > >>For example I can imagine that if black wants to process 3.7 input > >>code while running on 3.6, it might prefer a pa

Re: [Python-Dev] Feature request: Change a Dependency Package Version During Package Initiation

Thanks for the idea but there are currently no plans to support such a feature. If you would like to see it then you will need to write a PEP with a proof-of-concept to demonstrate how you would expect such a feature to work. On Fri., May 17, 2019, 07:55 Q via Python-Dev, wrote: > A lot of the P

Re: [Python-Dev] Parser module in the stdlib

On Mon., May 20, 2019, 16:00 Terry Reedy, wrote: > On 5/20/2019 11:55 AM, Guido van Rossum wrote: > > On Thu, May 16, 2019 at 3:57 PM Steve Dower > > wrote: > > > > [...] > > We still have the policy of not removing modules that exist in the > > Python

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On Tue., May 21, 2019, 04:25 Victor Stinner, wrote: > Le mar. 21 mai 2019 à 13:18, André Malo a écrit : > > There's software in production using both. (It doesn't mean it's on pypi > or > > even free software). > > > > What would be the maintenance burden of those modules anyway? (at least > for

Re: [Python-Dev] PEP 594: update 1

On Tue., May 21, 2019, 09:10 Christian Heimes, wrote: > On 21/05/2019 17.31, Antoine Pitrou wrote: > > > > As I said, if the main annoyance with nntplib is the sporadic test > > failures, then the relevant tests can be disabled on CI. > > > > NNTP itself is still used, even if less and less. > >

<    3   4   5   6   7   8   9   10   11   12   >