[Python-ideas] Re: Fwd: Re: Experimenting with dict performance, and an immutable dict

[Brett Cannon]

On Sat, Jul 25, 2020 at 12:58 PM Guido van Rossum  wrote:

> On Sat, Jul 25, 2020 at 12:45 PM Marco Sulla 
> wrote:
>
>> I also remembered another possible use-case: kwargs in CPython. In C
>> code, kwargs are PyDictObjects. I suppose they are usually not modified; if
>> so, fdict could be used, since it seems to be faster at creation.
>>
>
> That's an interesting idea. It has always vaguely bothered me that `*args`
> gives a tuple while `**kwds` gives a dict. Unfortunately it's impossible to
> change without breaking tons of existing code, since things like
> `kwds.pop("something")` have become a pretty standard idiom to use it.
>

And just to be clear for folks that don't know the idiom (it took me a
second to remember myself), it's common to do something like:

def spam(**kwargs):
"""Do 'something', then call bacon()."""
if 'something' in kwargs:
use_something(kwargs.pop('something')
bacon(**kwargs)

def bacon(**kwargs):
...

You see this in decorators, for instance, that add an extra argument to do
some pre-processing or something before calling the decorated function.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4XU3IECSVNQLFU2JWXLJY7A4ZRCTKPXM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Official joint communication from the Python Steering Council, PSF Board of Directors, and PSF Conduct WG

[Brett Cannon]

[This has been sent to python-committers, python-dev, and python-ideas]

Recently, a series of discussions on this mailing list resulted in behavior
that did not live up to the standards of the Python Community. The PSF
Board of Directors, Python Steering Council, and the PSF Conduct Working
Group would like to remind this community that our shared goal is to
advance the Python language while simultaneously building a diverse,
inclusive, and welcoming Python community. While the community has made
progress in recent years, this discussion made it clear to many of us that
we still have room to grow.

At the request of the PSF Board, the Steering Council, and members of the
community, the PSF Conduct WG met to discuss these recent events and
recommend action. As a result, warnings will be given to several members of
the Python Community, and the Steering Council will be taking further
action.

Especially during passionate discussions like these, we'd like to ask that
all Pythonistas focus on being welcoming and respectful, and that we all
try to act in the best spirit of the Python Community.

Thank you,
Python Steering Council
PSF Board of Directors
PSF Conduct WG
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RIWQEY5V7235A6URX6V7ERAG27NBZXMA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Thoughts about Fast Python Engine and Python EveryWhere

[Brett Cannon]

On Thu, Jul 16, 2020 at 11:52 AM  wrote:

> CPython is portable but due to integrated standard library (builtin
> functionality) it is hard to evolve it,


How so? The stdlib is just a collection of packages we happen to ship with
Python. Think of it as if we ship blessed packages from PyPI with Python
itself. That's it. The stdlib very much is not a hindrance to performance.
Python's design as a language is what makes it tough. We could rip out the
stdlib tomorrow and it would not change how we optimize the CPython
interpreter.


> for examle to add JIT,


As someone who helped create a JIT for Python (Pyjion), I can tell you as a
fact that the stdlib in no way hindered our work. It was a lack of time and
simply the fact that Python is a very dynamic language.


> anyway it is just my thoughts
>

And that's fine, but what we are all trying to do is help educate you about
some statements you made which are not accurate.

-Brett


> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/TX3XGC2THCJ3YL3X5LTL4YEDYZMH3JBH/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/22MDJ4SNMAVDGWKH434LGMVCWL5EHK5A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allowing -b (BytesWarning) to be activated in other ways

[Brett Cannon]

I honestly wouldn't expect that flag to last forever because it exists
purely to help with Python 2 -> 3 transitions. Since it fundamentally
changes how things like comparison and `str()` work it isn't something to
flip on needlessly and you would be better off using a type checker or
linter to look for those sorts of errors.

As such, changing the C API specifically for this flag isn't something I
personally would want to see.

On Thu, Jul 16, 2020 at 8:17 AM Shai Berger  wrote:

> Hi Pythonistas,
>
> The -b flag, which turns on checks which emit BytesWarnings on
> operations mixing bytes and str objects, is very useful.
>
> However, the only way to set this flag is via the Python invocation.
> This limits its usability in contexts where the user's control of the
> Python invocation is limited, e.g when using Python embedded in another
> executable (such as uwsgi). There appears to be no function which can
> set the flag, and no environment variable which controls it.
>
> Up to Python 3.7, the extension module provided by the bytes-warning
> package[1] works around this (it exposes a function which allows
> setting the flag from within Python). But with 3.8 (and I suspect,
> because of PEP-587[2] related changes), this fails silently and the sys
> flag bytes_warning remains unaffected.
>
> Can we have a non-invocation way to control this flag?
>
> Thanks,
> Shai.
>
> [1] https://pypi.org/project/bytes-warning/
> [2] https://www.python.org/dev/peps/pep-0587/
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/FV37A5SIQGY4VJ6ESUNAMVXHUXUHUVGO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/N6L6FUEQJF3GX3BLT65SG73LPCZTOUZU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Thoughts about Fast Python Engine and Python EveryWhere

[Brett Cannon]

CPython is already very portable thanks to it being implemented in C.

I don't see, though, how a lack of stdlib for JavaScript makes it fast?
Unless you're saying the Python core team should drop the stdlib so it has
more time to focus on the CPython interpreter itself?

On Thu, Jul 16, 2020 at 10:00 AM  wrote:

> Recently I have been thinking about why `JavaScript` with it's horrible
> type system and lots of edge cases has supported so many platform and is
> very fast ...
>
> First answer is simple, because big companies such as Google, Facebook and
> so on evolve this language and run-time for it ...
>
> But it is only part of story, all this platforms would not be possible
> without some good architecture that was done by this companies
>
> What is this architecture decision ? It is a splitting run-time and
> infrastructure
>
> V8 is JavaScript engine that could very fast execute JavaScript and that
> is all !!
> It has a reach API using which you can embed this run-time almost every
> where ...
>
> What if we in Python will accomplish the same solution ?
> What if Python would have some very fast engine that could be integrate in
> every environment ?
>
> Engine will be able only execute Python code and call some registered
> callback (hooks) for `import` some module, for calling some registered
> C-extension and so on
> If this engine will be very portable then Python would be embedded
> everywhere !! ;)
>
> Engine will not suport all builtin functions and it will not have any
> library embedded in it
> To add some buiiltin functionality you will need register the callbacks in
> engine, the same with libraries
> Engine will just call callback to import code and callback optionally will
> return Python script which will be executed
>
> To be continue ...
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/D7HOOBORH2FJOJO4PWBIRHNOOVIIFBXG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3YOGZEIPIVWVMCJPHYPB26PS4V7VXU45/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python GIL Thoughts

[Brett Cannon]

On Tue, Jun 30, 2020 at 5:26 AM  wrote:

> Brett Cannon wrote:
> > It's a discussion issue. PEP 554 is trying to focus on the API of
> > subinterpreters and doesn't want to distract from that by bringing the
> GIL
> > into it.
> > That being said, the general expectation from everyone involved is there
> > will be a perl-interpreter GIL.
> > On Sat, Jun 27, 2020 at 10:31 AM Denis Kotov redrad...@gmail.com wrote:
> > > Reading PEP554
> > > https://www.python.org/dev/peps/pep-0554/#a-disclaimer-about-the-gil
> > > seems like at the current implementation of subinterpretters there
> will be
> > > no separate GIL …
> > > But I am wondering, why ?
> > > Each subinterpreter has it own object management and Garbage
> Collection …
> > > Why subinterpreters should share one GIL ?
> > > Is there any technical issues ?
> > > Sent from Mail https://go.microsoft.com/fwlink/?LinkId=550986
> > > for
> > > Windows 10
> > >
> > > Python-ideas mailing list -- python-ideas@python.org
> > > To unsubscribe send an email to python-ideas-le...@python.org
> > > https://mail.python.org/mailman3/lists/python-ideas.python.org/
> > > Message archived at
> > >
> https://mail.python.org/archives/list/python-ideas@python.org/message/ZC3WVJ.
> ..
> > > Code of Conduct: http://python.org/psf/codeofconduct/
> > >
>
> Okay, where is discussions of PEP 554, because I wanted to propose to add
> `async` API for sub-interpreters in such way using it not required to
> create new thread, just use event_loop
>

For that specific case you should email the authors of PEP 554.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EKAXTYJVSYIVJIKOFV3LVYDPIA2IMDDG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python GIL Thoughts

[Brett Cannon]

It's a discussion issue. PEP 554 is trying to focus on the API of
subinterpreters and doesn't want to distract from that by bringing the GIL
into it.

That being said, the general expectation from everyone involved is there
will be a perl-interpreter GIL.

On Sat, Jun 27, 2020 at 10:31 AM Denis Kotov  wrote:

> Reading PEP554
> https://www.python.org/dev/peps/pep-0554/#a-disclaimer-about-the-gil
> seems like at the current implementation of subinterpretters there will be
> no separate GIL …
>
>
>
> But I am wondering, why ?
>
> Each subinterpreter has it own object management and Garbage Collection …
>
>
>
> Why subinterpreters should share one GIL ?
>
> Is there any technical issues ?
>
>
>
> Sent from Mail  for
> Windows 10
>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/ZC3WVJKNNIQNQLPLLTMDLU6SHTNYZ4ID/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/H5XRPUVM66KSINNODHIQC5YU6VUOUV3A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python JIT Compilation Thoughts

[Brett Cannon]

On Mon, Jun 29, 2020 at 2:50 AM  wrote:

> Ned Batchelder wrote:
> > On 5/25/20 6:02 AM, redrad...@gmail.com wrote:
> > > Hi all,
> > > I do not know maybe it was already discussed ...
> > > It's been extensively discussed and attempted.
> > > but the toolchain like LLVM is very mature and it can
> > > provide the simpler JIT compilation to machine code functionality and
> it will improve
> > > performance of the Python a lot !!
> > > Be careful with "will": nothing is simple in this arena.
> > --Ned.
>
> And what was the result of discussions ?


That it's very hard and PyPy is the only one that has pulled off a JIT and
kept it going with many other attempts that didn't make it as far.

-Brett


> There are also Cranelift toolchain that is written in Rust and it provides
> as for very good API ...
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/AJJWKG2OWZNMWHD7GUL3RXB25QBCBFPJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/F3PVWKHDXICCJ4CBMBAIMHAQVPEGZUOS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Access (ordered) dict by index; insert slice

[Brett Cannon]

Why can't you do `tuple(dict.items())` to get your indexable pairs?

Otherwise there are no plans as you would have to introduce a new method as
you can't assume e.g. `0` is being used as a dictionary key.

On Fri, Jun 26, 2020 at 10:32 AM Hans Ginzel  wrote:

> Date: Fri, 26 Jun 2020 18:47:44 +0200
> From: Hans Ginzel 
> To: Hans Ginzel 
> Subject: Access (ordered) dict by index; insert slice
>
> Hello,
>
> thank you for making dict ordered.
> Is it planned to access key,value pair(s) by index? See
> https://stackoverflow.com/a/44687752/2556118 for example. Both for
> reading and (re)writing?
> Is it planned to insert pair(s) on exact index? Or generally to slice? See
> splice() in Perl, https://perldoc.perl.org/functions/splice.html.
>
> Use case: Represent database table metadata (columns). It is useful as to
> access columns both by name and by index as to insert column on specific
> position, https://dev.mysql.com/doc/refman/8.0/en/alter-table.html,
> “ALTER TABLE ADD COLUMN [FIRST |AFTER col]” (consider default order or
> table storage size optimisation by aligning).
>
> Thank you in advance,
> Hans
> PS1: Named tuples cannot be used, are immutable.
> PS2: See
> https://metacpan.org/pod/perlref#Pseudo-hashes:-Using-an-array-as-a-hash
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/S7UMTWK65X6BJDYZ3SSU7I7HOIASDMMJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/AQQVNZ6XZWJOY37Q42LULNS7ZEV4DEZ6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: giving set.add a return value

[Brett Cannon]

On Thu, Jun 25, 2020 at 10:10 AM Ben Avrahami 
wrote:

> On Thu, Jun 25, 2020 at 7:55 PM Christopher Barker 
> wrote:
>
>> On Thu, Jun 25, 2020 at 9:02 AM Steele Farnsworth 
>> wrote:
>> indeed -- and that is pretty darn baked in to Python, so I don't think
>> it's going to change.
>>
>
30 years of history beats out 8 years since the last discussion of this. 😉


>
>>
> Except this convention doesn't hold for dict.setvalue (which I did
> misspell, sorry), or for dict.pop.
>

I don't know what you mean by setvalue(), but I'm assuming you meant
setdefault(). If that's true, then the guideline isn't "all mutating
methods must return None", it's "*unless* the method is specifically
designed to have a return value based on the purpose of the method, the
method should return None".


> Both these methods fundamentally mutate the collection, but they also
> return a value (which could be retrieved by a non-mutating method), that
> somewhat pertains to the operation performed.
>

Both pop() and setdefault() are meant to return something, they just also
happen to mutate things. You're wanting the reverse and that isn't how
Python has chosen to go.

Same with people who bring up wanting a fluent API where 'self' is always
returned. It's a very specific decision that for methods that do nothing
but mutation they return None to signify that you're not getting back a new
object, but something that mutated in-place. This is why list.sort(), for
instance, returns None; you are not getting a new copy of the list sorted,
you actually changed the original object which you should have named with a
variable. That way you have to access the object by the name you already
gave it as a reminder its the same object.

Plus Python isn't big on the crazy one-lineers where you might want to do
an inline call of add() to simply save yourself one line of code. Explicit
is better than implicit, and that can mean needing to simply do something
in two lines instead of one.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XBUPWZ3ZPEQZ233TF6CRYPMGXQ7XSJ7Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: String module name

[Brett Cannon]

You can do this via a function call; it does not require syntax support.

And Deno has specific needs as they also need to fetch type information, so
being able to parse out the URLs systematically has special meaning to deno.

On Tue, Jun 16, 2020 at 2:06 AM  wrote:

> Yeah, but it still desire to be solved ...
>
> One of the use-cases is if I want to use `Brython`, it will be usable to
> load the module or entire package from the internet and then to use it in
> my application ...
>
> Issue with the right to access some resources could be solve with flags as
> `Deno` did
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/RXITTI3MWQU6L5QKFGUSL7K2MXI4IYVM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/E2OBNEKY6VR6BNBNWX72YPV2Z7PPBHQ5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: await by default

[Brett Cannon]

That switch means other things can now occur. You have to know that when
you yield your coroutine other things may mutate state, which means you now
need to check that no previous assumptions have become invalid. Event loops
typically being single-threaded means you don't need to lock and worry
about race conditions, but it doesn't let you off the hook to not assume
something mutated when you weren't looking. Plus execution order is now
non-deterministic which is something else you need to worry about.

To be upfront, as a steering council member I wouldn't vote to approve a
PEP that proposed this change.

On Fri, Jun 12, 2020 at 2:27 PM J. Pic  wrote:

> I mean, if it pauses because of some blocking IO and switches to another
> coroutine, that's just a BIG win ... I have hard times trying to figure how
> that signal could be useful to me as a developer. On the other hand, I have
> to (await test()).bar ...
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7KRDXPZGXJJLQX5LMZ7FGAIONDW4VZRB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: await by default

[Brett Cannon]

The use of `await` is on purpose to signal to you as a developer that the
event loop may very well pause at that point and context switch to another
coroutine. Take that away and you lose that signal. You also would never
know from your code whether you need to have an event loop running or not
to make such a call.

On Fri, Jun 12, 2020 at 2:03 PM J. Pic  wrote:

> Hi all,
>
> Just wonder what it would look like if coroutines where awaited by
> default, you would only have to use "noawait" when you do *not* want to
> await a coroutine ?
>
>   async def test():
> return do_something()
>
>   # it's awaited here by default: we get the result and not a coroutine
>   result1 = test()
>
>   # not awaiting here because you want to do_something_else
>   coroutine = noawait test()
>   do_something_else()
>   result2 = await coroutine
>
> Then, you could be chaining code again like this:
>
>foo_of_result = test().foo
>
> Instead of:
>
>foo_of_result = (await test()).foo
>
> Thank you in advance for your replies
>
> Have a great weekend !
>
> --
> ∞
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/TZAVYTSA6MSMTJWODXIINT3OWMR5LQS4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/25E2UHUHUOIXE5ZB3EEHDVNFNV5WEHTD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: url imports

[Brett Cannon]

Do note that is not as easy as it seems as you would have to figure out how
to manage dependencies appropriately, especially if you are going to
support using different versions at the same time.

Otherwise you could write your own function today to see if you can get a
proof-of-concept working as the `import` statement isn't anything special
and everything it does is implemented in Python already.

On Wed, Jun 10, 2020 at 9:47 AM Aditya Shankar  wrote:

> it'd be really cool if we could drop virtualenvs + requirements.txt
> altogether, i.e., like deno, mordern javascript and so...
>
> i.e. instead of
> `pip install package`
> and
> `import package`
> and
> `pip freeze > requirements.txt`
> for every import,
>
> we stick to, for every python script
>
> `abc = import("package", "2.*")`
>
> from imports could be done like
>
> `value = import("package", "1.*").value `
>
> this completely removes the virtualenvs issue, and solves alot of
> problematic issues with python imports
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/FNQLJJMEDNPV3TWHVI6GFSEZWRUHY6M6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZHAAJF7ITYPMDGZUVLBZNI63UZKKIASW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Automatic notification when your PR test fails or succeeds

[Brett Cannon]

This sort of question belongs on core-workflow.

BTW, please don't open draft PRs for CPython. They are very distracting.
It's best to only send a PR to CPython when you're ready to review it.
Otherwise you should be able to check the CI via GitHub Actions on your own
fork before sending it out for review.

On Fri, Jun 5, 2020 at 10:11 AM Ram Rachum  wrote:

> Hi guys,
>
> I'm not sure whether this is the right mailing list for this, because it's
> more for the Python development process on GitHub than Python itself. If
> this belongs somewhere else, let me know.
>
> When you open a PR to CPython, it would be cool if there was an option to
> get email notifications on whether the tests fail or succeeded. For
> example, I may open a PR as a draft, and only after I get notification on
> success, mark it as "Ready for review".
>
> Right now I just poll it manually, which is annoying.
>
> What do you think?
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/6EUZYFIZH5KSGU7TR67K5LB6JCBTVWMR/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MZBGMY4ITA67236YKAVWGXZYTA2UV6M2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python JIT Compilation Thoughts

[Brett Cannon]

It was Unladen Swallow that used LLVM, but it was early on in LLVM's JIT
life and they unfortunately had to spend a bunch of time fixing LLVM which
ate up the time they had to do the experiment.

On Mon, May 25, 2020 at 2:36 PM Christopher Barker 
wrote:

> On Mon, May 25, 2020 at 3:05 AM  wrote:
>
>> I do not know maybe it was already discussed ... but the toolchain like
>> LLVM is very mature and it can provide the simpler JIT compilation to
>> machine code functionality and it will improve performance of the Python a
>> lot !!
>>
>
> see numba:  http://numba.pydata.org/
>
> Also, I"m pretty sure one of the efforts to make a faster python was based
> on LLVM, but it didn't work out as well as hoped -- unladen swallow maybe?
>
> -CHB
>
>
>
>
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/A3VF6DJ3H2IIUAYYEKSS3T3N7X443OO7/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> Christopher Barker, PhD
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/JJQNOXOO57NPLPGS243VIW6O2I7DD4WH/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JY53RHXRHHGZ3MBCCD5BC2KVYLLH76B6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Ensuring asserts are always on in a file

[Brett Cannon]

The closest you may ever get to something like this is a clean separation
of -O flags instead of the current -O/-OO options. That way you can flip on
everything *but* assertion removal. But a per-file directive I don't see
happening, and even the flag separation has never caught on enough for
anyone to put in the effort to get a PoC working since the only people who
ask for this are people wanting permanent asserts and that leads the usual
"you're doing it wrong" comments. Probably best/only way to motivate it is
to open up -O in a way to allow for more optimizations, but once again
that's a lot of work.

On Sun, May 17, 2020 at 2:08 PM Alex Hall  wrote:

> Some people (like myself, or the coworkers of [this person](
> https://mail.python.org/archives/list/python-ideas@python.org/thread/PLXOXKACKGXN4ZKISDVXLKMFIETWTF63/))
> just like to use asserts as a convenient way to check things. We don't want
> asserts to ever be turned off. Maybe there could be some kind of compiler
> directive which means "in this file, even with -O, keep the asserts". Maybe
> the line `assert __debug__`?
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/TQKXSCMH7JYCHAE3XN7MCSWVA2UJ4R5G/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/W7BNFTTJZ56NKGLEIBQGQVOGFAXZWUUK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Brett Cannon]

I'm going to ask that people please try to keep this thread on-topic to the
question of using Unicode characters directly for things that we currently
use two ASCII characters to represent. Other ideas that spring up from this
question are totally welcome to be done as new threads of discussion.

On Sun, May 17, 2020 at 6:42 PM MRAB  wrote:

> On 2020-05-18 02:25, Greg Ewing wrote:
> > On 18/05/20 1:59 am, Paul Sokolovsky wrote:
> >> But even
> >> {(int): str} is a better type annotation for a function than
> >> Callable[[int], str].
> >
> > I don't agree -- it looks more like some kind of dict type, and
> > would be better reserved for that purpose.
> >
> >> And if we e.g. talk about making "->" a special operator which would
> >> allow it to appear in other contexts
> >
> > Or maybe we could leverage the new walrus operator and write
> >
> >   str := (int)
> >
> It would be closer to the existing annotation if we could write:
>
>  [int] -> str
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/77OWDBQPQKDDQ3CGHUC4PY6ODI3LUBY3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BWFXZOADEX2ZEBJHOHHZIBX2LFR5AFBG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Keyword arguments self-assignment

[Brett Cannon]

On Fri, Apr 17, 2020 at 10:29 AM Alex Hall  wrote:

> Perhaps an easier next step would be to get better data about people's
> opinions with a simple poll? Is there a standard way to vote on things in
> this list?
>

No, but if you want to create a poll I would strongly advise that you
create a poll at https://discuss.python.org/c/ideas/6 and post the link
here (Discourse has built-in poll support). Otherwise you will get a swarm
of votes intertwined with comments and keeping track of it all will be
difficult.

-Brett


>
> I say we do a simple approval vote. Everyone ticks all the syntaxes that
> they think would be acceptable to include in the language. It's not very
> precise but it's easy and may inform what to do next.
>
> Here is a script to generate a bunch of options:
>
> ```
> for template in [
> 'foo(bar, baz="thing", %s)',
> '{"baz": "thing", %s}',
> ]:
> for affix in ["=", ":", "::"]:
> for rest in [
> f'spam{affix}, stuff{affix}',
> f'{affix}spam, {affix}stuff',
> ]:
> print(template % rest)
>
> for template in [
> 'foo(bar, baz="thing", %s, spam, stuff)',
> '{"baz": "thing", %s, spam, stuff}',
> ]:
> for separator in ["*", "**", ":", "::", "="]:
> print(template % separator)
>
> # These options are currently valid syntax that are guaranteed to fail at
> runtime
> print("""\
> foo(bar, baz="thing", **(spam, stuff))
> foo(bar, baz="thing", **{spam, stuff})
> {{"baz": "thing", spam, stuff}}
> """)
> ```
>
> The output:
>
> ```
> foo(bar, baz="thing", spam=, stuff=)
> foo(bar, baz="thing", =spam, =stuff)
> foo(bar, baz="thing", spam:, stuff:)
> foo(bar, baz="thing", :spam, :stuff)
> foo(bar, baz="thing", spam::, stuff::)
> foo(bar, baz="thing", ::spam, ::stuff)
> {"baz": "thing", spam=, stuff=}
> {"baz": "thing", =spam, =stuff}
> {"baz": "thing", spam:, stuff:}
> {"baz": "thing", :spam, :stuff}
> {"baz": "thing", spam::, stuff::}
> {"baz": "thing", ::spam, ::stuff}
> foo(bar, baz="thing", *, spam, stuff)
> foo(bar, baz="thing", **, spam, stuff)
> foo(bar, baz="thing", :, spam, stuff)
> foo(bar, baz="thing", ::, spam, stuff)
> foo(bar, baz="thing", =, spam, stuff)
> {"baz": "thing", *, spam, stuff}
> {"baz": "thing", **, spam, stuff}
> {"baz": "thing", :, spam, stuff}
> {"baz": "thing", ::, spam, stuff}
> {"baz": "thing", =, spam, stuff}
> foo(bar, baz="thing", **(spam, stuff))
> foo(bar, baz="thing", **{spam, stuff})
> {{"baz": "thing", spam, stuff}}
> ```
>
> Are there any other options to consider? If people think this list looks
> complete I can create an online poll with them. I'm open to suggestions
> about preferred software/websites.
>
> On Fri, Apr 17, 2020 at 6:41 PM Eric V. Smith  wrote:
>
>> On 4/17/2020 12:28 PM, Chris Angelico wrote:
>> > On Sat, Apr 18, 2020 at 1:54 AM David Mertz  wrote:
>> >> Hmmm... I disagree with Chris.
>> >>
>> >> I'm definitely -1 on a magic dangling 'foo=' after variable names. And
>> something less than -1 on the even more magic "Lisp symbol that isn't a
>> symbol" ':foo'.
>> >>
>> >> Those are just ugly and mysterious.
>> >>
>> >> However, I don't HATE the "mode switch" use of '*' or '**' in function
>> calls. I've certainly written plenty of code where I use the same variable
>> name in the calling scope as I bind in the call. Moreover, function
>> *definitions* have an an analogous mode switch with an isolated '*'.
>> >>
>> > It sounds to me like there's a lot of weak support or weak opposition,
>> > with some of it spread between the proposal itself and the individual
>> > spellings.
>> >
>> > Rodrigo, it may be time to start thinking about writing a PEP. If the
>> > Steering Council approves, I would be willing to be a (non-core-dev)
>> > sponsor; alternatively, there may be others who'd be willing to
>> > sponsor it. A PEP will gather all the different syntax options and the
>> > arguments for/against each, and will mean we're not going round and
>> > round on the same discussion points all the times.
>>
>> I've been around for a while, and I can't imagine that any of these
>> proposals would be accepted (but I've been accused of having a bad
>> imagination). I'm saying that not to dissuade anyone from writing a PEP:
>> far from it. I think it would be useful to have this on paper and
>> accepted or rejected, either way. I'm saying this to set expectations: a
>> PEP is a ton of work, and it can be disheartening to put in so much work
>> for something that is rejected.
>>
>> So, I'd be willing to sponsor such a PEP, but I'd be arguing that it get
>> rejected.
>>
>> And  I say this as someone who has maybe 20 hours of work left on a PEP
>> of my own that I think has less than a 50% chance of success. I already
>> probably have 10 to 15 hours invested in it already.
>>
>> Eric
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org

[Python-ideas] Re: Keyword arguments self-assignment

[Brett Cannon]

On Thu, Apr 16, 2020 at 10:02 AM  wrote:

> @
>
> >  Do any other languages already have this feature?
>
> JavaScript ES6 has similar feature:
>
> ```javascript
> x = 1
> y = 2
> do_something({ x, y })
> ```
>

Rust also has a similar feature when instantiating structs which are always
keyword-based:
https://doc.rust-lang.org/book/ch05-01-defining-structs.html#using-the-field-init-shorthand-when-variables-and-fields-have-the-same-name
.


> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/64SUXRENNQDDE3YH6FLTKUR26QEMBK3R/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OEO3JUVSNZNFLV24CEP46G2G5JDEVUEV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Should dataclass init call super?

[Brett Cannon]

On Wed, Apr 15, 2020 at 8:45 AM Christopher Barker 
wrote:

> > you'd just add *args and **kwargs to the init signature and call
> super().__init__(*args, **kwargs).
>
>>
>> Which is what the OP is after.
>>
>
> Hmm, makes me wonder if there should be an option to define a __pre_init__
> method.
>

Also note that the 'attr' package on PyPI is still available and provides
features that dataclasses do not. Generalizing something in the stdlib is
not always the best/necessary solution, especially if there's a
battle-tested alternative available on PyPI.

-Brett


>
> Then you could customize the signature, but still use data classes nifty
> features for the primary __init__
>
> And no, I haven’t thought this out, it would be tricky, and maybe
> impossible.
>
> Which brings me back to the suggestion in a PR:
>
> Optional have the __init__ accept *args, *kwargs, and then store them in
> self. Then users could do whatever they like with them in __post_init
>
> -Chris
>
> It becomes more painful the more parameters the parent has- parameters
>> which the dataclass may not even care about. It not only makes the class
>> definition long, it adds so these additional parameters to the init
>> signature, which is icky for introspection and discoverability. Lots of
>> "What the heck is this parameter doing here?" head scratching for future me
>> (because I forget everything).
>>
>> There's currently not a very compelling solution, AFAIK, to be able to
>> use dataclasses in these kinds of situations ("these kinds" = any situation
>> other than the most simple) other than the solution Christopher Barker
>> suggested: using a mixin approach that treats the dataclass parameters
>> specially. So I just haven't.
>>
>> I did write a decorator of my own that replaces the dataclass init with
>> one that calls super().__init__(*args, **kwargs) first before proceeding
>> with the one written by dataclasses... I can't find it at the moment. But
>> that has its own problems; one being the IDE doesn't know the init has been
>> rewritten this way and so will complain about parameters sent to the
>> dataclass that it doesn't know about.
>>
>>> --
> Christopher Barker, PhD
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/TH4I7L5FMDEAHCLN7EE3DZFZFPPXG5GH/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/E6RM5FFELZO5RTCGOQRQ5I6QDVWCTMKV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Live variable analysis -> earlier release?

[Brett Cannon]

On Wed, Apr 8, 2020 at 10:23 AM Guido van Rossum  wrote:

> On Wed, Apr 8, 2020 at 10:05 AM Alex Hall  wrote:
>
>> This would break uses of locals(), e.g.
>>
>
> Hm, okay, so suppose the code analysis was good enough to recognize most
> un-obfuscated uses of locals(), exec() and eval() (and presumably
> sys._getframe() -- IIUC there's already a Python implementation that
> generates less optimal code for functions where it detects usage of
> sys._getframe(), maybe IronPython).
>

Yep, it's IronPython.

-Brett


>
>
>> Plus if the calculation raises an exception and I'm looking at the report
>> on Sentry, I'd like to see the values of all variables. In particular I
>> might have expected the function to return early and I want to see what `x`
>> was.
>>
>
> That's a very valid objection. For simpletons like myself who just use pdb
> it could also be problematic. So at the very least there would have to be a
> way to turn it off, and probably it should have to be requested explicitly
> (maybe just with -O).
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/CNON3MYEASWG6WLW5C2QWRSTMQVZDDCX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VBP4ETELD4GCLFGYBPVEI7S3W7AJZBYQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing Package Representation On Shell

[Brett Cannon]

On Thu, Apr 2, 2020 at 8:22 AM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:

> Thanks for the snippet,
>
> Was wondering if given as a package option,
> we might display the module's help info.
>

That's what help() is for. The __repr__ is meant to help during development
with some succinct representation of the object (hence why they typically
have an identifier to help tell equal objects apart). Including docstrings
and such is not a goal for the repr and would make it no longer succinct.

-Brett
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZPWKXKI5UQ3TVQVIRMCYWLHLNVU3KUX2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

[Brett Cannon]

On Sun, Mar 29, 2020 at 10:58 AM Paul Sokolovsky  wrote:

> [SNIP]
>
> 1. Succumb to applying the same mis-optimization for string type as
> CPython3. (With the understanding that for speed-optimized projects,
> implementing mis-optimizations will eat into performance budget, and
> for memory-optimized projects, it likely will lead to noticeable
> memory bloat.)
> [SNIP]
>
> 1. The biggest "criticism" I see is a response a-la "there's no problem
> with CPython3, so there's nothing to fix". This is related to a bigger
> questions "whether a life outside CPython exists", or put more
> formally, where's the border between Python-the-language and
> CPython-the-implementation. To address this point, I tried to collect
> performance stats for a pretty wide array of Python implementations.
>

I don't think characterizing this as a "mis-optimization" is fair. There is
use of in-place add with strings in the wild and CPython happens to be able
to optimize for it. Someone was motivated to do the optimization so we took
it without hurting performance for other things. There are plenty of other
things that I see people regularly that I don't personally think is best
practices but that doesn't mean we should automatically ignore them and not
help make their code more performant if possible without sacrificing best
practice performance.

And I'm not sure if you're trying to insinuate that CPython represents
Python the language and thus needs to not optimize for something other
implementations have/can not optimize for, which if you are suggesting that
then I have an uncomfortable conversation I need to have with PyPy 😉. Or
if you're saying CPython and Python should be considered separate, then why
can't CPython optimize for something it happens to be positioned to
optimize for that other implementations can't/haven't?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QOGV74QJZE3DP26NFAHNNIRWZRSHIIPJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Brett Cannon]

On Wed, Mar 25, 2020 at 9:57 AM Paul Moore  wrote:

> On Wed, 25 Mar 2020 at 16:10, Eryk Sun  wrote:
>
> > The py launcher's "env" command searches PATH for anything from
> > "python" to "notepad" -- but not for a versioned Python command such
> > as "python3" or "python2".  It always uses a registered installation
> > in this case, which is at the very least problematic when using
> > "#!/usr/bin/env python3" in an active virtual environment. Paul Moore
> > will probably suggest that the script should use "#!/usr/bin/env
> > python" instead,
>
> Nope, I agree with your point about that running 2.x on Unix.
>
> IMO, the /usr/bin/python* and /usr/bin/env aliases are for Unix
> compatibility and so should prioritise that - but because Windows
> python doesn't include versioned executables, it's not always easy to
> do that.
>
> > but that will run 2.x in most Unix systems unless a
> > 3.x environment is active. We can assume that such a script requires
> > 3.x and is meant to run flexibly, in or out of an active environment.
>
> In principle I agree, but I'm not sure how you see that working in
> practice. If you have an activated venv, `#!/usr/bin/env python3`
> should use the venv Python or the system Python depending on whether
> the venv is Python 3 or not. But the only way of finding that out in
> the absence of versioned executables is running `python -V`. That's a
> performance hit that I'd rather we avoided.
>
> [see below about pyvenv.cfg - tl;dr is that there's no *documented*
> version info in there]
>
> > I'd prefer a consistent implementation of the "env" command that
> > doesn't special case versioned "pythonX[.Y]" commands compared to
> > plain "python". But another option that will at least make
> > virtual-environment users happy would be for "env" to check for an
> > active VIRTUAL_ENV and read its Python version from "pyvenv.cfg".
>
> I'd agree with that, if we had versioned executables. Without them, I
> honestly don't know what answer would cause the fewest issues, so I
> tend to assume that sticking with what we have is good enough, because
> we're not getting lots of complaints (we get some, but not that many).
>
> Following on from my comment above about needing to run `python -V`,
> I'd completely forgotten that pyvenv.cfg held the version statically
> nowadays.
>
> But virtualenv 20.0 and later writes a pyvenv.cfg with different
> information, and virtualenv < 20.0 doesn't write pyvenv.cfg at all.
> I'm OK with discounting old versions of virtualenv, but realistically,
> I believe that not interoperating with current versions of virtualenv
> is impractical. I think that if we want to rely on pyvenv.cfg, we
> should document/standardise its contents. At the moment, the docs only
> mention `home` and `include-system-site-packages`, and to be honest
> they sound more informational than normative anyway.
>

3.9 adds "prompt" to record any custom prompt that was specified.


>
> Unfortunately, there doesn't seem to be any real interest in
> standardising virtual environments at the moment.


I have interest. :)


> So for now, at
> least, it's difficult to see how the launcher can behave as you want
> (I assume it's obvious that we don't want to hard-code implementation
> details of virtualenv into the launcher).


Up to this point the only thing the Launcher has is support for when the
VIRTUAL_ENV environment variable is defined (my hope to standardize on
environment naming seems to have stalled out).


> I'd support a
> standardisation effort, but I don't intend to champion such an effort
> myself.
>

I don't either ATM, but maybe someday.


>
> Just to reiterate, I'd like a better, more uniform solution here. But
> I think there's more complexity than people are assuming, at least if
> we want to interoperate with 3rd party tools (which I view as
> necessary, although I guess others may take a more hard-line stance).
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6YFTKDP7AAEIOKNSR2F6TK64XS57VKV4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Brett Cannon]

On Mon, Mar 23, 2020 at 3:47 PM Mike Miller 
wrote:

>
> On 2020-03-23 10:59, Frédéric De Jaeger wrote:
> > Hi all,
> >
> > There is a recurring problem
>
> Yep, that's a problem.  I've built up a habit on Ubuntu where I type
> python3 a
> number of times a day, honed over several years.  So far so good.
>

Also note that Python doesn't control the OS vendors and this is very much
a vendor decision. We tried to provide guidance, but that doesn't mean we
are listened to. :)


>
> Recently I've had to use a Windows VM for some stuff at work, where I
> installed
> Python 3 as well.  Every time I type python3 at the command-line (instead
> of
> python) to use the repl, it tries to load the Microsoft App Store!
>

There is an option to install Python to PATH on Windows if you check the
appropriate box during installation, but that's not really the way Windows
apps typically work.


>
> I realize why that was done, to help out newbies, but it is not what I
> want at
> all.  Not the end of the world, but some consistency would be nice.
>

As I said, you can install Python to PATH on Windows if you choose.

I'm also slowly working on a Python Launcher for UNIX so the other option
some day might be `py` no matter what OS you're on.

-Brett


>
> -Mike
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/4XXUECWBIFLK6IRW7FA6TXLUIYQ7CQHS/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NZ3J3Y6GEQDBU7U2ID4L5J4CHRG4LWHS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: python-ideas@python.org post from python-id...@marco.sulla.e4ward.com requires approval

[Brett Cannon via Python-ideas]

These are coming in fine because they are not handled by Mailman's
filtering rules. And the reason for the holds is they are being flagged for
" Message has implicit destination".

On Fri, Mar 13, 2020 at 8:06 AM Marco Sulla <
python-id...@marco.sulla.e4ward.com> wrote:

> Well, probably it depends by two possible errors:
>
> 1. sometimes I send directly to python-ideas@python.org. This way my
> real address is used, and the system does not recognize it. I saved
> the "correct" address to my contact list, so now it's more simple to
> not do this mistake
>
> 2. I noticed that I can't put the address of the list in the CC field.
> Probably this is a problem of e4ward. Now I put it every time in the
> To: field
>
> PS: this message, for example, has some problems? I put the "correct"
> list address in the To field.
> PPS: maybe it's more simple to create a marco_sulla_pyt...@gmail.com
> address
>
> On Fri, 13 Mar 2020 at 14:27, C. Titus Brown  wrote:
> >
> > Hi Marco,
> >
> > all I can do is tell you what I’m seeing. Some of your posts go through
> fine, and others haven’t.
> >
> > I’ll approve your posts when I have time (almost always within 24 hrs),
> but some might be delayed.
> >
> > best,
> > —t
> >
> > > On Mar 13, 2020, at 4:56 AM, Marco Sulla <
> python-id...@marco.sulla.e4ward.com> wrote:
> > >
> > > Hello. I'm simply using e4ward, a disposable email address service, to
> > > avoid spam.
> > > I always used e4ward in past, with every mailing list, and also with
> > > Python mailing lists. Furthermore I'm using e4ward also with Python
> > > List mailing list in the current time, and I have no problem.
> > >
> > > On Fri, 13 Mar 2020 at 02:33, C. Titus Brown 
> wrote:
> > >>
> > >> Hi Marco,
> > >>
> > >> your e-mailing/response system is causing me to have to approve many
> of your messages manually. Please fix!
> > >>
> > >> thanks,
> > >> —titus
> > >>
> > >> Begin forwarded message:
> > >>
> > >> From: python-ideas-ow...@python.org
> > >> Subject: python-ideas@python.org post from
> python-id...@marco.sulla.e4ward.com requires approval
> > >> Date: March 12, 2020 at 5:47:03 PM PDT
> > >> To: python-ideas-ow...@python.org
> > >>
> > >> As list administrator, your authorization is requested for the
> > >> following mailing list posting:
> > >>
> > >>  List:python-ideas@python.org
> > >>  From:python-id...@marco.sulla.e4ward.com
> > >>  Subject: Re: [Python-ideas] Re: Make `del x` an expression
> evaluating to `x`
> > >>
> > >> The message is being held because:
> > >>
> > >>  Message has implicit destination
> > >>
> > >> At your convenience, visit
> > >>
> https://mail.python.org/mailman3/lists/python-ideas.python.org/held_messages
> > >> to approve or deny the request.
> > >>
> > >> From: Marco Sulla 
> > >> Subject: Re: [Python-ideas] Re: Make `del x` an expression evaluating
> to `x`
> > >> Date: March 12, 2020 at 5:45:46 PM PDT
> > >> To: Andrew Barnert , Python Ideas <
> python-ideas.python.org-mail.python.org.marco.sulla.e4ward@jr366bvb1z7.reply.e4ward.com
> >
> > >> Reply-To: python-id...@marco.sulla.e4ward.com
> > >>
> > >>
> > >> Well, so all this discussion is only for freeing _one_ memory
> location earlier?
> > >> Seriously... as the other users already said, if someone really need
> > >> it, he can use normal loops instead of comprehensions and split
> > >> complex expression so temporary objects are immediately free.
> > >> Furthermore, 2x speedup observations are done by benchmarks. In the
> > >> real world, how can you be sure that L2 cache is not already filled
> > >> up? :-)
> > >>
> > >>
> > >> From: python-ideas-requ...@python.org
> > >> Subject: confirm fc443c1d3d0ff72f9c645014ec4124ca207f5288
> > >> Date: March 12, 2020 at 5:47:03 PM PDT
> > >>
> > >>
> > >> If you reply to this message, keeping the Subject: header intact,
> > >> Mailman will discard the held message.  Do this if the message is
> > >> spam.  If you reply to this message and include an Approved: header
> > >> with the list password in it, the message will be approved for posting
> > >> to the list.  The Approved: header can also appear in the first line
> > >> of the body of the reply.
> > >>
> > >>
> >
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WILEALJRWV3PGYITMDA7X7FFDEMGWPJY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Mailman 3 monthly summaries broken for Python-ideas

[Brett Cannon]

Guido is correct as we don't directly control the software. It's probably a
bug with Mailman 3/Hyperkitty.

On Sun, Mar 8, 2020 at 2:35 PM Guido van Rossum  wrote:

> I think this is more of an issue to bring up with postmas...@python.org.
>
> On Sun, Mar 8, 2020 at 7:41 AM André Roberge 
> wrote:
>
>> I am currently attempting to go through the entire archives of
>> Python-ideas to make a summary of the discussions about adding a syntax for
>> decimal literals in Python. In doing so, I encountered a weird bug which I
>> find especially annoying since it makes me look like a spammer.
>>
>> If one goes through the archives by month, from May 2010 [1] to June 2011
>> [2], the first post shown at the top for each and every one of these
>> monthly treads is one I wrote on May 15, 2010 [3].  This problem is not
>> limited to the period between May 2010 and June 2011, as other misplaced
>> posts often appear at or near the top of monthly tread summaries.
>>
>> [1] https://mail.python.org/archives/list/python-ideas@python.org/2010/5/
>>
>> [2] https://mail.python.org/archives/list/python-ideas@python.org/2011/6/
>> [3]
>> https://mail.python.org/archives/list/python-ideas@python.org/thread/G4JCU5XEUSXHXFO42RA2DAVUSPWDGSHU/
>>
>> Please note that there is no need to discuss the idea I mentioned in that
>> old thread as it has since been implemented as a separate package.
>>
>> André Roberge
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/KASGQXTIHOK3IGDIQCWGWKWALKHBHWLF/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/L4R47AN3LB3LWLQ5RYMUOJO2HVPZZ42G/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/53CAPIWA5BFN4G3IEN4ROX7EPEZHJSZD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: IDEA: Allow override of all assignments of a built in type to be a different type

[Brett Cannon]

On Thu, Mar 5, 2020 at 7:02 AM Steven D'Aprano  wrote:

> On Thu, Mar 05, 2020 at 12:39:38PM +, Steve Barnes wrote:
>
> > Hmm, is there a PEP regarding Decimal literals?
>
> No.
>
> > I couldn't find one,
> > although there is PEP 240 regarding rational literals. Maybe it's time
> > to write up a rejected PEP explaining exactly what the problems are
> > with Decimal literals.
>
> The proposal hasn't been rejected, it just faded away for lack of
> somebody to write the PEP and offer to do the work.
>
> As I recall, a number of senior core developers were tentatively
> interested in the idea, at least in principle. Nick Coghlan was one, if
> memory serves me right. I don't recall any major objections, although
> that part might be confirmation bias :-)
>

My recollection on this idea (as I think I brought it up once as well) is
how do you handle decimal contexts? And having a global settings in the
decimal module for the default case influence syntax would be unique/weird.

-Brett


>
>
> > From memory, the problems are (a) it'd
> > effectively require the gigantic decimal module to be imported by
> > default, and (b) contexts don't work with literals.
>
> Neither of those are problems. They are only problems if you expect the
> (hypothetical) builtin decimal type to be the exact decimal.Decimal
> type, but that is overkill for the use-cases for a builtin decimals.
>
> All the context related functionality would be dropped: builtin.decimal
> would implement only a fixed width with a single rounding mode. They
> would be effectively like float, only base 10.
>
> For those who need the extra functionality of decimal.Decimal, the
> module would still exist. But builtins.decimal would be aimed at the
> simpler use-case of numerically unsophisticated users who wouldn't know
> a rounding mode or trap if it bit them but do know that 0.1 + 0.2 should
> equal 0.3 :-)
>
> There are a couple of standards for fixed-width decimals, by memory we
> were considering either 64 bit or 128 bit decimals.
>
>
> > I think that a part of the problem is that because Decimal silently
> > accepts both float and string literal inputs things get surprising
> > e.g.:
> >
> > In [5]: D(0.3) == D('0.3')
> > Out[5]: False
>
> That's only surprising to those who don't read the docs :-)
>
>
> >  1. Deprecate the use of the Decimal initialiser with float inputs so
> >  that decimal.Decimal(0.1), etc., issues a warning
> [...]
> >  3. Eventually outlaw float as an input to the initialiser.
>
> Please no. We started there, and relaxed that restriction because it was
> more annoying than helpful. Going backwards to Python 2.5 or thereabouts
> is, well, going backwards:
>
> >>> decimal.Decimal(0.5)
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/local/lib/python2.5/decimal.py", line 648,
>   in __new__ "First convert the float to a string")
> TypeError: Cannot convert float to Decimal.  First convert
> the float to a string
>
> Numerically unsophisticated users are not the only users of Decimal, and
> frankly, the unsophisticated users aren't going to be any less surprised
> by Decimal(0.1) raising an exception than they are surprised by any of
> the other floating-point oddities that affect both decimal and float.
>
>
> > While this would "break" code which happen to work as expected, e.g.
> > decimal.Decimal(0.5) but at least we would have consistent behaviour
> > and fail early rather than potentially working but giving incorrect or
> > inconsistent results.
>
> It's not giving incorrect results. It is giving correct results. The
> problem is not Decimal, but that people think that 0.1 means one tenth
> when it actually means 3602879701896397 ÷ 36028797018963968 :-)
>
> Viewing Decimal(0.1) is an excellent way to discover what value 0.1
> actually has, as opposed to the value you think it has.
>
>
> --
> Steven
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/LGVKOQR6CXOHDXD32Q3WA55LRZN7QZ7D/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/M6YXZRLV3GSEZJLATGTWLL3YPBN64HX5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Communication on mailing lists [was: Add a __valid_getitem_requests__ protocol]

[Brett Cannon]

Rhodri James wrote:

> I did not intend meanness.  I absolutely did intend rebuke; at the time 
> Soni was one poorly worded post away from my killfile, and I had 
> seriously considered reporting several previous posts for CoC 
> violations.  The only reason I didn't was that I was under the 
> impression that the list admins had seen those posts and chosen not to 
> react to them in public.

Please do not assume Titus and I read every post. We both have other 
obligations on top of administering this list, so assume we are too busy to 
read anything here and if something should come to our attention then please 
explicitly bring it to our attention.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/H5TRUYF2RB7DMXMUTZPAK6EF2T3VZ5A6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: `raise as` to raise with current exception as cause

[Brett Cannon]

On Fri, Feb 7, 2020 at 7:56 AM Ethan Furman  wrote:

> On 02/07/2020 07:33 AM, Serhiy Storchaka wrote:
> > 07.02.20 16:28, Ram Rachum пише:
> >> The idea is to add `raise as` syntax, that raises an exception while
> setting the currently caught exception to be the cause. It'll look like
> this:
> >>
> >>  try:
> >>  1/0
> >>  except ZeroDivisionError:
> >>  raise as ValueError('Whatever')
> >>
> >> What it does is a shorter version of this:
> >>
> >>  try:
> >>  1/0
> >>  except ZeroDivisionError as error:
> >>  raise ValueError('Whatever') from error
> >
> > How does it differ from
> >
> >  try:
> >  1/0
> >  except ZeroDivisionError:
> >  raise ValueError('Whatever')
>
> Here's a diff:
>
> $ diff no_from.py with_from.py
> 3,4c3,4
> - ... except ZeroDivisionError:
> - ... raise ValueError('Whatever')
> ---
> + ... except ZeroDivisionError as e:
> + ... raise ValueError('Whatever') from e
> 10c10
> - During handling of the above exception, another exception occurred:
> ---
> + The above exception was the direct cause of the following exception:
>
>
> To me the difference between "raise from" and "raise" is the implicit
> meaning:
>
> - "During handling of ..." implies that the second exception should not
> have occurred and there is a bug in the exception handling code
>
> - "The above exception ..." implies that this code path is normal and
> extra information is being supplied
>

They also set different attributes on the exception to communicate the
trigger of the exception, so there's also a structural difference beyond
just the textual one.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7QDKAXAWIOKCMX5DZUKDVYJ5QJ4GSPB2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allow spaces between string prefix and the string literal

[Brett Cannon]

The problem is that's ambiguous to the grammar whether you truly mean 'f'
as a prefix or 'f' as a variable and just happened to type something wrong.
And then debugging that would be horrible. So even if the grammar to
support it, I'm -1 on the idea.

On Wed, Jan 29, 2020 at 1:41 PM Mikhail V  wrote:

> I would like to see possibility to put spaces
> between the string prefix and the string literal
> so I could write e.g. like this:
>
> print (f "x: {x}")
>
> IMO it would help with legibility especially
> noticable with by proportional fonts.
>
> Mikhail
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/OXR2HHUYZYXJXNOL4INTOAOPXJWWCZBA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FNN6LK4DKQDCKLSULINBW524MX2V7N3H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Is the deployment standard for WSGI ready?

[Brett Cannon]

The PEP index can be found at https://www.python.org/dev/peps/ and there
isn't any PEP on this.

But honestly, I don't think this sort of thing should be a PEP. Look at
ASGI and how that isn't a PEP and still manages to exist. Since this isn't
a language-related or package-related thing I don't think it really needs
to go through the PEP process.

On Mon, Jan 27, 2020 at 8:07 PM Jesús Gómez  wrote:

> In the PEP-[1] they say the following:
>
> """
> After a sufficient number of servers and frameworks have implemented WSGI
> to provide field experience with varying deployment requirements, it may
> make sense to create another PEP, describing a deployment standard for WSGI
> servers and application frameworks.
> """
>
> Did this happen already? Will this happen anytime?
>
> [1] https://www.python.org/dev/peps/pep-/
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/SMT3VZKF6KVHJDRVD2OVPN5EMPN4RDCT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NAZB76QHU367T6Z63DMFI3Y3YATARNKJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: python -m anomaly Was: quality of life improvements

[Brett Cannon]

On Fri, Jan 10, 2020 at 10:24 PM Steve Barnes 
wrote:

>
>
> -Original Message-
> From: Steven D'Aprano 
> Sent: 11 January 2020 04:39
> To: python-ideas@python.org
> Subject: [Python-ideas] Re: python -m quality of life improvements
>
> On Fri, Jan 10, 2020 at 11:53:10PM -0300, Soni L. wrote:
> > currently python -m requires you to cwd to the desired package root.
> > I'd like to suggest the ability to python -m
> > relative/path/to/package/root/module.submodule and python -m
> > /absolute/path/to/package/root/module.submodule
>
> Oh, a further thought comes to mind... if your modules aren't on the
> PYTHONPATH, just drop the -m and you can execute any legal Python file,
> even if the name isn't a legal identifier.
>
> [steve@ando tmp]$ cp ~/python/spam/eggs.py /tmp/"some name".foo
> [steve@ando tmp]$ python3.5 "some name.foo"
> some name.foo
>
> So as I understand it, the functionality you want already exists, both for
> running scripts on the path using -m and scripts with arbitrary file names
> without -m.
>
> Have I missed some subtlety in your proposal?
>
>
>
> [Steve Barnes]
> I did notice one anomaly in the behaviour of python -m:
> taking your code structure above and using :
>
> > py -mzipfile -c eggs.zip spam\__init__.py spam\__main__.py spam\eggs.py
>
> to create eggs.zip I can run:
>
> > py eggs.zip
>
> Renaming eggs.zip to eggs.py I can run:
>
> >eggs.py
> E:\toolbuild\eggs.py\__main__.py
> Or
> >py eggs.py
> E:\toolbuild\eggs.py\__main__.py
>
> But get problems when I try:
> > py -meggs.py
> Traceback (most recent call last):
>   File "C:\Python38_64\lib\runpy.py", line 183, in _run_module_as_main
> mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
>   File "C:\Python38_64\lib\runpy.py", line 109, in _get_module_details
> __import__(pkg_name)
> ValueError: source code string cannot contain null bytes
>
> Gadget@GADGETLAPTOP E:\toolbuild
> > py -meggs
> Traceback (most recent call last):
>   File "C:\Python38_64\lib\runpy.py", line 183, in _run_module_as_main
> mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
>   File "C:\Python38_64\lib\runpy.py", line 153, in _get_module_details
> code = loader.get_code(mod_name)
>   File "", line 916, in get_code
>   File "", line 846, in
> source_to_code
>   File "", line 219, in
> _call_with_frames_removed
> ValueError: source code string cannot contain null bytes
>
> Is this expected behaviour or worth a ticket and some time investigating
> further?
>

It's expected behaviour. Passing a file path to the interpreter goes
through some special logic to look for a zip file, while -m is basically
fancy importing.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3DIQ5AUKLQN2OIBX2WKHDGKOPBMOAJKD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Brett Cannon]

On Wed, Jan 8, 2020 at 1:09 AM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:

>
> Yours,
>
> Abdur-Rahmaan Janhangeer
> pythonmembers.club | github
> Mauritius
>
>
> On Wed, Jan 8, 2020 at 1:32 AM Brett Cannon  wrote:
> >
> >
> > This would be a packaging detail so not something to be specified in the
> stdlib.
>
>
> Yes, the module opening the zip will look for it
>
> >> - [  ] Signing mechanism
> >>
> >> Mechanisms can be added to detect the integrity of the app. App hash
> can be
> >> used to check if the app has been modified and per-file hash can be
> used to
> >> detect what part has been modified. This can be further enhanced if
> needed.
> >>
> >> - [  ] Protecting meta data
> >>
> >> Metadata are not protected by basic signing. There existing ways to
> protect
> >> metadata and beyond [7]
> >
> >
> > This can be tricky because people want signing in specific ways that
> vary from OS to OS, case by case. So unless there's a built-in signing
> mechanism the flexibility required here is huge.
>
>
> Let's say we have a simple project
>
> folder/
> file.py
> __main__.py
>
> The first step is to include in the info file the file name and hashes
>
> file.py: 5f22669f6f0ea1cc7e5af7c59712115bcf312e1ceaf7b2b005af259b610cf2da
> __main__.py:
> e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
>

That's under-specified. What hash algorithm was used? How are you going to
specify it?


>
> Then by reading the info file and hashing the actual file and comparing,
> we can see which file was modified if any.
>

> But now, a malicious program might try to modify the info file
> and modify the hash. One way to protect even the metadata is
> to hash the entire content
>
> folder/
> file.py # we can add those in a folder if needed
> __main__.py
>infofile
>
> Then after zipping it, we hash the zipfile then append the hash to the zip
> binary
>
> [zipfile binary][hash value]
>
> We can have a zip file and yet another file stating the hash value but
> to maintain a single file structure, the one described above is best.
>
> Then when opening the zip file, we start reading upto the hash value. The
> hash
> value becomes the checking signature of the zipfile.
>
> This forms a base on which more sigining mechanism can be added like
> author keys
>

But then I can modify the signatures of any of these files by regenerating
them. Please trust me, this isn't simple to get right, especially if you
are shipping the hashes with the file if you're trying to protect tampering
versus just verifying a blip in a download.


>
> Since zipfiles are the same across OSes, this kind of approach supposedly
> don't pose a problem
>
> > Install the wheels where? You can't do that globally. And you also have
> to worry about the security of doing the install implicitly. And now the
> user suddenly has stuff on their file system they may not have asked for as
> a side-effect which may upset some people who are tight on disk space
> (remember that Python runs on some low-powered machines).
>
> Yes, global folders also defeat the spirit.
>
> Using the wheel-included zip (A), we can generate another zip file (B) with
> the packages installed. That generated zip file is then executed.
> Zip format A solves the problem of cross-platforming.
> Normal solutions upto now like use solution B where you can't share
> your zips across OSes.
>

That actually doesn't work. You cannot load an extension module from
memory; it *must* be from disk so this doesn't solve the extension module
problem.

-Brett


>
> As for space, it's a bit the same as with venvs. Zip format B is the
> equivalent
> of packages installed in venv.
>
> Venv usage can be a hint as to when to use.
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XP3D6AWQDDM7EBCOCDE2RIMW6BN5WZSS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Enhancing Zipapp

[Brett Cannon]

Thanks for the ideas, Abdur-Rahmaan! Some feedback below.

On Mon, Jan 6, 2020 at 11:35 AM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:

> Note: draft simplified
>
> Abstract
> ==
>
> This extracts aims at proposing enhancements to the generated zipapp
> executable
>
> Rationale
> ===
>
> One area where there remains some difficulty in Python is packaging for
> end-user consumption. To that effect either the code is distributed in pure
> Python form with installers [1] or native executables are built for each
> target
> Os [2]. Currently by default, Python does not provide such utilities. This
> pro-
> posal aims at finalising a Python-specific archive as the default VM exec-
> utable built on zipapp.
>
> In simple terms, it proposes to enhance zipapp from plain archive to
> app-level
> archive.
>
> Advantages of archives
> ==
>
> Archives provide a great way to publish software that needs to be
> distributed as
> a single file script but is complex enough to need to be written as a
> collection of
> modules [3]
>
> You can use archives for tasks such as lossless data compression,
> archiving,
> decompression, and archive unpacking. [4] Adding capabilities like digital
> signing is used to verify integrity and authenticity.
>
> Zip archives as apps
> 
>
> If we are to treat zip archives as app, here are some recommended features
>
> - [x] Main entry point
>
> A main entry point specifies which file to launch. Zipapp already solves
> this
> problem by either having a __main__.py [5] or specifying the entry point
> at the
> commandline ENTRYPOINT_MODULE:ENTRYPOINT_FUNCTION [6]
>
> - [  ] App info file
>
> An info file can have info such as author name, archiving date, company
> name
> etc.
>

This would be a packaging detail so not something to be specified in the
stdlib.


>
> - [  ] Signing mechanism
>
> Mechanisms can be added to detect the integrity of the app. App hash can
> be
> used to check if the app has been modified and per-file hash can be used
> to
> detect what part has been modified. This can be further enhanced if needed.
>
> - [  ] Protecting meta data
>
> Metadata are not protected by basic signing. There existing ways to protect
> metadata and beyond [7]
>

This can be tricky because people want signing in specific ways that vary
from OS to OS, case by case. So unless there's a built-in signing mechanism
the flexibility required here is huge.


>
>  - [x] Pure-Python 3rd party package bundling
>
> In Python, as long as the 3rd party packages are pure-python packages, we
> can bundle and use them [6]. The user can maybe just include a
> requirements.txt
>
> - [  ] C-based 3rd party packages
>
> Zipapp by default was not meant to include packages at all.
>
> << The executable zip format is specifically designed for standalone use,
> without needing to be installed. They are in effect a multi-file version
> of a
> standalone Python script >>
>
> Though the previous point shows that this can be done. Now remains the
> issue of C-based packages. Distributing wheels might be the answer [8].
> A zip archive is supposed to be standalone. A possible  solution might be
> to
> include wheels and the wheels are installed in a site-packages folder.
>
> When running such an app, the interpreter will check first if the
> app-specific
> site-packages folder is empty, if not, install the wheels. This provides
> package-
> freezing ability. The only downside is longer first-run time.
>

Install the wheels where? You can't do that globally. And you also have to
worry about the security of doing the install implicitly. And now the user
suddenly has stuff on their file system they may not have asked for as a
side-effect which may upset some people who are tight on disk space
(remember that Python runs on some low-powered machines).

-Brett


>
> Only specifying packages to be installed is not an option as if you really
> want
> stand-alone apps, using the internet etc defeats the purpose.
>
> FAQ
> 
>
> Why not a package manager?
> ---
> The zipapp pep was introduced for a reason, for easing the running of
> archives.
> Maybe the package manager idea came from listening to people talking about
> packaging and pex and comparing it with package-managers like homebrew
> and concluded that pex and hence zipapp is not worth it and people would
> better off not complicate their lives with some zip utility.
>
> This proposal is not solving any problem at all
> --
> This proposal aims at enhancing zipapp. Zipapp solved the problem. Zipapp
> had an aim. This proposal aims at helping zipapp better accompplish it's
> aim.
>
>
> References
>
> [1] https://pynsist.readthedocs.io/en/latest/
>
> [2] https://www.pyinstaller.org
>
> [3] https://www.python.org/dev/peps/pep-0441/
>
> [4]
> https://docs.oracle.com/javase/tutorial/deployment/jar/basicsindex.html
>
> [5] https://docs

[Python-ideas] Re: Argumenting in favor of first()

[Brett Cannon]

On Wed, Dec 11, 2019 at 9:48 PM Tim Peters  wrote:

> [Tim]
> >> Every suggestion here so far has satisfied that, if S is a non-empty
> set,
> >>
> >> assert next(iter(S)) is first(S)
> >>
> >> succeeds.  That is, `first()` is _defined_ by reference to iteration
> >> order.  It's "the first" in that order (hence the name).
>
> [Stephen J. Turnbull ]
> > The problem I'm concerned with is that sometimes users' definitions of
> > words differ from a computer language's definitions of words.  That's
> > why I used the word "natural", which doesn't really have much to do
> > with the way a computer language defines things, but frequently
> > features in human thought.
> >
> > Whether that potential difference matters here is an empirical
> > question.
> >
> >  Theoretically, I can say "Explicit is better than implicit."
> > I.e., the call to 'iter' tells us exactly what order is being used.
>
> But hasn't it already been settled by experience?  There is nothing
> unique about `first(set)` implicitly appealing to iteration order.  A
> set passed as the iterable to _any_ itertools function does exactly
> the same:
>
> >>> import itertools
> >>> list(itertools.zip_longest(set("abcde"), range(5))) # can vary from
> run to run
> [('a', 0), ('e', 1), ('c', 2), ('d', 3), ('b', 4)]
> >>> list(itertools.compress(set("abcde"), [1]*5)) # but is consistent
> within a run
> ['a', 'e', 'c', 'd', 'b']
> >>> list(itertools.takewhile(lambda x: True, set("abcde")))
> ['a', 'e', 'c', 'd', 'b']
>
>  So do, e.g., some builtins:
>
> >>> list(map(ord, set("abcde")))
> [97, 101, 99, 100, 98]
> >>> [ord(ch) for ch in set("abcde")]
> [97, 101, 99, 100, 98]
>
>
> > That's *my* opinion in this case, and I don't hold *you* to it just
> > because I'm quoting you.  (I am amused, though.)
>
> I just don't see the potential for "new" bafflement if itertools.first
> works exactly the same way as itertools.anything_else _has_ worked, in
> this respect, all along.  Give users some credit.  Programming is
> baffling, period, at first.  But to those who persist, nothing becomes
> truly unbearable ;-)
>

I'm also sure the docs will say "Returns the first item yielded by the
iterable." That last word is a dead give-away on how the choice will be
made on any collection, Sequence or not. 😉 (Doubly true if this goes into
itertools.)

There's also the contingency of users who will think of the question "how
would this function think of what "first" is for non-order collections?"
will simply think "iterator" and be done with thinking.

IOW I understand the desire to have a function that is fully
self-explanatory, but I view take() as more ambiguous as it doesn't say
where you will take form (e.g. are you going to treat a list as a deque or
a stack?), but first() has a clear understanding the instant you think
about this operating on iterables (which is as universal of a data
structure concept across collection types as we have).
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/O6OD3XNYEECJJXEZJK3RV35NGWXC6MFF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Argumenting in favor of first()

[Brett Cannon]

On Tue, Dec 10, 2019 at 1:50 PM Tim Peters  wrote:

> [Brett Cannon ]
> > Thinking out loud here...
> >
> > What idiom are we trying to replace with one that's more obviously and
> whose
> > semantics are easy to grasp?
>
> For me, most of the time, it's to have an obvious, uniform way to
> spell "non-destructively pick an object from a container (set, dict,
> list, deque, heap, tuple, custom tree class, ...)".  I don't even have
> iterators in mind then, except as an implementation detail.  For that
> reason, raising `StopIteration` if the container is empty grates.  The
> _value_ (the state of the container) I passed is inappropriate then,
> so more-itertool's ValueError makes more sense to me.
>

Fair enough. I will fully admit that while I'm currently learning Clojure
the fact they have such a uniform approach to containers is enviable, hence
why this discussion interests me. :) (Although I was already a functional
fan.)


>
> The toolz.itertoolz version of `first()` differs.  That one is just
> next(iter(argument)).  No default.  I like the more-itertools flavor
> better.
>
> As to which idiom it intends to replace, _that's_ the annoyance being
> addressed:  there is no "one obvious way to do it" now.  Although for
> each individual container type, there's sometimes an obvious way to do
> it for objects of that type (e.g., object[0] for a list or heap, or
> object.root for a rooted tree class).
>
> > `first(iterable)` that raises is StopIteration is
> `next(iter(iterable))`. `first(iterable)` that
> > defaults to None and doesn't raise is `next(iter(iterable), None)`. Now
> only if the raised
> > exception changes do you end up with something like Tim's examples where
> more
> > than one line is definitely needed.
>
> Talking about "needed" is treating this like an axiomatic system where
> redundancy is in Very Bad Taste.


Sorry, "needed" was too strong of a word. It's more about justification for
including in the stdlib and deciding to support it for a decade or more
versus the answer we give for simple one-liners of "put in your personal
toolbox if you don't want to type it out every time".


>   But, to the contrary, in functional
> languages the _implementers_ think very hard about creating a minimal
> core, but the user interface supplies everything _useful_ and
> sometimes doesn't even note whether a thing is part of the minimal
> core.
>

Yep, and the general abstraction to a universally applicable core is very
nice.


>
> When I want `first()`, I want `first()`.  I don't care how it's
> implemented, and I couldn't care less that I _could_ write it myself
> by composing other functions in a brief one-liner.
>

Sure, but the question I think that this thread and me are proposing are
what "first()" means to everyone. I think you and I are on the same page,
but it's a question as to whether others are as well. :)


>
> > So I think the question is what problem are we trying to solve here? Is
> it the lack of
> > knowledge of the 2-argument next() form? Or is it that people are
> regularly wanting
> > the first item from an iterable and when it doesn't exist they want to
> raise an
> > exception different from StopIteration (and what is that alternative
> exception)?
> >
> > If it's the former then I think the case could be made that more
> education of the
> > one-liner might be all that's needed here. Now Guido did the research
> and showed
> > that the stdlib doesn't seem to realize this form really exists, so it
> might be quite
> > the education. ;)
>
> `first()` definitely isn't _needed_.  Without it, people will continue
> reinventing their own ad hoc methods of getting it done, and they'll
> succeed.
>
> > But if it's the latter then there's a greater savings in complexity from
> providing first()
> > with those semantics. But once again the question becomes how often does
> that
> > come up?
>
> Often enough that both relevant packages (more-itertools and
> toolz.itertoolz) have supplied it for years, although with different
> endcase behavior.  Certainly not often enough to merit being
> __bulitin__.
>

I agree.


>
> > I obviously have no answers to provide. :) My gut is suggesting that if
> it's the one-liner
> > replacement it might not be worth it, but if it's to raise a different
> exception I could see
> > more of a use for adding something to the stdlib.
>
> As above, `first()` is an atomic concept in my head.  It _can_ be
> synthesized out of more

[Python-ideas] Re: Argumenting in favor of first()

[Brett Cannon]

On Mon, Dec 9, 2019 at 9:43 PM Tim Peters  wrote:

> [Guido]
> > The argument that first(it) and next(it) "look the same" doesn't convince
> > me;
>
> I'm sorry - I guess then I have absolutely no idea what you were
> trying to say, and read it completely wrong.
>
> > if these look the same then all function applications look the same, and
> > that can certainly not have been Meertens' intention.
>
> No argument on that from me ;-)
>
> > But if everyone thinks that first() should raise, fine, this thread is
> way too long
> > already (I should have kept it muted :-).
>
> It was being discussed.  The 1-argument more-itertools `first()` does
> raise on an exhausted iterator, and that does make most sense to me.
> In my algorithms I usually "know" I'm not trying to take an element
> from an empty iterable, and have no use for a default value in such a
> case.  Since there's no non-destructive way to assert that the
> iterable is not exhausted, raising an exception if it is exhausted is
> most useful.
>
> _empty = object()
> a = first(iterable, _empty)
> if a is _empty:
> raise ...
>
> is a PITA by comparison, as is my _current_ idiom:
>
> for a in iterable:
> break
> else:
> raise ...
>
> Plain old
>
> a = first(iterable)
>
> would be perfect - but only if it raised.
>

Thinking out loud here...

What idiom are we trying to replace with one that's more obviously and
whose semantics are easy to grasp?

`first(iterable)` that raises is StopIteration is `next(iter(iterable))`.
`first(iterable)` that defaults to None and doesn't raise is
`next(iter(iterable), None)`. Now only if the raised exception changes do
you end up with something like Tim's examples where more than one line is
definitely needed.

So I think the question is what problem are we trying to solve here? Is it
the lack of knowledge of the 2-argument next() form? Or is it that people
are regularly wanting the first item from an iterable and when it doesn't
exist they want to raise an exception different from StopIteration (and
what is that alternative exception)?

If it's the former then I think the case could be made that more education
of the one-liner might be all that's needed here. Now Guido did the
research and showed that the stdlib doesn't seem to realize this form
really exists, so it might be quite the education. ;)

But if it's the latter then there's a greater savings in complexity from
providing first() with those semantics. But once again the question becomes
how often does that come up?

I obviously have no answers to provide. :) My gut is suggesting that if
it's the one-liner replacement it might not be worth it, but if it's to
raise a different exception I could see more of a use for adding something
to the stdlib.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YHQVV6BAVT74XHUBABAA3HA5R6KHOG34/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Argumenting in favor of first()

[Brett Cannon]

On Mon, Dec 9, 2019 at 10:39 AM Tim Peters  wrote:

> [Steven D'Aprano ]
> > What do you think of my suggestion that we promote the itertools recipe
> > "take" into a function?
> >
> >
> https://mail.python.org/archives/list/python-ideas@python.org/message/O5RYM6ZDXEB3OAQT75IADT4YLXE25HTT/
>
> That it's independent of whether `first()` should be added.
>
> I would _much_ rather write - and read:
>
> a = first(iterable, default)
>
> than
>
> a = take(1, iterable, default)[0]
>
> for much the same reasons I'd much rather write and read "2" than
> "int(10 / 5)" ;-)
>

Ditto from me. I bumped up against calling next() recently for the first
item and had to rely on the fact that I controlled the code to ignore
StopIteration since it was in a small script, but I have needed just the
first item so many times before and didn't want any exception to propagate
out that I would have loved to have such a function instead of adding to
add in a 'try' as well.

-Brett


>
> But, as stated before, I'm not a minimalist when it comes to
> itertools.  In turn, I'd much rather write & read`take(n, iterable,
> default) than the stuff it takes to plug in "enough" defaults, when
> needed, without it.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/QO75UXCOC67Y4C2PXBKXHP7P34VCVVOS/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GO74TWUDHCDWAKHBMGEUARZK3R53FTCV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Argumenting in favor of first()

[Brett Cannon]

On Mon, Dec 9, 2019 at 10:03 AM Tim Peters  wrote:

> [Andrew Barnert ]
> > Didn’t PyPy already make the fix years ago of rewriting all of itertools
> > (for both 2.7 and 3.3 or whenever) as “Python builtins” in the underlying
> > namespace?
>
> I don't know.
>
> > Also, even if I’m remembering wrong, just writing a Python module in
> front
> > of the C module, with most of the functions still being C-only, wouldn’t
> help
> > PyPy.
>
> I wasn't suggesting that.  I was suggesting that we drop the tradition
> of writing _every_ itertools function in C and _only_ C.   That would
> lower the bar for adding new functions.  Many of the many functions in
> the more_itertools and toolz.itertools packages are implemented by
> brief pure Python functions, often just 1-liners.  Works fine for
> them.
>

Plus you have to start somewhere. ;) Any new interpreter in the future plus
existing ones would benefit if we said that the C versions were just
accelerators instead of the sole implementation.


>
> > You’d still need to port every function to Python
>
> Why?  My comments about pypy were a footnote to the main point:  that
> functional language people don't hesitate to "build in" any number of
> functions easily implemented in terms of other ones.  This started
> already with LISP, which very quickly, e.g., added (CADR x) for (CAR
> (CDR x)), (CADDR x) for (CAR (CDR (CDR x))) and so on - then went on
> to also add additional spellings (FIRST, SECOND, NTH, etc).  The point
> in that context is to have _common_ spelling and endcase behavior for
> things - no matter how simple - that are reinvented every day
> otherwise.
>

I've been learning Clojure and getting reminded of this again where the
uniformity of being able to use these common functions across sequences is
where the real power lies. From there you end up with abstractions that
everyone can build upon and only care about duck typing against something
that's an iterable.


>
> > (and be aware that the “equivalent code” in the help is usually only a
> rough
> > equivalent with subtle differences, so you’d have to spot, fix, and
> write unit tests
> > for all of those), with the C only an optional accelerator, a la PEP 399
> (the
> > requirements for C accelerators in newly-added modules).
>
> I'm not at all suggesting to rewrite itertools.  I am suggesting that,
> for most of itertools's natural audience most of the time, an
> implementation in Python _only_ is "good enough", and that it would
> best if we recognized that for _new_ itertools functions.
>

+1, but I wrote https://www.python.org/dev/peps/pep-0399/ so this shouldn't
shock anyone. :)

-Brett


>
> > Which is far from impossible, it’s just more work than it seems like
> anyone’s
> > ever been willing to do each time it comes up (and you’re right, it
> comes up
> > every time a new potentially useful itertools tool is proposed…). If
> someone
> > cares about first enough to finally do that, I’m +1 on the proposal
> instead of 0.
>
> Different itch.  I'm a "practicality beats purity" guy ;-)
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/KBKUC2O3O6G35Q67JQX62XMRPM6ANDDV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QKJHS33JFRWYCJYZSUAQM766P7W7RYEL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

[Brett Cannon]

On Wed, Dec 4, 2019 at 3:12 PM Guido van Rossum  wrote:

> We could treat it as a kind of future statement. If there’s a top level
> statement that defines the magic identitier we generate the special
> bytecode.
>

True, that would help solve the performance issue.

But I'm still -1 on the idea regardless of the performance. :)


>
> On Wed, Dec 4, 2019 at 12:26 Brett Cannon  wrote:
>
>>
>>
>> On Tue, Dec 3, 2019 at 5:58 PM Random832  wrote:
>>
>>> On Tue, Dec 3, 2019, at 13:43, Brett Cannon wrote:
>>> > -1 from me. I can see someone not realizing an operator was changed,
>>> > assuming it's standard semantics, and then having things break subtly.
>>> > And debugging this wouldn't be fun either. To me this is
>>> monkeypatching
>>> > without an explicit need for it, i.e. if you really want different
>>> > semantics in your module then define a function and use that instead
>>> of
>>> > influence-at-a-distance overriding of syntax.
>>>
>>> Does it make a difference that it'd only apply to code that is
>>> physically in the same module where the function is defined? I'd originally
>>> planned to suggest full lexical scope for the lookup, in fact, so you could
>>> in theory do it within a single function.
>>>
>>
>> Not enough to change my opinion. Changing how fundamental operators work
>> just in a module is still influencing too far from the code site. For
>> instance, if I navigate in my editor directly into the middle of a file or
>> open a file and immediately start searching for the function I care about I
>> won't notice that "+" no longer means what I thought it meant for integers
>> because someone thought it would be smart to redefine that.
>>
>> And as Serhiy pointed out, performance is going to get slammed by this,
>> no opcode or not as you just introduced a new lookup on every syntactic
>> operation.
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/DXZO7UVMBXMV7KNBPZU25YA3PQLUI4NF/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> --
> --Guido (mobile)
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/34DZCM7APSYSN2WGVP6U4RDGYYTROQ32/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

[Brett Cannon]

On Tue, Dec 3, 2019 at 5:58 PM Random832  wrote:

> On Tue, Dec 3, 2019, at 13:43, Brett Cannon wrote:
> > -1 from me. I can see someone not realizing an operator was changed,
> > assuming it's standard semantics, and then having things break subtly.
> > And debugging this wouldn't be fun either. To me this is monkeypatching
> > without an explicit need for it, i.e. if you really want different
> > semantics in your module then define a function and use that instead of
> > influence-at-a-distance overriding of syntax.
>
> Does it make a difference that it'd only apply to code that is physically
> in the same module where the function is defined? I'd originally planned to
> suggest full lexical scope for the lookup, in fact, so you could in theory
> do it within a single function.
>

Not enough to change my opinion. Changing how fundamental operators work
just in a module is still influencing too far from the code site. For
instance, if I navigate in my editor directly into the middle of a file or
open a file and immediately start searching for the function I care about I
won't notice that "+" no longer means what I thought it meant for integers
because someone thought it would be smart to redefine that.

And as Serhiy pointed out, performance is going to get slammed by this, no
opcode or not as you just introduced a new lookup on every syntactic
operation.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DXZO7UVMBXMV7KNBPZU25YA3PQLUI4NF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

[Brett Cannon]

On Tue, Dec 3, 2019 at 2:00 AM Serhiy Storchaka  wrote:

> [SNIP]
> > ## What about performance?
>
> It should be mentioned in the PEP that `dict1 | dict2 | dict3` is less
> efficient than `{**dict1, **dict2, **dict3}`.
>

... in CPython, but is it guaranteed to be faster in e.g. PyPy? We should
be very careful about making any performance promises/points unless we know
it is fairly universal that the design will explicitly make something
faster or slower relative to another operation.

To me this PEP is entirely a question of whether the operators will
increase developer productivity and not some way to do dict merging faster,
and so performance questions should stay out of it unless it's somehow
slower than dict.update().
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PIMJI45CURM2EUWKWWH7VT3Q2EQCFTNI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

[Brett Cannon]

On Tue, Dec 3, 2019 at 8:29 AM Random832  wrote:

> What if there was a general mechanism to allow operators to be implemented
> by user code that does not belong to the class?
>
> If the name [e.g.] __operatorhook_or__ is defined anywhere in a module,
> within that module all calls to that operator are replaced with a two-step
> process:
>
> call __operatorhook_or__(dict1, dict2)
> if it returns a value, use that value
> if it returns NotImplemented use the ordinary operator lookup process,
> i.e. dict1.__or__ and dict2.__ror___
> [if __operatorhook_or__ is not defined, treat the same as if it had
> returned NotImplemented]
>
> Then a user could simply do:
>
> def __operatorhook_or__(obj1, obj2):
> if isinstance(obj1, dict) and isinstance(obj2, dict):
> return {**obj1, **obj2}
> return NotImplemented
>
> def __operatorhook_ior__(obj1, obj2):
> if isinstance(obj1, dict):
> obj1.update(obj2)
> return obj1
> return NotImplemented
>

-1 from me. I can see someone not realizing an operator was changed,
assuming it's standard semantics, and then having things break subtly. And
debugging this wouldn't be fun either. To me this is monkeypatching without
an explicit need for it, i.e. if you really want different semantics in
your module then define a function and use that instead of
influence-at-a-distance overriding of syntax.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YZWWDFL4LY7NEJDF5Y3GHV3URIJ6QIVQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding fixed-point decimals as an option to replace floating-point

[Brett Cannon]

On Thu, Nov 14, 2019 at 9:04 AM  wrote:

> Does decimal make this:
> 4.1 + 0.1
> produce 4.2 instead of 4.18?
>

Yes, see https://docs.python.org/3/library/decimal.html#module-decimal.


> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/AXXMVUXSXKBFHI2D2ILCSDM65O6KEVR4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KGJZMJTR42SELTRAOSIZXGDN73SYSDNX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Suggest having a mechanism to distinguish import sources

[Brett Cannon]

Correct, bad typo. :)

On Tue, Nov 12, 2019 at 2:31 PM Eric V. Smith  wrote:

>
> *PEP 328 doesn’t seem to mention any of the names detailed below.*
>>
>
> I strongly advise reading PEPs as documentation once their work has
> landed. At that point they are mostly historical documents and will not be
> kept up to date going forward. IOW do not read any import-related PEPs for
> help; everything will be in the stdlib docs for importlib or in the
> language reference for imports.
>
> Just to be clear, I think Brett meant he strongly advises *against *reading
> the PEPs as documentation once they've landed.
>
> Eric
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CTOVXLKIHHO4XCN6NRIJ2N2QQMCT3WKB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Suggest having a mechanism to distinguish import sources

[Brett Cannon]

On Fri, Nov 8, 2019 at 11:07 AM Ricky Teachey  wrote:

>
>
>> __import__ already has a 'level' argument.
>>
>
> doh! maybe "context" is better, then.
>
>
>> Not without frame inspection to know what import statements are in the
>> context manager's block.
>>
>>
> I don't doubt you know what you're talking about, so this is a learning
> question: why couldn't you do it by simply adding an
> "inside_context_manager" flag, and producing an appropriate globals and
> locals based on the flag value?
>

Not thread-safe (we have a custom import lock to avoid this sort of
problem) and the instant you start mucking with globals() and locals() you
have (a) become a bit magical, and (b) made things extremely slow for PyPy.

My opinion on this idea is while I appreciate the motivation behind it,
this is proposing a lot of churn and change in Python to fix a single issue
that only some people hit and most people learn to avoid the first time to
realize what they have done. If it was a problem people ran into constantly
throughout their life using Python then maybe I would personally be more
receptive, but since it's a one-time mistake for vast majority of people I
think I don't feel comfortable making every book on Python be outdated
overnight over this.

-Brett


>
> this is really lame, but maybe like this:
>
> class __import__:
>
> def __enter__(self):
> self.inside_context_manager = True
> return None
>
> def __exit__(self, *args):
> self.inside_context_manager = False
>
> def __call__(self, name, globals=None, locals=None, fromlist=(),
> level=0, context=None):
> am_i_outside_context_manager =  not self.inside_context_manager
> if am_i_outside_context_manager:
> do_normal_import(name, globals, locals, fromlist, level)
> else:
> # inside context manager
> if context is None:
> raise ValueError("invalid import context")
> cglobals = contextualized_globals(globals, context)
> clocals = contextualized_locals(locals, context)
> do_special_import(name, cglobals, clocals, fromlist, level)
>
>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UM3WJZDPGS6C2PWVUOKJX6WLHLSZXPQI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Suggest having a mechanism to distinguish import sources

[Brett Cannon]

On Sat, Nov 9, 2019 at 10:57 AM Steve Barnes  wrote:

>
>
>
>
> *From:* Brett Cannon 
> *Sent:* 08 November 2019 18:10
> *To:* Ricky Teachey 
> *Cc:* Dan Sommers <2qdxy4rzwzuui...@potatochowder.com>; python-ideas <
> python-ideas@python.org>
> *Subject:* [Python-ideas] Re: Suggest having a mechanism to distinguish
> import sources
>
>
>
>
>
>
>
> On Fri, Nov 8, 2019 at 10:01 AM Ricky Teachey  wrote:
>
> throwing this idea out there, no idea if it is practical but it might be
> pretty nice/easily understood syntax.
>
>
>
> could a context manager be created such that anything imported under it is
> guaranteed to be imported from the standard library, and produce an error
> otherwise? perhaps by adding a level keyword argument to the __import__
> built in.
>
>
>
> __import__ already has a 'level' argument.
>
> *[Steve Barnes] *
>
> *To be honest this is the first that I have heard of __import__(level) but
> looking at the docs and help for 3.8 doesn’t read like what you describe
> below – maybe it is an un/under-documented feature – it certainly wasn’t
> easy to find in the documentation (*
> https://docs.python.org/3/library/functions.html#__import__*)!*
>

It has to do with handling relative imports. It doesn't have anything to do
with the idea being proposed beyond being a parameter name that already
exists.


>
>
> *level* specifies whether to use absolute or relative imports. 0 (the
> default) means only perform absolute imports. Positive values for *level* 
> indicate
> the number of parent directories to search relative to the directory of the
> module calling __import__()
> <https://docs.python.org/3/library/functions.html#__import__> (see *PEP
> 328* <https://www.python.org/dev/peps/pep-0328> for the details).
>
> *PEP 328 doesn’t seem to mention any of the names detailed below.*
>

I strongly advise reading PEPs as documentation once their work has landed.
At that point they are mostly historical documents and will not be kept up
to date going forward. IOW do not read any import-related PEPs for help;
everything will be in the stdlib docs for importlib or in the language
reference for imports.

-Brett


>
>
>
>
> something like:
>
>
>
> with __import__(level="std"):
>
> # imports guaranteed to fail of not in the standard library
>
> from pathlib import Path
>
> from sys import argv
>
>
>
> with __import__(level="package"):
>
> # imports guaranteed to fail of not in the current package
>
> import mod1
>
> import mod2
>
>
>
> with __import__(level="local"):
>
> # imports guaranteed to fail of not in the local directory
>
> import mod1
>
> import mod2
>
>
>
> with __import__(level="site"):
>
> # imports guaranteed to fail if not in site-packages, or some other
> definition that makes sense
>
> import numpy as np
>
>
>
> Not without frame inspection to know what import statements are in the
> context manager's block.
>
>
>
> This can all be done with code which calls importlib.import_module() and
> checks __spec__.origin to see where the module came from. Basically if
> you're willing to give up the syntax support of 'import' statements (which
> are just calls to __import__ with some assignments afterwards to bind
> things to names) you can have this protection today without adding syntax
> (which is always a massive ask).
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NO2CKBUAXYCLPVJLFJJ3HN2JUTH4UREF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Suggest having a mechanism to distinguish import sources

[Brett Cannon]

On Fri, Nov 8, 2019 at 10:01 AM Ricky Teachey  wrote:

> throwing this idea out there, no idea if it is practical but it might be
> pretty nice/easily understood syntax.
>
> could a context manager be created such that anything imported under it is
> guaranteed to be imported from the standard library, and produce an error
> otherwise? perhaps by adding a level keyword argument to the __import__
> built in.
>

__import__ already has a 'level' argument.


>
> something like:
>
> with __import__(level="std"):
> # imports guaranteed to fail of not in the standard library
> from pathlib import Path
> from sys import argv
>
> with __import__(level="package"):
> # imports guaranteed to fail of not in the current package
> import mod1
> import mod2
>
> with __import__(level="local"):
> # imports guaranteed to fail of not in the local directory
> import mod1
> import mod2
>
> with __import__(level="site"):
> # imports guaranteed to fail if not in site-packages, or some other
> definition that makes sense
> import numpy as np
>

Not without frame inspection to know what import statements are in the
context manager's block.

This can all be done with code which calls importlib.import_module() and
checks __spec__.origin to see where the module came from. Basically if
you're willing to give up the syntax support of 'import' statements (which
are just calls to __import__ with some assignments afterwards to bind
things to names) you can have this protection today without adding syntax
(which is always a massive ask).
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZJA25HGF2FFNSUYMB4AQJT6KEZKIGGK6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: add a .with_stem() method to pathlib objects

[Brett Cannon]

On Tue, Oct 29, 2019 at 12:29 PM Ricky Teachey  wrote:

> Cool. Sounds like
>>
>> def with_stem(self, new_stem):
>> self.with_name(new_stem + self.suffix)
>>
>> is the preferred solution. I agree it seems like the right option.
>>
>> As I said, I don't think it's a big deal either way. A bugs.python.org
>> issue with an attached PR implementing (and documenting) this seems
>> like the way to go - no big need to debate it. Although it's good that
>> we caught the difference in behaviour between the two options - any
>> patch adding this should include tests for this particular corner case
>> (and any others that you can think of ;-))
>>
>> Paul
>>
>
> *(Apologies to Paul who is receiving this a second time)*
>
> Seems like the right implementation to me. Does anybody disagree that a
> bug report with a PR is the way to move forward on this?
>

Depends if you're okay with the PR potentially being rejected because the
idea gets rejected. If you're fine with that then do both, if you're not
then I would open the issue to make sure other core devs don't object.


>
> Also: I've filed bug reports before, but I don't think I've ever filed a
> bug report with a PR and with tests against core python. Is there a link
> that might help with learning the process, with an eye to how to setup and
> run the test correctly for the project...? I believe I've already signed
> the usage agreement and that sort of thing.
>

https://devguide.python.org/ should have everything you need (and if it
doesn't then please submit a PR to fix it 😉).

-Brett


>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/MEARZKOEGHTVSUOQJQSJ2ZPVDFVXSR4B/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IGLA6SDR7ZTP6ZTJTTMTSJRIEC23HA5V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: foo.setParseAction(lambda a, b, c: raise FuckPython(":("))

[Brett Cannon]

On Sun, Oct 27, 2019 at 6:58 AM Soni L.  wrote:

> foo.setParseAction(lambda a, b, c: raise FuckPython(":(")) is invalid
> syntax, which makes pyparsing useless.
>

Insulting the project that you're trying to get help with is unnecessary to
get your point across.

Consider this a warning that such a poor attitude is not welcome here.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BCWY5XHIRWG24FP4CGI6ZTTJYBQABDLG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: RFC: PEP xxx: Python Compatibility Version

[Brett Cannon]

On Thu, Oct 17, 2019 at 7:39 PM Ethan Furman  wrote:

> On 10/17/2019 06:02 PM, Victor Stinner wrote:
>
> > I propose the following PEP to add
> > sys.set_python_compat_version(version) to introduce a partial
> > compatibility with Python 3.8 in the next Python 3.9 version.
>
> -1
>

-1 from me as well.


>
> > If possible, please try to read the whole PEP before replying.
>
> Done.
>
> TL;DR  Besides being a maintenance burden, and one more source of bugs, it
> will be a debugging nightmare -- especially if different levels of
> "back-compatibility" have been selected.
>

That was my immediate thought as well as you now have to test that code
works in the stdlib for all potential version values to make sure all
side-effects/ramifications are accounted for.

And you already have sys.version_info for making sure you have a minimum
version support for your code.

Basically if people can't update yet then they simply can't update yet.
Staying on an older version that they were already happy enough with to
support shouldn't lead to a maintenance burden just to try and give them
free performance perks at a cost to the core devs.

-Brett


>
>
> > Rationale
> > =
> >
> > The need to evolve frequently
> > -
> >
> > To remain relevant and useful, Python has to evolve frequently. Some
> > enhancements require incompatible changes. Any incompatible change can
> > break an unknown number of Python projects.  Developers can decide to
> > not implement a feature because of that.
>
> Is "developer" an app developer or a library developer?  Either way, such
> developers are constrained by the lowest python version they support.
>
> How many versions back are we going to allow?  If we don't support each
> and every breaking change then some application/library is going to be
> inoperable at the latest Python version, even with "back compatibility".
>
>
> > Users want to get the latest Python version to get new features and
> > better performance. A few incompatible changes prevent them to use their
> > applications on the latest Python version.
>
> If they have to enable back-compatibility mode they still aren't getting
> the latest features/performance.  Also, if the app isn't using these new
> features (even without back-compatibility), how are they benefiting the
> user?
>
>
> > Partial compatibility to minimize the Python maintenance burden
> > ---
> >
> > Backward compatibility code will be dropped at each Python release, on a
> > case by case basis. Each compatibility function can be supported for a
> > different number of Python releases depending on its maintenance cost
> > and the estimated risk (number of broken projects) if it's removed.
>
> How will we estimate this number?  What's the minimum?  Is that minimum
> number dependent on the user base of those projects?  How do we estimate
> that?
>
>
> > Upgrade a project to a newer Python
> > ---
> >
> > Without backward compatibility, all incompatible changes must be fixed
> > at once, which can be a blocker issue. It is even worse when a project
> > is upgraded to a newer Python which is separated by multiple releases
> > from the old Python.
> >
> > Postponing an upgrade only makes things worse: each skipped release adds
> > more incompatible changes. The technical debt is only steadily
> > increasing.
> >
> > With backward compatibility, it becomes possible to upgrade Python
> > increamentally in a project, without having to fix all issues at once.
>
> Because the technical debt is now burdening Python instead.
>
>
> > The "all-or-nothing" is a showstopper to port large Python 2 code bases
> > to Python 3. The list of incompatible changes between Python 2 and
> > Python 3 is long, and it's getting longer at each Python 3.x release.
>
> Are you saying we are going to add a Python2.7 compatibility layer?
>
>
> --
> ~Ethan~
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/7D5IJJVWP3WY2YYSBOL6I6GRGLPZSPPN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NR7BBKYJXVJKZTGRDKLQCMJOU5XO745T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Quick notice about an update to the Code of Conduct

[Brett Cannon]

We just wanted to quickly let people know that the PSF Code of Conduct
recently got an update:
https://pyfound.blogspot.com/2019/09/the-python-software-foundation-has_24.html.
Since this list falls under the PSF CoC these changes apply here.

In terms of reporting CoC violations, you can continue to report them to
python-ideas-owner@ and then Titus and I will have a look. Otherwise you
can always report directly to conduct@ (see
https://www.python.org/psf/conduct/reporting/ for details).
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JPVULPOMMUKJKVGUSYJG2EX7OFLTZA2V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal: Use "for x = value" to assign in scope

[Brett Cannon]

On Fri, Aug 9, 2019 at 9:03 AM Peter O'Connor 
wrote:

> Alright hear me out here:
>
> I've often found that it would be useful for the following type of
> expression to be condensed to a one-liner:
>
> def running_average(x_seq):
> averages = []
> avg = 0
> for t, x in enumerate(x_seq):
> avg =  avg*t/(t+1) + x/(t+1)
> averages.append(avg)
> return averages
>
> Because really, there's only one line doing the heavy lifting here, the
> rest is kind of boilerplate.
>

But it's boilerplate that communicates the starting state of your loop
which is useful to know and to have be very clearly communicated.


>
> Then I learned about the beautiful and terrible "for x in [value]":
>
> def running_average(x_seq):
> return [avg for avg in [0] for t, x in enumerate(x_seq) for avg in
> [avg*t/(t+1) + x/(t+1)]]
>
> Many people find this objectionable because it looks like there are 3 for
> loops, but really there's only one: loops 0 and 2 are actually assignments.
>
> **My Proposal**
>
> What if we just officially bless this "using for as a temporary
> assignment" arrangement, and allow "for x=value" to mean "assign within the
> scope of this for".  It would be identical to "for x in [value]", just more
> readable.  The running average function would then be:
>
> def running_average(x_seq):
> return [avg for avg=0 for t, x in enumerate(x_seq) for avg = avg *
> t/(t+1) + x / (t+1)]
>

I personally don't find that more readable then the unrolled version you're
trying to avoid. And based on the amount of grief we got for the walrus
operator I wouldn't expect much uptake on this as being considered more
readable by others either. (And remember that "Readability counts").

-Brett


>
> -- P.S. 1
> I am aware of Python 3.8's new "walrus" operator, which would make it:
>
> def running_average(x_seq):
> avg = 0
> return [avg := avg*t/(t+1) + x / (t+1) for t, x in enumerate(x_seq)]
>
> But it seems ugly and bug-prone to be initializing a in-comprehension
> variable OUTSIDE the comprehension.
>
> -- P.S. 2
> The "for x = value" syntax can achieve things that are not nicely
> achievable using the := walrus.  Consider the following example (wherein we
> carry forward a "hidden" variable h but do not return it):
>
> y_seq = [y for h=0 for x in x_seq for y, h = update(x, h)]
>
> There's not really a nice way to do this with the walrus because you can't
> (as far as I understand) combine it with tuple-unpacking.  You'd have to do
> something awkward like:
>
> yh = None, 0
> y_seq, _ = zip(*(yh := update(x, yh[1]) for x in x_seq))
> --
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/RHW5AUV3C57YOF3REB2HEMYLWLLXSNQT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/J7FQP2KPODR4LA5K7HCLYU547O7CHHEV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Exceptions with Message Templates

[Brett Cannon]

On Thu, Aug 8, 2019 at 11:38 AM Ryan Fox  wrote:

> Thanks for the comments.
>
> I'm not really sure what you mean with regards to backwards compatibility.
> Would it suffice to have ExceptionTemplate.__init__ accept *args and pass
> that into super().__init__? I see that BaseException does something with
> args in __new__ and __init__, but I'm not very familiar with the Python
> internals. How does BaseException deal with kwargs?
>

It doesn't deal with them because it won't accept them. :)


>
> str.format_map() would make the formatting simpler, but I also use
> string.Formatter.parse() to in ExceptionTemplate._error_check() to find the
> required arguments. I don't see an alternative for this on str.
>

You can also use str.format(**kwargs) if you want to be strict about what
you accept in terms of keyword arguments while being generic in your
implementation.

I also just realized that your class won't have any helpful introspection
on the call signature either, so all users of your class will have to
document in the docstring very clearly what is expected in the constructor
call as their code editors won't be able to tell them and help()/inspect
won't be able to help either.


>
> You're right about the third thing. I hadn't even considered the books! I
> have released on PyPI as 'exception-template' and we'll see what happens.
> One person commented on Reddit that they liked the idea but would probably
> copy the code directly into their project rather than require an additional
> external dependency.
>

Yep, this is small enough to easily fit into a person's personal toolbox of
handy code.


>
> I guess I was hoping to get a feel of whether this was something that
> appealed to this audience and/or could ever be accepted, as well as to
> refine the idea and implementation.
>
> On Thu, Aug 8, 2019 at 2:03 PM Brett Cannon  wrote:
>
>> Three things. One, this isn't backwards-compatible as you are not passing
>> any details down into Exception.__init__() to make sure that
>> BaseException.args gets populated.
>>
>> Two, you can simplify your code by using str.format_map() instead of the
>> string module.
>>
>> Three, I don't see enough overhead from version 2 to your version 3 since
>> you're only saving a line of code so say there's that much boilerplate. But
>> the best way to prove me wrong is to release this on PyPI and see if people
>> use it. But without community use proving people want this we won't be up
>> for adding a new built-in exception as you're asking every book on Python
>> to be rewritten to cover this which is no small thing.
>>
>> On Thu, Aug 8, 2019 at 8:56 AM Ryan Fox  wrote:
>>
>>> Exception definitions in Python are not great. There are two main ways
>>> they're used in the code that I've read:
>>>
>>> 1) By far the most common:
>>>
>>> >>> class MyException(Exception):
>>> ... pass
>>> >>> raise MyException(f'Bad thing happened during {action} in {context}')
>>>
>>> 2) Much rarer:
>>>
>>> >>> class MyException(Exception):
>>> ... def __init__(self, action, context):
>>> ... super().__init__(f'Bad thing happened during {action} in
>>> {context}')
>>> >>> raise MyException(current_action, current_context)
>>>
>>> Version 1 is quick and easy, but messages skew and become inconsistent
>>> as they're copied from place to place. The Python standard library isn't
>>> immune to this either.
>>>
>>> Version 2 looks simple enough to do, but all of the repetitious
>>> boilerplate adds up when several exception types need to be defined. (And
>>> it's even worse when you want all of your code to include typing
>>> annotations.) Most people don't bother.
>>>
>>> My proposal is a new exception class as the preferred base for
>>> user-defined exceptions:
>>>
>>> >>> class MyException(ExceptionTemplate):
>>> ...message = 'Bad thing happened during {action} in {context}'
>>> >>> raise MyException(action=current_action, context=current_context)
>>>
>>> I have a reference implementation, implemented in an almost trivial
>>> amount of pure Python code:
>>> https://github.com/rcfox/exception-template/blob/master/exception_template/exception_template.py
>>>
>>> So why am I bothering you with this? I would like to see this become the
>>> preferred meth

[Python-ideas] Re: Exceptions with Message Templates

[Brett Cannon]

On Thu, Aug 8, 2019 at 5:24 PM Sebastian Kreft  wrote:

>
>
> On Thu, Aug 8, 2019 at 7:09 PM Andrew Barnert via Python-ideas <
> python-ideas@python.org> wrote:
>
>> On Aug 8, 2019, at 15:01, Ryan Fox  wrote:
>>
>> I don't see why you would want to access arguments by their position.
>>
>>
>> Because that’s the way it’s worked since Python 1.x, and there’s tons of
>> existing code that expects it, including the default __str__ and __repr__
>> for exceptions and the code that formats tracebacks.
>>
> I don't really understand what you mean here. This property was broken
> since ImportError started accepting keyword arguments.
>

The property isn't broken for ImportError, it just isn't being given the
keyword arguments because it didn't makes sense to pass them down with no
information attached to it. The 'args' attribute still gets the message
which is the key detail.

-Brett


>
> For example:
>
> >>> ImportError("message", name="name", path="path").args
> ('message',)
>
> >>> ImportError("message", "foo", name="name", path="path").args
> ('message', 'foo')
>
> For the case of str and repr, one could just call super with the formatted
> message as the only positional argument.
>
>
> I suggest taking a look at PEP 473
>  for ideas on why having
> structured arguments is a good idea.
>
>>
>> The user-defined exceptions in the Python documentation don't pass
>> arguments to the base class either:
>> https://docs.python.org/3/tutorial/errors.html#user-defined-exceptions
>>
>>
>> Yes they do. Try it:
>>
>> >>> e = InputError('[2+3)', 'mismatched brackets')
>> >>> e.args
>> ('[2+3)', 'mismatched brackets')
>> >>> e
>> InputError('[2+3)', 'mismatched brackets')
>>
>> If you’re wondering why this works, it’s because Error and InputError
>> don’t override __new__. Which should make it obvious why a tutorial aimed
>> at novices doesn’t get into the details, but that’s why Python has
>> reference manuals instead of just a tutorial.
>>
>> Also, notice that the tutorial examples don’t even try to create a
>> formatted message; they expect that the type name and the args will be
>> enough for debugging. I’m not sure that’s a great design, but it means that
>> your intended fix only solves a problem they didn’t even have in the first
>> place.
>>
>> So let's go ahead and assume my implementation is flawed. The fact that
>> people prefer to copy their format strings all over their projects implies
>> that the current exception scheme is suboptimal. Can we agree on that? If
>> not, there's no need to continue this discussion.
>>
>>
>> I agree that it would be nice for more people to move their message
>> formatting into the class, but you need a design that encourages that
>> without fighting against the fact that exception args are positional, and
>> I’m not sure what that looks like. And I don’t think it’s your
>> implementation that’s bad (it seems to do what it says perfectly well), but
>> that the design doesn’t work.
>>
>> Of course if you were designing a new language (or a new library from
>> builtins up for the same language), this would be easy. Exceptions would
>> look like (maybe be) @dataclasses, storing their arguments by name and
>> generating repr/str/traceback that takes that into account, and all of them
>> would actually store the relevant values instead of half of them making you
>> parse it out of the first arg, and there would be a special message
>> property or method instead of args[0] being sort of special but not special
>> enough, and so on. And then, providing an easier way to create that message
>> property would be an easy problem. But I think with the way Python is
>> today, it’s not.
>>
>> Of course I’d be happy to be proven wrong on that.  :)
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/5ULPVNH6RBFXY24P76YZCAKIKOLHWF2B/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> Sebastian Kreft
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/ZOLTXVQPUFWFJXO66JT7JEP2BMLVC5OF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/34RJSUDUOT3ORA

[Python-ideas] Re: Exceptions with Message Templates

[Brett Cannon]

Three things. One, this isn't backwards-compatible as you are not passing
any details down into Exception.__init__() to make sure that
BaseException.args gets populated.

Two, you can simplify your code by using str.format_map() instead of the
string module.

Three, I don't see enough overhead from version 2 to your version 3 since
you're only saving a line of code so say there's that much boilerplate. But
the best way to prove me wrong is to release this on PyPI and see if people
use it. But without community use proving people want this we won't be up
for adding a new built-in exception as you're asking every book on Python
to be rewritten to cover this which is no small thing.

On Thu, Aug 8, 2019 at 8:56 AM Ryan Fox  wrote:

> Exception definitions in Python are not great. There are two main ways
> they're used in the code that I've read:
>
> 1) By far the most common:
>
> >>> class MyException(Exception):
> ... pass
> >>> raise MyException(f'Bad thing happened during {action} in {context}')
>
> 2) Much rarer:
>
> >>> class MyException(Exception):
> ... def __init__(self, action, context):
> ... super().__init__(f'Bad thing happened during {action} in
> {context}')
> >>> raise MyException(current_action, current_context)
>
> Version 1 is quick and easy, but messages skew and become inconsistent as
> they're copied from place to place. The Python standard library isn't
> immune to this either.
>
> Version 2 looks simple enough to do, but all of the repetitious
> boilerplate adds up when several exception types need to be defined. (And
> it's even worse when you want all of your code to include typing
> annotations.) Most people don't bother.
>
> My proposal is a new exception class as the preferred base for
> user-defined exceptions:
>
> >>> class MyException(ExceptionTemplate):
> ...message = 'Bad thing happened during {action} in {context}'
> >>> raise MyException(action=current_action, context=current_context)
>
> I have a reference implementation, implemented in an almost trivial amount
> of pure Python code:
> https://github.com/rcfox/exception-template/blob/master/exception_template/exception_template.py
>
> So why am I bothering you with this? I would like to see this become the
> preferred method of defining new exceptions as recommended by the Python
> documentation. This would also require adding ExceptionTemplate as a
> built-in exception type.
>
> I will grant that ExceptionTemplate seems a little bit magical, but all of
> the required arguments are explicitly laid out to the user in the 'message'
> field, and format strings should be a familiar concept to most users.
>
> I've also included some tests that show that you can still treat these
> exceptions as regular classes:
> https://github.com/rcfox/exception-template/blob/master/tests/test.py#L53
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/GEO2WZQQJ6HMSXZIRFCKTRM7TYFQXNZ2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4XW6RKX5QIZTQ3A3PFHDPM6KFM4TWQLM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

[Brett Cannon]

On Thu, Aug 1, 2019 at 10:49 AM Eli Berkowitz 
wrote:

> In terms of an argument for why it should be included, for most Python
> users the itertools recipes remain unseen. I consider myself relatively
> fluent in Python (not compared to y'all of course) and hadn't seen them
> until I started this thread. If I had to hazard a guess, they're probably
> unused by 95%+ of the Python userbase.
> Having a function like consume as a builtin or part of a library widely
> increases visibility, and as it's a clean and efficient way of running an
> expression on a collection of data I think it's worth it especially as it
> has very little overhead.
>
> Also, given that `consume_iterator` is already in CPython in the
> collections module as a special case for `collections.deque(..., maxlen=0)`
> (and maybe some other things), I'm guessing it would not be hard at all to
> add consume to the itertools module, though I'll be honest I have no idea
> how Python's underlying C code fits together at the module level.
>
> https://github.com/python/cpython/blob/master/Modules/_collectionsmodule.c#L368
>

You can open an issue at bugs.python.org to make consume() a top-level
itertools function, but check it hasn't been asked for before.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZYABCLWUENLXUNECEZTUZVFJQHSNOERX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: support toml for pyproject support

[Brett Cannon]

On Mon, Jul 29, 2019 at 12:57 AM Sardorbek Imomaliev <
sardorbek.imomal...@gmail.com> wrote:

> Thanks, Brett. You've brought good points. And I wasn't necessarily
> advocating about adding TOML support to stdlib, actually it was more about
> having a defacto library for TOML parsing. Currently setuptools, pip and
> others(now even requests) are under supervision(not total but some) of PSF.
> I suggest doing same for TOML parsing. If we are bringing new standard to
> python ecosystem we should provide all parts needed for this
> tool/lib/standard to be usable "out of the box" for most users.
>

That's unfortunately not a general thing we can make happen. Someone needs
to implement a TOML package and then ask to move it to under the PSF after
gaining enough traction. Your best option would be to ask one of the TOML
package authors if they are interested in moving their project.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BJHULHSZWSWKYJPTJ6Q5KZNF543UQRW2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Skip modules by default in star-import

[Brett Cannon]

On Fri, Jul 26, 2019 at 11:51 PM Anders Hovmöller 
wrote:

>
>
> > On 26 Jul 2019, at 22:53, Guido van Rossum  wrote:
> >
> > Serhiy proposed a relatively minor change to the behavior of `import *`
> in the absence of __all__. This sounds like an idea we could try though we
> should have a look at the implications for various well-known packages. It
> is also a relatively minor problem that he's trying to solve, so it's not
> worth breaking lots of stuff over. (We can just add an __all__ to Tkinter
> that contains the desired list.)
> >
> > Anders then stole Serhiy's thread to advocate fora much more radical
> idea. That's not good netiquette. That idea is going to break a lot more
> code than Serhiy's. But my key message here is to Anders: stay on topic or
> start a new thread. You're welcome to discuss your idea in a separate
> thread. But don't steal existing threads.
>
> I respectfully disagree. Sure I advocated for a more radical idea, but one
> that solves the original problem and also other problems.


But the fact that you tried to solve "other problems" means you changed the
scope of the discussion in this thread.


> That doesn't seem like stealing a thread to me but offering another
> perspective on the problem at hand. Taking a step back and getting a bigger
> picture seems like a good thing. We're just throwing ideas around after
> all.
>

Please start a separate thread if you want to discuss the much broader
topic of disallowing exporting imported modules as this thread is
specifically around `import *`.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TIH5WBOIHQM3ED52DAXKUCIRO26XCFCL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

[Brett Cannon]

On Fri, Jul 26, 2019 at 6:57 AM Eli Berkowitz 
wrote:

> By #1 "should" be a 1-liner, I mean that I think a reasonable goal is to
> have a good syntax for this operation to be one line.
>
> And for #3 I'm basing it also off Pep 8: "Compound statements (multiple
> statements on the same line) are generally discouraged."
>
> Given that the proposed alternative isn't currently valid and #1 isn't
> 'bad' in any way other than being an extra line, I can understand not
> wanting to move this forward.
>
> One last thing to consider is how this would work with filtering:
> ```
> f(item) for item in lst if g(item)
> ```
> saves even more space, as the #1 alternative would be
>

Do understand that Python also strives for explicitness on top of clarity
which suggests trying to compress logic for the sake of saving a line or
two isn't a goal if it doesn't help readability. I do get the desire for
having an easy way to exhaust an iterator, but even with your desire for a
generator expression syntax, you can still make it short with:
```
for _ in (f(item) for item in lst if g(item)): pass
```

That doesn't require any new syntax (which is a very "expensive" thing to
do in Python as you have to update books for that sort of thing).

-Brett

```
> for item in lst:
> if g(item):
> f(item)
> ```
> However this advantage doesn't apply to if/else as the syntax becomes
> ambiguous:
> ```
> f(item) for item in lst if g else h
> # could mean:
> [f(item) for item in lst] if g else h
> # or
> [f(item) for item in lst if g else h]
> ```
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/BSALZNYSBZRUDDIFXRHFXGQ3B4V64ZFQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/F77N4HEANGAHG62KBGKKBMS2Q7DNR5WY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: support toml for pyproject support

[Brett Cannon]

On Fri, Jul 26, 2019 at 5:15 AM Sardorbek Imomaliev <
sardorbek.imomal...@gmail.com> wrote:

> Hello everyone, it has been almost a year after this issue was brought up.
> I suggest starting discussion on this again. I created an issue in
> python/peps repo https://github.com/python/peps/issues/1133
>
> > Hi, I am sure this was suggested somewhere before, but I couldn't find
> any references. I think toml file parser should be part of standard
> library. I know there is discussions like
> https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704.
> But toml is now official format for build system via pyproject.toml. So it
> is very odd that we have to use external tools to parse it.


It's actually not that odd. Think about all the setuptools usage and that
isn't in the stdlib either.


> Also many tools like black already started using it as configuration file.
> I know that pyproject.toml wasn't intended for such usecase, but
> nonetheless it very well may be a centralised configuration file for many
> QA and dev tools like flake8, coverage etc.
>

We relaxed the intent of pyproject.toml for those use-cases, so it's
officially considered okay. :)


>
> but was pointed that discussion should start here. In the era of 0.x
> software https://0ver.org I think it is not feasible to always wait till
> some standard, library or software becomes 1.x, take flask for example it
> has been years of usage in production before it got 1.x release. TOML
> standard pretty well defined, it was already chosen as fileformat for our
> new build system requirements https://www.python.org/dev/peps/pep-0518/.
> Standard library evolves and grows. I don't see a problem of having not
> TOML parser in standard library. Or at least some official package that
> will be defacto shipped with python itself as battery on installation.
>

1.0 actually isn't that far off:
https://github.com/toml-lang/toml/projects/1, so I would still much rather
wait for that rather than rush ahead, especially since we have survived
this long without a TOML parser in the stdlib.

-Brett


>
> As @Anders Hovmöller said in this thread
> https://mail.python.org/archives/list/python-ideas@python.org/message/OEKD6MFLPGCBSVL3B5VZQOVKXNJ4N53A/
> > This thread isn't about regretting past decisions but what makes sense
> given
> current realities though.
>
> I see this could be solved in one of these ways
> 1) We add TOML in standard library and have versioned parsers like
> TOMLParser05, TOMLParser06 etc and current version would be set TOMLParser
> = TOMLParser05, this way there won't be a problem when standard library and
> next version of python will ship new standard. Deprecation of parser
> classes could follow our standard deprecation procedure
> 2) There could be official TOML parser package under new
> https://github.com/psf group supervision, which will could be installed
> to platforms during python installation as pip does currently
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/VU6LRLQXVOWF6IWJCTFSWETFX36ERT45/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YPUSUOV4VEIIEV5LCKGKLQAUBM3VU3CN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP's shouldn't require a sponsor

[Brett Cannon]

On Thu, Jul 25, 2019 at 5:21 AM Rhodri James  wrote:

> On 25/07/2019 13:14, Batuhan Taskaya wrote:
> > Why do i need to convince a core developer for my PEP? AFAIK the steering
> > council can include non core developers (i know it isn't that current
> case
> > but for the future this is important). And if the last authority who will
> > approve my PEP is the steering council i just need to convince them not
> > core developers.
> >
> > Sponsors can stay (and they should because guidance is important) but thy
> > shouldn't be mandatory.  Let everyone to send their peps.
>
> Consider it this way; if you can't convince a single core developer to
> back your idea, your chances of getting general support, never mind the
> steering council, are very limited.
>

I'll make it even more concrete: if a single core dev won't sign off on a
PEP idea then the steering council won't consider it. It should be
understood that I came up with the sponsorship idea as a PEP author, core
dev, and steering council member (which the steering council signed off on):

- As a PEP editor because there's only so many of us and so I want PEPs to
be as "done" as they can be by the time they come to the peps repo so
there's less copy-editing
- As a core dev because I don't want a discussion on python-dev to start
until a PEP is in great shape and there won't be rehashing of previous
ideas or any critical points missing
- As a member of the steering council because if not a single core dev
likes an idea then I'm not interested in considering a PEP because the
steering council may help break stalemates but we are not about to against
the entire Python core team (which is what we would be asked to do if not a
single core dev wanted to back a PEP)

In other words the hurdle of finding a sponsor is very deliberate.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HPWNGP4MCHBJ3VXQO4ADXWUUGIRWB7TI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Suggestion: Windows launcher default to not using pre-releases by default

[Brett Cannon]

On Wed, Jul 10, 2019 at 1:58 PM Brendan Barnwell 
wrote:

> On 2019-07-09 23:23, Alex Walters wrote:
> > I have made this suggestion in the past.  The response then was that
> there
> > is no metadata in the windows install that includes if the release is
> > development or stable (that information is not stored in the registry).
> I
> > was advised to adjust my configuration of the py.exe launcher to set a
> > different default version.
> >
> > I think that's a reasonable stance to take with development versions -
> they
> > are intended for testing in specialist situations, so you can expect the
> > users to take the extra steps to make sure using them doesn't blow up
> their
> > world.
> >
> > It still would be nice if the registry details of the install had a bool
> > "stable" field that py.exe could poll.  I can't imagine it adds a lot to
> the
> > release process, or adds significant complexity to the launcher, and that
> > negates the need to update the launcher regularly.
>
> I agree that it seems the real problem here is the lack of a real
> way
> to determine if an available version is a real release or a
> prerelease/beta.  Is it not possible to change that, so that it is
> possible for the launcher to quickly and easily determine the highest
> release version available?
>

That's the question people are trying to figure out.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SERHTQODL3DU62BPBX36Y35WA74HKYU3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Suggestion: Windows launcher default to not using pre-releases by default

[Brett Cannon]

I'll also mention it's covered in the official docs at
https://docs.python.org/3/using/windows.html#launcher.

On Wed, Jul 10, 2019 at 2:04 PM Brett Cannon  wrote:

>
>
> On Wed, Jul 10, 2019 at 1:13 PM Steve Barnes 
> wrote:
>
>> Brett,
>>
>>
>>
>> Can I suggest that it might be an idea to add the honouring of PY_PYTHON
>> and PY_PYTHON2 environmental variables to the help text. This is the
>> missing piece as far as I am concerned.
>>
>
> I would then open a bug report and if you feel up for it open a PR (the
> function you want to change is
> https://github.com/python/cpython/blob/master/PC/launcher.c#L1398).
>
> FYI the Python launcher for UNIX already has this in its help output:
> https://github.com/brettcannon/python-launcher/blob/master/src/HELP.txt.
>
>
>>
>>
>> Steve
>>
>>
>>
>> *From:* Brett Cannon 
>> *Sent:* 10 July 2019 18:41
>> *To:* Steve Barnes 
>> *Cc:* Python-Ideas 
>> *Subject:* Re: [Python-ideas] Re: Suggestion: Windows launcher default
>> to not using pre-releases by default
>>
>>
>>
>> Based on the various responses I've seen, one thing I want to make very
>> clear is the launcher needs to be *fast*. That means no executing Python
>> code, minimizing stat calls, etc.
>>
>>
>>
>> Also be aware that I'm developing a launcher for UNIX, which puts its own
>> twist on this whole situation as there's no real registry on UNIX. ;) So
>> that means there are limited options for making this too fancy. (The UNIX
>> launcher uses PATH and the file name to determine what versions of Python
>> are installed.)
>>
>>
>>
>> One thing I will say is this issue can be solved manually today:
>> environment variables. If you define PY_PYTHON=3.7 then that will make
>> Python 3.7 the default version to use. Same goes for PY_PYTHON3=3.7 if
>> you're launching with `py -3`. Since this discussion is for people
>> installing betas I would assume those people are also installing new
>> versions of Python, which means you probably only need to update this once
>> every 18 months once you install the newest stable feature release.
>>
>>
>>
>> On Wed, Jul 10, 2019 at 12:13 AM Steve Barnes 
>> wrote:
>>
>> My thought is one of:
>>  -  if an explicit version is not specified the top (i.e. highest
>> version) candidate at the call time could be timestamp checked and compared
>> with a registry or ini file entry - if the entry for that version is
>> missing or has a different timestamp stored then it could be invoked with
>> --version and the version string parsed for either being \d+\.\d+\.\d+\s or
>> \d+\.\d+\.\d+-?\w+ to generate or set a stable/unstable flag (and the
>> timestamp). This should be minimal overhead and would be transparent to the
>> user.
>>  - There could be a --refresh-candidates flag or some such that could run
>> through each of the possible pythons, or a specified one, using the same
>> technique to check stability flags and the results saved in the registry
>> and used - this would be less per run overhead but more manual it could
>> potentially be added to a post install step in the installer at some point.
>>  - If a metadata flag for the registry could be decided on and honoured
>> by py & pyw but ignored if missing then a separate utility (possibly pip
>> installed) could be used to set/unset it again using the detect version
>> string mechanism or otherwise. (This could possibly even query an online
>> resource to disable by default unsupported, or known bad if it ever became
>> necessary,  versions.
>>
>> Any of these approaches would, I believe, address the need for the
>> maintainers to add metadata to the build, (other than what is already added
>> to adjust the version string), and would be fast & future proof (addressing
>> Ben's concerns).
>>
>> -Original Message-
>> From: Alex Walters 
>> Sent: 10 July 2019 07:23
>> To: 'Steve Barnes' ; 'Python-Ideas' <
>> python-ideas@python.org>
>> Subject: RE: [Python-ideas] Suggestion: Windows launcher default to not
>> using pre-releases by default
>>
>> I have made this suggestion in the past.  The response then was that
>> there is no metadata in the windows install that includes if the release is
>> development or stable (that information is not stored in the registry).  I
>> was advised to adjust my configuration of the py.exe launcher to set a
>> different default version.
>>
>&

[Python-ideas] Re: Suggestion: Windows launcher default to not using pre-releases by default

[Brett Cannon]

On Wed, Jul 10, 2019 at 1:13 PM Steve Barnes  wrote:

> Brett,
>
>
>
> Can I suggest that it might be an idea to add the honouring of PY_PYTHON
> and PY_PYTHON2 environmental variables to the help text. This is the
> missing piece as far as I am concerned.
>

I would then open a bug report and if you feel up for it open a PR (the
function you want to change is
https://github.com/python/cpython/blob/master/PC/launcher.c#L1398).

FYI the Python launcher for UNIX already has this in its help output:
https://github.com/brettcannon/python-launcher/blob/master/src/HELP.txt.


>
>
> Steve
>
>
>
> *From:* Brett Cannon 
> *Sent:* 10 July 2019 18:41
> *To:* Steve Barnes 
> *Cc:* Python-Ideas 
> *Subject:* Re: [Python-ideas] Re: Suggestion: Windows launcher default to
> not using pre-releases by default
>
>
>
> Based on the various responses I've seen, one thing I want to make very
> clear is the launcher needs to be *fast*. That means no executing Python
> code, minimizing stat calls, etc.
>
>
>
> Also be aware that I'm developing a launcher for UNIX, which puts its own
> twist on this whole situation as there's no real registry on UNIX. ;) So
> that means there are limited options for making this too fancy. (The UNIX
> launcher uses PATH and the file name to determine what versions of Python
> are installed.)
>
>
>
> One thing I will say is this issue can be solved manually today:
> environment variables. If you define PY_PYTHON=3.7 then that will make
> Python 3.7 the default version to use. Same goes for PY_PYTHON3=3.7 if
> you're launching with `py -3`. Since this discussion is for people
> installing betas I would assume those people are also installing new
> versions of Python, which means you probably only need to update this once
> every 18 months once you install the newest stable feature release.
>
>
>
> On Wed, Jul 10, 2019 at 12:13 AM Steve Barnes 
> wrote:
>
> My thought is one of:
>  -  if an explicit version is not specified the top (i.e. highest version)
> candidate at the call time could be timestamp checked and compared with a
> registry or ini file entry - if the entry for that version is missing or
> has a different timestamp stored then it could be invoked with --version
> and the version string parsed for either being \d+\.\d+\.\d+\s or
> \d+\.\d+\.\d+-?\w+ to generate or set a stable/unstable flag (and the
> timestamp). This should be minimal overhead and would be transparent to the
> user.
>  - There could be a --refresh-candidates flag or some such that could run
> through each of the possible pythons, or a specified one, using the same
> technique to check stability flags and the results saved in the registry
> and used - this would be less per run overhead but more manual it could
> potentially be added to a post install step in the installer at some point.
>  - If a metadata flag for the registry could be decided on and honoured by
> py & pyw but ignored if missing then a separate utility (possibly pip
> installed) could be used to set/unset it again using the detect version
> string mechanism or otherwise. (This could possibly even query an online
> resource to disable by default unsupported, or known bad if it ever became
> necessary,  versions.
>
> Any of these approaches would, I believe, address the need for the
> maintainers to add metadata to the build, (other than what is already added
> to adjust the version string), and would be fast & future proof (addressing
> Ben's concerns).
>
> -Original Message-
> From: Alex Walters 
> Sent: 10 July 2019 07:23
> To: 'Steve Barnes' ; 'Python-Ideas' <
> python-ideas@python.org>
> Subject: RE: [Python-ideas] Suggestion: Windows launcher default to not
> using pre-releases by default
>
> I have made this suggestion in the past.  The response then was that there
> is no metadata in the windows install that includes if the release is
> development or stable (that information is not stored in the registry).  I
> was advised to adjust my configuration of the py.exe launcher to set a
> different default version.
>
> I think that's a reasonable stance to take with development versions -
> they are intended for testing in specialist situations, so you can expect
> the users to take the extra steps to make sure using them doesn't blow up
> their world.
>
> It still would be nice if the registry details of the install had a bool
> "stable" field that py.exe could poll.  I can't imagine it adds a lot to
> the release process, or adds significant complexity to the launcher, and
> that negates the need to update the launcher regularly.
>
> > -Original Me

[Python-ideas] Re: Suggestion: Windows launcher default to not using pre-releases by default

[Brett Cannon]

Based on the various responses I've seen, one thing I want to make very
clear is the launcher needs to be *fast*. That means no executing Python
code, minimizing stat calls, etc.

Also be aware that I'm developing a launcher for UNIX, which puts its own
twist on this whole situation as there's no real registry on UNIX. ;) So
that means there are limited options for making this too fancy. (The UNIX
launcher uses PATH and the file name to determine what versions of Python
are installed.)

One thing I will say is this issue can be solved manually today:
environment variables. If you define PY_PYTHON=3.7 then that will make
Python 3.7 the default version to use. Same goes for PY_PYTHON3=3.7 if
you're launching with `py -3`. Since this discussion is for people
installing betas I would assume those people are also installing new
versions of Python, which means you probably only need to update this once
every 18 months once you install the newest stable feature release.

On Wed, Jul 10, 2019 at 12:13 AM Steve Barnes 
wrote:

> My thought is one of:
>  -  if an explicit version is not specified the top (i.e. highest version)
> candidate at the call time could be timestamp checked and compared with a
> registry or ini file entry - if the entry for that version is missing or
> has a different timestamp stored then it could be invoked with --version
> and the version string parsed for either being \d+\.\d+\.\d+\s or
> \d+\.\d+\.\d+-?\w+ to generate or set a stable/unstable flag (and the
> timestamp). This should be minimal overhead and would be transparent to the
> user.
>  - There could be a --refresh-candidates flag or some such that could run
> through each of the possible pythons, or a specified one, using the same
> technique to check stability flags and the results saved in the registry
> and used - this would be less per run overhead but more manual it could
> potentially be added to a post install step in the installer at some point.
>  - If a metadata flag for the registry could be decided on and honoured by
> py & pyw but ignored if missing then a separate utility (possibly pip
> installed) could be used to set/unset it again using the detect version
> string mechanism or otherwise. (This could possibly even query an online
> resource to disable by default unsupported, or known bad if it ever became
> necessary,  versions.
>
> Any of these approaches would, I believe, address the need for the
> maintainers to add metadata to the build, (other than what is already added
> to adjust the version string), and would be fast & future proof (addressing
> Ben's concerns).
>
> -Original Message-
> From: Alex Walters 
> Sent: 10 July 2019 07:23
> To: 'Steve Barnes' ; 'Python-Ideas' <
> python-ideas@python.org>
> Subject: RE: [Python-ideas] Suggestion: Windows launcher default to not
> using pre-releases by default
>
> I have made this suggestion in the past.  The response then was that there
> is no metadata in the windows install that includes if the release is
> development or stable (that information is not stored in the registry).  I
> was advised to adjust my configuration of the py.exe launcher to set a
> different default version.
>
> I think that's a reasonable stance to take with development versions -
> they are intended for testing in specialist situations, so you can expect
> the users to take the extra steps to make sure using them doesn't blow up
> their world.
>
> It still would be nice if the registry details of the install had a bool
> "stable" field that py.exe could poll.  I can't imagine it adds a lot to
> the release process, or adds significant complexity to the launcher, and
> that negates the need to update the launcher regularly.
>
> > -Original Message-
> > From: Steve Barnes 
> > Sent: Tuesday, July 9, 2019 1:32 AM
> > To: Python-Ideas 
> > Subject: [Python-ideas] Suggestion: Windows launcher default to not
> > using pre-releases by default
> >
> > Currently the py[w] command will launch the latest python by default
> > however I feel that this discourages the testing of pre-releases &
> > release candidates as once they are installed they will become the
> > default. What I would like is for the default to be the highest
> > version number of a full
> release
> > but the user to be able to specify a specific version even if it is a
> pre-release.
> >
> >
> >
> > The currently py or py -3 would give python 3.7 (if installed) but py
> > -3.8
> would
> > give the pre-release/release candidate if installed.
> >
> >
> >
> > Any thoughts on whether this would be a good idea - I am quite willing
> > to undertake the changes.
> >
> >
> >
> > Steve Barnes
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/SI

[Python-ideas] Re: Suggestion: Windows launcher default to not using pre-releases by default

[Brett Cannon]

On Mon, Jul 8, 2019 at 10:39 PM Steve Barnes  wrote:

> Currently the py[w] command will launch the latest python by default
> however I feel that this discourages the testing of pre-releases & release
> candidates as once they are installed they will become the default. What I
> would like is for the default to be the highest version number of a full
> release but the user to be able to specify a specific version even if it is
> a pre-release.
>
>
>
> The currently py or py -3 would give python 3.7 (if installed) but py -3.8
> would give the pre-release/release candidate if installed.
>
>
>
> Any thoughts on whether this would be a good idea – I am quite willing to
> undertake the changes.
>

The problem with this is it would either make the Python launcher have to
be updated with every release or it would have to download some data to
know what versions are not considered stable. Both of these go against the
general design of the launcher as it's meant to not require updating, be
future-compatible, and extremely fast.

-Brett


>
>
> Steve Barnes
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/JVMSAWZSH2QM6TBUHE724J5OKHNWHW6W/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XZSG5BYIKMD7KX55GSZMH4OEXRSEIPLX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Sildenafil is the best medicine to cure ED issues

[Brett Cannon]

I've marked their emails to be automatically discarded.

On Sat, Jul 6, 2019 at 6:50 AM Chris Angelico  wrote:

> On Sat, Jul 6, 2019 at 11:37 PM David Mertz  wrote:
> >
> > Seems useful, but it probably needs a PEP. :-)
>
> Please don't quote spam, but if you must, do please delete the links
> from your post :)
>
> ChrisA
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/V6DGJ5LS4OYZNFOUSIY3FE2GULYJT4AF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EKZLOUKQJOFCG3GKUYIKZR2J3YICOXWV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: venv.EnvBuilder environmental variable hooks

[Brett Cannon]

Just an FYI that I actually plan to try and make the activation scripts (at
least under PowerShell) completely static so they can be signed.

On Tue, Jun 18, 2019 at 3:31 PM Caleb Donovick 
wrote:

> Currently EnvBuilder allows for a number of customizations of virtual
> environments, changing which python is used, automatically installing
> libraries, etc...  However, it does not allow for any modifications of the
> activate script itself (unless one wants to rewrite it completely).
> However, a fairly common requirement for python packages is to edit some
> environmental variable e.g., DJANGO_SETTINGS_MODULE=.
>
> Which leaves developers with two options set the variables globally or
> manually edit the activate script.  Granted the activate script has been
> fairly static for the past few years, so a patch file can be used after
> manually editing once but its not the most elegant solution.  Further,
> there is no guarantee that activate script will be static going forward.
> In my mind there is a very simple solution, allow EnvBuilder to extend the
> set of variables which are set and restored on activate / deactivate (or
> more generally have activate / deactivate hooks).
>
> In the cpython implementation of venv there is a number of template
> parameters in the skeleton activate scripts which are filled by the
> EnvBuilder (__VENV_DIR__, __VENV_NAME__, ...).  A simple solution would be
> to extend these with __VENV_ACTIVATE_EXTRAS__ and
> __VENV_DEACTIVATE_EXTRAS__ where by default
> ```
> #Let env_vars: Dict[str, str] be the custom environmental variables
> __VENV_ACTIVATE_EXTRAS__ = ''.join(f'''
> _OLD_VIRTUAL_{key}="${key}"
> {key}="{value}"
> export {key}
> ''' for key,value in env_vars.items())
>
> __VENV_DEACTIVATE_EXTRAS__ = ''.join(f'''
> if [ -n "${{_OLD_VIRTUAL_{key}:-}}" ] ; then
> {key}="${{_OLD_VIRTUAL_{key}:-}}"
> export {key}
> unset _OLD_VIRTUAL_{key}
> fi
> ''' for key in env_vars)
> ```
>
> With __VENV_ACTIVATE_EXTRAS__ at
>
> https://github.com/python/cpython/blob/54cf2e0780ca137dd9abea5d3d974578ce0c18a9/Lib/venv/scripts/common/activate#L46
> and __VENV_DEACTIVATE_EXTRAS__ at
>
> https://github.com/python/cpython/blob/54cf2e0780ca137dd9abea5d3d974578ce0c18a9/Lib/venv/scripts/common/activate#L16
>
> Full activate / deactivate hooks could be achieved by setting
> __VENV_*_EXTRAS__ to be arbitrary shell commands.
>
> Caleb Donovick
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/MJNFEFT4GBVBEETJWZUQM5SS6C34PT3K/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IFDZX73T6PA3ALXAXCFRYK6TEHJ3IIOX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Comparison operator support (>= and <=) for type

[Brett Cannon]

I think the logic breaks down with multiple inheritance. If you make C(A,
B), then you can say C > A and C > B, but then you can't say A > B or A < B
which breaks sorting.

If you want to know if a B inherits from Base, then I think `Base in
B.mro()` will cover that just as succinctly. And if you need to know
position you can compare indexes into the MRO.

On Fri, Jun 14, 2019 at 1:06 AM eminbugrasaral--- via Python-ideas <
python-ideas@python.org> wrote:

> Let's assume you have this model:
>
> ```
> class Base:
> pass
>
> class A(Base):
> pass
>
> class B(Base):
> pass
>
> class C(A):
>pass
> ```
>
> While we can do `A == B`, or `B == C` or `B == B`, I would expect to be
> able to compare like this as well: `A >= B (if B is subclass or itself of
> A)`, or `B <= C (if B is a subclass or itself of C)`
>
> Because, since == means equality check. With the same logic, a class wraps
> another class is actually greater than this class from its type.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/6W7HCI4UIEAUD6AVLFSJF5Q2X55LWYZA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IFW2UQNCCNYFZH3TFKD26WH7SKCP4YKT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: python-ideas is now running on Mailman 3

[Brett Cannon]

On Thu, Jun 6, 2019 at 2:15 AM Paul Moore  wrote:

> On Wed, 5 Jun 2019 at 20:05, Pradyun Gedam  wrote:
> >
> > On Wed, 5 Jun 2019 at 10:52 PM, Brett Cannon  wrote:
> >>
> >> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> >> ___
> >> Python-ideas mailing list -- python-ideas@python.org
> >> To unsubscribe send an email to python-ideas-le...@python.org
> >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> >> Code of Conduct: http://python.org/psf/codeofconduct/
> >
> >
> > This is great news! :D
> >
> > FWIW, it seems the trailing text added by mailman is not getting
> formatted properly.
> >
> > Pradyun
> >
> > Python-Ideas mailing list -- python-dev(a)python.org
> > To unsubscribe send an email to python-ideas-leave(a)python.org
> > https://mail.python.org/mailman3/lists/python-ideas.python.org/
>
> Indeed it is :-) I'm not 100% sure what incorrect formatting you were
> referring to, but there seem to be 2 different issues - in Brett's
> original email, the URL was not being formatted correctly, but in
> Pradyun's, the trailer didn't have a separating line.
>
> Also, on the distutils-sig setup, an extra footer:
>
> Message archived at
>
> https://mail.python.org/archives/list/distutils-...@python.org/message/YN3DHLPXVH5RYLV2P4QJFSWHC6KKRGNH/
>
> was added to the setup. This is really useful - is there any chance it
> could be added to the other lists as well (here, python-dev, etc)?
>

I don't control python-dev, so that's up those admins.

I could add it, but I would have to reconstruct the footer for Mailman 3 as
the current ones are on-disk and not exposed to the UI, so I have to
basically override what's currently there. If someone wants to propose a
new footer then they can email me or start a new thread and hash one out.
The allowed variables are:

$hyperkitty_url: Permalink to archived message in Hyperkitty
$listname: Name of the Mailing List e.g. a...@example.com
$list_id: The List-ID header e.g. ant.example.com
$display_name: Display name of the mailing list e.g. Ant
$short_listname: Local part of the listname e.g. ant
$domain: The domain part of the listname e.g. example.com
$info: The mailing list's longer descriptive text
$request_email: The email address for -request address
$owner_email: The email address for -owner address
$site_email: The email address to reach the owners of the site
$language: The two letter language code for list's preferred language e.g.
fr, en, de
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] python-ideas is now running on Mailman 3

[Brett Cannon]

https://mail.python.org/mailman3/lists/python-ideas.python.org/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Making code objects filename an absolute path.

[Brett Cannon]

On Fri., May 24, 2019, 12:48 Batuhan Taskaya,  wrote:

> > changing this will probably break code
> It is why i'm suggesting making the real transition at 4.0 and adding a
> future flag for now.
> > And so you need to justify *why* you think that's acceptable
> I dont know it is acceptable or not, i saw this issue triaged to stage
> "patch required". AFAIK it means someone needs to write a patch for this
> issue and i wrote.
>

It's a bit more subtle because obviously some of us disagree that there's
an issue and there wasn't any discussion to see if there was consensus.
Plus tests are typically requires first regardless.

-Brett

I'm

> posting it here because i need to know do i have to write a pep or just
> give bpo link to __future__ page.
>
> On Fri, May 24, 2019 at 10:34 PM Brett Cannon  wrote:
>
>>
>>
>> On Fri, May 24, 2019 at 11:52 AM Batuhan Taskaya 
>> wrote:
>>
>>> The bpo i referenced can explain it better. An example;
>>>
>>>def foo(): pass
>>>assert foo.__code__.co_filename = 
>>> os.path.abspath(foo.__code__.co_filename)
>>>
>>>
>> Do realize there's a reason that issue has been open for well over five
>> years: changing this will probably break code. And so you need to justify
>> *why* you think that's acceptable since Python has existed with these
>> semantics on code objects for decades as this point.
>>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Making code objects filename an absolute path.

[Brett Cannon]

On Fri, May 24, 2019 at 11:52 AM Batuhan Taskaya 
wrote:

> The bpo i referenced can explain it better. An example;
>
>def foo(): pass
>assert foo.__code__.co_filename = os.path.abspath(foo.__code__.co_filename)
>
>
Do realize there's a reason that issue has been open for well over five
years: changing this will probably break code. And so you need to justify
*why* you think that's acceptable since Python has existed with these
semantics on code objects for decades as this point.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)

[Brett Cannon]

On Wed, May 15, 2019 at 12:46 AM Anders Hovmöller 
wrote:

>
>
> > On 15 May 2019, at 07:51, Jonathan Goble  wrote:
> >
> > That's not a realistic goal; there are some use cases, including in
> > CPython builtins, that cannot be accomplished without positional-only
> > arguments. For example, the current behavior of the `dict` constructor
> > is to accept both certain iterables as a positional-only argument
> > and/or keyword arguments from which a dict can be created. If the
> > iterable argument was not positional-only, then it would be forced to
> > consume a keyword (even if the caller passes it as a positional
> > argument), meaning that that keyword could never be included in
> > **kwargs and could not become a dict key via keyword arguments.
>
> You lost me. How is this not handled by *args and **kwargs? I think it is.
> "Positional only" isn't needed in this case.
>
> > Additionally, PEP 570 [1], which will add syntax for positional-only
> > parameters in Python functions, was accepted by Guido last month.
>

It was actually a decision of the Python steering council, of which Guido
is a member and so am I.


>
> I know and in my opinion it's a big mistake. It adapts python to a
> misfeatures of C extension code instead of making the C extentions play
> nice end behave like python.


There's actually more to it than that (it actually resolves various bugs we
had in the stdlib that have nothing to do with C extension modules). The
details can be found in the PEP.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] (meta) Broken link to gmane.org archive of python-ideas

[Brett Cannon]

Bugs about the website should be reported to
https://github.com/python/pythondotorg .

On Mon, May 13, 2019 at 7:42 AM Tom Hale  wrote:

> On 13/5/19 5:21 pm, Steven D'Aprano wrote:
> > If you don't like the mailman archives here
> >
> > https://mail.python.org/pipermail/python-ideas/
> >
> > you might try ActiveState:
> >
> > https://code.activestate.com/lists/python-ideas/
>
> Would https://bugs.python.org/ be an appropriate place for suggesting
> the updated links, or is there a specific channel for web updates?
>
> --
> Tom Hale
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Specific equality method for hashable objects

[Brett Cannon]

This goes against "there's only one way to do it" and overriding equality
and hashing is niche enough that I don't think it warrants having two ways
of  doing it (because you can't drop overriding __eq__/__hash__ due to
backwards-compatibility concerns).

On Wed, May 8, 2019 at 9:50 AM Phillip Cloud  wrote:

> A number of libraries override the equality operator (__eq__) in such a
> way that it returns an object that isn't a Python bool. This all but
> precludes making these objects hashable, even though there's nothing in
> principle that prevents them from being so.
>
> The main use case I have in mind is an expression DSL that returns another
> expression when its __eq__ method is called (sqlalchemy is a good example
> of such a DSL). In such DSLs you often want to use expressions as keys in
> dict. You *can* use them as keys, but the code that does is only reliable
> insofar as it can guarantee that the expressions in the dict are identical
> (in the sense of a pointer) to the values you're going to later use for
> lookup.
>
> After thinking about this for a bit, I'd like to understand whether it's
> reasonable to propose a new method __hash_eq__ that would be used during
> dict key comparisons (in lookdict).
>
> This new method would allow an object to override __eq__ *and* be
> hashable, by defining __hash_eq__. __hash_eq__ would only be allowed to
> return a bool, unlike __eq__.
>
> Regarding backwards compatibility, __hash_eq__ would be defined by default
> to be equivalent to __eq__.
>
> I haven't thought about other standard library mappings like OrderedDict
> yet, and it's entirely possible that such considerations would kill this
> idea.
>
> I did some googling before writing this up, and I couldn't find anything
> that proposed anything like this but perhaps my google skills are lacking.
> If there's a history here that I'm missing I'm happy to learn more about it.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] CPython Bytecode Assembler

[Brett Cannon]

Since bytecode is a CPython-specific implementaiton detail I don't know if
it makes sense to enshrine an assembler for it in the stdlib (if you were
to ask me today if I thought the dis module belonged in the stdlib I would
probably say "no", but I also know not everyone agrees with that view :) .

On Wed, Apr 24, 2019 at 10:36 AM Batuhan Osman Taşkaya <
batuhanosmantask...@gmail.com> wrote:

> Hello,
>
> Currently it is hard to assemble cpython bytecode without help of 3rd
> party libraries (like: vstinner/bytecode). I'm proposing an assembler to
> standard library and an API to cpython's peephole optimizer. Also an
> interface like `ast.NodeVisitor` and `ast.NodeTransformer` for bytecode
> objects will may be handy.
>
> It would help if you are doing;
> - Runtime patching
> - Specific optimizations at bytecode level
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] What are the strong use cases for str.rindex()?

[Brett Cannon]

Given "abcdefabcdefabcdef", what is the last result of "abc"?
x.rindex("abc") will tell you.

Given [1, 2, 3, 4, 5, 1, 2, 3, 4, 5] where is the last result of 3?
reversed(x).index(3) will tell you (or x[::-1]).

Notice how with lists you can easily reverse them and still get at the
value since you are searching per index. But with strings, you searching by
a subslice that can be greater than 1 in which case you can't use a similar
approach.

On Mon, Apr 22, 2019 at 11:47 PM 林自均  wrote:

> Hi all,
>
> I found that there are str.index() and str.rindex(), but there is only
> list.index() and no list.rindex(). So I filed the issue
> https://bugs.python.org/issue36639 to provide list.rindex(). However, the
> issue was rejected and closed with the comment:
>
> > There were known, strong use cases for str.rindex().  The list.rindex()
> method was intentionally omitted.  AFAICT no compelling use cases have
> arisen, so we should continue to leave it out.  In general, we don't grow
> the core APIs unnecessarily.
>
> However, I am not sure what the known, strong use cases for str.rindex()
> are. Why doesn't the strong use cases apply on list.rindex()? Could anyone
> give me some examples? Thanks.
>
> Best,
> John Lin
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP-582 and multiple Python versions

[Brett Cannon]

I just wanted to warn people that I don't know if any of the authors of PEP
582 subscribe to python-ideas and they have not brought it forward for
discussion yet, so there's no guarantee of a response.

On Mon, Apr 1, 2019 at 5:27 AM Calvin Spealman  wrote:

> While the PEP does show the version number as part of the path to the
> actual packages, implying support for multiple versions, this doesn't seem
> to be spelled out in the actual text. Presumably __pypackages__/3.8/ might
> sit beside __pypackages__/3.9/, etc. to keep future versions capable of
> installing packages for each version, the way virtualenv today is bound to
> one version of Python.
>
> I'd like to raise a potential edge case that might be a problem, and
> likely an increasingly common one: users with multiple installations of the
> *same* version of Python. This is actually a common setup for Windows users
> who use WSL, Microsoft's Linux-on-Windows solution, as you could have both
> the Windows and Linux builds of a given Python version installed on the
> same machine. The currently implied support for multiple versions would not
> be able to separate these and could create problems if users pip install a
> Windows binary package through Powershell and then try to run a script in
> Bash from the same directory, causing the Linux version of Python to try to
> use Windows python packages.
>
> I'm not actually sure what the solution here is. Mostly I wanted to raise
> the concern, because I'm very keen on WSL being a great entry path for new
> developers and I want to make that a better experience, not a more
> confusing one. Maybe that version number could include some other unique
> identify, maybe based on Python's own executable. A hash maybe? I don't
> know if anything like that already exists to uniquely identify a Python
> build or installation.
>
> --
>
> CALVIN SPEALMAN
>
> SENIOR QUALITY ENGINEER
>
> cspea...@redhat.com  M: +1.336.210.5107
> 
> TRIED. TESTED. TRUSTED. 
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] New Project to Capture summaries from this

[Brett Cannon]

I think this thread has gone off-topic as this mailing list is not about
Gmail (the client or the service). ;)

On Fri, Mar 29, 2019 at 4:21 AM Chris Angelico  wrote:

> On Fri, Mar 29, 2019 at 8:41 PM Steven D'Aprano 
> wrote:
> > On Fri, Mar 29, 2019 at 02:23:52PM +1100, Chris Angelico wrote:
> >
> > > Have you ever actually
> > > convinced someone to move off Gmail onto some other client?
> >
> > Gmail is an email provider with a web interface. As a provider, it is
> > available on any email client, so long as it speaks POP3 or IMAP.
>
> In those terms, I'm talking about convincing someone to move off the
> _Gmail client_, whether or not they continue using the Gmail service.
> Have you ever convinced someone to stop using the Gmail web interface
> and start using some other client, as a means of improving their use
> of the mailing list (eg to resolve some complaints they were having)?
>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Unified style of cache management API

[Brett Cannon]

On Thu, Mar 28, 2019 at 10:53 AM Serhiy Storchaka 
wrote:

> 28.03.19 19:45, Brett Cannon пише:
> > So I would say that a cache-clearing function convention would be a
> > reasonable starting point. If that turns out to not be enough for folks
> > we can talk about expanding it, but I think we should start small and
> > grow from there as needed.
> >
> > So what name would people want. clear_cache() or _clear_cache()? I
> > personally prefer the latter since clearing the cache shouldn't be
> > something people should typically need to do and thus the function is an
> > implementation detail.
>
> This is an interesting idea. I think it should be a dunder name:
> __clearcache__() or __clear_cache__().
>

Between those two then I would go with __clearcache__(), but I was talking
about a naming scheme for a function in each module, not a new built-in in
case you thought I meant that.

-Brett


> The disadvantage is that this method is slower in the case of large
> number of imported modules.
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Unified style of cache management API

[Brett Cannon]

On Wed, Mar 27, 2019 at 10:34 AM Serhiy Storchaka 
wrote:

> 27.03.19 15:46, Ma Lin пише:
> > re module [1] and struct module [2] have module-level cache for compiled
> > stuffs.
> > Other third-party modules may also need cache for something.
> >
> > Do we need an unified cache management API like this?
> > I suppose it's not mandatory, but welcome each module to use this API.
> >
> >module.cache_get_capacity() # return current capacity
> >module.cache_set_capacity(100)  # set capacity
> >module.cache_clear()# clear cache
> >
> > Moreover, add these API to sys module, then the users can manage system
> > wide cache easily:
> >
> >sys.cache_register(f)  # register a .cache_clear() function
> >sys.cache_clear()  # call all registered .cache_clear()
>
> I proposed similar idea at 2015.
>
> https://mail.python.org/pipermail/python-ideas/2015-April/032836.html


So I would say that a cache-clearing function convention would be a
reasonable starting point. If that turns out to not be enough for folks we
can talk about expanding it, but I think we should start small and grow
from there as needed.

So what name would people want. clear_cache() or _clear_cache()? I
personally prefer the latter since clearing the cache shouldn't be
something people should typically need to do and thus the function is an
implementation detail.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Unified style of cache management API

[Brett Cannon]

On Wed, Mar 27, 2019 at 6:47 AM Ma Lin  wrote:

> re module [1] and struct module [2] have module-level cache for compiled
> stuffs.
> Other third-party modules may also need cache for something.
>
> Do we need an unified cache management API like this?
>

Need? No. Nice to have? Maybe.


> I suppose it's not mandatory, but welcome each module to use this API.
>
>module.cache_get_capacity() # return current capacity
>module.cache_set_capacity(100)  # set capacity
>module.cache_clear()# clear cache
>

The only thing might be a cache-clearing function and I would name that
module._clear_cache() or something like importlib.invalidate_cache() (which
isn't a module-level cache, but it's still a cache ;) .


>
> Moreover, add these API to sys module, then the users can manage system
> wide cache easily:
>
>sys.cache_register(f)  # register a .cache_clear() function
>sys.cache_clear()  # call all registered .cache_clear()
>

That's not necessary if you standardize on the name as all you're asking to
do is:

for module in sys.modules.values():
  if hasattr(module, '_clear_cache'):
module._clear_cache()

-Brett


>
> [1] re module
> policy: FIFO
> capacity: 512 (default), changeable
> implementation: Python
> https://github.com/python/cpython/blob/v3.8.0a3/Lib/re.py#L268-L295
>
> [2] struct module
> clear entire cache when full
> capacity: 100, unchangeable
> implementation: C
>
> https://github.com/python/cpython/blob/v3.8.0a3/Modules/_struct.c#L2071-L2126
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A directive for indentation type, stricter indentation parsing.

[Brett Cannon]

On Mon, Mar 25, 2019 at 9:33 AM Mikhail V  wrote:

> Not a proposal yet, but some thoughts:
> I think it would help in a longer perspective if a user could
> include a directive in the header of the source code file that
> defines indentation character(s) for this source file. So this
> source would be parsed strictly by this char (or sequence).
>

This is more of a linter thing than a language thing, so I would propose
you take it to the code-quality mailing list.

-Brett


>
> E.g.:
>
> # indent "\t"
> ...
>
> Would force the Python parser to use exactly 1 tab for 1 indent level.
>
> # indent ""
> ...
>
> Would accordingly force the parser to use exactly 4 spaces for
> 1 indent level.
>
> Frankly I don't have much proof in hand for that will be a good
> addition, but intuitively I suppose it would help with some possible
> future features and in general, ease the development of source
> processors.
>
> One possible example: if a potential future feature would require
> a statement, and moreover require it to be indentation-aware?
> Lets take e.g. a multi-line string:
>
> s = """
> Hello
> world
> """
> print (s)
>
> >>>
>
> Hello
> world
>
>
> Here it is not so intuitive (unless you already know) how the string would
> be parsed (given that Python blocks are actually indentation-based).
> So if one would want to try introduce a new indent-aware string type and
> look into possible parsing disambiguation scenarios - it will be not an
> easy task.
> E.g. say one proposes a syntax for auto-unindented string block:
>
> s = !!!
> Hello
> world
> print (s)
> >>>
> Hello
> world
>
> (no leading newline, no leading indent in resulting string, which is a bit
> more
> expected result IMO).
>
> Then it seems one can define the parsing rule unambiguously _only_
> if one has a strictly defined character sequence for the indent level
> (e.g.  1 tab or 4 spaces, but not both).
> Thus it seems such a directive would be a prerequisite for such feature.
>
> And in general, I think it could help to make automatic conversions from
> one
> type of indentation to other easier.
>
>
>
> Mikhail
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] META: Is a PEP a good place to record Python's core design decisions and coding principles?

[Brett Cannon]

On Sun, Mar 24, 2019 at 10:34 AM Jonathan Fine  wrote:

> Guido van Rossum wrote:
>
>> I think this belongs in a personal blog, not on python-ideas and
>> definitely not in a PEP.
>>
>
> I don't agree, but I will accept that judgement, as if Guido still had
> BDFL status.
>

To help add more weight to what Guido said, it doesn't belong here and it
only belongs in a PEP if that PEP is justifying the feature to begin with.
IOW we don't need a PEP justifying every design decision that we have prior
to the PEP process.

-Brett


> --
> Jonathan
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP: Dict addition and subtraction

[Brett Cannon]

On Fri, Mar 15, 2019 at 11:15 AM Steven D'Aprano 
wrote:

> On Fri, Mar 15, 2019 at 10:34:45AM -0700, Brett Cannon wrote:
>
> > Watch the tone please.
>
> Brett, you might have missed my comment about wanting to avoid unhelpful
> arguments about tone, but if you are going to complain about people's
> tone, the considerate thing to do is to say what it is that you're
> objecting to.
>

The phrasing of "just sounding like an asshole who wants to shut people up"
is unnecessary.


>
> Otherwise we're left guessing as to what it is and whether or not you
> are making an implied threat to apply the CoC.
>

No implied "threat". If it was an official warning then I would have said
so.


>
> I responded to Antoine's post earlier, but thought that it was a
> respectful disagreement. Do you think that's not the case?
>

I think it skirts the edge of being disrespectful, hence the request to
please be aware of how one comes across.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP: Dict addition and subtraction

[Brett Cannon]

On Fri, Mar 15, 2019 at 4:36 AM Antoine Pitrou  wrote:

> On Thu, 7 Mar 2019 10:58:02 +1100
> Chris Angelico  wrote:
> >
> > Lots of words that basically say: Stuff wouldn't be perfectly pure.
>
> Chris, please learn to think twice before contributing what is
> essentially a trivialization of someone else's arguments.  You're not
> doing anything useful here, and are just sounding like an asshole who
> wants to shut people up.
>

Watch the tone please.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Attribute-Getter Syntax Proposal

[Brett Cannon]

On Fri, Mar 8, 2019 at 8:57 AM Samuel Li  wrote:

> Don't know if this has been suggested before. Instead of writing something
> like
>
> >>> map(lambda x: x.upper(), ['a', 'b', 'c'])
>
> I suggest this syntax:
> >>> map(.upper(), ['a', 'b', 'c'])
>

Do note you get the same results with `map(str.upper, ['a', 'b', 'c'])`.


>
> This would also work for attributes:
> >>> map(.real, [1j, 2, 3+4j])
>
> Internally, this would require translating
>
> .attribute -> lambda x: x.attribute
>
> and
>
> .method(*args, **kwargs) -> lambda x: x.method(*args, **kwargs)
>
> This translation should only take place where a "normal" attribute lookup
> makes no sense (throws a SyntaxError); i.e. foo.bar works as before,
> foo(.bar) would previously throw a SyntaxError, so the new syntax applies
> and the .bar is interpreted as an attrgetter.
>
> This is of course only a cosmetic improvement over operator.attrgetter and
> operator.methodcaller, but I think it's nice enough to warrant
> consideration.
>
> If you like this idea or think it's utter garbage, feel free to discuss.
>

Sorry, I'm personally not a fan as it looks like you have a typo in your
code, e.g. you left of 'x' or something before the dot.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Dict joining using + and +=

[Brett Cannon]

On Mon, Mar 4, 2019 at 1:29 PM Neil Girdhar  wrote:

> On Mon, Mar 4, 2019 at 3:58 PM Christopher Barker 
> wrote:
> >
> >
> >
> > On Mon, Mar 4, 2019 at 12:41 PM Guido van Rossum 
> wrote:
> >>
> >> Honestly I would rather withdraw the subtraction operators than reopen
> the discussion about making dict more like set.
>
> I think that's unfortunate.
> >
> >
> > +1
> >
> > I think the "dicts are like more-featured" sets is a math-geek
> perspective, and unlikely to make things more clear for the bulk of users.
> And may make it less clear.
>
> I'd say reddit has some pretty "common users", and they're having a
> discussion of this right now
> (
> https://www.reddit.com/r/Python/comments/ax4zzb/pep_584_add_and_operators_to_the_builtin_dict/
> ).
> The most popular comment is how it should be |.
>
> Anyway, I think that following the mathematical metaphors tends to
> make things more intuitive in the long run.


Only if you know the mathematical metaphors. ;)


>   Python is an adventure.
> You learn it for years and then it all makes sense.  If dict uses +,
> yes, new users might find that sooner than |.  However, when they
> learn set union, I think they will wonder why it's not consistent with
> dict union.
>

Not to me. I barely remember that | is supported for sets, but I sure know
about + and lists (and strings, etc.) and I'm willing to bet the vast
majority of folks are the some; addition is much more widely known than set
theory.


>
> The PEP's main justification for + is that it matches Counter, but
> counter is adding the values whereas | doesn't touch the values.   I
> think it would be good to at least make a list of pros and cons of
> each proposed syntax.
>

I suspect Steven will add more details to a Rejected Ideas section.


>
> > We need to be careful -- there are a lot more math geeks on this list
> than in the general Python coding population.
> >
> > Simply adding "+" is a non-critical nice to have, but it seems unlikely
> to really confuse anyone.
>

I agree with Chris.

-Brett


> >
> > -CHB
> >
> >
> > --
> > Christopher Barker, PhD
> >
> > Python Language Consulting
> >   - Teaching
> >   - Scientific Software Development
> >   - Desktop GUI and Web Development
> >   - wxPython, numpy, scipy, Cython
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP: Dict addition and subtraction

[Brett Cannon]

On Fri, Mar 1, 2019 at 8:50 AM Brandt Bucher  wrote:

> I’ve never been part of this process before, but I’m interested in
> learning and helping any way I can.
>

Thanks!


>
> My addition implementation is attached to the bpo, and I’m working today
> on bringing it in line with the PEP in its current form (specifically,
> subtraction operations).
>
> https://github.com/python/cpython/pull/12088
>

When your proposed patch is complete, Brandt, just ask Steven to update the
PEP to mention that there's a proposed implementation attached to the issue
tracking the idea.

-Brett


>
>
> Brandt
>
> On Mar 1, 2019, at 08:26, Steven D'Aprano  wrote:
>
> Attached is a draft PEP on adding + and - operators to dict for
> discussion.
>
> This should probably go here:
>
> https://github.com/python/peps
>
> but due to technical difficulties at my end, I'm very limited in what I
> can do on Github (at least for now). If there's anyone who would like to
> co-author and/or help with the process, that will be appreciated.
>
>
> --
> Steven
>
> 
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] About PEP-582

[Brett Cannon]

On Tue, Feb 19, 2019 at 3:29 PM Philip Bergen via Python-ideas <
python-ideas@python.org> wrote:

> First attempt at this, so please be gentle. :)
> I am very interested in the overall goal of not needing virtualenvs, but
> I'm curious about the motivations behind pep-582.
>

In a word, simplicity. Teaching newcomers about virtual environments is a
stumbling block, but so if when they accidentally pollute their global
installation when they get started.PEP 582 is an attempt to handle the
simple case nicely.


> Could someone help me understand if this has previously been discussed and
> in that case why it was decided against?
> 1: Why only look in CWD and not traverse root-wise?
>

Surprise, potential security implications, other languages that have a
similar solution don't do that.


> 2: It feels to me like there is a larger story here about sprucing up
> PYTHONPATH.
>

It's been a common theme that when people read PEP 582 they think there's a
larger story, so you're not alone. :)


>
> About 2) I would prefer if we had a mechanism to automatically look for
> .pythonpath.pth (or something with a better name, but to that effect). Then
> we were not limited to a specific directory or location. This would
> streamline cross project repos, for instance: you could have docker images
> that came preloaded with common libraries and just add a layer with your
> specifics in a different directory earlier in the paths specified by
> .pythonpath.pth
>
> Using pip to install into your directories of choice is already supported,
> although perhaps we should have some way of telling it to use the first
> entry in .pythonpath.pth.
>

PEP 582 isn't about sharing installs, so I think your idea is orthogonal to
its goals.

-Brett


>
> I would be very grateful for some interaction on this. If there is general
> interest I could submit some working code.
>
> Thanks,
> // Phil
>
> --
> *Philip Bergen*
> P: +1(415)200-7340
> *"Without data you are just another person with an opinion" -- W. Edwards
> Deming*
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] add fluent operator to everything

[Brett Cannon]

On Tue, Feb 19, 2019 at 6:23 AM Jimmy Girardet  wrote:

> Hi,
>
> There was the discussion about vector, etc...
>
> I think I have a frustration about chaining things easily in python in
> the stdlib where many libs like orm  do it great.
>
> Here an example :
>
> The code is useless, just to show the idea
>
> >>> a = [1,2,3]
>
> >>> a.append(4)
>
> >>> a.sort()
>
> >>> c = max(a) + 1
>
>
> I would be happy to have
>
> >>> [1,2,3].append(4)::sort()::max() +1
>
> It makes things very easy to read: first create list, then append 4,
> then sort, then get the max.
>

Easy for you, but not necessarily everyone else. For instance, I find the
explicit writing out of the lines easier.

Also realize that design is on purpose so that mutating method calls on
lists do not return themselves to get the point across that the mutation
was in-place and not in fact a new list.

-Brett


>
> To resume, the idea is to apply via a new operator (::, .., etc...) the
> following callable on the previous object. It's clearly  for standalone
> object or after a method call when the return is None (there is fluent
> `.` when there is a return value)
>
> >> object::callable()  = callable(object)
> >> object(arg)::callable = callable(object(arg))
>
> def callable(arg1,arg2):
>pass
>
> >> object::callable(arg) == callable(object, arg)
>
> The idea is to use quite everything as first argument of any callable.
>
> I do not know if it was already discussed, and if it would be
> technically doable.
>
> Nice Day
> Jimmy
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)

[Brett Cannon]

The below email was reported to the PSF board for code of conduct
violations and then passed on to the conduct working group to decide on an
appropriate response.

Based on the WG's recommendation and after discussing it with Titus, the
decision has been made to ban Jacco from python-ideas. Trivializing
assault, using the n-word, and making inappropriate comments about
someone's mental stability are all uncalled for and entirely unnecessary to
carry on a reasonable discourse of conversation that remains welcoming to
others.

On Mon, 17 Sep 2018 at 00:18 Jacco van Dorp  wrote:

> Op zo 16 sep. 2018 om 05:40 schreef Franklin? Lee <
> leewangzhong+pyt...@gmail.com>:
>
>> I am very disappointed with the responses to this thread. We have
>> mockery, dismissiveness, and even insinuations about OP's
>> psychological health. Whether or not OP is a troll, and whether or not
>> OP's idea has merit, that kind of response is unnecessary and
>> unhelpful.
>
>
> Sure, I'll take your bait.
>
>
>> Jacco:
>> - This is completely disrespectful and way over the line. Don't try to
>> make a psychological evaluation from two emails, especially when it's
>> just someone having an idea you don't like.
>> """However, if merely the word ugly being on a page can be
>> "harmful", what you really need is professional help, not a change to
>> Python. Because there's obviously been some things in your past you
>> need to work through."""
>>
>
> Is it, though ? Even more because in order for it to apply to any one
> person's aesthetics, you need to pull it out of context first. You need to
> be looking for it. Being triggered by a word this simple is not exactly a
> sign of mental stability. I know a girl who's been raped more than she can
> count - but the word doesn't trigger her like this(only makes her want to
> beat up rapists). If people can do that, then surely a playground insult
> wont reduce you to tears, right ?
>
>
>> - Mockery.
>> """If we have to ban "Ugly" for american sensitivities, then
>> perhaps we need to ban a number of others for china's sensitivities.
>> Where will it end ?"""
>>
>
> Well, on the internet, the word "nigger" is already basically banned for
> american sensibilities, while the version in dutch, my language, is
> "neger", which doesn't really have any racist connotation, probably because
> the amount of slaves that have ever been in what's currently the
> netherlands, has been negligible. However, it's use is effectively banned
> because some other culture considers it offensive to use. Why should your
> culture be my censorship ? And it's no coincidence I used china there -
> it's notorious for it's censorship. If merely labeling a word as
> "offensive" is sufficient to ban it, I daresay they'd mark a whole lot more
> words as offensive. And why would their opinion be any less valid than
> yours ?
>
> Don't think you're special - you're not. If you want to give yourself the
> power to ban words for offensive, you're giving that same power to
> everyone. And since offensive is subjective, it means anybody could ban any
> word, since you couldn't tell the difference between real or fake offense.
>
> Therefore, it is a disastrous idea and I'll predict the end of Python if
> we go down that route.
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving to another forum system where moderation is possible

[Brett Cannon]

On Tue, 18 Sep 2018 at 12:20 Ethan Furman  wrote:

> On 09/18/2018 12:05 PM, Franklin? Lee wrote:
> > On Tue, Sep 18, 2018 at 2:37 PM Jonathan Goble wrote:
>
> >> Perhaps not, but part of that might be because stopping an active
>  >> discussion on a mailing list can be hard to do, so one might not even
>  >> try. Some discussions, I suspect, may have gone on in circles long past
>  >> the point where they would have been locked on a forum. With forum
>  >> software, it becomes much easier, and would be a more effective tool to
>  >> terminate discussions that are going nowhere fast and wasting
> everyone's
>  >> time.
>
> True.
>
> > But there's no evidence that such tools would help.

Software
> > enforcement powers are only necessary if verbal enforcement isn't
> > enough. We need the current moderators (or just Brett) to say whether
> > they feel it isn't enough.
>
> It isn't enough.
>

Ethan's correct, it isn't enough. The past two weeks have been pretty
horrible for me as an admin and Titus and I need to find a solution to keep
this place sustainable long-term, otherwise I'm liable to burn out from
running this list (and before anyone says it, more admins will not help as
we have already tried that in the past).


>
> > What people may really be clamoring for is a larger moderation team,
> > or a heavier hand. They want more enforcement, not more effective
> > enforcement.
>
> More ineffective enforcement will be, um, ineffective.
>
> Let's have a test.  I'm a moderator (from -List).  We're* working on
> avenues to improve the mailing tools and
> simultaneously testing other options.  I'm not seeing anything new in this
> thread that will impact that one way or
> another, so I'm asking for all of us to move on to other topics.
>

What Ethan said. :) I'm now muting this thread as it has already become a
subjective debate of the value of email versus not which doesn't help me as
no one has come forward with anything I didn't already know, and this is
all before we have even had a chance to start an evaluation of alternatives
(IOW there's nothing for anyone on either side of this debate to actually
debate about when it comes to this mailing list yet :) .
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Moving to another forum system where moderation is possible

[Brett Cannon]

On Mon., Sep. 17, 2018, 13:21 James Lu,  wrote:

> How can the Zulip chat be joined? Im interested in consolidating all the
> discussion into one centralized forum.
>

No consolidation is happening yet. We're testing out mailing list
alternatives on smaller, more manageable lists first before we try to
migrate something as large as python-ideas.

In other words please be patient as we try to figure this out while knowing
we are looking into this.

-Brett


> Sent from my iPhone
>
> On Sep 17, 2018, at 3:35 PM, Philippe Godbout  wrote:
>
> Also, by restricting to python.org email address, do we not run the risk
> of cutting off a lot of would be contributor?
>
> Le lun. 17 sept. 2018 à 15:23, Abdur-Rahmaan Janhangeer <
> arj.pyt...@gmail.com> a écrit :
>
>> py already has a Zulip chat
>>
>> Abdur-Rahmaan Janhangeer
>> Mauritius
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

[Brett Cannon]

On Thu, 13 Sep 2018 at 13:10 Koos Zevenhoven  wrote:

>
> If you can't tell inclusivity/diversity from political correctness, or
> dirty words from dirty bytes or from unfriendliness and intolerance, you'd
> better go fuck yourself.
>

That language and tone is entirely uncalled for and you have been
participating here long enough to know that it isn't.

Due to the severity of the language and the fact that I have received
previous reports of negative interactions I am implementing a 2 month ban
for you, Koos. After two months you can submit a request to have your
posting abilities restored.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Keyword only argument on function call

[Brett Cannon]

On Thu, 6 Sep 2018 at 09:51 Ethan Furman  wrote:

> On 09/06/2018 07:05 AM, Anders Hovmöller wrote:
> > On Thursday, September 6, 2018 at 3:11:46 PM UTC+2, Steven D'Aprano
> wrote:
> >> On Thu, Sep 06, 2018 at 12:15:46PM +0200, Anders Hovmöller wrote:
>
> >>> Wouldn't it be awesome if [...]
> >>
> >> No.
> >
> > Heh. I did expect the first mail to be uncivil :P
>
> Direct disagreement is not uncivil, just direct.  You asked a yes/no
> question and got a yes/no answer.  D'Aprano's
> comments further down are also not uncivil, just explicative (not
> expletive ;) ) of his position.
>

It also wouldn't have hurt to say "I don't think so" versus the hard "no"
as it means the same thing. You're right that blunt isn't necessarily
uncivil, but bluntness is also interpreted differently in various cultures
so it's something to avoid if possible.

-Brett


>
> As for your proposal, I agree with D'Aprano -- this is a lot machinery to
> support a use-case that doesn't feel
> compelling to me, and I do tend to name my variables the same when I can.
>
> --
> ~Ethan~
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/