Re: [Python-ideas] a new namedtuple

[Ethan Furman]

On 07/17/2017 05:01 PM, Ethan Furman wrote:


I haven't timed it (I'm hoping somebody will volunteer to be the bench mark 
guru), I'll offer my NamedTuple
implementation from my aenum [1] library.  It uses the same metaclass 
techniques as Enum, and offers doc string and
default value support in the class-based form.


Oh, and to be clear, there are some other nice-to-have and/or neat features (such as variable-sized NamedTuples), that I 
would expect to be trimmed from a stdlib version.


--
~Ethan~

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

[Python-ideas] a new namedtuple

[Ethan Furman]

Guido has decreed that namedtuple shall be reimplemented with speed in mind.

I haven't timed it (I'm hoping somebody will volunteer to be the bench mark guru), I'll offer my NamedTuple 
implementation from my aenum [1] library.  It uses the same metaclass techniques as Enum, and offers doc string and 
default value support in the class-based form.


--
~Ethan~


[1] https://pypi.python.org/pypi/aenum/1.4.5
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A suggestion for a do...while loop

[Ethan Furman]

On 06/26/2017 01:20 PM, Mikhail V wrote:


I dont't like "while True:"  simply because it does not make enough
visual distinction with the "while condition:" statement.


My "while True:" loops look something like:

  while "":

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

Re: [Python-ideas] the error that raises an AttributeError should be passed to __getattr__

[Ethan Furman]

On 06/19/2017 07:26 PM, Steven D'Aprano wrote:


Or maybe we decide that it's actually a feature, not a problem, for an
AttributeError inside self.attr.__get__ to look like self.attr is
missing.


It's a feature.  It's why Enum classes can have members named 'value' and 
'name'.

--
~Ethan~

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

Re: [Python-ideas] the error that raises an AttributeError should be passed to __getattr__

[Ethan Furman]

On 06/19/2017 06:31 PM, Chris Angelico wrote:

On Tue, Jun 20, 2017 at 10:18 AM, Steven D'Aprano  wrote:

Having said that, there's another problem: adding this feature (whatever
it actually is) to __getattr__ will break every existing class that uses
__getattr__. The problem is that everyone who writes a __getattr__
method writes it like this:

 def __getattr__(self, name):

not:

 def __getattr__(self, name, error):

so the class will break when the method receives two arguments
(excluding self) but only has one parameter.


Why not just write cross-version-compatible code as

def __getattr__(self, name, error=None):

? Is there something special about getattr?


The point was existing code would fail until that change was made.  And a lot 
of existing code uses __getattr__.

--
~Ethan~

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

Re: [Python-ideas] Define __fspath__() for NamedTemporaryFile and TemporaryDirectory

[Ethan Furman]

On 06/16/2017 01:37 PM, Alexandre Brault wrote:


So a  if used directly, and a  if used as a
context manager.  I don't have a copy of 3.6 nor the future 3.7 handy,
so maybe it changed there?


The code in master has the context manager return `self.name`. This
behaviour has (based on looking at the 3.2 tag where TemporaryDirectory
was added) always been used.


It is an often overlooked fact that a context manager is free to return anything, not just itself.  So 
TemporaryDirectory can create the folder, return the name of the folder, and remove the folder on exit.  So no need for 
the "extract the name from the object" dance.  Interestingly enough, that is what the docs say [1].


Pretty cool.

--
~Ethan~

[1] https://docs.python.org/3/library/tempfile.html#tempfile.TemporaryDirectory
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Restore the __members__ behavior to python3 for C extension writers

[Ethan Furman]

On 06/14/2017 01:54 PM, Barry Scott wrote:


super().__dir__ looks at the class above me that is typically object() and so 
is not useful
as it does not list the member function from my class or __mro__ or other stuff 
I may not be aware of
that is important to return.


__dir__ should return whatever you think is interesting about your object.  It does not have to return everything, and 
in fact makes no guarantees that it will return everything.  Enum's __dir__, for example, only returns a handful of entries.


--
~Ethan~

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

Re: [Python-ideas] Define __fspath__() for NamedTemporaryFile and TemporaryDirectory

[Ethan Furman]

On 06/08/2017 12:22 PM, Brett Cannon wrote:


Already exists, been discussed, and rejected: 
https://bugs.python.org/issue29447 .


Ah, right, because the returned object is not a file path.  Makes sense.

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

Re: [Python-ideas] Define __fspath__() for NamedTemporaryFile and TemporaryDirectory

[Ethan Furman]

On 06/08/2017 06:42 AM, Antoine Pietri wrote:

Hello everyone!

A very common pattern when dealing with temporary files is code like this:

 with tempfile.TemporaryDirectory() as tmpdir:
 tmp_path = tmpdir.name

 os.chmod(tmp_path)
 os.foobar(tmp_path)
 open(tmp_path).read(barquux)

PEP 519 (https://www.python.org/dev/peps/pep-0519/) introduced the
concept of "path-like objects", objects that define a __fspath__()
method. Most of the standard library has been adapted so that the
functions accept path-like objects.

My proposal is to define __fspath__() for TemporaryDirectory and
NamedTemporaryFile so that we can pass those directly to the library
functions instead of having to use the .name attribute explicitely.

Thoughts? :-)


Good idea.  Check bugs.python.org to see if there is already an issue for this, 
and if not create one! :)

--
~Ethan~

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

Re: [Python-ideas] Allow function to return multiple values

[Ethan Furman]

On 06/01/2017 07:17 AM, joannah nanjekye wrote:


Today I was writing an example snippet for the book and needed to write a 
function that returns two values something
like this:

def return_multiplevalues(num1, num2):
  return num1, num2

  I noticed that this actually returns a tuple of the values which I did not 
want in the first place.I wanted python to
return two values in their own types so I can work with them as they are but 
here I was stuck with working around a tuple.


If you had a function that returned two values, how would you assign them?  
Maybe something like:

  var1, var2 = return_multiplevalues(num1, num2)

?

That is exactly how Python works.


I will appreciate discussing this. You may also bring to light any current way 
of returning multiple values from a
function that I may not know of in python if there is.


While I am somewhat alarmed that you don't know this already after four years of Python programming, I greatly 
appreciate you taking the time to find out.  Thank you.


--
~Ethan~

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

Re: [Python-ideas] [semi-OT] NamedTuple from aenum library [was: JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)]

[Ethan Furman]

On 05/17/2017 02:06 PM, Ethan Furman wrote:


You might want to check out the NamedTuple class from my aenum [1]
library


[1] https://pypi.python.org/pypi/aenum

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

[Python-ideas] [semi-OT] NamedTuple from aenum library [was: JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)]

[Ethan Furman]

On 05/17/2017 10:43 AM, Ivan Levkivskyi wrote:

On 17 May 2017 at 19:40, Juancarlo Añez wrote:

On Wed, May 17, 2017 at 12:48 PM, Ivan Levkivskyi wrote:



class Foo(NamedTuple):
 """Foo is a very important class and
 you should totally use it.
 """
 bar: int
 baz: int = 0

 def grand_total(self):
 return self.bar + self.baz


Really?!

I didn't know that idiom existed.

It is enough for many use cases, and I was just about to require
typing and pathlib on my 2.7-compatible projects.


Unfortunately, this works _only_ in Python 3.6+.


You might want to check out the NamedTuple class from my aenum [1] 
library -- it is metaclass based (no execing), supports defaults, 
doc-strings, and other fun and possibly useful things.


Here's the NamedTuple section from the docs:


Creating NamedTuples


Simple
^^

The most common way to create a new NamedTuple will be via the functional API::

>>> from aenum import NamedTuple
>>> Book = NamedTuple('Book', 'title author genre', module=__name__)

This creates a ``NamedTuple`` called ``Book`` that will always contain three
items, each of which is also addressable as ``title``, ``author``, or ``genre``.

``Book`` instances can be created using positional or keyword argements or a
mixture of the two::

>>> b1 = Book('Lord of the Rings', 'J.R.R. Tolkien', 'fantasy')
>>> b2 = Book(title='Jhereg', author='Steven Brust', genre='fantasy')
>>> b3 = Book('Empire', 'Orson Scott Card', genre='scifi')

If too few or too many arguments are used a ``TypeError`` will be raised::

>>> b4 = Book('Hidden Empire')
Traceback (most recent call last):
...
TypeError: values not provided for field(s): author, genre
>>> b5 = Book(genre='business')
Traceback (most recent call last):
...
TypeError: values not provided for field(s): title, author

As a ``class`` the above ``Book`` ``NamedTuple`` would look like::

>>> class Book(NamedTuple):
... title = 0
... author = 1
... genre = 2
...

For compatibility with the stdlib ``namedtuple``, NamedTuple also has the
``_asdict``, ``_make``, and ``_replace`` methods, and the ``_fields``
attribute, which all function similarly::

>>> class Point(NamedTuple):
... x = 0, 'horizontal coordinate', 1
... y = 1, 'vertical coordinate', -1
...
>>> class Color(NamedTuple):
... r = 0, 'red component', 11
... g = 1, 'green component', 29
... b = 2, 'blue component', 37
...
>>> Pixel = NamedTuple('Pixel', Point+Color, module=__name__)
>>> pixel = Pixel(99, -101, 255, 128, 0)

>>> pixel._asdict()
OrderedDict([('x', 99), ('y', -101), ('r', 255), ('g', 128), ('b', 0)])

>>> Point._make((4, 5))
Point(x=4, y=5)

>>> purple = Color(127, 0, 127)
>>> mid_gray = purple._replace(g=127)
>>> mid_gray
Color(r=127, g=127, b=127)

>>> pixel._fields
['x', 'y', 'r', 'g', 'b']

>>> Pixel._fields
['x', 'y', 'r', 'g', 'b']


Advanced


The simple method of creating ``NamedTuples`` requires always specifying all
possible arguments when creating instances; failure to do so will raise
exceptions::

>>> class Point(NamedTuple):
... x = 0
... y = 1
...
>>> Point()
Traceback (most recent call last):
...
TypeError: values not provided for field(s): x, y
>>> Point(1)
Traceback (most recent call last):
...
TypeError: values not provided for field(s): y
>>> Point(y=2)
Traceback (most recent call last):
...
TypeError: values not provided for field(s): x

However, it is possible to specify both docstrings and default values when
creating a ``NamedTuple`` using the class method::

>>> class Point(NamedTuple):
... x = 0, 'horizontal coordinate', 0
... y = 1, 'vertical coordinate', 0
...
>>> Point()
Point(x=0, y=0)
>>> Point(1)
Point(x=1, y=0)
>>> Point(y=2)
Point(x=0, y=2)

It is also possible to create ``NamedTuples`` that only have named attributes
for certain fields; any fields without names can still be accessed by index::

>>> class Person(NamedTuple):
... fullname = 2
... phone = 5
...
>>> p = Person('Ethan', 'Furman', 'Ethan Furman',
...'ethan at stoneleaf dot us',
...'ethan.furman', '999.555.1212')
>>> p
Person('Ethan', 'Furman', 'Ethan Furman', 'ethan at stoneleaf dot us',
   'ethan.furman', '999.555.1212')
>>> p.fullname
'Ethan Furman'
>>> p.phone
'999.555.1212'
>>> p[0]
'Ethan'

In the

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Ethan Furman]

On 05/17/2017 06:20 AM, Stephan Houben wrote:


class MyClass:
foo = attr.ib()

MyClass = attr.s(MyClass)


Given that one of Python's great strengths is its readability, I would 
not use the attr library in teaching because it is not.  Having a dot in 
the middle of words is confusing, especially when you don't already have 
a basis for which abbreviations are common.  Is it attr.ib or att.rib or 
at.trib?


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

Re: [Python-ideas] Add an option for delimiters in bytes.hex()

[Ethan Furman]

On 05/01/2017 07:04 AM, Juancarlo Añez wrote:

On Mon, May 1, 2017 at 9:38 AM, Nick Coghlan wrote:


just support two
keyword arguments to hex(): "delimiter" (as you suggest) and
"chunk_size" (defaulting to 1, so you get per-byte chunking by
default)


I'd expect "chunk_size"  to mean the number of hex digits (not bytes) per chunk.


I was also surprised by that.  Also, should Python be used on a machine with, say, 24-bit words then a chunk size of 
three makes more sense that one of 1.5.  ;)


--
~Ethan~

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

Re: [Python-ideas] Callable Enum values

[Ethan Furman]

On 04/21/2017 09:04 AM, Stephan Hoyer wrote:

On Thu, Apr 20, 2017 at 10:58 AM, Ethan Furman wrote:



I'm curious, what did you find ugly with:

 class TestEnum(CallableEnum):

  @enum
  def hello(text):
  "a pleasant greeting"
  print('hello,', text)

  @enum
  def goodbye(text):
  print('goodbye,', text)

Yeah, this is actually pretty reasonable.

For my use case, both the functions and their names are pretty long, so I 
wouldn't want to write them inside the enum
class. With a decorator/function wrapper, it just gets kind of long -- 
especially if I only import modules as required
<https://google.github.io/styleguide/pyguide.html?showone=Imports#Imports> by 
the Google style guide. So my real usage
looks more like:

class Greeting(callable_enum.Enum):
 HELLO = callable_enum.Value(_greet_hello)
 GOODBYE = callable_enum.Value(_greet_goodbye)
 TO_PYTHON_IDEAS =callable_enum.Value(_welcome_to_python_ideas)

The large callable_enum.Value() wrappers make it harder to track what's going 
on.


You have to use the complete module name?  Instead of `from callable_enum 
import Enum, Value`?  Ouch.

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

Re: [Python-ideas] Callable Enum values

[Ethan Furman]

[redirecting back to the list]

On 04/19/2017 11:15 PM, Stephan Hoyer wrote:

Ethan and Steven,

Thanks for your feedback on this one. I agree that it probably doesn't make 
sense for the standard library.

I'm still not really happy with any of the standard approaches for choosing a 
function based on an enum value -- they
all seem pretty verbose/ugly -- but clearly I'm bothered by this more than 
most, and the standard library is not a good
place for novel solutions.


I'm curious, what did you find ugly with:

class TestEnum(CallableEnum):

 @enum
 def hello(text):
 "a pleasant greeting"
 print('hello,', text)

 @enum
 def goodbye(text):
 print('goodbye,', text)

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

Re: [Python-ideas] Callable Enum values

[Ethan Furman]

On 04/16/2017 01:24 AM, Steven D'Aprano wrote:

On Fri, Apr 14, 2017 at 06:06:29PM -0700, Stephan Hoyer wrote:



One way that I've found myself using enums recently is for dispatching (as
keys in a dictionary) between different interchangeable functions or
classes.


[...]


Given that wanting to use a function as the enumeration value is quite
unusual in the first place, I don't think this belongs in the standard
library.


I agree with D'Aprano: such unusual usage does not belong in the stdlib.

Fortunately, there is the Advanced Enumeration (aenum) library*:

--- 8< -
from aenum import Enum, enum

class CallableEnum(Enum):

def __new__(cls, *args, **kwds):
member = object.__new__(cls)
member._impl = args[0]
if member._impl.__doc__ is not None:
member._value_ = member._impl.__doc__
else:
member._value_ = repr(member._impl)
return member

def __call__(self, *args, **kwds):
return self._impl(*args, **kwds)
--- 8< -

and in use

--- 8< -
class TestEnum(CallableEnum):

@enum
def hello(text):
"a pleasant greeting"
print('hello,', text)

@enum
def goodbye(text):
print('goodbye,', text)

list(TestEnum)
# [
#  ,
#  '>,
# ]

print(TestEnum.hello)
# TestEnum.hello

TestEnum.hello('how are you?')
# 'hello, how are you?'

TestEnum.goodbye('see you soon!')
# 'goodbye, see you soon!'
--- 8< -

Note that it is possible to do the same thing using the stdlib Enum if 
you create your own decorator (it must return a class instance) and a 
slight rewrite of __new__ -- but I'll leave that as an exercise for the 
reader.


--
~Ethan~


* Disclosure:  I am the primary author of the stdlib Enum; I am also the 
author if the enum34 backport and the aenum library.


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

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

[Ethan Furman]

On 03/27/2017 08:04 AM, Steven D'Aprano wrote:

On Mon, Mar 27, 2017 at 02:50:38PM +0200, Ram Rachum wrote:



What do you think about adding methods pathlib.Path.write_json and
pathlib.Path.read_json , similar to write_text, write_bytes, read_text,
read_bytes?


That's not pathlib's responsibility, and there is nothing wrong with
writing two lines of code.


+1

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

Re: [Python-ideas] Proposal: making __str__ count in time's class

[Ethan Furman]

On 03/08/2017 08:01 AM, Francesco Franchina wrote:


Before expressing my thought and proposal, I want to make sure we all agree on 
a simple and clear fact:
the __str__ magic method is used to give a literal and human-readable 
representation to the object (unlike __repr__).


If __str__ has not been defined, then __repr__ is used instead.


time.struct_time(tm_year=2017, tm_mon=3, tm_mday=8, tm_hour=16, tm_min=6, 
tm_sec=16, tm_wday=2, tm_yday=67, tm_isdst=0)


Which is what that looks like.

--
~Ethan~

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

Re: [Python-ideas] get() method for list and tuples

[Ethan Furman]

On 03/05/2017 11:13 AM, Ed Kellett wrote:

I'm not trying to get anyone to implement list.get, I'm trying to get it 
centrally

> documented and allowed into list's overly-mappingproxied namespace.

--> dir(list)
# non dunder methods
'append', 'clear', 'copy', 'count', 'extend', 'index', 'insert', 'pop', 
'remove', 'reverse', 'sort'

--> dir(dict)
# non dunder methods
'clear', 'copy', 'fromkeys', 'get', 'items', 'keys', 'pop', 'popitem', 
'setdefault', 'update', 'values'

I will admit I'm not entirely sure what you meant with that last statement, but it sounds like you think `list` has a 
bunch of the same methods as `dict` does.  I count 11 methods on dict, 11 methods on list, and only 3 methods that are 
shared (1 of which doesn't work precisely the same on both).


So I'm not seeing a bunch of similarity between the two.

And I'm not seeing any progress here in this discussion, so I'm dropping out 
now.

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

Re: [Python-ideas] get() method for list and tuples

[Ethan Furman]

On 03/03/2017 10:48 AM, Sven R. Kunze wrote:

On 03.03.2017 18:06, Ethan Furman wrote:

On 03/02/2017 12:36 PM, Sven R. Kunze wrote:



It then would make sense to remove .get() on dicts.  ;-)

and to remove parameter "default" of max().
and to remove parameter "default" of getattr().


Backwards compatibility, and performance, says no.  ;)

try/except expressions are not a silver bullet any more than try/except blocks. 
 But they can still be very useful.


Totally true. I think both proposals have their merit.

IIRC, Guido rightfully declared that try/except expressions aren't a good idea. 
It's better to find more concrete
patterns instead of it. And I still agree with him.

The "default parameter" pattern is such a pattern, and it's vastly used in the 
stdlib.



$ grep "def get(" *.py */*.py */*/*.py

queue.py:def get(self, block=True, timeout=None):
pickle.py:def get(self, i):
shelve.py:def get(self, key, default=None):
doctest.py:def get(self):
mailbox.py:def get(self, key, default=None):
weakref.py:def get(self, key, default=None):
weakref.py:def get(self, key, default=None):
sre_parse.py:def get(self):
webbrowser.py:def get(using=None):
tkinter/ttk.py:def get(self, x=None, y=None):
configparser.py:def get(self, section, option, *, raw=False, vars=None, 
fallback=_UNSET):
configparser.py:def get(self, option, fallback=None, *, raw=False, 
vars=None, _impl=None, **kwargs):
email/message.py:def get(self, name, failobj=None):
asyncio/queues.py:def get(self):
logging/config.py:def get(self, key, default=None):
idlelib/pyparse.py:def get(self, key, default=None):
wsgiref/headers.py:def get(self,name,default=None):
xml/dom/minidom.py:def get(self, name, value=None):
_collections_abc.py:def get(self, key, default=None):
tkinter/__init__.py:def get(self):
tkinter/__init__.py:def get(self):
tkinter/__init__.py:def get(self):
tkinter/__init__.py:def get(self):
tkinter/__init__.py:def get(self):
tkinter/__init__.py:def get(self):
tkinter/__init__.py:def get(self, first, last=None):
tkinter/__init__.py:def get(self):
tkinter/__init__.py:def get(self):
tkinter/__init__.py:def get(self, index1, index2=None):
tkinter/__init__.py:def get(self, x, y):
tkinter/__init__.py:def get(self):
xml/sax/xmlreader.py:def get(self, name, alternative=None):
collections/__init__.py:def get(self, key, default=None):
idlelib/scrolledlist.py:def get(self, index):
idlelib/searchengine.py:def get(root):
multiprocessing/pool.py:def get(self, timeout=None):
xml/etree/ElementTree.py:def get(self, key, default=None):
multiprocessing/queues.py:def get(self, block=True, timeout=None):
multiprocessing/queues.py:def get(self):
multiprocessing/managers.py:def get(self):
multiprocessing/managers.py:def get(self):
idlelib/idle_test/mock_tk.py:def get(self):
idlelib/idle_test/mock_tk.py:def get(self, index1, index2=None):

I wouldn't consider 10 out of 43 "vastly" (11 out of 46 if one includes dict, list, and tuple).  The numbers are even 
worse if one considers the "get_something_or_other" methods which do not have a default parameter.


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

Re: [Python-ideas] For/in/as syntax

[Ethan Furman]

On 03/03/2017 01:14 AM, Brice PARENT wrote:


Sorry for the very long message, I hope it will get your interest. And I also
hope my English was clear enough.


Long messages that explain the idea are welcome!

I think it looks interesting.

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

Re: [Python-ideas] For/in/as syntax

[Ethan Furman]

On 03/03/2017 08:21 AM, Matthias Bussonnier wrote:


##
# forloop.break(), to break out of nested loops (or explicitly out of
current
#loop) - a little like pep-3136's first proposal

has_dog_named_rex = False
for owner in owners:
 for dog in dogs:
 if dog.name == "Rex":
 has_dog_named_rex = True
 break

 if has_dog_named_rex:
 break

# would be equivalent to

for owner in owners as owners_loop:
 for dog in dogs:  # syntax without "as" is off course still supported
 if dog.name == "Rex":
 owners_loop.break()


See my above proposal, you would still need to break the inner loop
here as well. So i'm guessing you miss a `break` afrer owner_loop.break() ?


No, he's not -- part of implementing this change includes not needing to 
specify the inner breaks.

--
~Ethan~

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

Re: [Python-ideas] get() method for list and tuples

[Ethan Furman]

On 03/02/2017 12:36 PM, Sven R. Kunze wrote:

On 01.03.2017 06:34, Ethan Furman wrote:



On the bright side, if enough use-cases of this type come up (pesky try/except 
for a simple situation), we may be able
to get Guido to reconsider PEP 463.  I certainly think PEP 463 makes a lot more 
sense that adding list.get().


It then would make sense to remove .get() on dicts.  ;-)

and to remove parameter "default" of max().
and to remove parameter "default" of getattr().


Backwards compatibility, and performance, says no.  ;)

try/except expressions are not a silver bullet any more than try/except blocks. 
 But they can still be very useful.

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

Re: [Python-ideas] get() method for list and tuples

[Ethan Furman]

On 03/03/2017 08:09 AM, Ed Kellett wrote:


P.S. all the talk of PEP 463 seems misplaced. That it solves (FSVO solve) this 
problem doesn't mean it should supersede
this discussion.


The advantage of PEP 463 is that issues like this would be less pressing, and 
it's much more general purpose.

Personally, I don't think `get` belongs on list/tuple for reasons already 
stated.

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

Re: [Python-ideas] Optional parameters without default value

[Ethan Furman]

On 03/03/2017 06:29 AM, Victor Stinner wrote:


An alternative for generated signature of multiple optional arguments
is "bytearray([source[, encoding[, errors]]])", but I'm not a big fan
of nested [...],


But that's not the same thing.

  bytearry([source,] [encoding,] [errors])

says that each argument can be passed without passing any others.

  bytearray([source [, encoding [,errors]]])

says that in order to pass encoding, source must also be specified.

At least, that's what it says to me.

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

Re: [Python-ideas] add __contains__ into the "type" object

[Ethan Furman]

-1.

It is already possible to specify what

  inst in cls

means by using a metaclass.  For example:

  class Color(enum.Enum):
 RED = 1
 GREEN = 2
 BLUE = 3

  some_var = Color.GREEN
  some_var in Color  # True
  some_var in enum.Enum  # False

Containment != isinstance()

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

Re: [Python-ideas] Positional-only parameters

[Ethan Furman]

On 03/01/2017 11:41 PM, Stephan Houben wrote:


I have a slight variant of the decorator proposal.
Rather than specify a count, let the decorator implement the typeshed dunder 
convention:

@positional_only
 def replace(self, __old, __new, count=-1):

(I imagine this decorator would also treat "self" as position_only,
so no need for __self.)

Pros:
1. Consistent with the typeshed convention.


Only a pro if you like that convention.  ;)


2. Avoids a count.
3. Strictly opt-in, so hopefully keeps those @#?! underscore preservationists 
from picketing my lawn (again!).


Using a decorator is also strictly opt-in.

Oh, and did someone say it was time for the protest?

[--]   [--]
[  ]   [  ]
[ NO MORE UNDERSCORES! ]   [ NO MORE UNDERSCORES! ]
[  ]   [  ]
[--]   [--]
  | | | |
  | | | |
  | | | |
  | | | |
  |-| |-|

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

Re: [Python-ideas] Positional-only parameters

[Ethan Furman]

On 03/01/2017 11:53 AM, Guido van Rossum wrote:


FWIW in typeshed we've started using double leading underscore as a convention 
for positional-only parameters, e.g. here:

https://github.com/python/typeshed/blob/master/stdlib/3/builtins.pyi#L936


I would much rather have a single '/' to denote where positional-only ends, 
than have multiple leading '__'.

Newest-member-of-the-society-for-the-preservation-of-underscores-ly yrs,
--
~Ethan~

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

Re: [Python-ideas] for/except/else

[Ethan Furman]

On 03/01/2017 01:37 AM, Wolfgang Maier wrote:


Now here's the proposal: allow an except (or except break) clause to follow 
for/while loops that will be executed if the
loop was terminated by a break statement.


I find the proposal interesting.  More importantly, the proposal is well 
written and clear -- thank you!

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

Re: [Python-ideas] get() method for list and tuples

[Ethan Furman]

On 02/28/2017 05:18 PM, Michel Desmoulin wrote:


I love this proposal but Guido rejected it. Fighting for it right now
would probably be detrimental to the current proposed feature which
could potentially be more easily accepted.


PEP 463 has a better chance of being accepted than this one does, for reasons 
that D'Aprano succinctly summarized.

--
~Ethan~

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

Re: [Python-ideas] Positional-only parameters

[Ethan Furman]

https://www.python.org/dev/peps/pep-0457/

https://mail.python.org/pipermail/python-dev/2014-January/131865.html

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

Re: [Python-ideas] Fwd: Define a method or function attribute outside of a class with the dot operator

[Ethan Furman]

On 02/10/2017 10:48 AM, Nick Timkovich wrote:


If everything was contained right in the same file, this is sanctioning
 another way to do it (when there should only be one obvious way).


No worries, this way is not obvious.


 If you have multiple modules/packages, horrors can evolve where a class
 method could be patched in an unknown location by any loaded module (or
 you could even introduce order-of-import sensitivities).


Folks can still do that nightmare right now.

I'm -0.5 on it -- I don't think the payoff is worth the pain.

But I'm +1 on writing a PEP -- collect all these pros and cons in one place to 
save on future discussion.  (And (good) PEP writing is a way to earn valuable 
Python Points!)

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

Re: [Python-ideas] A more readable way to nest functions

[Ethan Furman]

On 01/27/2017 01:07 PM, Brent Brinkley wrote:


I’m relatively new to the world of python


Welcome!


 but in my short time here I’ve
 fallen in love with how readable this language is. One issue that I’ve
 seen in a lot of languages struggle with is nested function calls.
 Parenthesis when nested inherently create readability issues. I stumbled
 upon what I believe is an elegant solution within the elm platform in
 their use of the backward pipe operator <|.


Please use text -- it save responders from having to reenter the non-text 
content>


Suggested structure:

  print() <| some_func() <| another_func("Hello")


My first question is what does this look like when print() and some_func() have 
other parameters?  In other words, what would this look like?

print('hello', name, some_func('whatsit', another_func('good-bye')), sep=' 
.-. ')

Currently, I would format that as:

   print(
'hello',
name,
some_func(
 'whatsit',
 another_func(
 'good-bye')
 ),
  ),
sep=' .-. ',
)

Okay, maybe a few more new-lines than such a short example requires, but that's 
the idea.

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

Re: [Python-ideas] globals should accept parenteses for extending beyond 1 line

[Ethan Furman]

On 01/23/2017 01:18 PM, João Matos wrote:


Why should I repeat global if I can use the line separation character \
 (like I mentioned on my 1st email) or parentheses as I suggested?


Because prefixing each line with global is more readable than either \ or ( )?  
At least to me.  ;)

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

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

[Ethan Furman]

On 01/23/2017 05:33 AM, Soni L. wrote:


It's literally sugar for repeating the name and moving the dot to the right.
 I think it's clearer than most other compound operators in that it doesn't
 affect precedence rules.

`x += y`, for any code `y`, is equivalent to `x = x + (y)`, not `x = x + y`.

`x .= y`, for any code `y`, is equivalent to `x = x . y`, not `x = x . (y)`.


This is not an improvement.

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

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

[Ethan Furman]

On 01/22/2017 03:30 PM, Soni L. wrote:

On 22/01/17 08:54 PM, Serhiy Storchaka wrote:

On 23.01.17 00:45, Soni L. wrote:



I've been thinking of an Immutable Builder pattern and an operator to go
with it. Since the builder would be immutable, this wouldn't work:

long_name = mkbuilder()
long_name.seta(a)
long_name.setb(b)
y = long_name.build()


I think the more pythonic way is:

y = build(a=a, b=b)

A Builder pattern is less used in Python due to the support of keyword 
arguments.


I guess you could do something like this, for an IRC bot builder:

fnircbotbuilder = mkircbotbuilder(network="irc.freenode.net", port=6697, 
ssl=true)
mainbot = mkircbotbuilder(parent=fnircbotbuilder,  # ???
   channels=["#bots"]).build()
fndccbotbuilder = mkircbotbuilder(parent=fnircbotbuilder, dcc=true, 
channeldcc=true)
dccbot = mkircbotbuilder(parent=fndccbotbuilder, channels=["#ctcp-s"]).build()
otherircbotbuilder = mkircbotbuilder(parent=fndccbotbuilder, 
network="irc.subluminal.net")  # because we want this whole network
otherbot = mkircbotbuilder(parent=otherircbotbuilder, 
channels=["#programming"]).build()# to use DCC and channel DCC


The following is just fine:

   fnircbotbuilder = mkircbotbuilder(
network="irc.freenode.net",
port=6697,
ssl=true,
)
mainbot = fnircbotbuilder(channels=["#bots"]).build()

fndccbotbuilder = fnircbotbuilder(dcc=true, channeldcc=true)
dccbot = fndccbotbuilder(channels=["#ctcp-s"]).build()

otherircbotbuilder = fndccbotbuilder(network="irc.subluminal.net")
otherbot = otherircbotbuilder(channels=["#programming"]).build()

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

Re: [Python-ideas] [PEP-0541] On issues with reclaiming namespaces in PyPi

[Ethan Furman]

On 01/15/2017 08:40 AM, Chris Rose wrote:


I want to address one gap in the PEP regarding reclaiming abandoned names.


This should be on the DistUtils sig where the PEP is being discussed.

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

Re: [Python-ideas] How to respond to trolling (Guido van Rossum)

[Ethan Furman]

On 01/12/2017 03:21 PM, Random832 wrote:


Just out of curiosity... in your estimation, what is a "wart", and why
is the term "wart" used for it? I mean, this is an accepted term that
the Python community uses to refer to things [...]


I do not see any difference between calling something a "wart" and calling something 
"ugly".

The sticking point in this case is highlighted by your statement, "an accepted term 
*by the Python community*" [emphasis added].

In other words, it is equally offensive for a stranger to come in and start 
branding this or that as warts as it is for that same stranger to come in and 
start declaring this or that as ugly.

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

Re: [Python-ideas] api suggestions for the cProfile module

[Ethan Furman]

On 01/10/2017 08:36 AM, Thane Brimhall wrote:


Does anyone have thoughts on this topic? I assume the silence is because
 this suggestion is too trivial to matter.


Sometimes it's just a matter of timing.  :)


I use cProfile a lot, and would like to suggest three backwards-compatible
 improvements to the API.

1: When using cProfile on a specific piece of code I often use the
 enable() and disable() methods. It occurred to me that this would
 be an obvious place to use a context manager.


Absolutely.


2: Enhance the `print_stats` method on Profile to accept more options
 currently available only through the pstats.Stats class. For example,
 strip_dirs could be a boolean argument, and limit could accept an int.
 This would reduce the number of cases you'd need to use the more complex
 API.


I don't have much experience with cProfile, but this seems reasonable.


3: I often forget which string keys are available for sorting. It would
 be nice to add an enum for these so a user could have their linter and
 IDE check that value pre-runtime. Since it would subclass `str` and
 `Enum` it would still work with all currently existing code.


Absolutely!  :)


The current documentation contains the following code:

import cProfile, pstats, io
pr = cProfile.Profile()
pr.enable()
# ... do something ...
pr.disable()
s = io.StringIO()
sortby = 'cumulative'
ps = pstats.Stats(pr, stream=s).sort_stats(sortby)
ps.print_stats()
print(s.getvalue())

While the code below doesn't exactly match the functionality above (eg. not
 using StringIO), I envision the context manager working like this, along
 with some adjustments on how to get the stats from the profiler:

import cProfile, pstats
with cProfile.Profile() as pr:
 # ... do something ...
 pr.print_stats(sort=pstats.Sort.cumulative, limit=10, strip_dirs=True)

As you can see, the code is shorter and somewhat more self-documenting. The
 best thing about these suggestions is that as far as I can tell they would
 be backwards-compatible API additions.


The `pr.print_stats... line should not be inside the `with` block unless you 
want to profile that part as well.

These suggestions seem fairly uncontroversial.  Have you opened an issue on the 
issue tracker?

The fun part of the patch will be the C code, but a Python proof-of-concept 
would be useful.

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

Re: [Python-ideas] Python Reviewed

[Ethan Furman]

On 01/09/2017 09:18 PM, Simon Lovell wrote:

[snip]

This is not the place for this conversation.  Please take it to Python List.

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

Re: [Python-ideas] incremental hashing in __hash__

[Ethan Furman]

On 12/30/2016 06:47 PM, j...@math.brown.edu wrote:


__eq__ only has to be called when a hash bucket is non-empty. In that case,
 it may be O(n) in pathological cases, but it could also be O(1) every time.
 On the other hand, __hash__ has to be called on every lookup, is O(n) on
 the first call, and ideally O(1) after. I'd expect that __eq__ may often
 not dominate, and avoiding an unnecessary large tuple allocation on the
 first __hash__ call could be helpful. If a __hash__ implementation can
 avoid creating an arbitrarily large tuple unnecessarily and still perform
 well, why not save the space? If the resulting hash distribution is worse,
 that's another story, but it seems worth documenting one way or the other,
 since the current docs give memory-conscious Python programmers pause for
 this use case.


A quick list of what we have agreed on:

- __hash__ is called once for every dict/set lookup
- __hash__ is calculated once because we are caching the value
- __eq__ is being called an unknown number of times, but can be quite
  expensive in terms of time
- items with the same hash are probably cheap in terms of __eq__ (?)

So maybe this will work?

def __hash__(self):
return hash(self.name) * hash(self.nick) * hash(self.color)

In other words, don't create a new tuple, just use the ones you already have 
and toss in a couple maths operations.  (and have somebody vet that ;)

--
~Ethan~

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

Re: [Python-ideas] incremental hashing in __hash__

[Ethan Furman]

On 12/30/2016 06:12 PM, j...@math.brown.edu wrote:


... your point stands that Python had to call __eq__ in these cases.

But with instances of large, immutable, ordered collections, an
 application could either:

1. accept that it might create a duplicate, equivalent instance of
 an existing instance with sufficient infrequency that it's okay
 taking the performance hit, or

2. try to avoid creating duplicate instances in the first place,
 using the existing, equivalent instance it created as a singleton.
 Then a set or dict lookup could use the identity check, and avoid
 the expensive __eq__ call.



I think it's much more important to focus on what happens with
 unequal instances here, since there are usually many more of them.
 And with them, the performance hit of the __eq__ calls definitely
 does not necessarily dominate that of __hash__.  Right?


I don't think so.  As someone else said, a hash can be calculated once and then 
cached, but __eq__ has to be called every time.  Depending on the clustering of 
your data that could be quick... or not.

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

Re: [Python-ideas] incremental hashing in __hash__

[Ethan Furman]

On 12/30/2016 03:36 PM, j...@math.brown.edu wrote:


In the use cases I described, the objects' members are ordered. So in the 
unlikely event that two objects hash to the same value but are unequal, the 
__eq__ call should be cheap, because they probably differ in length or on their 
first member, and can skip further comparison. After a successful hash lookup 
of an object that's already in a set or dict, a successful identity check 
avoids an expensive equality check. Perhaps I misunderstood?


If you are relying on an identity check for equality then no two 
FrozenOrderedCollection instances can be equal.  Was that your intention?  It 
it was, then just hash the instance's id() and you're done.

If that wasn't your intention then, while there can certainly be a few quick 
checks to rule out equality (such as length) if those match, the expensive full 
equality check will have to happen.

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

Re: [Python-ideas] AtributeError inside __get__

[Ethan Furman]

On 12/30/2016 07:10 AM, Chris Angelico wrote:


Actually, that makes a lot of sense. And since "property" isn't magic
syntax, you could take it sooner:

from somewhere import property

and toy with it that way.

What module would be appropriate, though?


Well, DynamicClassAttribute is kept in the types module, so that's probably the 
place to put optionalproperty as well.

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

Re: [Python-ideas] Enhancing vars()

[Ethan Furman]

On 12/12/2016 03:45 PM, Steven D'Aprano wrote:


Proposal: enhance vars() to return a proxy to the object namespace,
regardless of whether said namespace is __dict__ itself, or a number of
__slots__, or both.


+1

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

Re: [Python-ideas] Add optional defaults to namedtuple

[Ethan Furman]

On 11/30/2016 02:32 AM, Jelte Fennema wrote:


It would be nice to have a supported way to add defaults to namedtuple,
 so the slightly hacky solution here does not have to be used:
 http://stackoverflow.com/a/18348004/2570866


Actually, the solution right below it is better [1]:

--> from collections import namedtuple
--> class Node(namedtuple('Node', ['value', 'left', 'right'])):
--> __slots__ = ()
--> def __new__(cls, value, left=None, right=None):
--> return super(Node, cls).__new__(cls, value, left, right)

But even more readable than that is using the NamedTuple class from my aenum 
[3] library (and on SO as [3]):

--> from aenum import NamedTuple
--> class Node(NamedTuple):
--> val = 0
--> left = 1, 'previous Node', None
--> right = 2, 'next Node', None

shamelessly-plugging-my-own-solutions'ly yrs,
--
~Ethan~


[1] http://stackoverflow.com/a/16721002/208880
[2] https://pypi.python.org/pypi/aenum
[3] http://stackoverflow.com/a/40891597/208880
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP: Distributing a Subset of the Standard Library

[Ethan Furman]

On 11/28/2016 05:46 PM, Random832 wrote:

On Mon, Nov 28, 2016, at 15:05, Ethan Furman wrote:



Because it is unfriendly.  Helpful error messages are a great tool to
both beginner and seasoned programmers.


There won't be a helpful error message unless the distributor writes
one.


The purpose of this PEP, if I understand correctly, is to settle on a standard 
for the location of that distributor written helpful error message.  As a 
bonus, cpython itself can use the same mechanism for modules that are possible 
to build in the stdlib, but weren't.  This would be useful for folks that build 
their own version.


Whatever the standard method is, it has to be something we can direct
distributors to modify, it's simply not something Python can do on its
own.



---
Yo, Distributor!  If you move tkinter to a separate module, please add a 
tkinter.missing file in your main python package where tkinter is supposed to 
be; this file should contain a helpful message on how to install the tkinter 
package!
---

There.  Done.



 The default exception hook is as good a place as any. Maybe write
most of the logic and get the distributors to just populate an
empty-by-default array of structs with the module name and error message
(and what about localization?)


This might handle the stdlib portion, but the PEP's solution could be easily 
extended to handle any Python application that is installable in pieces.  As 
far as localization -- it's a small text file, surely there are mechanisms 
already to deal with that?  (I don't know, it's not a problem I have to deal 
with.)


And the idea that building a ".missing.py" for every optional module
that's disabled is going to adequate is a bit naive.


Who said disabled?  The PEP says missing, as in not there -- not disabled, as 
in there but ... what? not able to be used?


For one thing, they're not going to *be* disabled,


Ah, whew -- we agree on something! ;)


the distributors are going to build
the whole thing and break up the installed files into packages. And
you've still got to get the distributors to actually put their friendly
error message in those files,


No, we don't.  We provide a mechanism for them to use, and they use it or don't 
at their whim.  It's a quality-of-implementation issue.


and the missing.py files are build
artifacts instead of a source file that they can patch.


They are the ones that decide how to segment the stdlib, so they get to do the 
work.  I would imagine, or at least hope, that they have the build and 
segmentation code under version control -- they can patch that.

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

Re: [Python-ideas] PEP: Distributing a Subset of the Standard Library

[Ethan Furman]

On 11/28/2016 01:26 PM, Paul Moore wrote:

On 28 November 2016 at 21:11, Ethan Furman <et...@stoneleaf.us> wrote:

One "successful" use-case that would be impacted is the fallback import
idiom:

try:
 # this would do two full searches before getting the error
 import BlahBlah
except ImportError:
 import blahblah


Under this proposal, the above idiom could potentially now fail. If
there's a BlahBlah.missing.py, then that will get executed rather than
an ImportError being raised, so the fallback wouldn't be executed.


Which is why the strong recommendation is for the .missing.py file to raise an 
ImportError exception, but with a useful error message, such as "Tkinter is not 
currently installed.  Install python-tkinter to get it."


This could actually be a serious issue for code that currently
protects against optional stdlib modules not being available like
this. There's no guarantee that I can see that a .missing.py file
would raise ImportError (even if we said that was the intended
behaviour, there's nothing to enforce it).


Presumably the folks doing the splitting know what they are doing.  Any cPython 
auto-generated .missing.py files would be correct:

raise ImportError("tkinter was not compiled due to ...") .


Could the proposal execute the .missing.py file and then raise
ImportError? I could imagine that having problems of its own,
though...


Yeah, I don't think that's a good idea.

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

Re: [Python-ideas] PEP: Distributing a Subset of the Standard Library

[Ethan Furman]

On 11/28/2016 01:01 PM, Guido van Rossum wrote:

On Mon, Nov 28, 2016 at 12:51 PM, Ethan Furman wrote:

On 11/28/2016 05:28 AM, Tomas Orsava wrote:



Rendered PEP: https://fedora-python.github.io/pep-drafts/pep-A.html 
<https://fedora-python.github.io/pep-drafts/pep-A.html>



Overall +1, but using Guido's #2 option instead for handling
 *.missing.py files (searching all possible locations for the
module before falling back to the stdlib xxx.missing.py default).


Actually the .missing.py feature would be useful for other use
 cases, so it shouldn't be limited to the stdlib part of sys.path.
 (Also I'm withdrawing my idea of searching for it while searching
 for the original .py since that would burden successful imports
 with extra stat() calls.)


Absolutely.  The key point in your counter proposal is not failing at the first 
.missing.py file possible, but rather searching all possible locations first.

If we do the full search for the import first, then a full search for the 
.missing.py, and that ends up not hurting performance at all for successful 
imports -- well, that's just icing on the cake.  :)

One "successful" use-case that would be impacted is the fallback import idiom:

try:
# this would do two full searches before getting the error
import BlahBlah
except ImportError:
import blahblah

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

Re: [Python-ideas] PEP: Distributing a Subset of the Standard Library

[Ethan Furman]

On 11/28/2016 05:28 AM, Tomas Orsava wrote:


Rendered PEP: https://fedora-python.github.io/pep-drafts/pep-A.html


Overall +1, but using Guido's #2 option instead for handling *.missing.py files 
(searching all possible locations for the module before falling back to the 
stdlib xxx.missing.py default).

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

Re: [Python-ideas] Generator-based context managers can't skip __exit__

[Ethan Furman]

On 11/18/2016 12:42 PM, Ram Rachum wrote:


Sure, here are a couple of use cases:

1. I'm making a program that lets people lease machines. They can issue
 a command to lease 7 machines. When they do, my program leases them one
 by one and adds them all to an exit stack, so in case there aren't 7
 machines available, all the machines we leased get released and the
 situation is back to normal. If everything goes fine, I do pop_all on
 the exit stack so it doesn't get exited and the machines stay leased,
 then the command exits and the user gets his machines.


So you're using the contextlib.ExitStack context manager?


2. I have a test suite that creates a temporary folder to put files that
 are used by the test. The temporary folder is created by a context
 manager that deletes it at the end. But, if the test fails I want to
 move the temporary folder away into a dedicated folder for the user to
 be able to examine those files later to figure out why the test fails.
 So I want to tell the temporary folder context manager to not delete
 the folder, because it'll fail since it was moved away so it's not at
 the expected location.


My first thought is to make a custom context manager for this use-case, but if 
you really want to use a generator instead can't you just put in an existence 
check for the directory and only delete if it is still there?

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

Re: [Python-ideas] Technical possibilities for a syntax [was: Reverse assignment operators ...]

[Ethan Furman]

On 11/18/2016 11:34 AM, Chris Angelico wrote:


Hmm. I'm seeing them. Where are you reading -ideas? Is there possibly
a glitch between mailing list and newsgroup?


Yeah, I'm using the mailing list.
 


On 11/18/2016 11:39 AM, Mikhail V wrote:


I am really sorry :( Didn't intended it
Something with my mailer it showed me python-ideas in to: in Stevens reply.


Looks like it's not an issue with you, Mikhail, my apologies.

I'll ask Brett to check it out.

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

Re: [Python-ideas] Support for OAuth2/OIDC in the standard distribution ?

[Ethan Furman]

On 11/16/2016 03:51 AM, Roland Hedberg wrote:


My question to you is if it would be possible to get an OAuth2/OIDC 
implementation like mine
to be part of the Python standard distribution.

I realise that I will have to rewrite parts of pyoidc because presently it uses 
modules
(for instance pycryptdome and requests) that are not part of the standard 
distribution.


My concern with a rewrite is that your code is no longer thoroughly tested.  Of 
course, this depends in large part on the completeness of your unit tests.

I agree with Cory that discoverability is the problem to solve.

You can help with that somewhat by seeding sites like StackOverflow with the 
information.*

--
~Ethan~

* SO is not very tolerant of questions looking for opinion-based answers such as software 
recommendations, so make sure you phrase your question as "How do I do XXX using 
pyoidc?" and your answer can also include other links on the OIDC subject.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Generator-based context managers can't skip __exit__

[Ethan Furman]

On 11/06/2016 08:11 PM, Nick Coghlan wrote:

On 7 November 2016 at 12:25, Ethan Furman <et...@stoneleaf.us> wrote:

On 11/06/2016 12:44 AM, Ram Rachum wrote:


I see that Python does allow you to not call `__exit__` if you don't want
  to [...]


Um, how?  I was unaware of this (mis-)feature.


It involves wrapping the context manager in another context manager
that deliberately doesn't delegate the call to __exit__ in some cases
(cf contextlib.ExitStack.pop_all()).


Ah, okay.

Perhaps a custom iterator class would suit Ram's needs better than using a 
generator shortcut.

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

Re: [Python-ideas] Generator-based context managers can't skip __exit__

[Ethan Furman]

On 11/06/2016 12:44 AM, Ram Rachum wrote:


I see that Python does allow you to not call `__exit__` if you don't want
 to [...]


Um, how?  I was unaware of this (mis-)feature.

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

Re: [Python-ideas] Generator-based context managers can't skip __exit__

[Ethan Furman]

On 11/06/2016 12:18 AM, Ram Rachum wrote:


Well, you think it's weird that I want a `finally` clause to not be called
 in some circumstances.


Yes I (we) do.


 Do you think it's equally weird to want an `__exit__` method that is not
 called in some circumstances?


Yes I (we) do.

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

Re: [Python-ideas] Null coalescing operator

[Ethan Furman]

On 11/02/2016 12:32 PM, Nikolaus Rath wrote:

On Nov 02 2016, Zero Piraeus  
wrote:

On Wed, 2016-11-02 at 08:46 -0700, Guido van Rossum wrote:

[...] we need to agree on what even the right definition of ?. is. It's
been frighteningly difficult to explain this even on this list, even
though I have a very clear view in my head, and PEP 505 also has the
same semantics and explains well why those are the right semantics.


I think the proposed semantics for ?. are confusing (and the operator
itself dangerous, but more on that later).

If I write something like obj.attr, the failure mode I care about is that
obj has no attribute attr, rather than that obj is specifically None (or
one of a defined group of somewhat Nonelike objects).

Clearly, in such a circumstance, obj is not what I expected it to be,
because I thought it was going to have an attribute attr, and it
doesn't.


That means that you do not need null coalescing operators. They're not
intended for your use-case, and you are not the target audience.


However, it's definitely a point for the confusiness of it all.

I like the idea of null-(coalescing|negation|borrowing|what-have-you), but I 
also very much appreciate the keyword approach used in Python.  I can already 
feel the headache coming on from trying to read and decipher the various ? 
accesses...

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

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

[Ethan Furman]

On 10/21/2016 10:17 PM, Ryan Birmingham wrote:


I want to start small and ask about smart/curly quote marks (” vs ").
 Although most languages do not support these characters as quotation
 marks, I believe that cPython should, if possible. I'm willing to write
 the patch, of course, but I wanted to ask about this change, if it has
 come up before, and if there are any compatibility issues that I'm not
 seeing here.


What is the advantage of supporting them?  New behavior, or just more possible 
quotes characters?

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

Re: [Python-ideas] Deterministic iterator cleanup

[Ethan Furman]

On 10/21/2016 03:48 PM, Amit Green wrote:


NOTE: This is my first post to this mailing list, I'm not really sure
   how to post a message, so I'm attempting a reply-all.


Seems to have worked! :)


I like Nathaniel's idea for __iterclose__.

I suggest the following changes to deal with a few of the complex issues
he discussed.


Your examples are interesting, but they don't seem to address the issue of 
closing down for loops that are using generators when those loops exit early:

-
def some_work():
with some_resource():
  for widget in resource:
  yield widget


for pane in some_work():
break:

# what happens here?
-

How does your solution deal with that situation?  Or are you saying that this 
would be closed with your modifications, and if I didn't want the generator to 
be closed I would have to do:

-
with some_work() as temp_gen:
for pane in temp_gen:
break:

for another_pane in temp_gen:
# temp_gen is still alive here
-

In other words, instead using the preserve() function, we would use a with 
statement?

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

Re: [Python-ideas] please try to keep things civil

[Ethan Furman]

On 10/21/2016 12:13 PM, Mark Lawrence via Python-ideas wrote:


This list is irrelevant.  The PSF has to be consistent across all of its lists.


This list is not irrelevant, and yes *volunteers who moderate* should be 
consistent.


 Who the hell is Marietta, I don't recall a single post from her in 16 years of 
using Python?


She is a fellow Pythonista, and you owe her an apology.

--
~Ethan~

P.S. Should you decide to bring my own stupidity a few months of ago of being 
insulting, you should also take note that I took responsibility for it and 
apologized myself.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] warn/error when using a method as boolean in ifs/whiles

[Ethan Furman]

On 10/11/2016 07:00 AM, Steven D'Aprano wrote:

On Tue, Oct 11, 2016 at 02:41:34PM +0200, Sven R. Kunze wrote:



on django-developers, an intriguing idea appeared:
https://groups.google.com/d/msg/django-developers/4bntzg1HwwY/HHHjbDnLBQAJ

"""
It seems to me that the default `method.__bool__` is undesirable in
Jinja2 templates. I do not know Jinja2 well enough, but maybe they could
benefit from a patch where `if`-statements give a warning/error when the
expression is a callable (with the default `FunctionType.__bool__`?
This would solve the issue not just for the methods you mention, but
more in general.


That should be easy enough to do as a custom descriptor.

But I would not like to see the default function or method __bool__
raise a warning.


[...]


So I think this is something that Django/Jinja2 should implement for its
own methods that need it, it should not be a general feature of all
Python functions/methods.


Agreed. Python is a /general/-purpose programming language.  We should not make 
changes to help one subset of users when those changes will harm another subset 
(and being flooded with false positives is harmful) -- particularly when easy 
customization is already available.

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

Re: [Python-ideas] async objects

[Ethan Furman]

On 10/05/2016 12:20 PM, Sven R. Kunze wrote:

On 05.10.2016 18:06, Nick Coghlan wrote:



Guido's idea of a shadow thread to let synchronous threads run
coroutines without needing to actually run a foreground event
loop should provide a manageable way of getting the two runtime
models (traditional C and asynchronous coroutines) to play
nicely together in a single application, and has the virtue of
being something folks can readily experiment with for themselves
before we commit to anything specific in the standard library
(since all the building blocks of thread local storage, event
loop management, and inter-thread message passing primitives are
 already available).


I needed to think about this further when Guido mentioned it. But
 I like it now.

If you check https://github.com/srkunze/fork/tree/asyncio , I
already started working on integrating asyncio into xfork at long
time ago. But I still couldn't wrap my mind around it and it
stalled. But IIRC, I would have implemented a shadow thread
 solution as well. So, if his idea goes into the stdlib first, I
 welcome it even more as it would do the heavy lifting for me. xfork
would then be just a common interface to threads, processes and
 coroutines.


At this point I'm willing to bet that you (Sven) are closest to actually having 
a shadow thread thingy that actually works.  Maybe some other asyncio folks 
would be willing to help you develop it?

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

Re: [Python-ideas] from __pip__ import

[Ethan Furman]

On 09/19/2016 06:45 PM, Chris Angelico wrote:


Yes we are (at least in that instance). With more real-world tests,
they're allowed to use all the standard library - this was the "in
some cases" bit. (We don't teach float multiplication, because it's
very complication, but we do teach some stuff about how bitwise
operations work. So yes, we are teaching low level stuff in high level
languages.)


Good.  Just remember that "bin(x)" does not print 2s-complement for negative 
numbers.  Had me pulling my hair out for a while.

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

Re: [Python-ideas] from __pip__ import

[Ethan Furman]

On 09/19/2016 04:38 PM, אלעזר wrote:


I was talking specifically about advanced courses, in which an assignment
 is "implement a side-channel attack using data" and you can use whatever
 library you like.


Am I misunderstanding, or did you just say you want this new functionality in 
order to implement attacks on people's computers?

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

Re: [Python-ideas] from __pip__ import

[Ethan Furman]

On 09/19/2016 09:25 AM, אלעזר wrote:


Many proposals to add something to stdlib are rejected here with the suggestion 
to add such library to pypi first. As noted by someone, pypi is not as 
reachable as stdlib, and one should install that package first, which many 
people don't know how. Additionally, there is no natural distinction between 
3rd party dependencies and in-project imports (at least in tiny projects).

This can be made easier if the first line of the program will declare the 
required library, and executing it will try to download and install that 
library if it is not installed yet. Additionally, the 3rd party dependencies 
will be more explicit, and editors can then allow you to search for them as you 
type.

Of course it is *not* an alternative for real dependency management, but it 
will ease the burden on small scripts and tiny projects - which today simply 
break with errors that many users does not understand, instead of simply asking 
permission to install the dependency.


This should start out as a library on PyPI.  (Sorry, couldn't resist. ;)

Actually, it should.  Perhaps a name of "import_pip" would make sense?  Any 
hurdles faced by this library would be (mostly) the same as a stdlib version.

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

Re: [Python-ideas] divmod(): fallback to __floordiv__ and __mod__?

[Ethan Furman]

On 09/17/2016 03:14 PM, Chris Angelico wrote:

On Sun, Sep 18, 2016 at 8:06 AM, Ethan Furman wrote:



Just like Python will use the defined __ne__ if
it's present, or fall back to negating the result of __eq__ if __ne__ is
not present, I see __divmod__ working the same way:

- is __mod__ present? use it
- is __floordiv__ present? use it
- otherwise, use __divmod__ and return the needed piece

I'm pretty sure __div__ should not fall back to __divmod__.


How does __mod__ fall back to __floordiv__? I'm lost.


Oops, sorry.  Got my directions reversed when thinking about how __div__ should 
fit in.

Bird's eye view: if the exact method needed is present, use it; otherwise if a 
fallback method is available, use that.

Currently this is done for __ne__ --> not __eq__, and I seem to remember 
another case or two that was talked about but I don't remember what they were and 
I'm not sure if they got implemented to follow the fallback pattern.

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

Re: [Python-ideas] Naming convention for Enums

[Ethan Furman]

On 09/15/2016 10:03 AM, Steven D'Aprano wrote:

On Wed, Sep 14, 2016 at 09:51:32PM +1000, Chris Angelico wrote:



Perhaps the advice needs to be along the lines of: Decide what the
purpose of the enum is, and follow a naming convention accordingly.
Uppercase if you're basically making constants; lowercase if you're
not; etcetera.


I can't think of any situation where Enums would *not* be treated as
constants. Can you give an example?


Besides being CONSTANTS enum members are also Singletons, and since I find 
CamelCase easier to read than UPPERCASE I may use that instead; otherwise I 
leave it all lowercase.

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

Re: [Python-ideas] New Python syntax for continuing definitions for existing classes

[Ethan Furman]

On 09/13/2016 09:29 AM, Chris Angelico wrote:

On Wed, Sep 14, 2016 at 2:16 AM, Pim Schellart wrote:


A well-written PEP that looked very interesting.


https://github.com/Rosuav/Decorators/blob/master/evil.py



@monkeypatch
class A:
 x = 5
 def foo(self):
 pass
 def bar(self):
 pass


But this seems to solve the problem nicely.  In other words, you now need to 
explain why this particular class decorator is not good enough to solve the 
general problem.

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

Re: [Python-ideas] Fwd: Null coalescing operator

[Ethan Furman]

On 09/12/2016 08:37 AM, Guido van Rossum wrote:


For the record, I still really don't like PEP 463. We should strive to
catch fewer exceptions, not make it easier to catch them.


I certainly agree with the first part, slightly reworded: we should strive to 
generate fewer exceptions that we have to catch.

I disagree with the second part:  being able to condense four lines of code (1 
for try, 1 for except, 1 for the attempt, and 1 for recovery) in to one line of 
code seems like a win.  I know I find it frustrating when my choice is between 
the 4-line boiler-plate try/except, or an equally verbose and ugly multi-line 
non-exception generating stanza.

Anyway, my two cents worth.  If you collect them all for this subject I think I 
owe you a dime.  ;)

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

Re: [Python-ideas] Fwd: Null coalescing operator

[Ethan Furman]

On 09/12/2016 12:05 AM, Michel Desmoulin wrote:


There is also an alternative to this operator, and it's allowing a
shortcut to do:

try:
 val = do_thing()
except ThingError:
 val = "default"

In the form of:

val = do_thing() except ThingError: "default"

I was debated, and rejected, but I feel like mentioning it again because
it has some strong benefits.


+1

There are many places in my code where this would clean things up a bit.  Not 
having it is like not having list comps or not having the ternary if-else -- 
possible, but it would be much nicer to have it.

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

Re: [Python-ideas] Let’s make escaping in f-literals impossible

[Ethan Furman]

On 08/29/2016 02:16 PM, Eric V. Smith wrote:


I've been looking at this, and I agree it's the best thing to do, for
now (and possibly forever).

I'm just not convinced I can get it done before alpha 1.


Isn't the f-string feature already in place?

Update the PEP, then it's a bugfix.  ;)

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

Re: [Python-ideas] Let’s make escaping in f-literals impossible

[Ethan Furman]

On 08/19/2016 08:57 PM, C Anthony Risinger wrote:

[...]


The appeal of f-strings is the rapid inlining of whatever plus string data. "Whatever" is 
typically more complex than a simple attribute access or variable reference, though not much more 
complex eg. `object.method(key, "default")`. If I have to water it down for people to 
find it acceptable (such as creating simpler variables ahead-of-time) I'd probably just keep using 
.format(...). Because what I have gained with an f-string?


I suspect f-strings are in the same category as lambda -- if it's that complex, 
use the other tools instead.

At this point I don't see this changing.  If you want to make any headway 
you're going to have to do it with a complete alternate implementation, and 
even then I don't think you have good odds.

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