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

> 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

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

On Sat, Jul 27, 2019 at 12:50 PM Kyle Stanley wrote: > > Eric V. Smith wrote: > > In addition, I find it hard to believe someone couldn't find a sponsor > > for a well-written PEP. I'm happy to sponsor such a PEP, even if I think > > it will be rejected. Rejected PEPs serve a useful purpose, too,

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

Eric V. Smith wrote: > In addition, I find it hard to believe someone couldn't find a sponsor > for a well-written PEP. I'm happy to sponsor such a PEP, even if I think > it will be rejected. Rejected PEPs serve a useful purpose, too, if only > to point to when the same issue comes up in the fut

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

On Jul 26, 2019, at 15:05, Kyle Stanley wrote: > > Andrew Barnert wrote: >> consume(print(item) for item in lst) > > From my understanding, consume() effectively provides the functionality the > author was looking for. Exactly. And it’s readable and concise, and there’s even an implementation i

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

On Fri, Jul 26, 2019 at 10:06 PM Kyle Stanley wrote: > From my understanding, consume() effectively provides the functionality the > author was looking for. Also, between the options of `for _ in iter:` vs > `colllections.deque(it, maxlen=0)`, how significant is the performance > difference? > >

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

On Fri, Jul 26, 2019 at 12:51:46PM -, Eli Berkowitz wrote: > (This is my first time posting on any Python list; I've tried to search for > this idea and didn't find it but if I looked in the wrong places/this has > already been discussed I apologize and feel free to tell me!) > > Say you ha

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

On 7/26/2019 6:05 PM, Kyle Stanley wrote: Andrew Barnert wrote: consume(print(item) for item in lst) From my understanding, consume() effectively provides the functionality the author was looking for. Also, between the options of `for _ in iter:` vs `colllections.deque(it, maxlen=0)`, how sig

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

Andrew Barnert wrote: > consume(print(item) for item in lst) >From my understanding, consume() effectively provides the functionality the author was looking for. Also, between the options of `for _ in iter:` vs `colllections.deque(it, maxlen=0)`, how significant is the performance difference? I

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

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. itertools.product() is good enough for the occasional legitimate use case (I think I recall encounte

[Python-ideas] Re: for ... except, with ... except

These are interesting ideas. It looks like you intend the except clause of the for loop to *only* cover the iter() and next() calls that are implicit in the for loop. You're right that it's awkward to catch exceptions there. However, I worry that when people see this syntax, they will think that th

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

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 wor

[Python-ideas] Re: for ... except, with ... except

On 2019-07-26 19:26, Serhiy Storchaka wrote: [snip] I propose to add "except" clause to "for" and "with" statement to catch exceptions in the code that can't be wrapped with "try ... except". for VAR in EXPR: BLOCK except EXC: HANDLER should be equivalent to

[Python-ideas] Re: for ... except, with ... except

On Jul 26, 2019, at 11:26, Serhiy Storchaka wrote: > > I propose to add "except" clause to "for" and "with" statement to catch > exceptions in the code that can't be wrapped with "try ... except". > >for VAR in EXPR: >BLOCK >except EXC: >HANDLER I’m pretty sure for…exce

[Python-ideas] Re: Namespace context managers

On Jul 26, 2019, at 05:25, Ricky Teachey wrote: > This is a neat idea and I have wanted something similar myself in situations > I do not want to instantiate class object or break code out to another module. > > Controversial opinion: it may even justify a keyword. But it wouldn't have > to b

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

On 7/26/2019 4:23 PM, Anders Hovmöller wrote: On 26 Jul 2019, at 20:58, Eric V. Smith wrote: On 7/26/2019 2:50 PM, Anders Hovmöller wrote: On 26 Jul 2019, at 20:34, Serhiy Storchaka wrote: 26.07.19 21:10, Anders Hovmöller пише: This doesn't really solve the problem imo. Imported symbol

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

> On 26 Jul 2019, at 20:58, Eric V. Smith wrote: > > On 7/26/2019 2:50 PM, Anders Hovmöller wrote: >>> On 26 Jul 2019, at 20:34, Serhiy Storchaka wrote: >>> >>> 26.07.19 21:10, Anders Hovmöller пише: This doesn't really solve the problem imo. Imported symbols shouldn't be i portabl

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

> On 26 Jul 2019, at 21:50, Brendan Barnwell wrote: > >> On 2019-07-26 11:10, Anders Hovmöller wrote: >> This doesn't really solve the problem imo. Imported symbols shouldn't be i >> portable elsewhere. Not by import * or explicitly. That's the problem. > >I see a fair number of questions

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

On 2019-07-26 11:10, Anders Hovmöller wrote: This doesn't really solve the problem imo. Imported symbols shouldn't be i portable elsewhere. Not by import * or explicitly. That's the problem. I see a fair number of questions about this on StackOverflow and I just don't understand why people f

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

On 7/26/2019 2:50 PM, Anders Hovmöller wrote: On 26 Jul 2019, at 20:34, Serhiy Storchaka wrote: 26.07.19 21:10, Anders Hovmöller пише: This doesn't really solve the problem imo. Imported symbols shouldn't be i portable elsewhere. Not by import * or explicitly. That's the problem. I do no

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

> On 26 Jul 2019, at 20:34, Serhiy Storchaka wrote: > > 26.07.19 21:10, Anders Hovmöller пише: >> This doesn't really solve the problem imo. Imported symbols shouldn't be i >> portable elsewhere. Not by import * or explicitly. That's the problem. > > I do not think that this is always a probl

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

26.07.19 21:10, Anders Hovmöller пише: This doesn't really solve the problem imo. Imported symbols shouldn't be i portable elsewhere. Not by import * or explicitly. That's the problem. I do not think that this is always a problem. It is common to refactor the code by defining names in submodu

[Python-ideas] for ... except, with ... except

Python allows you to write code in tight and readable form. Consider the following example. with connect() as stream: # connect() or __enter__() can fail. for data in stream: # __next__() can fail write(data) # write() can fail The problem is that different lines can

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

This doesn't really solve the problem imo. Imported symbols shouldn't be i portable elsewhere. Not by import * or explicitly. That's the problem. One could propose to fix this by doing: 1. Imported symbols and locally declared symbols are put in two different dicts 2. Deprecation warning when y

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

On Jul 26, 2019, at 05:51, Eli Berkowitz wrote: > > #1 > for item in lst: >print(item) > > # 2 > [print(item) for item in lst] > > # 3 > for item in lst: print(item) > ``` Normally, expressions are about producing a value, and if you only care about side effects, you want a statement. Th

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

From the description of the import statement in the language reference [1]: The *public names* defined by a module are determined by checking the module's namespace for a variable named ``__all__``; if defined, it must be a sequence of strings which are names defined or imported by that module.

[Python-ideas] Re: Namespace context managers

On 07/26/2019 09:52 AM, Dan Sommers wrote: There Is Only One Way To Do It. There should be one-- and preferably only one --obvious way to do it. There is very little in Python that can only be done one way. -- ~Ethan~ ___ Python-ideas mailing list

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

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 ge

[Python-ideas] Re: Namespace context managers

On 7/26/19 12:23 PM, Ricky Teachey wrote: >> >> The class statement works in this fashion. >> > I would argue there are at least 2 significant reasons why a separate > namespace would be preferred over using class in this way: [...] > 2. using class means that all of the "new style class" ma

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

On 7/26/2019 11:21 AM, Geoffrey Spear wrote: On Thu, Jul 25, 2019 at 8:17 AM 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 b

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

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/113

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

On Jul 26, 2019, at 04:57, Sardorbek Imomaliev wrote: > > 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, I think _in general_ waiting for 1.0 makes sense. Many projects don’t make any compatibility p

[Python-ideas] Re: Namespace context managers

> > The class statement works in this fashion. > > I would argue there are at least 2 significant reasons why a separate namespace would be preferred over using class in this way: 1. using class in this way signals to the user that you are writing a class (ie, meant to be instantiated), and

[Python-ideas] Re: Namespace context managers

The class statement works in this fashion. foo = 1 class Bar: foo = 2 assert foo = 1 assert Bar.foo = 2 On Fri, Jul 26, 2019, 12:19 AM Batuhan Taskaya wrote: > I am proposing namespace context managers with implementing `__enter__` > and `__exit__` on dict objects. It would make closures p

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

On Thu, Jul 25, 2019 at 8:17 AM 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

[Python-ideas] Re: Namespace context managers

> a = {"foo": 1} > b = {} > with a: >with b: > foo = 0 It doesnt change `foo` value of `a` namespace unless `nonlocal` usage. assert a == {"foo": 1} assert b == {"foo": 0} On Fri, Jul 26, 2019 at 5:53 PM Calvin Spealman wrote: > Let's say you do this or any of the variants suggested..

[Python-ideas] Re: Namespace context managers

Let'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 managers with implementing `__enter__` > and `__exit__` on dict object

[Python-ideas] Re: Namespace context managers

On 26 Jul 2019, at 14:25, Ricky Teachey wrote: >> a = 4 >> >> with Namespace("ns") as ns: >> a = 3 >> print(a) # prints "3", not "4" >> >> def func(): >> return a # Closes on ns.a, not global a >> >> assert isinstance(ns, types.ModuleType) >> assert ns.name = "ns" >> as

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

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

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

On Fri, 26 Jul 2019 at 13:55, Eli Berkowitz wrote: > Say you have a list and you want to perform some operation on each item in > the list - but you don't need to store the result in a list. > > There are three simple ways of doing this, at least as far as I know: > ([print(item)] could be any e

[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 > or

[Python-ideas] For-expression/throwaway comprehension

(This is my first time posting on any Python list; I've tried to search for this idea and didn't find it but if I looked in the wrong places/this has already been discussed I apologize and feel free to tell me!) Say you have a list and you want to perform some operation on each item in the list

[Python-ideas] Re: Namespace context managers

> > a = 4 > > with Namespace("ns") as ns: > a = 3 > print(a) # prints "3", not "4" > > def func(): > return a # Closes on ns.a, not global a > > assert isinstance(ns, types.ModuleType) > assert ns.name = "ns" > assert ns.func() == 3 > assert a == 4 > This is a neat idea and I

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

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

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

Andrew Barnert via Python-ideas wrote: The usual set-theoretic definition of tuples is just recursively as ordered pairs: () is 0, (a) is a, (a, b) is , (a, b, c) is <, c>, etc. So, you don’t have to gloss over anything; s1 * s2 * s3 gives you elements ((a, b), c), but those are identical to elem

[Python-ideas] Re: Namespace context managers

On Fri, Jul 26, 2019 at 06:34:52PM +1000, Steven D'Aprano wrote: > On Fri, Jul 26, 2019 at 10:13:45AM +0300, Batuhan Taskaya wrote: > > > I am proposing namespace context managers with implementing `__enter__` and > > `__exit__` on dict objects. It would make closures possible in python with > > a

[Python-ideas] Re: Namespace context managers

On Fri, Jul 26, 2019 at 10:13:45AM +0300, Batuhan Taskaya wrote: > 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. I don't understand what you mean here. Closures are alre

[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 >

[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 __