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

[Anders Hovmöller]

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

/ Anders 
___
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/ICKVRBAMWUYXFI77JH66J7KX5J5ZVTBL/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

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, if only
> > to point to when the same issue comes up in the future.
>
> Do most of the other core developers also share this perspective? Even
> though PEPs were not intended to be intimidating, they definitely can be
> for those who are less familiar with the process. I can imagine that many
> people would think that a "sponsor" would mean fully convincing someone
> to be completely on board with their idea.
>
> As someone who only more recently began contributing to Python, my previous 
> perception of PEPs were these monolithic technical
> documents that were well approved by the entire community. I'm slowly
> starting to see them more as simply being well structured proposals after
> having seen more of them.

Not a core dev, but from my perspective, PEPs are far too "iconic".
People make their first posts to python-ideas under the impression
that they should be writing PEPs. No, that's not the case; start with
discussion (which doesn't require a sponsor), and *then* start talking
about a PEP. By the time you get that far along with a proposal,
either your idea has enough support for a core dev to say "yeah, I'll
sponsor that" (even if s/he doesn't actually agree with the proposal),
or you know you're asking for something controversial (in which case
your first hurdle is to convince a core dev).

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/6ED2GZP6PFP3REWMDIFYE7X6OS4OMVI5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Kyle Stanley]

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 future.

Do most of the other core developers also share this perspective? Even 
though PEPs were not intended to be intimidating, they definitely can be 
for those who are less familiar with the process. I can imagine that many
people would think that a "sponsor" would mean fully convincing someone
to be completely on board with their idea.

As someone who only more recently began contributing to Python, my previous 
perception of PEPs were these monolithic technical 
documents that were well approved by the entire community. I'm slowly
starting to see them more as simply being well structured proposals after
having seen more of them.

To many outside of the development community though, such as those proposing 
ideas, their impression of a PEP is probably based on the
massive ones such as PEP 8. Although it was purely comical, I think PEP 401
helped me quite a lot to see them as less intimidating. PEP 581 is a good
example of an actual approved one that's easily digestible.
___
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/4WVJMMCFKQOUBSO452K45KIARIJ2Y6KB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Andrew Barnert via Python-ideas]

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 in 
the docs if you don’t think of it yourself.

> Also, between the options of `for _ in iter:` vs 
> `colllections.deque(it, maxlen=0)`, how significant is the performance 
> difference?
> 
> I had assumed that the performance of `for _ in iter` would be significantly
> better, since due to the overhead cost of creating and filling a double ended 
> queue, 
> which provides optimization for insertion at the beginning and end. Wouldn't 
> a one
> directional iterator provide better performance and have a lower memory cost 
> if 
> there is no modification required?

The maxlen of 0 means after determining that 0+1 > 0, the (C) function returns 
without even getting to the array manipulation stuff. Consuming the iterator in 
a for loop does even less work inside the loop, but it means the loop is in 
Python rather than C, which is a lot more expensive than the INC and JNZ that 
you save.

You’re right that it probably rarely makes a difference, but for something 
that’s going to be recommended in the official docs and potentially used in 
who-knows-what code, apparently someone thought it was worth the effort to 
benchmark.

I don’t know if anyone has retested this recently, but there was a 
StackOverflow question maybe 5 years back asking why itertools did this instead 
of something faster, and IIRC, after testing every idea everyone had an a 
variety of platforms and versions, the conclusion was that deque was (still) by 
far the fastest way to do it in CPython (short of a custom C function for 
consume, and even that isn’t much faster), and not quite the fastest but close 
enough in PyPy.


___
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/VPQASVOAH7VHZFXHMEYS4IECDL7AEJKR/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Josh Rosenberg]

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?
>
> I had assumed that the performance of `for _ in iter` would be
> significantly
> better, since due to the overhead cost of creating and filling a double
> ended queue,
> which provides optimization for insertion at the beginning and end.
> Wouldn't a one
> directional iterator provide better performance and have a lower memory
> cost if
> there is no modification required?
>

 collections.deque with an explicit maxlen of 0 doesn't actually populate
the queue at all; it has a special case for maxlen 0 that just pulls items
and immediately throws away the reference to what it pulled without storing
it in the deque at all. They split off that special case into its own
function at the C layer, consume_iterator:
https://github.com/python/cpython/blob/master/Modules/_collectionsmodule.c#L368

It's basically impossible to beat that in CPython in the general case. By
contrast, for _ in iterable would need to execute at least three bytecodes
per item (advance iterator, store, jump), which is *way* more expensive per
item. collections.deque(maxlen=0) can lose for small inputs (because it
does have to call a constructor, create a deque, then throw it away;
precreating a singleton for consume with `consumer =
collections.deque(maxlen=0).extend` can save on some of that though), but
for any meaningful length input, the reduced cost per item makes up for 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/WN7GAF7O7UANIYR5JTVWV6SP34D6WEKU/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

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

Does that come up very often? That means you're performing the operation 
only for the side-effects. I can't think of many situations where that 
would be useful. And the few times that it does come up, there are 
usually better ways to get the result you want, e.g.:

# Instead of this:
for x in lst:
L.append(x)

# Use this:
L.extend(lst)

# Instead of this:
for x in lst:
print(x)

# Use this:
print(*lst, sep='\n')



> There are three simple ways of doing this, at least as far as I know: 
> ([print(item)] could be any expression, just using it as an example)
> 
> ```
> lst = [1, 2, 3, 4]
> 
> #1 
> for item in lst:
> print(item)
>
> # 2
> [print(item) for item in lst]

No no no, this is wrong and bad, because you are building a list full of 
Nones that has to be thrown away afterwards. But you know that.

> # 3
> for item in lst: print(item)

Aside from being compressed to one line instead of two, that's identical 
to #1. They generate the same code, and both are perfectly fine if you 
have some reason for wanting to save a line.


> #1 - In my opinion, this should be a one line operation so #1 is not ideal.

Why should it be a one-liner? Do you have a shortage of vertical space 
to work with? Your comment here contradicts your comment about #3, where 
you say that making it a one-liner is "very unpythonic".


> #2 - It also shouldn't require storing results in array, to save 
> time/memory, so #2 is out.
> #3 - I think #3 is just not good syntax, it seems very unpythonic to 
> me - it breaks the norm that blocks go on their own lines. It does 
> seem the best of the three though and I know my assessment is kind of 
> subjective.

You can't have #1 and #3 at the same time. If it is unpythonic to have a 
loop on one line, then you need to split it over two lines. Inventing 
new syntax just so you can have a loop on one line when the language 
already permits loops on one line is unnecessary.


> I'm wondering if a possible alternative syntax could be a for-expression, 
> like there's if-expressions, which always evaluates to None:
> ```
> print(item) for item in lst
> ```

That clashes with the syntax for a generator comprehension. Generator 
comprehensions are funny beasts, because they require parentheses when 
they stand alone:

it = expression for item in lst# Syntax error.
it = (expression for item in lst)  # Permitted.

But when the parens are already there, as in a function call, you can 
(and should) leave the gen comprehension brackets out:

all((expression for item in lst))  # Unnecessary extra parens.
all(expression for item in lst)# Preferred.


Because of that, your suggested syntax would be ambiguous:

function(expression for item in lst)

could mean you are calling function() with a single generator 
comprehension as argument, or you are evaluating a "for-expression" for 
its side-effects and then calling function() with None as argument.


> A more practical example of when this would be useful is extending list-2 
> with a modified version of list-1 - this syntax would avoid creating an 
> intermediate list (not sure if the way lists are implemented in python 
> removes this advantage by the way it resizes lists though).
> 
> ```
> lst1 = [1, 2, 3]
> lst2 = [4, 5, 6]
> lst1.append(item * 2) for item in lst1
> ```

lst2.extend(item*2 for item in lst1)

lst2.extend(map(lambda x: 2*x, lst1)


In my personal toolbox, I have this function:


def do(func, iterable, **kwargs):
for x in iterable:
func(x, **kwargs)


Which I can use like this:

do(print, lst)

But I hardly ever do, since most of the time there are simpler 
alternatives. But feel free to use it in your own code.


-- 
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/H3FEB4ZECGBPDBHKWTQLF34DZF6WKDGD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Eric V. Smith]

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 significant is the performance 
difference?

I had assumed that the performance of `for _ in iter` would be significantly
better, since due to the overhead cost of creating and filling a double ended 
queue,
which provides optimization for insertion at the beginning and end. Wouldn't a 
one
directional iterator provide better performance and have a lower memory cost if
there is no modification required?


I haven't run any numbers. But moving a loop from Python code to C code 
is almost always a win. That's what's happening here. And I think the 
idea is a that deque with 0 members doesn't have much overhead.


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/WNZKN7OGCTPN6AKRG5TG3IL6BXZRHNNE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Kyle Stanley]

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 had assumed that the performance of `for _ in iter` would be significantly
better, since due to the overhead cost of creating and filling a double ended 
queue, 
which provides optimization for insertion at the beginning and end. Wouldn't a 
one
directional iterator provide better performance and have a lower memory cost if 
there is no modification required?
___
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/RFT7CZTXFQVHXCS3RRKFAGOHQGOXK2JU/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

 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 encountering one in the past decade or so).

Batuhan, if you still want to continue to debate this, please show some
real use cases of programs where itertools.product() makes it hard for the
human reader to understand the code. Examples like {1, 2, 3} * {"a", "b",
"c"} do *not* count.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(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/QTY5NNDEGHPYYOHOVYYL5ZDMF77RWPPU/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

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 the
except clause is for handling exceptions in the loop body. (That's
certainly what I assumed when I read just your subject line. :-)

On Fri, Jul 26, 2019 at 11:26 AM Serhiy Storchaka 
wrote:

> 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 raise an exception of the same
> type (for example OSError). We want to catch and handle exceptions
> raised when open a connection, when read a data and when write a data in
> different ways. Currently you need to expand so convenient Python
> statements "with" and "for" (see PEP 343)
>
>  _mgr = connect()
>  _enter = type(_mgr).__enter__
>  _exit = type(_mgr).__exit__
>  _value = _enter(_mgr)
>  _exc = True
>  try:
>  stream = _value
>  _it = iter(stream)
>  while True:
>  try:
>  data = next(_it)
>  except StopIteration:
>  break
>  write(data)
>  except:
>  _exc = False
>  if not _exit(_mgr, *sys.exc_info()):
>  raise
>  finally:
>  if _exc:
>  _exit(_mgr, None, None, None)
>
> and then add "try ... except" around corresponding explicit calls of
> `__enter__()` and `next()`.
>
>  try:
>  _mgr = connect()
>  _enter = type(_mgr).__enter__
>  _exit = type(_mgr).__exit__
>  _value = _enter(_mgr)
>  _exc = True
>  except OSError:
>  handle_connection_error()
>  else:
>  try:
>  stream = _value
>  try:
>  _it = iter(stream)
>  except OSError:
>  handle_read_error()
>  else:
>  while True:
>  try:
>  data = next(_it)
>  except StopIteration:
>  break
>  except OSError:
>  handle_read_error()
>  break
>  try:
>  write(data)
>  except OSError:
>  handle_write_error()
>  except:
>  _exc = False
>  if not _exit(_mgr, *sys.exc_info()):
>  raise
>  finally:
>  if _exc:
>  _exit(_mgr, None, None, None)
>
> Does not it look ugly?
>
> 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
>
>  try:
>  _it = iter(EXPR)
>  except EXC:
>  HANDLER
>  else:
>  while True:
>  try:
>  VAR = next(_it)
>  except StopIteration:
>  break
>  except EXC:
>  HANDLER
>  break
>  BLOCK
>
> and
>
>  with EXPR as VAR:
>  BLOCK
>  except EXC:
>  HANDLER
>
>  try:
>  _mgr = EXPR
>  _enter = type(_mgr).__enter__
>  _exit = type(_mgr).__exit__
>  _value = _enter(_mgr)
>  _exc = True
>  except EXC:
>  HANDLER
>  else:
>  try:
>  VAR = _value
>  BLOCK
>  except:
>  _exc = False
>  if not _exit(_mgr, *sys.exc_info()):
>  raise
>  finally:
>  if _exc:
>  _exit(_mgr, None, None, None)
>
> And correspondingly for asynchronous versions "async for" and "async with".
>
> So you will be able to add errors handling like in:
>
>  with connect() as stream:
>  for data in stream:
>  try:
>  write(data)
>  except OSError:
>  handle_write_error()
>  except OSError:
>  handle_read_error()
>  except OSError:
>  handle_connection_error()
> ___
> 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/M76F3434TXNO2EUMZZ647EABTCNXYGXA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.o

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

[Guido van Rossum]

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.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(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/UAQUOJCOCENYNVB2MDJGZGGNSOGAQSC6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[MRAB]

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

  try:
  _it = iter(EXPR)
  except EXC:
  HANDLER
  else:
  while True:
  try:
  VAR = next(_it)
  except StopIteration:
  break
  except EXC:
  HANDLER
  break
  BLOCK


[snip]
1. The 'for' loop can have an 'else' clause, and so can the 'try' 
statement. Is there any ambiguity over its meaning?


2. In your example you have it catching the exception if EXPR or 
iter(EXPR) raises. Is that a good idea?

___
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/QGJDHMK5LU55RAIAVCLFTPRUEBVOJ7U6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Andrew Barnert via Python-ideas]

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…except has been proposed in the past, and people didn’t 
think it was common enough or the workaround ugly enough.

But with…except, that really is ugly to workaround. And very easy to get wrong, 
too. Usually, I think people either just scrap the nice context managers and 
use finally, or add two more layers of indentation, or, most commonly, just 
punt on the problem and don’t handle errors correctly.

So, I think adding with to the idea makes it a lot more compelling.

___
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/KWJOOWC63HMIHGUKRH2TKPEGWH3PTVVB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Andrew Barnert via Python-ideas]

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 be a new one, def could work just fine:
> 
> def ns:
> a = 3 

It’s not clear to me whether people want a module-like, class-like, or 
function-like namespace here, but I do think it’s probably exactly one of those 
three. And it’ll be a lot easier to define and implement—and for everyone to 
understand  future Python code—if it is.

I don’t think anyone cares about fast locals here, and I hope nobody cares 
about things like super magic. But the differences in how variables in the 
namespace interact with functions and classes (and 
new-kind-of-namespace-things) defined within the namespace do probably matter. 
And you’d probably want to know what to expect from eval/exec, 
locals/globals/vars, etc., because someone is going to do that and you want it 
to be obvious what it means, rather than having to dig through the spec or 
trial-and-error at the interactive prompt to figure it out. And people probably 
occasionally want to know how to do the same thing programmatically (just like 
people occasionally want to know how to call a metaclass explicitly). But the 
nesting is the key question.

Meanwhile, do we even need to name the namespace? While it does allow the 
JS-style trick you gave for defining a “prototype” object without a class, do 
we actually want that in Python? And are there any other practical uses for 
names here? If not, there’s a really easy design and implementation, something 
like one of the following:

A bare “def:” statement defines a function, doesn’t bind it to anything, calls 
it with no args, and discards both the function and the result. So locals, 
nonlocal, eval, etc. work exactly the same way as in any other def body.

A bare “class:” statement defines a class namespace, doesn’t call the 
metaclass, and doesn’t bind anything to anything. Again, everything works 
exactly the same way as in any other class body.

A bare “import:” statement defines a module namespace, doesn’t construct a 
module out of it, and doesn’t bind anything to anything.

> Final observation: I think one shortfall in python is that it nudges the user 
> to use OOP a little bit too forcefully

I think it’s a strength of Python that it uses OOP under the hood for all kinds 
of stuff, but usually doesn’t make you think in OOP terms while writing and 
reading the code. And I think your version of the proposal takes it farther in 
that direction, which is good.

For example, nobody thinks of def as being syntactic sugar for constructing an 
object of type function that has a descriptor that returns an object of type 
method, and then binding it to a name. It just defines a method on a class, and 
it works. But, because that’s what it does under the covers, on the rare 
occasions where you need to go under the covers, you use the same OO style as 
with everything else. Compare that to the way reflection on methods works in, 
say, ObjC, where you end up calling a bunch of C functions, and passing them 
not actual classes and methods but pointers to opaque Class and Selector 
objects, and it feels more like you’re writing an ObjC interpreter than writing 
ObjC code.

___
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/C3T65OO4UAELIGMPMPYQXASMLPN5OMWY/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Eric V. Smith]

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 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 submodules and then importing them in the main module. For 
example, in `json/__init__.py`:

from .decoder import JSONDecoder, JSONDecodeError
from .encoder import JSONEncoder

It is possible even to use a star import.

So this change would break much more code.

I believe I covered that in my last email. I'll repeat it here for clarity: if 
you indent to re-export you can do that explicitly:
from foo import bar
bar = bar


I think breaking a whole lot of existing code is a bad idea.


I don't think it's that common that code would break for this. If it does the 
fixed code is very likely better (except in libs where some API is exposed but 
implented in another module).


I personally have dozens of packages where I do "from .submodule import 
*" in a __init__.py. The stdlib has about 20 such cases. It's a very 
common pattern when you had a module that became a package and was 
refactored over time.



And the length of the deprecation period is tweakable. We can set it for 30 
years if we want.


I don't see the point of this change, then. I'm okay with making it a 
style guide issue, or catch it in a linter.


I'm -1 on this proposal. There's not enough advantage given the churn it 
would cause.


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/R7FQ2WFF2WDOOGZ7O2RLFYOLPSHEVZLG/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Anders Hovmöller]

> 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 
 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 submodules and then importing them in the main 
>>> module. For example, in `json/__init__.py`:
>>> 
>>>from .decoder import JSONDecoder, JSONDecodeError
>>>from .encoder import JSONEncoder
>>> 
>>> It is possible even to use a star import.
>>> 
>>> So this change would break much more code.
>> I believe I covered that in my last email. I'll repeat it here for clarity: 
>> if you indent to re-export you can do that explicitly:
>> from foo import bar
>> bar = bar
> 
> I think breaking a whole lot of existing code is a bad idea.

I don't think it's that common that code would break for this. If it does the 
fixed code is very likely better (except in libs where some API is exposed but 
implented in another module). 

And the length of the deprecation period is tweakable. We can set it for 30 
years if we want. 

/ Anders 
___
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/KPXZ5B4XMBY2ZGFLMIXLKTW42GXRTVFI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Anders Hovmöller]

> 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 about this on StackOverflow and I just 
> don't understand why people feel it's a problem.  

If you see many questions it's by definition a problem. Take the questions 
seriously. It's Confusing at best. We can fix it. 

> Who cares what names are accessible in an imported module's namespace?  If 
> you do `import foo` and then `foo.blah` happens to be some oddball name you 
> didn't expect to be in there, so what?  Just don't use it and it doesn't 
> matter.

I see fairly often and it creates weird cases where searching doesn't find 
stuff because it's imported from the wrong place. It is bad for readability for 
no good use imo. 

>As for star-import, it should NEVER be used except in cases where the 
> module you're star-importing explicitly defines an __all__ and documents that 
> it's okay to star-import it, in which case the issue is moot since the 
> __all__ will prevent any unexpected names from being imported.

OK. How about enforcing that? This seems to be your suggestion?

>The actual problem is that people use star-importing when they shouldn't.  

That's OPs problem. But that's not mine. I only use import * interactively or 
in throw away scripts. 

> I don't think there's any need to change the language to make star imports 
> easier or more convenient; if anything we should be trying to move away from 
> their use.

I'm fine with keeping star import for interactive use only. *shrug* But this 
also a long deprecation process. 

/ Anders 
___
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/PR6PTKK5F6XA4LX2QUJR5F67QLY6X5TS/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brendan Barnwell]

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 feel it's a problem.  Who cares what names 
are accessible in an imported module's namespace?  If you do `import 
foo` and then `foo.blah` happens to be some oddball name you didn't 
expect to be in there, so what?  Just don't use it and it doesn't matter.


	As for star-import, it should NEVER be used except in cases where the 
module you're star-importing explicitly defines an __all__ and documents 
that it's okay to star-import it, in which case the issue is moot since 
the __all__ will prevent any unexpected names from being imported.


	The actual problem is that people use star-importing when they 
shouldn't.  I don't think there's any need to change the language to 
make star imports easier or more convenient; if anything we should be 
trying to move away from their use.


--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."

   --author unknown
___
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/5L32UECKDWZ4JSUGA62GXN2CZQ7NDC6Q/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Eric V. Smith]

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 not think that this is always a problem. It is common to refactor the code 
by defining names in submodules and then importing them in the main module. For 
example, in `json/__init__.py`:

from .decoder import JSONDecoder, JSONDecodeError
from .encoder import JSONEncoder

It is possible even to use a star import.

So this change would break much more code.


I believe I covered that in my last email. I'll repeat it here for clarity: if 
you indent to re-export you can do that explicitly:

from foo import bar
bar = bar


I think breaking a whole lot of existing code is a bad idea. This just 
isn't a big problem in practice. We've typically said that the 
documentation is the final word on what's public, and that we can change 
anything else.


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/5W7S5FAHLJ7TTXLEEZ54EG64ONO4I2YK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Anders Hovmöller]

> 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 problem. It is common to refactor the 
> code by defining names in submodules and then importing them in the main 
> module. For example, in `json/__init__.py`:
> 
>from .decoder import JSONDecoder, JSONDecodeError
>from .encoder import JSONEncoder
> 
> It is possible even to use a star import.
> 
> So this change would break much more code.

I believe I covered that in my last email. I'll repeat it here for clarity: if 
you indent to re-export you can do that explicitly:

from foo import bar
bar = bar

For "from x import *" you'd need to iterate over __import_dict__ (or whatever 
we call it) and set them all. 

/ Anders 
   
___
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/EP3PK3C4ZPJSBIYT4OLFIBREOW7RX67Y/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Serhiy Storchaka]

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 submodules and then importing them in the 
main module. For example, in `json/__init__.py`:


from .decoder import JSONDecoder, JSONDecodeError
from .encoder import JSONEncoder

It is possible even to use a star import.

So this change would break much more code.
___
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/DAC2BSL6IT53WDQYVPOHZ6OMDGD33HHL/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Serhiy Storchaka]

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 raise an exception of the same 
type (for example OSError). We want to catch and handle exceptions 
raised when open a connection, when read a data and when write a data in 
different ways. Currently you need to expand so convenient Python 
statements "with" and "for" (see PEP 343)


_mgr = connect()
_enter = type(_mgr).__enter__
_exit = type(_mgr).__exit__
_value = _enter(_mgr)
_exc = True
try:
stream = _value
_it = iter(stream)
while True:
try:
data = next(_it)
except StopIteration:
break
write(data)
except:
_exc = False
if not _exit(_mgr, *sys.exc_info()):
raise
finally:
if _exc:
_exit(_mgr, None, None, None)

and then add "try ... except" around corresponding explicit calls of 
`__enter__()` and `next()`.


try:
_mgr = connect()
_enter = type(_mgr).__enter__
_exit = type(_mgr).__exit__
_value = _enter(_mgr)
_exc = True
except OSError:
handle_connection_error()
else:
try:
stream = _value
try:
_it = iter(stream)
except OSError:
handle_read_error()
else:
while True:
try:
data = next(_it)
except StopIteration:
break
except OSError:
handle_read_error()
break
try:
write(data)
except OSError:
handle_write_error()
except:
_exc = False
if not _exit(_mgr, *sys.exc_info()):
raise
finally:
if _exc:
_exit(_mgr, None, None, None)

Does not it look ugly?

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

try:
_it = iter(EXPR)
except EXC:
HANDLER
else:
while True:
try:
VAR = next(_it)
except StopIteration:
break
except EXC:
HANDLER
break
BLOCK

and

with EXPR as VAR:
BLOCK
except EXC:
HANDLER

try:
_mgr = EXPR
_enter = type(_mgr).__enter__
_exit = type(_mgr).__exit__
_value = _enter(_mgr)
_exc = True
except EXC:
HANDLER
else:
try:
VAR = _value
BLOCK
except:
_exc = False
if not _exit(_mgr, *sys.exc_info()):
raise
finally:
if _exc:
_exit(_mgr, None, None, None)

And correspondingly for asynchronous versions "async for" and "async with".

So you will be able to add errors handling like in:

with connect() as stream:
for data in stream:
try:
write(data)
except OSError:
handle_write_error()
except OSError:
handle_read_error()
except OSError:
handle_connection_error()
___
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/M76F3434TXNO2EUMZZ647EABTCNXYGXA/
Code of Conduct: http://python.org/psf/codeofconduct/

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

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

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 you import a symbol from the import dict of another 
module
3. At some future point promote this to an error

In this future re-exporting a symbol might be done with:

from foo import bar
bar = bar

There are other details like being able to programmatically access the import 
dict for example.

I'm +1 on this. 

> On 26 Jul 2019, at 19:43, Serhiy Storchaka  wrote:
> 
> 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.  The names
>> given in ``__all__`` are all considered public and are required to exist.  If
>> ``__all__`` is not defined, the set of public names includes all names found
>> in the module's namespace which do not begin with an underscore character
>> (``'_'``).  ``__all__`` should contain the entire public API. It is intended
>> to avoid accidentally exporting items that are not part of the API (such as
>> library modules which were imported and used within the module).
> 
> As an example of names which should be excluded from the public API the 
> reference mentions names of modules which were imported and used within the 
> module. And they are perhaps the most common cases. It is often imported 
> module names are the only non-underscored names which are imported by a 
> star-import by accident.
> 
> For example, modules re and sys were used in Lib/idlelib/editor.py but there 
> were no imports for them. This worked because they were imported implicitly 
> by `from tkinter import *`. [1]
> 
> There is other case when a module name can be occurred in the module 
> namespace: if it is a submodule. For example:
> 
>   >>> from xml.etree import *
>   >>> ElementTree
>   Traceback (most recent call last):
>   File "", line 1, in 
>   NameError: name 'ElementTree' is not defined
>   >>> ElementPath
>   Traceback (most recent call last):
>   File "", line 1, in 
>   NameError: name 'ElementPath' is not defined
>   >>> import xml.etree.ElementTree
>   >>> from xml.etree import *
>   >>> ElementTree
>'/home/serhiy/py/cpython3.8/Lib/xml/etree/ElementTree.py'>
>   >>> ElementPath
>'/home/serhiy/py/cpython3.8/Lib/xml/etree/ElementPath.py'>
> 
> Names imported by a `from xml.etree import *` are depended on importing a 
> xml.etree's submodule ElementTree. I do not think this is good.
> 
> I propose to change the rule for determining the set of public names if 
> `__all__` is not defined. In addition to underscored names I propose to 
> exclude names of modules.
> 
> In these rare cases where modules should be imported in a star import it is 
> not difficult to introduce `__all__`.
> 
> [1] https://docs.python.org/3/reference/simple_stmts.html#the-import-statement
> [2] https://bugs.python.org/issue29446
> 
> ___
> 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/AKWL7CRCCFACSITAH2NNFBL5BGRKLKJD/
> 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/UPARIKB6LKNCROYUMDZSTP6BFLDOUF5V/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Andrew Barnert via Python-ideas]

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. That’s why #3 is better than #2, beyond the 
watered memory.

Sometimes you want to violate guidelines like that, but in that case it’s 
usually worth explicitly marking that you're doing so. Which you can do easily 
and concisely in today’s Python:

#4
consume(print(item) for item in lst)

This signals that you’re iterating the iterator for side effects, rather than 
to build a value, and it’s nicely concise.

You need to write that consume function (or just borrow it from the itertools 
docs), but it’s a trivial one-liner you can write once, and you can choose 
whether you want clarity:

def consume(it):
for _ in it: pass

… or performance:

def consume(it):
colllections.deque(it, maxlen=0)

___
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/FBDC4PKOO7A3VOW5GY7JFH46ZKTCAASC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Serhiy Storchaka]

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.  The names
given in ``__all__`` are all considered public and are required to exist.  If
``__all__`` is not defined, the set of public names includes all names found
in the module's namespace which do not begin with an underscore character
(``'_'``).  ``__all__`` should contain the entire public API. It is intended
to avoid accidentally exporting items that are not part of the API (such as
library modules which were imported and used within the module).


As an example of names which should be excluded from the public API the 
reference mentions names of modules which were imported and used within 
the module. And they are perhaps the most common cases. It is often 
imported module names are the only non-underscored names which are 
imported by a star-import by accident.


For example, modules re and sys were used in Lib/idlelib/editor.py but 
there were no imports for them. This worked because they were imported 
implicitly by `from tkinter import *`. [1]


There is other case when a module name can be occurred in the module 
namespace: if it is a submodule. For example:


   >>> from xml.etree import *
   >>> ElementTree
   Traceback (most recent call last):
   File "", line 1, in 
   NameError: name 'ElementTree' is not defined
   >>> ElementPath
   Traceback (most recent call last):
   File "", line 1, in 
   NameError: name 'ElementPath' is not defined
   >>> import xml.etree.ElementTree
   >>> from xml.etree import *
   >>> ElementTree
   '/home/serhiy/py/cpython3.8/Lib/xml/etree/ElementTree.py'>

   >>> ElementPath
   '/home/serhiy/py/cpython3.8/Lib/xml/etree/ElementPath.py'>


Names imported by a `from xml.etree import *` are depended on importing 
a xml.etree's submodule ElementTree. I do not think this is good.


I propose to change the rule for determining the set of public names if 
`__all__` is not defined. In addition to underscored names I propose to 
exclude names of modules.


In these rare cases where modules should be imported in a star import it 
is not difficult to introduce `__all__`.


[1] 
https://docs.python.org/3/reference/simple_stmts.html#the-import-statement

[2] https://bugs.python.org/issue29446

___
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/AKWL7CRCCFACSITAH2NNFBL5BGRKLKJD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Ethan Furman]

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@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/LLLBNAM2M5WNCHVCRICEG75K6AWX2DLE/
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: Namespace context managers

[Dan Sommers]

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" machinery
> is at work-- for good or for ill-- when working in your
> class-defined namespace.  so if, for example, you create a
> descriptor and instantiate it inside a class namespace, the
> descriptor __get__ method will be invoked when accessing the
> descriptor via the class name. this could be very limiting in
> certain cases.

Flat is better than nested.  Yes, at some point, flat becomes unweildy,
and you have to do something.  Or not.

Simple is better than complex.  With every one of these nesting
constructs (e.g., comprehensions, classes, functions, methods, modules),
there are possibly subtle scoping and name lookup rules.  For every new
such construct, there are new and possibly subtle such rules.  At some
point, the expressiveness of a language disappears into the noise of
complexity (no, I don't have a citation, just lots of experience).

There Is Only One Way To Do It.  Enough said.

I'm pretty sure I'm not a luddite, but I'm also pretty sure that new
ways to capture ("close over") a value and/or to encapsulate state is a
long way from your father's executable pseudo code.

Yes, at some point, every little throwaway automation script takes on a
life of its own, and you have to make a choice.  Please choose the
simplicity of small reusable building blocks (aka modules full of
functions; or classes full of methods if you must) rather than yet
another way to inline your encapsulation.
___
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/R24IUB5VSCEHF7LRHA4FQXD55N7O2YEJ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Eric V. Smith]

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



To convince a majority of the steering council and 0 core developers to 
make a change, you'd need a hypothetical future steering council with a 
non-core-developer majority.


Even if we stipulate that this would ever happen (which seems 
exceedingly unlikely), presumably that majority would change the policy 
to allow themselves to sponsor PEPs.


(In my opinion if there's even a single steering council member who 
isn't a core developer, they'd probably be able to convince the rest of 
the council to add a special exception allowing them to sponsor PEPs; I 
find it hard to imagine someone being trusted enough to sit on the 
council without the rest of the council thinking they can be trusted to 
sponsor a PEP...)


I agree with all of these points.

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 future.


Just be aware that writing a PEP so that it gets to the accept/reject 
stage can take months of work. At least it has in my case.


What you won't find is someone to sponsor a PEP that says something like 
"remove the GIL", without any details of how to do it. And it's good 
that no one would sponsor that: it's just noise! This is what the "you 
must have a sponsor" rule is trying to prevent. It's not trying to 
prevent well thought out ideas that might not get accepted.


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/OWZSXAD72VYBNVZ63UWGLNGGYBE6VEW4/
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: support toml for pyproject support

[Andrew Barnert via Python-ideas]

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 promises until 1.0 (think YAML 0.9). But different projects use 
version numbers differently. And TOML says:

> As of version 0.5.0, TOML should be considered extremely stable. The goal is 
> for version 1.0.0 to be backwards compatible (as much as humanly possible) 
> with version 0.5.0. All implementations are strongly encouraged to become 
> 0.5.0 compatible so that the transition to 1.0.0 will be simple when that 
> happens.

And that’s been the official word unchanged for over a year now, so they seem 
serious about this.

> Standard library evolves and grows.

But it evolves and grows slowly—not only on an 18-month cycle, but with strict 
rules about backward compatibility, and arguments about any substantial 
improvements. Would you be happy using today’s TOML library, with nothing but 
minor fixes, in 3 years? If not, you shouldn’t want it in the stdlib. Lots of 
libraries that lots of people need still need to evolve rapidly or 
independently. A big reason for working so hard on the pip ecosystem is so 
things like requests or numpy can be there for millions of users without having 
to get pulled into the stdlib to die.

And, even if the packaging tools need it, and can freeze on an existing version 
and a specific subset of functionality, that still isn’t necessarily a reason 
to pull it in. It could be treated like requests: setuptools/pip/ensurepip 
bundle a version of requests internally, while end users can install a newer 
(or a specific) version in site-packages so they aren’t burdened by the release 
cycle. Would that not be appropriate for the way packaging needs TOML?
___
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/5DIT6RK6VTV2THBWNZZ5V4FP6VTKE36S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Ricky Teachey]

>
> 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 not a namespace; the author has
   to tell the reader it isn't actually intended to be a class in the
   docstring or in the class name ("eg, MyNamespace")
   2. using class means that all of the "new style class" machinery is at
   work-- for good or for ill-- when working in your class-defined namespace.
   so if, for example, you create a descriptor and instantiate it inside a
   class namespace, the descriptor __get__ method will be invoked when
   accessing the descriptor via the class name. this could be very limiting in
   certain cases.
___
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/KUFOJ4FK2H76JA5KO3H5AZAY2NYD3P5M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Michael Selik]

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 possible in python
> with a pythonic syntax.
>
> a = 4
> namespace = {}
>
> with namespace:
> a = 3
>
> assert a == 4
> assert namespace["a"] == 3
> ___
> 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/TAVHEKDZVYKJUGZKWSVZVAOGBPLZVKQG/
> 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/SL2VZACTCSYB76BZI5QFP2CE3WSUFXPA/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Geoffrey Spear]

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 PEP is the steering council i just need to convince them not
> core developers.
>

To convince a majority of the steering council and 0 core developers to
make a change, you'd need a hypothetical future steering council with a
non-core-developer majority.

Even if we stipulate that this would ever happen (which seems exceedingly
unlikely), presumably that majority would change the policy to allow
themselves to sponsor PEPs.

(In my opinion if there's even a single steering council member who isn't a
core developer, they'd probably be able to convince the rest of the council
to add a special exception allowing them to sponsor PEPs; I find it hard to
imagine someone being trusted enough to sit on the council without the rest
of the council thinking they can be trusted to sponsor a 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/2V7IIPMNQCKJFXMKZXZQK6WJ4URKDHR4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Batuhan Taskaya]

> 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... 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 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 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/TAVHEKDZVYKJUGZKWSVZVAOGBPLZVKQG/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
>
> CALVIN SPEALMAN
>
> SENIOR QUALITY ENGINEER
>
> cspea...@redhat.com  M: +1.336.210.5107
> [image: https://red.ht/sig] 
> TRIED. TESTED. TRUSTED. 
>
___
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/MMPDY47QNAMBYZITWSBAF3W3ZANPJPED/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Calvin Spealman]

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 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 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/TAVHEKDZVYKJUGZKWSVZVAOGBPLZVKQG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

cspea...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
___
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/WIXNCWAEKSOUP6IY7CPCY6TOUJJSTDOP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Anders Hovmöller]

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"
>> assert ns.func() == 3
>> assert a == 4
>  
> 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 be a new one, def could work just fine:
> 
> def ns:
> a = 3 
> 
> Food goodly or for badly: something like this would allow one to write code 
> similar to how you can in javascript (by simply putting it in curly braces in 
> js), without going to the effort of creating a full fledged class:
> 
> def a:
> x = 1
> def b:  
> x = 2
> def func():
> return x  # prints 1  
> 

This looks pretty nice. Seems like it can be implemented with a subclass of 
dict pretty easily if we change the syntax a bit:

a = ns(
  x=1,
  b=ns(
x=2),
  func=lambda self: self.x)
)

?___
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/KONYW4MWQC42YIREPDHI6HO53PGTUUFH/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Eli Berkowitz]

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
```
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] Re: For-expression/throwaway comprehension

[Paul Moore]

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 expression, just using it as an example)
>
> ```
> lst = [1, 2, 3, 4]
>
> #1
> for item in lst:
> print(item)
>
> # 2
> [print(item) for item in lst]
>
> # 3
> for item in lst: print(item)
> ```
>
> #1 - In my opinion, this should be a one line operation so #1 is not ideal.
> #2 - It also shouldn't require storing results in array, to save time/memory, 
> so #2 is out.
> #3 - I think #3 is just not good syntax, it seems very unpythonic to me - it 
> breaks the norm that blocks go on their own lines. It does seem the best of 
> the three though and I know my assessment is kind of subjective.

#1 and #3 are the same (in terms of statement structure) and I see no
reason to treat them differently. (#2 is significantly different, in
that it retains all the intermediate values, and can only be used for
expressions).

In #1 you say "this should be a one line operation" - but there's no
particular reason why it "should". If it should, then #3 *is* the
appropriate one-line version.
In #3 you say it "is just not good syntax", and yet you said above
that the statement "should" be a one-liner. The only thing that is
"not good" about #3 over #1 is that it's a one-liner...

> I'm wondering if a possible alternative syntax could be a for-expression, 
> like there's if-expressions, which always evaluates to None:
> ```
> print(item) for item in lst
> ```

This seems to me to be no better than #3, and worse in the sense that
it isn't currently valid, whereas #3 is. I think you should simply
accept that #3 is entirely valid and acceptable syntax. I use it
fairly regularly, where appropriate (which isn't often - #1 *is*
typically better - but it's certainly all of the cases where your
proposed new syntax would be useful).

Paul
___
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/T5T7EBL3EKFWZHY2XFRWI3JX25POPOCF/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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
> 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 elements (a, b, c).
>
> But that makes the cartesian product operator non-associative, since
> s1 * (s2 * s3) would be a set of >. I still maintain that
> *in practice* mathematicians ignore the issue and consider that
> ((a, b), c), (a, (b, c)) and (a, b, c) are just different ways of
> writing essentially the same thing.
>
> A programming language *could* be designed with a tuple type for
> which that is literally true, but Python wasn't designed that way.
> And I don't think it's a problem at all. You can easily write a
> comprehension that gives you whatever kind of cartesian product
> you want.
>
> --
> Greg
> ___
> 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/CBXVP365LCLKKZV4FYB57CXSMW376VXW/
> 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/4ZB3KZ5UJZHTVTHZDEYRKFCSR6MSC5Y3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] For-expression/throwaway comprehension

[Eli Berkowitz]

(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 - 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 expression, just using it as an example)

```
lst = [1, 2, 3, 4]

#1 
for item in lst:
print(item)

# 2
[print(item) for item in lst]

# 3
for item in lst: print(item)
```

#1 - In my opinion, this should be a one line operation so #1 is not ideal.
#2 - It also shouldn't require storing results in array, to save time/memory, 
so #2 is out. 
#3 - I think #3 is just not good syntax, it seems very unpythonic to me - it 
breaks the norm that blocks go on their own lines. It does seem the best of the 
three though and I know my assessment is kind of subjective.

I'm wondering if a possible alternative syntax could be a for-expression, like 
there's if-expressions, which always evaluates to None:
```
print(item) for item in lst
```

A more practical example of when this would be useful is extending list-2 with 
a modified version of list-1 - this syntax would avoid creating an intermediate 
list (not sure if the way lists are implemented in python removes this 
advantage by the way it resizes lists though).

```
lst1 = [1, 2, 3]
lst2 = [4, 5, 6]
lst1.append(item * 2) for item in lst1
```
___
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/KMEX5FKXUJYSQ2WAEYLQYNQBOT2LBXCI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Ricky Teachey]

>
> 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 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 be a new one, def could work just fine:

def ns:
a = 3

Food goodly or for badly: something like this would allow one to write code
similar to how you can in javascript (by simply putting it in curly braces
in js), without going to the effort of creating a full fledged class:

def a:
x = 1
def b:
x = 2
def func():
return x  # prints 1

print(a.b.x)  # prints 2

Final observation: I think one shortfall in python is that it nudges the
user to use OOP a little bit too forcefully-- especially inexperienced
users, after learning how to write a class the first time. I remember very
well regretting using classes quite a bit too readily in my first couple
years of coding (on year 6 now), when a module would have done much better.
It's true you CAN create a module object and do all of this, but as a
relatively "non expert user" IMO it is very opaque syntax for someone
getting started.
___
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/6HHDIOYGIYLHQGOVE7UAZRCXLR2HGSWT/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Sardorbek Imomaliev]

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

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. 

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] Re: Cartesian Product on `__mul__`

[Greg Ewing]

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 elements (a, b, c).


But that makes the cartesian product operator non-associative, since
s1 * (s2 * s3) would be a set of >. I still maintain that
*in practice* mathematicians ignore the issue and consider that
((a, b), c), (a, (b, c)) and (a, b, c) are just different ways of
writing essentially the same thing.

A programming language *could* be designed with a tuple type for
which that is literally true, but Python wasn't designed that way.
And I don't think it's a problem at all. You can easily write a
comprehension that gives you whatever kind of cartesian product
you want.

--
Greg
___
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/CBXVP365LCLKKZV4FYB57CXSMW376VXW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Steven D'Aprano]

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 pythonic syntax.
> 
> I don't understand what you mean here. Closures are already possible in 
> Python with a pythonic syntax.

To be clear here, I meant nested functions.

If you mean some other used of closures, can you explain what you mean 
please? Perhaps with an example.


-- 
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/JJOKD2LTALNEYAV2YEZEKOYRMIDHEHV2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Steven D'Aprano]

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 already possible in 
Python with a pythonic syntax.


> a = 4
> namespace = {}
> 
> with namespace:
> a = 3
> 
> assert a == 4
> assert namespace["a"] == 3


I have long wanted namespaces in Python, but I don't like the above. I 
would prefer to see something like this:

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




Our standard namespace is the module, which is great for 
small libraries and scripts. When your needs are greater (too much code 
to comfortably co-exist in a single file), you can use a package.

But when your needs are lower, and a seperate .py file is too 
heavyweight, we don't have anything convenient for a seperate namespace. 
You can build a module object by hand:

from types import ModuleType
ns = ModuleType("ns")
ns.a = 3

def func():
return ns.a

ns.func = func


but it's not pretty code, its not convenient, and closures and name 
lookups don't work or look right. You can use a class instead, but again 
closures don't work right, and it is surprising to use a class object 
without instantiating it.

I think a namespace context manager that created and populated a new 
module (or subclass of module) object would fit this use-case nicely.

Use-case summary:

You have a collection of classes, functions and variables which should 
live together in a namespace, seperate from the rest of your classes 
etc, but you don't want to push them out into a seperate .py file.



-- 
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/YUMYJFTWWGUXPCFUFQV2O5AO4UU53X7Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[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
> with a pythonic syntax.
>
> a = 4
> namespace = {}
>
> with namespace:
> a = 3
>
> assert a == 4
> assert namespace["a"] == 3
>
___
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/GHMOUUC36KREUCQMJ67SRUR7WRTCCF7O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Namespace context managers

[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 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/TAVHEKDZVYKJUGZKWSVZVAOGBPLZVKQG/
Code of Conduct: http://python.org/psf/codeofconduct/