[Python-Dev] Surely "nullable" is a reasonable name?

Argument Clinic "converters" specify how to convert an individual argument to the function you're defining. Although a converter could theoretically represent any sort of conversion, most of the time they directly represent types like "int" or "double" or "str". Because there's such variet

Re: [Python-Dev] Surely "nullable" is a reasonable name?

On 08/04/2014 05:46 PM, Glenn Linderman wrote: There remains, of course, one potential justification for using "nullable", that you didn't make 100% clear. Because "argument clinic is it is all about clearly defining the C-side of how things are done in Python API's." and that is that C uses N

Re: [Python-Dev] Surely "nullable" is a reasonable name?

On 08/05/2014 03:53 AM, Antoine Pitrou wrote: Le 04/08/2014 13:36, Alexander Belopolsky a écrit : If the receiving type is PyObject*, either NULL or Py_None is a valid choice. But here the receiving type can be an int. Just to be precise: in the case where the receiving type *would* have be

Re: [Python-Dev] Surely "nullable" is a reasonable name?

On 08/05/2014 08:13 AM, "Martin v. Löwis" wrote: For the feature in question, I find both "allow_none" and "nullable" acceptable; "noneable" is not. Well! It's rare that the core dev community is so consistent in its opinion. I still think "nullable" is totally appropriate, but I'll change

Re: [Python-Dev] os.walk() is going to be *fast* with scandir

On 08/09/2014 10:40 PM, Robert Collins wrote: A small tip from my bzr days - cd into the directory before scanning it I doubt that's permissible for a library function like os.scandir(). //arry/ ___ Python-Dev mailing list Python-Dev@python.org http

[Python-Dev] Proposed schedule for 3.4.2

Matthias asked me when I was going to release 3.4.2. I propose the following schedule: Tag 3.4.2rc1 Friday Sep 12 2014 Release 3.4.2rc1 Saturday Sep 13 2014 Tag 3.4.2 final Saturday Sep 27 2014 Release 3.4.2 final Sunday Sep 28 2014 Normally I want to tag on Saturdays and releas

Re: [Python-Dev] Proposed schedule for 3.4.2

On 09/08/2014 05:08 AM, Nick Coghlan wrote: On 8 September 2014 14:28, Ned Deily wrote: As I've already discussed with Larry, I think adding a week to the scheduled dates would be preferable. The original dates give pretty short notice and there are a number of open issues that would be good t

Re: [Python-Dev] 3.5 release schedule PEP

Yep. I plan to write it on Monday, at the PyCon UK sprints, right after 3.4.2rc1 goes out. FWIW it'll be 3.4 + 18 months. //arry/ On 09/19/2014 03:31 PM, Barry Warsaw wrote: Hi Larry, I think we need a Python 3.5 Release Schedule PEP. Cheers, -Barry ___

Re: [Python-Dev] PEP476: Enabling certificate validation by default

On 09/20/2014 11:05 PM, Nick Coghlan wrote: On 21 September 2014 03:05, Alex Gaynor wrote: That sounds reasonable to me -- at this point I don't expect this to make it into 3.4.2; Nick has some working code on the ticket: http://bugs.python.org/issue22417 it's mostly missing documentation. I

[Python-Dev] [RELEASE] Python 3.4.2rc1 is now available

On behalf of the Python development community and the Python 3.4 release team, I'm chuffed to announce the availability of Python 3.4.2rc1. Python 3.4.2 has many bugfixes and other small improvements over 3.4.1. One new feature for Mac OS X users: the OS X installers are now distributed as

Re: [Python-Dev] [python-committers] [RELEASE] Python 3.4.2rc1 is now available

/issue21431 We'll get it right for 3.4.2 final. I don't think we need to respin 3.4.2rc1 / add a 3.4.2rc2 for this. On 09/22/2014 06:02 PM, Terry Reedy wrote: On 9/22/2014 10:15 AM, Larry Hastings wrote: You can download it here: https://www.python.org/download/rele

Re: [Python-Dev] 3.5 release schedule PEP

On 09/19/2014 03:31 PM, Barry Warsaw wrote: I think we need a Python 3.5 Release Schedule PEP. Just checked it in as PEP 478. It should show up here in a few minutes: http://legacy.python.org/dev/peps/pep-0478/ Key facts: * Beta 1 is May 24th 2015, about a month after the end of the P

Re: [Python-Dev] 3.5 release schedule PEP

On 09/23/2014 06:48 PM, Nick Coghlan wrote: On 24 September 2014 03:05, Steve Dower wrote: I'd like to move the Windows versions onto the next release of VC (currently "VC 14" until the branding team figures out what to call it). There isn't a promised RTM date for VC 14 yet, so it looks like

Re: [Python-Dev] 3.5 release schedule PEP

On 09/24/2014 08:04 AM, Victor Stinner wrote: It was too distrubing to read "3.4" in the "3.5" schedule. I modified the PEP directly, sorry Larry. No sweat. I would have fixed it myself, but yesterday was a big travel day. Thanks for fixing it! //arry/ __

Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7

On 09/26/2014 11:01 AM, Steve Dower wrote: Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). We've produced this package to help library developers build wheels for Windows, but also to help users unblock themselves when they need to build C extensions themselves. T

[Python-Dev] 3.4.2 is slipping by a day

We don't have Windows installers yet. If we can't get 'em in the next 24 hours or so, I'll release without them. But for now... we wait. Twiddling my thumbs, //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailm

[Python-Dev] [RELEASE] Python 3.4.2 is now available

On behalf of the Python development community and the Python 3.4 release team, I'm pleased to announce the availability of Python 3.4.2. Python 3.4.2 has many bugfixes and other small improvements over 3.4.1. One new feature for Mac OS X users: the OS X installers are now distributed as sig

Re: [Python-Dev] Status of C compilers for Python on Windows

On 10/10/2014 08:07 AM, Paul Moore wrote: On 10 October 2014 01:29, Victor Stinner wrote: What about the Python stable ABI? Would it be broken if we use a different compiler? What about third party Python extensions? What about external dependencies like gzip, bz2, Tk, Tcl, OpenSSL, etc.? T

Re: [Python-Dev] Status of C compilers for Python on Windows

On 10/10/2014 03:36 PM, Tres Seaver wrote: On 10/10/2014 05:26 AM, Larry Hastings wrote: IMO the benefit from supporting other compilers on Windows is negligible Did you miss the OP's point that OpenBLAS cannot be compiled with MSVC, raising the priority of mingw-buildable extension

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On 11/29/2014 04:37 PM, Donald Stufft wrote: On Nov 29, 2014, at 7:15 PM, Alex Gaynor wrote: Despite being a regular hg user for years, I have no idea how to create a local-only branch, or a branch which is pushed to a remote (to use the git term). I also don’t know how to do this. Instead

[Python-Dev] Schedule for 3.4.3, revised schedule for 3.5.0a1

Python 3.5.0a1 is currently scheduled to be released February 1. Since I'll be on the road that day, the 3.5 team has agreed to push the release back a week. 3.5.0a1 will be tagged Saturday February 7 and released Sunday February 8. This doesn't change any of the other release dates for 3.

Re: [Python-Dev] PEP 475 accepted

On 02/02/2015 12:58 PM, Victor Stinner wrote: 2015-02-02 21:49 GMT+01:00 Guido van Rossum : W00t! Congratulations les Français! We will celebrate this acceptance with a glass of red wine and cheese. If it were me, I'd use separate glasses. //arry/ __

[Python-Dev] [RELEASE] Python 3.4.3rc1 is now available

On behalf of the Python development community and the Python 3.4 release team, I'm happy to announce the availability of Python 3.4.3rc1. Python 3.4.3rc1 has many bugfixes and other small improvements over 3.4.2. You can download it here: https://www.python.org/download/releases/3.4.3

[Python-Dev] [RELEASE] Python 3.5.0a1 is now available

On behalf of the Python development community and the Python 3.5 release team, I'm also pleased to announce the availability of Python 3.5.0a1. Python 3.5.0a1 is the first alpha release of Python 3.5, which will be the next major release of Python. Python 3.5 is still under heavy developm

Re: [Python-Dev] (no subject)

What's an example of a way inspect.signature must change? I thought PEP 448 added new unpacking shortcuts which (for example) change the *caller* side of a function call. I didn't realize it impacted the *callee* side too. //arry/ On 02/09/2015 03:14 PM, Antoine Pitrou wrote: On Tue, 1

Re: [Python-Dev] how to inspect if something includes a bound first param

On 02/24/2015 05:56 PM, Gregory P. Smith wrote: inspect.getargspec(method) and inspect.signature(method) both include the 'self' parameter but how are we to figure out from method itself that it is actually bound and that its first parameter is expected to be a bound instance? Given the mec

[Python-Dev] [RELEASED] Python 3.4.3 is now available

On behalf of the Python development community and the Python 3.4 release team, I'm pleased to announce the availability of Python 3.4.3. Python 3.4.3 has many bugfixes and other small improvements over 3.4.2. You can find it here: https://www.python.org/downloads/release/python-343/

Re: [Python-Dev] PEP 471 Final: os.scandir() merged into Python 3.5

On 03/07/2015 06:13 PM, Victor Stinner wrote: Hi, FYI I commited the implementation of os.scandir() written by Ben Hoyt. I hope that it will be part of Python 3.5 alpha 2 It is. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail

[Python-Dev] [RELEASED] Python 3.5.0a2 is now available

On behalf of the Python development community and the Python 3.5 release team, I'm thrilled to announce the availability of Python 3.5.0a2. Python 3.5.0a2 is the second alpha release of Python 3.5, which will be the next major release of Python. Python 3.5 is still under heavy development

[Python-Dev] Minor update to Python 3.5 release schedule

I always intended all my releases to be on Sundays--that all the release engineering work is done on weekends, which is generally easier for everybody. But I goofed up the 3.5 release schedule and had proposed 3.5.0a3 to be released Saturday March 28th. With the assent of the team I bumped

Re: [Python-Dev] cpython: Issue #23752: When built from an existing file descriptor, io.FileIO() now only

On 03/30/2015 12:30 AM, Victor Stinner wrote: So is it correct to use "alpha 4" in Misc/NEWS? It's the release manager's responsibility to update the version number in Misc/NEWS. As I finish up 3.5.0a3, I will be changing it to say "What's New in Python 3.5.0 alpha 4?". And I will change t

[Python-Dev] [RELEASED] Python 3.5.0a3 is now available

On behalf of the Python development community and the Python 3.5 release team, I'm thrilled to announce the availability of Python 3.5.0a3. Python 3.5.0a3 is the third alpha release of Python 3.5, which will be the next major release of Python. Python 3.5 is still under heavy development,

[Python-Dev] Do we need to sign Windows files with GnuPG?

As of Python 3.5 Steve Dower has taken over the Windows builds of Python from Martin van Loewis. He's also taken over for 2.7--though Martin's still doing builds for 3.4. For both versions, Steve is using all-new tooling for the build process. The output is different, too; he's producing

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

On 04/04/2015 08:21 PM, Nathaniel Smith wrote: (I guess you could call Larry or someone, read them a hash over the phone, and then have them create the actual gpg signatures.) By sheer coincidence, I believe Steve and I both live in the Seattle area...! //arry/

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

On 04/05/2015 06:41 AM, Antoine Pitrou wrote: On Sun, 05 Apr 2015 01:06:01 -0700 Larry Hastings wrote: On 04/04/2015 08:21 PM, Nathaniel Smith wrote: (I guess you could call Larry or someone, read them a hash over the phone, and then have them create the actual gpg signatures.) By sheer

Re: [Python-Dev] Keyword-only parameters

On 04/14/2015 01:40 PM, Eric V. Smith wrote: I'm working on adding a numeric_owner parameter to some tarfile methods (http://bugs.python.org/issue23193), In a review, Berker suggested making the parameter keyword-only. I agree that you'd likely never want to pass just "True", but that "numeric

Re: [Python-Dev] Surely "nullable" is a reasonable name?

On 08/07/2014 09:41 PM, Larry Hastings wrote: Well! It's rare that the core dev community is so consistent in its opinion. I still think "nullable" is totally appropriate, but I'll change it to "allow_none". (reviving eight-month-old thread) In case anybo

Re: [Python-Dev] Surely "nullable" is a reasonable name?

On 04/19/2015 01:26 PM, Glenn Linderman wrote: Is argument clinic a special case of type annotations? (Quoted and worded to be provocative, intentionally but not maliciously.) OK, I know that argument clinic applies to C code and I know that type annotations apply to Python code. And I know t

[Python-Dev] [RELEASED] Python 3.5.0a4 is now available

On behalf of the Python development community and the Python 3.5 release team, I'm thrilled to announce the availability of Python 3.5.0a4. Python 3.5.0a4 is the fourth and alpha release of Python 3.5, which will be the next major release of Python. Python 3.5 is still under development, a

Re: [Python-Dev] Surely "nullable" is a reasonable name?

On 04/21/2015 04:50 AM, Tal Einat wrote: As for the default set of accepted types for various convertors, if we could choose any syntax we liked, something like "accept=+{NoneType}" would be much better IMO. In theory Argument Clinic could use any syntax it likes. In practice, under the cove

Re: [Python-Dev] Surely "nullable" is a reasonable name?

On 04/24/2015 09:45 PM, Nick Coghlan wrote: Ah, I misread Tal's suggestion. Using unary + is an even neater approach. Not exactly. The way I figure it, the best way to achieve this with unary plus is to ast.parse it (as we currently do) and then modify the parse tree. That works but it's

Re: [Python-Dev] Accepting PEP 492 (async/await)

On 05/05/2015 04:53 PM, Guido van Rossum wrote: I've given Yury clear instructions to focus on how to proceed -- he's to work with another core dev on getting the implementation ready in time for beta 1 (scheduled for May 24, but I think the target date should be May 19). Released on Sunday M

Re: [Python-Dev] Free lists

On 05/09/2015 12:01 PM, Serhiy Storchaka wrote: Here is a statistic for most called PyObject_INIT or PyObject_INIT_VAR for types (collected during running Python tests on 32-bit Linux). Can you produce these statistics for a 64-bit build? //arry/ __

Re: [Python-Dev] Free lists

On 05/09/2015 11:22 PM, Serhiy Storchaka wrote: On 10.05.15 02:25, Ian Cordasco wrote: Can you share how you gathered them so someone could run them on a 64-bit build? This is quick and dirty patch. It generates 8 GB log file! I ran it under 64-bit Linux. Actually it generated a 10GB log fi

[Python-Dev] Is it kosher to use a buffer after release?

In Python's argument parsing code (convertsimple in Python/getargs.c), a couple of format units* accept "read-only bytes-like objects", aka read-only buffer objects. They call a helper function called convertbuffer() which uses the buffer protocol to extract a pointer to the memory. Here'

[Python-Dev] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

Python 3.5 beta 1 is coming up soon. After beta is rc; after rc is 3.5.0 final. During the beta and rc periods the Python developer workflow changes a little--what sorts of checkins are permissible, and how to get something accepted and merged generally becomes more complicated. I was the

Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On 05/12/2015 10:23 AM, Ned Deily wrote: One possible issue with Workflow 1 is that there would need to be an additional set of buildbots (for 3.5, in addition to the existing 3.x (AKA "trunk"), 3.4, and 2.7 ones) for the period from beta 1 until at least 3.5.0 is released and, ideally, until 3

Re: [Python-Dev] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On 05/12/2015 10:23 AM, Chris Angelico wrote: Will this model be plausibly extensible to every release? For instance, when a 3.5.1 rc is cut, will the 3.5 branch immediately become 3.5.2, with a new 3.5.1 branch being opened on bitbucket? Yes, we could always do it that way, though in the past

Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On 05/12/2015 11:21 AM, Ned Deily wrote: I like the idea of experimentally trying the push workflow but, if we are all doing our jobs right, there should be very few changes going in after rc1 so most committers won't need to push anything to the 3.5.0rc repo and, if for some reason they aren'

Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On 05/12/2015 05:11 PM, Dirkjan Ochtman wrote: Couldn't you just keep this as a branch that you then keep rebasing (without unlinking the original branch)? It doesn't seem like something that needs a one-off script, to me. Probably. It's water under the bridge now--that all happened last Febr

Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On 05/12/2015 11:18 AM, Jesus Cea wrote: Larry, could you comment about the impact in the buildbots?. I suppose option #1 could allows us to test both 3.5 and 3.6 changes. Would you confirm this? Workflow #1 gets us automatic buildbot testing for the 3.5 branch (betas and 3.5.1) and trunk (3.6

Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On 05/12/2015 05:19 PM, Nick Coghlan wrote: Workflow 0: -0 Workflow 1: +1 Workflow 2: +0 That's taking into account the clarification that the buildbots will be set up to track the 3.5.x branch after the beta is forked, and that Larry will also push the 3.5rcX repo to hg.python.org

Re: [Python-Dev] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

On 05/12/2015 10:04 AM, Larry Hastings wrote: What do you think? [...] Please cast your votes workflow 012 Larry Hastings-0.5 10.5 Brett Cannon 010 Nick Coghlan 010 Chris Angelico 000“in favor of [Workflow 1]” Ned Deily

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

On 09/06/2017 09:45 AM, Guido van Rossum wrote: So we're looking for a competing PEP here. Shouldn't be long, just summarize the discussion about use cases and generality here. I don't think it's necessarily a /competing/ PEP; in my opinion, they serve slightly different use cases. After al

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

On 09/07/2017 03:49 PM, Larry Hastings wrote: Excluding Lib/test, there are 375 uses of "@property" in the stdlib in trunk, 60 uses of __getattr__, and 34 of __getattribute__. I spent a minute looking at the output and realized there were a bunch of hits inside pydoc_data/topi

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

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 finalizer being called on the thread where the last reference is dropped. This is usually the same thread

[Python-Dev] PEP 549 v2: now titled Instance Descriptors

I've updated PEP 549 with a new title--"Instance Descriptors" is a better name than "Instance Properties"--and to clarify my rationale for the PEP. I've also updated the prototype with code cleanups and a new type: "collections.abc.InstanceDescriptor", a base class that allows user classes

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

On 09/08/2017 12:30 PM, Benjamin Peterson wrote: 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

Re: [Python-Dev] PEP 549 v2: now titled Instance Descriptors

odule initialization needs to be done within--or propagated to--the new class or instance. //arry/ On 09/08/2017 01:45 PM, Ethan Furman wrote: On 09/08/2017 12:44 PM, Larry Hastings wrote: I've updated PEP 549 with a new title--"Instance Descriptors" is a better name than "Ins

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

On 09/06/2017 08:26 AM, Guido van Rossum wrote: So we've seen a real use case for __class__ assignment: deprecating things on access. That use case could also be solved if modules natively supported defining __getattr__ (with the same "only used if attribute not found otherwise" semantics as

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

On 09/06/2017 02:13 PM, Ronald Oussoren wrote: To be honest this sounds like a fairly crude hack. Updating the __class__ of a module object feels dirty, but at least you get normal behavior w.r.t. properties. Okay. Obviously I disagree, I think it's reasonable. But I'll assume you're -1.

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

On 09/11/2017 08:44 AM, Guido van Rossum wrote: I worry that in the end @property isn't general enough and the major use cases end up still having to use __class__ assignment, and then we'd have a fairly useless feature that we cant withdraw, ever. What can I say--I don't have that worry ;-)

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

On 09/11/2017 07:22 PM, Guido van Rossum wrote: I still don't follow. How does one use InstanceDescriptor? If you write a class that inherits from InstanceDescriptor and supports the descriptor protocol, module objects will call the descriptor protocol functions when that object is accessed

Re: [Python-Dev] PEP 490 "Chain exceptions at C level" rejected

On 09/12/2017 02:49 AM, Victor Stinner wrote: Note: The PEP is not yet rejected on python.org, it will be done at the next cron job run. My understanding is that the docs are built once a day via cron job, but the PEPs are built every time the repo changes thanks to Travis CI. So it should

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

On 09/12/2017 12:38 AM, Larry Hastings wrote: On 09/11/2017 07:22 PM, Guido van Rossum wrote: The prototype is linked to from the PEP; for your convenience here's a link: https://github.com/larryhastings/cpython/tree/module-properties <https://github.com/larry

[Python-Dev] Why aren't decorators just expressions?

The syntax for decorators in the grammar is quite specific: decorator: '@' dotted_name [ '(' [arglist] ')' ] NEWLINE Decorators can be either a dotted name, or a dotted name followed by arguments. This disallows: @mapping['async'] # looking something up in a mapping @func(1, 2, 3

[Python-Dev] Can Python guarantee the order of keyword-only parameters?

First, a thirty-second refresher, so we're all using the same terminology: A *parameter* is a declared input variable to a function. An *argument* is a value passed into a function.  (*Arguments* are stored in *parameters.*) So in the example "def foo(clonk): pass; foo(3)", clonk i

Re: [Python-Dev] Can Python guarantee the order of keyword-only parameters?

On 11/27/2017 12:19 PM, Robert Collins wrote: Plus 1 from me. I'm not 100% sure the signature / inspect backport does this, but as you say, it should be trivial to do, to whatever extent the python version we're hosted on does it. I'm not sure exactly what you mean when you say "signature / i

Re: [Python-Dev] Can Python guarantee the order of keyword-only parameters?

On 11/27/2017 03:58 PM, Yury Selivanov wrote: We can't say anything about the order if someone passes a partial object Sure we could.  We could ensure that functools.partial behaves in a sane way, then document and guarantee that behavior. or sets custom Signature objects to func.__signa

[Python-Dev] Proposed schedule for next 3.4 and 3.5 releases - end of January / early February

Howdy howdy.  I know nobody's excited by the prospect of 3.4 and 3.5 releases--I mean, fer gosh sakes, neither of those versions even has f-strings!   But we're about due.  I prefer to release roughly every six months, and the current releases came out in early August. Here's my proposed sc

Re: [Python-Dev] Positional-only parameters in Python

On 01/17/2018 08:29 AM, Ethan Furman wrote: On 01/17/2018 08:14 AM, Serhiy Storchaka wrote: 17.01.18 16:34, Victor Stinner пише: In Februrary 2017, I proposed on python-ideas to change the Python syntax to allow to declare positional-only parameters in Python: https://mail.python.org/piperma

Re: [Python-Dev] Positional-only parameters in Python

On 01/19/2018 08:47 PM, Nick Coghlan wrote: - proposing the full PEP 547, including the "argument groups" feature (which is a bigger change, but allows the expression of signatures like "range([start,] stop, [step,] /)") I hope we don't go down that route. I added support for "argument group

Re: [Python-Dev] Positional-only parameters in Python

On 01/21/2018 05:59 AM, Mario Corchero wrote: Credit for making left option groups higher precedence goes to Nick Coghlan. (Conversation in person at PyCon US 2013.) Actually Argument Clinic has always given left option groups higher precedence.  This theoretically allows Argument Clinic to

[Python-Dev] Slipping Python 3.5.5rc1 and 3.4.8rc1 because of a Travis CI issue--can someone make Travis CI happy?

I have three PRs for Python 3.5.5rc1: https://github.com/python/cpython/pull/4656 https://github.com/python/cpython/pull/5197 https://github.com/python/cpython/pull/5201 I can't merge them because Travis CI is unhappy.  All three CI tests fail in the same way, reporting this error:

Re: [Python-Dev] Slipping Python 3.5.5rc1 and 3.4.8rc1 because of a Travis CI issue--can someone make Travis CI happy?

On 01/22/2018 07:51 AM, Brett Cannon wrote: I can switch off the requirement that holds admins to having to pass the same status checks as everyone else (there's still a big warning when you exercise this power), that way you can override the merge if you want. Not sure if you want to ignore

[Python-Dev] [RELEASED] Python 3.4.8rc1 and Python 3.5.5rc1 are now available

On behalf of the Python development community, I'm pleased to announce the availability of Python 3.4.8rc1 and Python 3.5.5rc1. Both Python 3.4 and 3.5 are in "security fixes only" mode. Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only.

Re: [Python-Dev] Intention to accept PEP 567 (Context Variables)

On 01/23/2018 09:56 AM, Koos Zevenhoven wrote: On Tue, Jan 23, 2018 at 2:23 AM, Victor Stinner mailto:victor.stin...@gmail.com>>wrote: The PEP 555 looks a competitor PEP of the PEP 567. Since the Yury's PEP 567 was approved, I understand that Koos's PEP 555 should be rejected, no?

[Python-Dev] [RELEASED] Python 3.4.8 and Python 3.5.5 are now available

On behalf of the Python development community, I'm happy to announce the availability of Python 3.4.8 and Python 3.5.5. Both Python 3.4 and 3.5 are in "security fixes only" mode.  Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only. You

Re: [Python-Dev] [RELEASED] Python 3.4.8 and Python 3.5.5 are now available

Actually, it was updated on the server, but somehow the old version was sticking around in the CDN cache.  I "purged" it and it's fine now.  Weird that it would linger this long! Cheers, //arry/ On 02/10/2018 03:20 AM, Serhiy Storchaka wrote: 05.02.18 02:35, Larry Ha

Re: [Python-Dev] Symmetry arguments for API expansion

On 03/12/2018 08:41 PM, Guido van Rossum wrote: If you force me to choose between allowing hex(3.14) or 42.hex() I'll choose the latter I assume you meant (42).hex() here.  If you're also interested in changing the language to permit 42.hex(), well, color me shocked :D (For those who haven

Re: [Python-Dev] Use more Argument Clinic Annotations?

On 03/25/2018 09:58 AM, Serhiy Storchaka wrote: 25.03.18 19:47, Dave Halter пише: Is there a way though in which the __text_signature__ could contain the information `-> str` or do we need to engineer that first? There is no such way currently. Are you sure?  I'm pretty sure Argument Clin

[Python-Dev] [Crosspost from python-committers] Announcing: signups are open for the 2018 Python Language Summit

It’s that time again: time to start thinking about the Python Language Summit!  The 2018 summit will be held on Wednesday, May 9, from 10am to 4pm, at the Huntington Convention Center in Cleveland, Ohio, USA.  Your befezzled and befuddled hosts Barry and Larry will once more be behind the big

[Python-Dev] Reminder: 2018 Python Language Summit signups close next week

The deadline is a week from today, April 18th 2018.  Original announcement below. -- It’s that time again: time to start thinking about the Python Language Summit!  The 2018 summit will be held on Wednesday, May 9, from 10am to 4pm, at the Huntington Convention Center in Cleveland, Ohio,

Re: [Python-Dev] PEP 572: Assignment Expressions

On 04/17/2018 06:55 AM, Steve Dower wrote: Agree with Paul. The PEP is well thought out and well presented, but I really don’t think we need this in Python (and I say this as someone who uses it regularly in C/C#). -1 on the idea; no disrespect intended toward to people who did a lot of w

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

On 04/26/2018 06:27 AM, Kirill Balunov wrote: Not sure, but if additional motivating examples are required, there is a common pattern for dynamic attribute lookup (snippet from `copy.py`):     reductor = dispatch_table.get(cls)     if reductor:     rv = reductor(x)     else:     reduc

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

On 04/26/2018 11:18 AM, Chris Angelico wrote: In the reference implementation, it's just DUP_TOP followed by STORE_FAST (well, technically by "whatever the assignment compiles to", as it could be affected by global/nonlocal, closures, etc). Is there much advantage to creating a new opcode? Pr

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

On 04/26/2018 12:12 PM, Tim Peters wrote: [Larry Hastings ] I hate to be pedantic--there's enough of that going on in this thread--but I can't agree with the word "simplifed" above. I agree that the code using binding expressions is shorter. But considering that emit t

[Python-Dev] PEP 572 at the Language Summit next week

In case it helps, we're planning on presentations on / a discussion of PEP 572 at the 2018 Python Language Summit next Wednesday.  (I'm assuming it won't be pronounced upon before then--after all, what's the rush?)  Naturally the discussion isn't going to escape the room until it gets report

Re: [Python-Dev] PEP 572: Assignment Expressions

On 04/30/2018 07:30 AM, Mark Shannon wrote: Would Python be better with two subtly different assignment operators? The answer of "no" seems self evident to me. Maybe this has been covered in the thread earlier--if so, I missed it, sorry.  But ISTM that Python already has multiple ways to perf

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

On 05/02/2018 11:14 AM, Nathaniel Smith wrote: I would guess that the folks who end up supporting python 2 past 2020 (either as distributors or as library authors) will have an easier time of it if python 2's ssl module gets resynced with python 3 before the eol. But I suppose it's up to them

[Python-Dev] Why aren't escape sequences in literal strings handled by the tokenizer?

I fed this into tokenize.tokenize(): b''' x = "\u1234" ''' I was a bit surprised to see \U in the output.  Particularly because the output (t.string) was a *string* and not *bytes*. It turns out, Python's tokenizer ignores escape sequences.  All it does is ignore the next character

Re: [Python-Dev] Idea: reduce GC threshold in development mode (-X dev)

On 06/08/2018 12:48 AM, Victor Stinner wrote: Question: Do you think that bugs spotted by a GC collection are common enough to change the GC thresholds in development mode (new -X dev flag of Python 3.7)? I'd prefer that the development / debug environment be as much like production use as p

[Python-Dev] Reminder: Python 3.5 beta 1 will be tagged tomorrow

Howdy howdy. It's-a me, Larry, your friendly neighborhood Python 3.5 Release Manager. Somewhere around 2 or 3pm tomorrow I expect to tag Python 3.5 beta 1. We'll actually release beta 1 on Sunday, once the binary installers are all built. Beta 1 is also feature-freeze, meaning no new fe

Re: [Python-Dev] Reminder: Python 3.5 beta 1 will be tagged tomorrow

On 05/22/2015 02:29 PM, Chris Barker wrote: Is it too late to get the isclose() code (PEP 485) into 3.5? I posted the code here, and got a tiny bit of review, but have not yet merged it into the source tree -- and don't know the process for getting it committed to the official source. So --

[Python-Dev] Can we clean up the buildbots please?

Right now we have eight online buildbots for Python trunk. Of those, currently *six* are reporting errors in either the compile or test phases. http://buildbot.python.org/all/waterfall?category=3.x.stable There's one platform ("AMD64 Snow Leop") where the failures are sporadic "stack ov

Re: [Python-Dev] [python-committers] Can we clean up the buildbots please?

On 05/22/2015 03:06 PM, Steve Dower wrote: The Windows 7 buildbots are failing on test_asdl_parser, but I have no idea why – the test works for me just fine. Yury and Benjamin made the most recent changes to Python.asdl, but I have no idea what effect they would have here, or why it’s Windows

Re: [Python-Dev] [python-committers] Can we clean up the buildbots please?

*From:*Larry Hastings [mailto:la...@midwinter.com] *On Behalf Of *Larry Hastings *Sent:* Friday, May 22, 2015 1530 *To:* Steve Dower; Python Dev; python-committers *Cc:* Yury Selivanov; Benjamin Peterson *Subject:* Re: [python-committers] Can we clean up the buildbots please? Is MSVS 2015 the

Re: [Python-Dev] [python-committers] Can we clean up the buildbots please?

On 05/22/2015 05:11 PM, Trent Nelson wrote: Do we still support WS2K3? (Can I even install VS 2015 on that? I would have thought not.) According to PCbuild/readme.txt, no. It says: This directory is used to build CPython for Microsoft Windows NT version 6.0 or higher (Windows Vista, Wi

[Python-Dev] Fwd: Re: [python-committers] Reminder: Python 3.5 beta 1 will be tagged tomorrow

Whoops, didn't send my reply to both lists. Forwarded, below. Forwarded Message Subject: Re: [python-committers] [Python-Dev] Reminder: Python 3.5 beta 1 will be tagged tomorrow Date: Sat, 23 May 2015 12:23:09 -0700 From: Larry Hastings To: python-co

Re: [Python-Dev] Preserving the definition order of class namespaces.

On 05/23/2015 07:38 PM, Nick Coghlan wrote: Eric clarified for me that Larry was considering granting a feature freeze exemption to defer landing this to beta 2 while Eric tracked down a segfault bug in the current patch that provides a C implementation of OrderedDict. Yeah, I'm willing to gr

  1   2   3   4   5   6   7   8   9   >