[Python-Dev] Helper Python core development tools

- Commit helpers (various hooks) - Various Roundup extensions Please be invited to comment and raise your concerns, so we could discuss them together and make our hacker's life more enjoyable. My name is Mario Đanić, a hopeful GSoC student, and I am looking forward working with you. Than

Re: [Python-Dev] Mercurial?

> > > Not sure what this means. There is currently svn support insofar as the > tracker can format rNNN references into ViewCVS links; this should be > updated if possible (removed if not). There would also be a possibility > to auto-close issues from the commit messages. This is not done > current

Re: [Python-Dev] Google Summer of Code/core Python projects - RFC

> > > He says vague things about patches too, but I'm not sure what. If he > wanted to make that into a 'patchbot' that just applied every patch in > isolation and ran 'make && make test' and posted results in the > tracker I'd be a happy camper. > > Jack, how about you write that idea down on the

[Python-Dev] Roundup improvements use-cases

www.roundup-tracker.org/cgi-bin/moin.cgi/GSoC09 Thanks for your attention and time. Respectfully, Mario ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/op

[Python-Dev] PEP 484

Please don't clutter executable code. We need to read it without growing an headache. Much better is: def myfunction(arg1, arg2): """ Normal docstring... @hint: (str, int) -> bool """ return True While I agree type hinting, for the purposes of static analy

Re: [Python-Dev] Analog of PEP 448 for dicts (unpacking in assignment with dict rhs)

Do you mean making getitems call itemgetter? At the moment we can already do with itemgetter: from operator import itemgetter a,b = itemgetter("a", "b")(d) > I tend to post this every time the topic comes up, but: it's highly > unlikely we'll get syntax for this when we don't even have a bu

Re: [Python-Dev] iso8601 parsing

The basics should be possible already with issue31800 , that said the issue you reference is to get a single function to parse it (without having to put the whole format), which would be neat. I believe Paul Ganssle is planning on adding it to dateutil as well:

Re: [Python-Dev] iso8601 parsing

There were discussions about having it a function, making the constructor of datetime accept a string(this was strongly rejected), having a static funcion in datetime, etc... and there was no real agreement. If the agreement is that we want a funcion to be able to parse it I am sure Paul G will be

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

Hi Victor, I'd like to work on it if you accept "a random person" to work on it (saying it in case the mail was directed to core developers). Regards, Mario On 17 January 2018 at 14:34, Victor Stinner wrote: > Hi, > > In Februrary 2017, I proposed on python-ideas to ch

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

I am happy to put some work into this (and Pablo Galindo in CC offered to pair on it) but it is not clear for me whether the next step is drafting a new PEP or this is just blocked on "re-evaluating" the current one. If someone can clarify we can put something together. Thanks! On 18 January 201

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

OK, if no one has anything against, Pablo and I can start a PEP just for the ‘/‘ simple syntax (without the argument group part). On Sat, 20 Jan 2018 at 07:17, Larry Hastings wrote: > > > On 01/19/2018 08:47 PM, Nick Coghlan wrote: > > - proposing the full PEP 547, including the "argument groups

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

ob/pep-pos-only/pep-.rst PEP: Title: Python Positional-Only Parameters Version: $Revision$ Last-Modified: $Date$ Author: Larry Hastings , Pablo Galindo , Mario Corchero Discussions-To: Python-Dev Status: Type: Content-Type: text/x-rst Created: 20-Jan-2018 Overview

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

Thanks, Oleg! Fixed that and a bunch more typos in the GitHub document. https://github.com/mariocj89/peps/blob/pep-pos-only/pep-.rst On 21 January 2018 at 14:16, Oleg Broytman wrote: > Hi! A few minor corrections below. > > On Sun, Jan 21, 2018 at 01:59:49PM +0000, Mario

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

Ups, indeed, totally missed it. Removed it from https://github.com/mariocj89/peps/blob/pep-pos-only/pep-.rst On 21 January 2018 at 21:44, Larry Hastings wrote: > > > On 01/21/2018 05:59 AM, Mario Corchero wrote: > > Credit for making left option groups higher precedence

[Python-Dev] Proposal: Interpreter customization at Python startup time

r for submitting the proposal as a PEP. Thanks a lot and happy holidays :)! Mario ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Me

[Python-Dev] Re: SC feedback: PEP 648 -- Extensible customizations of the interpreter at startup

Thanks all. I'll address this feedback next week. Regards, Mario On Wed, 31 Mar 2021 at 03:01, Barry Warsaw wrote: > Kind of :) > > PEP 648 would definitely allow us to deprecate the executable part of pth > files. I let my own biases leak in to my response because I would

[Python-Dev] Re: Deferral of PEP 648 - Extensible customizations of the interpreter at startup

efore the end of the week. Regards, Mario On Mon, 26 Apr 2021 at 20:39, Barry Warsaw wrote: > Hi Mario, > > The Python Steering Council today decided that we will defer consideration > of PEP 648 to Python 3.11. On March 30, 2021 we sent the following > feedback to you via pytho

[Python-Dev] Re: SC feedback: PEP 648 -- Extensible customizations of the interpreter at startup

and for users we expect to add a CLI option to site to list them. > We think io.open_code() should be used so that reading the files can be audited. Sure thing! > We think io.open_code() should be used so that reading the files can be audited. I've added a section focused on security. Not su