[Python-ideas] Re: Introduce "__python__" built-in attribute

2020-11-19 Thread Batuhan Taskaya
Also there is sys.implementation On Thu, Nov 19, 2020, 11:25 PM David Mertz wrote: > This is called sys.version, right? > > On Thu, Nov 19, 2020, 3:21 PM William Pickard > wrote: > >> TL/DR: A new built-in attribute who's purpose is to provide a simple way >> for developers to detect the Python

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

2020-06-05 Thread Batuhan Taskaya
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 triggere

[Python-ideas] Re: Copying a multiple values of a dict to another with a lot easier syntax

2019-10-21 Thread Batuhan Taskaya
You are introducing new keywords (of & to) which can break a lot of code. Beside that, i dont think any practical use of that statement so -1 from me. On Mon, Oct 21, 2019, 6:01 PM wrote: > m and n are lists or dicts or enumerates or classes or anything it can be > assigned like following: > > i

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

2019-10-18 Thread Batuhan Taskaya
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 patc

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

2019-10-07 Thread Batuhan Taskaya
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 n

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

2019-08-12 Thread Batuhan Taskaya
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

2019-08-12 Thread Batuhan Taskaya
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 https://mail.python.org/mailman3/lists/python-ideas.python.org

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

2019-07-27 Thread Batuhan Taskaya
> IMO if you need the concrete Cartesian product instantiated you're probably doing something wrong, or you're addicted to a certain kind of programming competitions with highly mathematical puzzles. Nop, operators are useful as you've said and it is why i am proposing this. neopythonic.blogspot.

[Python-ideas] Re: Namespace context managers

2019-07-26 Thread Batuhan Taskaya
27;s 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 man

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

2019-07-26 Thread Batuhan Taskaya
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 > or

[Python-ideas] Re: Namespace context managers

2019-07-26 Thread Batuhan Taskaya
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

2019-07-26 Thread Batuhan Taskaya
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] Re: Cartesian Product on `__mul__`

2019-07-25 Thread Batuhan Taskaya
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] Cartesian Product on `__mul__`

2019-07-25 Thread Batuhan Taskaya
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@p

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

2019-07-25 Thread Batuhan Taskaya
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

2019-07-25 Thread Batuhan Taskaya
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

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

2019-05-24 Thread Batuhan Taskaya
h required". 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, 2

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

2019-05-24 Thread Batuhan Taskaya
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 https://mail.python.org/mailman/listinfo/pytho

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

2019-05-24 Thread Batuhan Taskaya
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

2019-05-18 Thread Batuhan Taskaya
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

2019-05-12 Thread Batuhan Taskaya
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(). __