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

I don't think this is the right mailing list (core workflow on discuss.python.org would be more suitable IMHO), other than that you are already able to do such a thing for github actions of your own PRs. If you enable a particular setting, you will get fail notifications for actions you've

[Python-ideas] Re: Expose Py_TabcheckFlag as other PyAPI_DATA flag.

On Fri, Oct 18, 2019, 1:00 PM GAUDRY Eloi wrote: > Hi > > When looking at the pydebug.h header file, I see that some symbols are not > declared as exported. > For instance, I would like to be able to change the value of the > Py_TabcheckFlag when running specific codelines. > Any chance this

[Python-ideas] Re: Allow kwargs in __{get|set|del|}item__

In fact, that would be a cool feature for ORMs. IMHO instead of ugly call chain with filters, slicing is a better option (on `__class_getattr__`). As said there are some disadvantages but i think this proposal deserves a PEP. On Fri, Oct 4, 2019, 10:59 PM Caleb Donovick wrote: > While there is

[Python-ideas] Re: Disallow all ending statements (continue/break/return) inside of finally

continue inside of finally, a new feature of python. But it crashed the interpreter, Then i submited a bug report and saw there are other cases where it crashes to. I think we shouldnt allow continue/break/return inside of finally as a language standard. https://bugs.python.org/issue37830

[Python-ideas] Disallow all ending statements (continue/break/return) inside of finally

About 2 days ago i was writing a blog post and i thought why dont i use a ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org

[Python-ideas] Re: Namespace context managers

say you do this or any of the variants suggested... What does this > do? > > a = {"foo": 1} > b = {} > with a: > with b: > foo = 0 > > On Fri, Jul 26, 2019 at 3:20 AM Batuhan Taskaya > wrote: > >> I am proposing namespace context managers

[Python-ideas] Re: Cartesian Product on `__mul__`

Python is for simplicity. It would be really cool to do such shortcuts instead of import itertools; itertools.product everytime. On Fri, Jul 26, 2019 at 2:55 PM Greg Ewing wrote: > Andrew Barnert via Python-ideas wrote: > > The usual set-theoretic definition of tuples is just recursively as >

[Python-ideas] Re: Namespace context managers

As an extra it will be identical with contextvars but it is going work on builtin dicts. On Fri, Jul 26, 2019 at 10:13 AM Batuhan Taskaya wrote: > I am proposing namespace context managers with implementing `__enter__` > and `__exit__` on dict objects. It would make closures possible in

[Python-ideas] Namespace context managers

I am proposing namespace context managers with implementing `__enter__` and `__exit__` on dict objects. It would make closures possible in python with a pythonic syntax. a = 4 namespace = {} with namespace: a = 3 assert a == 4 assert namespace["a"] == 3

[Python-ideas] Cartesian Product on `__mul__`

I think it looks very fine when you type {1, 2, 3} * {"a", "b", "c"} and get set(itertools.product({1, 2, 3}, {"a", "b", "c"})). So i am proposing set multiplication implementation as cartesian product. >>> ___ Python-ideas mailing list --

[Python-ideas] Re: Cartesian Product on `__mul__`

And i know this is proposed before but it should be reconsidered under steering council. On Thu, Jul 25, 2019 at 7:46 PM Batuhan Taskaya wrote: > I think it looks very fine when you type {1, 2, 3} * {"a", "b", "c"} and > get set(itertools.product({1, 2, 3},

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

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 i

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

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

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

red". AFAIK it means someone needs to write a patch for this issue and i wrote. 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

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

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) ___ Python-ideas mailing list Python-ideas@python.org

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

I was working on bpo20443 but then i realized it changes behavior of the compiler and some functions so i want to propose this change to here and then write a pep. I have a draft pr, it introduces a new future flag and as far as i can understand from the future

Re: [Python-ideas] Proposal: Allowing any variable to be used in a 'with... as...' expression

Good idea, +1 from me. On Sun, May 19, 2019, 3:17 AM Yonatan Zunger wrote: > Hi everyone, > > I'd like to bounce this proposal off everyone and see if it's worth > formulating as a PEP. I haven't found any prior discussion of it, but as we > all know, searches can easily miss things, so if this

[Python-ideas] Path conversion for f-strings

Like repr and string the file system path is used alot and something like path!p might be handy. >>> class MyClass: ... def __fspath__(self): ... return "/home/batuhan" ... >>> assert f"{mc!p}" == f"{os.fspath(mc)}" Also it saves us to unnecessarily import os for only fspath().