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

[Mario Corchero]

Hello All,

I've pushed a change to rework a bit the pep wording and add further
details on its working. It needed indeed some extra work. PR still in
flight: https://github.com/python/peps/pull/1941
I've also changed it to target 3.11. I believe most of your concerns should
be answered in the PEP now, but I will answer them here as well.

Let me know if there is any additional question or any section you think
can benefit from additional work.

> Thank you for your submission of PEP 648

Thank you for reviewing and considering it :).

> We would like to eventually go farther, including deprecation of pth
files entirely, but that is outside the scope of this PEP.

Agree on deprecating only code execution as Nick pointed out. This PEP
includes that in the Backward compatibility a mention to adding a warning
already to code execution in pth files.

> The introduction of the section titled “Benefits of __sitecustomize__”
seems out of place.

Agree, I've restructured it to make things (IMHO) clearer. Happy to apply
further changes if you think it is still confusing.

> Some of the terminology used in the PEP could be clarified.

Changes applied.

> Another ambiguity is what the PEP means by “executing” said “scripts”.

Read + exec. It used to be import but there seemed to be a general
preference on read+exec on the discourse thread. (Info now included in the
PEP).

> The “Backward compatibility” section has this incomplete sentence

Fixed

> There’s this odd grammar in the “Do nothing” section

Thanks for pointing it out, updated with your suggestion. Please let me
know if you see anything else like that, I'm not an English native speaker.

> Definition of “site path”

Clarified in the PEP. I'm purposely leaving site-path definition to the
`site` module rather than saying something too concrete. Hopefully the
updates make it clearer now.

> Order of Execution

I've added a section for this. The work plans to piggyback on the discovery
of `pth` files.

> How do pth file sys.path extensions affect the search for
__sitecustomize__ directories?

They should not, I've added a section to the PEP to explain it.

> Impact on startup time

I've added a more detailed benchmark that can be reproduced.

> How does this feature interact with virtual environments?

Outstanding question, I've added a section for it.

> Why not explicitly deprecate these

+1. I was trying to be not too ambitious here.

> Do you have any concerns that this feature will be overused?

I could see some more people starting to use it, but I think it is a niche
case. I expect system administrators and packaging tools (like venv) to use
it (and with a better experience).

> Will the runtime have any access to the list of __sitecustomize__ modules
being executed?  I.e. will you collect their paths in a new sys module
attribute?

Nope, the PEP explains how to find them programmatically though 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 sure if you were looking for
anything further in terms of security analysis.

Regards,
Mario

On Fri, 2 Apr 2021 at 17:22, Nick Coghlan  wrote:

> On Wed, 31 Mar 2021 at 11: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 like
> to find a way to replace the sys.path feature of pth with something much
> more auditable and discoverable.  To me that means deprecating pth files
> and finding something better, but maybe not.
>
> Adding pth file auditing to the output of "python -m site" should be
> entirely feasible, it just hasn't been done yet.
>
> Even if it just listed the files found, it would make them easier to
> audit than they are today.
>
> Declaring the feature impossible to audit when we haven't even really
> tried to make it auditable seems premature (the existing site output
> doesn't even indicate which paths in sys.path will be considered when
> looking for pth files, let alone indicate which of those directories
> actually contain any).
>
> Cheers,
> Nick.
>
___
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/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/775VQR46ESG435OYHCRRE4B4MGMCEPPT/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mario Corchero]

Hi Barry,

After the feedback and seeing how busy the 3.10 release is being, I was not
expecting less. As mentioned, I have no rush in getting this through. Let's
put the right time into it.
I have been updating the PEP with the feedback you gave me and I expect to
get an updated version up before 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 python-dev, which began a discussion thread:
>
>
> https://mail.python.org/archives/list/python-dev@python.org/message/OGYZZZ4A54RI24YEKZEPPLWU4WPRLJPE/
>
> We on the SC extend our thanks again for the PEP, and encourage you to
> continue to work on this PEP for pronouncement in Python 3.11.
>
> Cheers,
> -Barry
> (on behalf of the Python Steering Council)
>
>
___
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/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KIRJF3NMTF3G5W7TEYCK25ISIT2B4TC4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mario Corchero]

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 like to
> find a way to replace the sys.path feature of pth with something much more
> auditable and discoverable.  To me that means deprecating pth files and
> finding something better, but maybe not.
>
> In any case, this is outside the scope of PEP 648 so just pretend that
> part wasn’t in my response.
>
> -Barry
>
> > On Mar 30, 2021, at 17:00, Pablo Galindo Salgado 
> wrote:
> >
> > Hi Nick,
> >
> > Please don't, since that would force everyone to start using PEP 648
> just to extend sys.path, which would be just as bad as the status quo.
> >
> > I think Barry is referring to deprecate the execution capabilities of
> pth files (https://bugs.python.org/issue33944), not the files themselves.
> >
> > Cheers,
> > Pablo Galindo Salgado
> >
> > On Wed, 31 Mar 2021 at 00:34, Nick Coghlan  wrote:
> >
> >
> > On Wed, 31 Mar 2021, 3:15 am Barry Warsaw,  wrote:
> > .  We would like to eventually go farther, including deprecation of pth
> files entirely, but that is outside the scope of this PEP.
> >
> > Please don't, since that would force everyone to start using PEP 648
> just to extend sys.path, which would be just as bad as the status quo.
> >
> > Cheers,
> > Nick.
> >
> >
> >
> > ___
> > 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/
> > Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/MSOV7NKDCO7L3X46SDDLVTUEN7ER2EDB/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
___
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/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/S2RTLPBF5FYVTOBT6MKAXR5PDTBCS5PH/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mario Corchero]

Hi All,

I posted a proposal in Python ideas that I think deserves to be discussed
among core devs and the community. In short, it aims at providing a way of
customizing Python startup in a similar way of what sitecustomize provides
today.

Link to the discourse thread:
https://discuss.python.org/t/add-folder-for-python-customizations-sitecustomize/6190
Link to the proposal in a pepish format:
https://gist.github.com/mariocj89/36daffd1e157b93e5c697bbadcb05806

I'd appreciate feedback in the discourse thread if possible. If this looks
reasonable, Pablo Galindo would be my sponsor 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/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MZUFM2O4IZKTHEVYFY3U2CQ6FCGC3MWA/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mario Corchero]

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 <la...@hastings.org> wrote:

>
>
> 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 elegantly support
> the range builtin as "range([start,] stop, [step])", although nobody has
> bothered to actually convert range() to Clinic.  (Which is reasonable--I
> don't think there's any reason to bother.)
>
> Anyway, this acknowledgement is the only mention of "option groups" in the
> document.  Perhaps this was in reference to the now-abandoned idea of
> adding "option groups" to the language?  If so, this acknowledgement should
> probably be removed too.
>
>
> */arry*
>
___
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/archive%40mail-archive.com

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

[Mario Corchero]

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 <p...@phdru.name> wrote:

> Hi! A few minor corrections below.
>
> On Sun, Jan 21, 2018 at 01:59:49PM +, Mario Corchero <
> marioc...@gmail.com> wrote:
> > Author: Larry Hastings <la...@hastings.org>, Pablo Galindo
> > <pablog...@gmail.com>, Mario Corchero  <marioc...@gmail.com>
>  ^
> Add a space or a few here - this is the way for line wrapping in long
> headers.
>
> > introduces an asymetry on how parameter behavior is declared. Also, as
> the `\`
>
>\ -> /
>
> Oleg.
> --
>  Oleg Broytmanhttp://phdru.name/p...@phdru.name
>Programmers don't die, they just GOSUB without RETURN.
> ___
> 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/
> mariocj89%40gmail.com
>
___
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/archive%40mail-archive.com

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

[Mario Corchero]

Here is the proposal we have worked on (Pablo and I).

I've added Larry as co-author given that a good chunk of the content and
the idea comes from his PEP. Larry, if you don't want to appear as such
please let us know.

Thanks!

Rendered content:
https://github.com/mariocj89/peps/blob/pep-pos-only/pep-.rst


PEP: 
Title: Python Positional-Only Parameters
Version: $Revision$
Last-Modified: $Date$
Author: Larry Hastings <la...@hastings.org>, Pablo Galindo
<pablog...@gmail.com>, Mario Corchero  <marioc...@gmail.com>
Discussions-To: Python-Dev <python-dev@python.org>
Status:
Type:
Content-Type: text/x-rst
Created: 20-Jan-2018



Overview


This PEP proposes a syntax for positional-only parameters in Python.
Positional-only parameters are parameters without an externally-usable
name; when a function accepting positional-only parameters is called,
positional arguments are mapped to these parameters based solely on
their position.

=
Rationale
=

Python has always supported positional-only parameters.
Early versions of Python lacked the concept of specifying
parameters by name, so naturally all parameters were
positional-only.  This changed around Python 1.0, when
all parameters suddenly became positional-or-keyword.
This allowed users to provide arguments to a function both
positionally or referencing the keyword used at the definition
of it. But, this is not always desired nor even available as
even in current versions of Python, many CPython
"builtin" functions still only accept positional-only arguments.

Even if positional arguments only in a function can be achieved
via using``*args`` parameters and extracting them one by one,
the solution is far from ideal and not as expressive as the one
proposed in this PEP, which targets to provide syntax to specify
accepting a specific number of positional-only parameters.
Additionally, this will bridge the gap we currently find between
builtin functions that today allows to specify positional-only
parameters and pure Python implementations that lack the
syntax for it.

-
Positional-Only Parameter Semantics In Current Python
-

There are many, many examples of builtins that only
accept positional-only parameters.  The resulting
semantics are easily experienced by the Python
programmer--just try calling one, specifying its
arguments by name::


>>> help(pow)
...
pow(x, y, z=None, /)
...
>>> pow(x=5, y=3)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: pow() takes no keyword arguments

Pow clearly expresses that its arguments are only positional
via the `/` marker, but this is at the moment only documentational,
Python developers cannot wright such syntax.

In addition, there are some functions with particularly
interesting semantics:

* ``range()``, which accepts an optional parameter
  to the *left* of its required parameter. [#RANGE]_

* ``dict()``, whose mapping/iterator parameter is optional and
  semantically must be positional-only.  Any externally
  visible name for this parameter would occlude
  that name going into the ``**kwarg`` keyword variadic
  parameter dict! [#DICT]_

Obviously one can simulate any of these in pure Python code
by accepting ``(*args, **kwargs)`` and parsing the arguments
by hand.  But this results in a disconnect between the
Python function signature and what it actually accepts,
not to mention the work of implementing said argument parsing.

==
Motivation
==

The new syntax will allow developers to further control how their
api can be consumed. It will allow to restrict the usage of keyword
Specify arguments by adding the new type of positional-only ones.

A similar PEP with a broader scope (PEP 457) was proposed
to define the syntax. This PEP builds on top of part of it
to define and provide an implementation for the ``/`` syntax on
function signatures.

=
The Current State Of Documentation For Positional-Only Parameters
=

The documentation for positional-only parameters is incomplete
and inconsistent:

* Some functions denote optional groups of positional-only arguments
  by enclosing them in nested square brackets. [#BORDER]_

* Some functions denote optional groups of positional-only arguments
  by presenting multiple prototypes with varying numbers of
  arguments. [#SENDFILE]_

* Some functions use *both* of the above approaches. [#RANGE]_ [#ADDCH]_

One more important idea to consider: currently in the documentation
there's no way to tell whether a function takes positional-only
parameters.  ``open()`` accepts keyword arguments, ``ord()`` does
not, but there is no way of telling just by reading the
documentation

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

[Mario Corchero]

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" 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 groups" to Argument Clinic in an attempt to
> support legacy functions with crazy argument signatures that count their
> arguments.  (For example, curses.window.overlay() takes either one or seven
> arguments exactly--not two!, and not six!.)  I have deeply mixed feelings
> about the result, and I would hate to see support for it added to the
> language.  If I had my way I'd rewrite or replace those functions and have
> only modern Pythonic signatures in the standard library.
>
>
> */arry*
>
___
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/archive%40mail-archive.com

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

[Mario Corchero]

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 2018 at 14:40, Nick Coghlan  wrote:

> On 18 January 2018 at 19:26, Larry Hastings  wrote:
> > Would we be adding yet a third argument-parsing function,
> > PyArg_ParseTupleAndKeywordsWithPositionalOnly()?
>
> Checking the docs, it turns out PyArg_ParseTupleAndKeywords already
> gained positional-only argument support in 3.6 by way of empty strings
> in the keyword array.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> 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/
> mariocj89%40gmail.com
>
___
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/archive%40mail-archive.com

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

[Mario Corchero]

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 <victor.stin...@gmail.com>
wrote:

> Hi,
>
> 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/pipermail/python-ideas/2017-February/044879.html
> https://mail.python.org/pipermail/python-ideas/2017-March/044956.html
>
> There are already supported at the C level, but not at the Python level.
>
> Our BDFL approved the idea:
>
> https://mail.python.org/pipermail/python-ideas/2017-March/044959.html
>
> But I didn't find time to implement it. Does someone want to work on
> an implementation of the idea?
>
> March 2, 2017 7:16 PM, "Brett Cannon"  wrote:
> > It seems all the core devs who have commented on this are in the positive
> > (Victor, Yury, Ethan, Yury, Guido, Terry, and Steven; MAL didn't
> explicitly
> > vote). So to me that suggests there's enough support to warrant writing a
> > PEP. Are you up for writing it, Victor, or is someone else going to write
> > it?
>
> It seems like a PEP is needed.
>
> Victor
> ___
> 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/
> mariocj89%40gmail.com
>
___
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/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Mario Corchero]

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 kind to do it (he told me not long ago he was thinking on
sending a PR for it). If he is busy I am happy to chip in time this
weekend.

All I wanted when I sent https://bugs.python.org/issue31800 was actually to
be able to parse isoformat datetime ^^.



 Thu, 30 Nov 2017 at 00:09, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:

> On Wed, Nov 29, 2017 at 6:42 PM, Chris Barker 
> wrote:
>
>>
>> indeed what is the holdup? I don't recall anyone saying it was a bad idea
>> in the last discussion.
>>
>> Do we just need an implementation?
>>
>> Is the one in the Bug Report not up to snuff? If not, then what's wrong
>> with it? This is just not that hard a problem to solve.
>>
>
>
> See my comment from over a year ago: <
> https://bugs.python.org/issue15873#msg273609>.  The proposed patch did
> not have a C implementation, but we can use the same approach as with
> strptime and call Python code from C.  If users will start complaining
> about performance, we can speed it up in later releases.  Also the new
> method needs to be documented.  Overall, it does not seem to require more
> than an hour of work from a motivated developer, but the people who
> contributed to the issue in the past seem to have lost their interest.
> ___
> 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/mariocj89%40gmail.com
>
___
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/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Mario Corchero]

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:
https://github.com/dateutil/dateutil/pull/489/files

On 28 November 2017 at 19:51, Mike Miller  wrote:

> This may have gotten bogged down again.  Could we get the output of
> datetime.isoformat() parsed at a minimum?  Perfection is not required.
>
> Looks like there is a patch or two and test cases on the bug.
>
> -Mike
>
>
> Could anyone put this five year-old bug about parsing iso8601 format
>> date-times on the front burner?
>>
>>  http://bugs.python.org/issue15873
>>
>> In the comments there's a lot of hand-wringing about different variations
>> that bogged it down, but right now I only need it to handle the output of
>> datetime.isoformat():
>>
>>  >>> dt.isoformat()
>>  '2017-10-20T08:20:08.986166+00:00'
>>
>> Perhaps if we could get that minimum first step in, it could be iterated
>> on and made more lenient in the future.
>>
>> ___
> 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/mariocj89
> %40gmail.com
>
___
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/archive%40mail-archive.com

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

[Mario Corchero]

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 builtin
> to extract multiple items from a mapping in a single operation.

You mean subitems as attrgetter does? That would be actually quite cool!

  d = dict(a=dict(b=1), b=dict(c=2))
  ab, ac = itemgetter("a.b", "b.c", separator=".")(d)


I've created an issue in case something like that is desired:
https://bugs.python.org/issue32010
No real strong push for it, happy to just close it if it does not get
interest.

That said I am not sure it solves Ben requests as he seamed to be
targetting a way to bind the variable name with the dictionary keys
implicitly.

On 12 November 2017 at 10:06, Nick Coghlan  wrote:

> On 11 November 2017 at 16:22, Jelle Zijlstra 
> wrote:
> > 2017-11-10 19:53 GMT-08:00 Ben Usman :
> >> I was not able to find any PEPs that suggest this (search keywords:
> >> "PEP 445 dicts", "dictionary unpacking assignment", checked PEP-0),
> >> however, let me know if I am wrong.
> >>
> > It was discussed at great length on Python-ideas about a year ago. There
> is
> > a thread called "Unpacking a dict" from May 2016.
>
> 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 builtin
> to extract multiple items from a mapping in a single operation.
>
> So if folks would like dict unpacking syntax, then a suitable place to
> start would be a proposal for a "getitems"  builtin that allowed
> operations like:
>
> b, a  = getitems(d, ("b", "a"))
>
> operator.itemgetter and operator.attrgetter may provide some
> inspiration for possible proposals.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> 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/
> mariocj89%40gmail.com
>
___
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/archive%40mail-archive.com

[Python-Dev] PEP 484

[Mario Figueiredo]

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 analysis, has no
place in __doc__, I think that we could live with that. Otherwise:

  def myfunction(arg1, arg2):
  
  Normal docstring...
  
  @hint: (str, int) - bool
  return True
___
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/archive%40mail-archive.com

[Python-Dev] Roundup improvements use-cases

[Mario]

 linked/browsed (starting)
from the Roundup UI and issues can be created/linked to commits
(starting) from the navigation tool UI.

USE CASE K: For a given issue, add per patched file links for RSS logs
(see http://selenic.com/hg/rss-log/tip/mercurial/hgweb/hgweb_mod.py).

USE CASE M: Besides links to files, allow adding links to files at
given versions/tags/branchs, links to tarballs and easy to clone links
to branches and repositories.

USE CASE V:

Handle small branches (and maybe suggest using them for small
patches?) generated using the convert extension with --filemap.
==

Improvements to the use cases will follow on the wiki page:
http://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/options/python-dev/archive%40mail-archive.com

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

[Mario]

 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 wiki page mentioned in the
proposal, along with the use case? Following that, I'll see if I can do
anything about it to make it a reality.

Cheers,
M.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial?

[Mario]

 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
 currently, so I would not make it a prerequisite for the switch.

 While I don't know how urgent this is, I will just mention that I am
willing to work on Roundup-mercurial during GSoC (or outside
it, if I don't get accept).

Cheers,
M.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Helper Python core development tools

[Mario]

With all the sand and sun on the beaches, should I really be doing this now?

That is the question we probably ask ourselves every time we have to do some
boring task. What kind of things do you think could be made better? What
would
make your workflow smoother and more fun? Now is your chance to voice your
opinion.

http://wiki.python.org/moin/CoreDevHelperTools

Some of the tools/extensions categories that could be relevant:

- Wrappers for working with tracker issues
- Wrapper for managing patches
- Wrapper for running tests
- Wrapper for submitting diffs for review
- 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. Thank you for your time and your help in this matter.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com