[Python-ideas] Re: Add an __exclude_all__ complement to __all__

[Ethan Furman]

On 3/5/21 12:41 PM, Caleb Donovick wrote:


 > __all__ = (Class.__name__, func.__name__, ...)
 >
 > So I have to put it at the end of the module. I do this because if I
 > change the class or function name and I forget to change it in
 > __all__, I get an exception.

I certainly will not claim to be the arbitrator of good and bad practices but 
that seems reasonable enough.

It is worth pointing out that it's pretty easy to unit test `__all__`

```
# module/__init__.py
__all__ = 'Foo', 'Bar'

class Foo: pass
```

```
# tests/test_imports.py
def test_star():
       # will raise `AttributeError: module 'module' has not attribute 'Bar'`
       from module import *
```

 > from .a import *
 > from .b import *

 > __all__ = a.__all__ + b.__all__

Assuming you mean:
```
from . import a
from . import b
from .a import *
from .b import *
__all__ = a.__all__ + b.__all__
```


Actually, Marko's version works, and is the same style used by asyncio.  
Apparently,

  from .a import *

also adds `a` to the module's namespace.

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

[Python-ideas] Re: Add an __exclude_all__ complement to __all__

[Ethan Furman]

On 3/3/21 2:18 PM, George Harding wrote:


__all__ does not stop anyone from importing anything in the module using `from 
foo import bar`.


That is true, but that is also Python.  If you import something not included in 
`__all__` then you do so at your own risk as it could change or vanish in the 
next release.

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

[Python-ideas] Re: Add an __exclude_all__ complement to __all__

[Ethan Furman]

On 3/3/21 3:38 PM, George Harding wrote:


If you are using __all__ to define your API, then you'll end up needing `from 
foo import *` if you want to combine modules, e.g.:

https://github.com/python/cpython/blob/master/Lib/asyncio/__init__.py


Absolutely!

So the two need to coexist. *-import does have valid uses. 


Agreed.

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

[Python-ideas] Re: Add an __exclude_all__ complement to __all__

[Ethan Furman]

On 3/3/21 2:17 PM, Brendan Barnwell wrote:


[...] usually you want to define [__all__] at the beginning as a sort of 
documentation
aid ("this is the public API").


That is its purpose. :-)


I do think something like __exclude_all__ would be handy.  It can be annoying 
to have
to define __all__ just to exclude a few things.


Exclude a few things from what?  *-imports?  If you're using *-imports that 
often you are already courting confusion (where did that name come from?  why 
is this name not that function?).

I maintain a handful of libraries, all with `__all__`, and only one them is 
designed to be used with `from ... import *`.

The presence or absence of `__all__` has no bearing on named imports.  `from 
blahblah import _xyz` will work in either case.

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

[Python-ideas] Re: Add an __exclude_all__ complement to __all__

[Ethan Furman]

On 3/3/21 12:55 PM, George Harding wrote:


Python has an __all__ variable that can be defined in a module to restrict
which members of the module should be included in a call `from foo import *`.


The primary purpose these days for `__all__` is to codify a module's API.  The 
*-import is just a happy accident.


However specifying which members of the module should be excluded is more
difficult.


And unnecessary -- specify `__all__` so your users know which classes, 
functions, variables, etc., can be safely used.  If it should be excluded, 
don't put it in `__all__`.

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

[Python-ideas] Re: Alternate lambda syntax

[Ethan Furman]

On 2/17/21 8:47 AM, Random832 wrote:

On Tue, Feb 16, 2021, at 23:24, Stephen J. Turnbull wrote:



except a couple of characters.  So what currently looks like

 some_list.sort(key=lambda e: e[3].priority)

would then be

 some_list.sort(key=(e)->e[3].priority)


Let's not pretend the key argument being keyword-only isn't a wart. Surely this 
would be better if it could be some_list.sort(e->e[3].priority).


No need to pretend, it isn't a wart.

-1 on removing the lambda keyword.  Just because excessive punctuation 
works for other languages does not mean it's a good fit for Python.


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

[Python-ideas] Re: Using explicit parenthesization to convey aspects of semantic meaning?

[Ethan Furman]

On 12/17/20 11:09 AM, Chris Angelico wrote:

> I said I wasn't going to respond, but this one is SUCH a common
> misunderstanding that I don't want people led astray by it.
>
> "a+b" is NOT implemented as "a.__add__(b)", nor as "type(a).__add__(b)"!

Okay, what is it implemented as?

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

[Python-ideas] Re: @classproperty, @abc.abstractclasspropery, etc.

[Ethan Furman]

On 12/16/20 1:31 AM, Serhiy Storchaka wrote:


Things like abstractclassmethod are legacy. It is more preferable to
combine elemental decorators.


I completely disagree, although I suppose the determining factor is one's point of view.  I see it as 
"abstractclassmethod" being its own thing, and while it can be composed from "abstract" and "classmethod", nothing is 
gained by splitting those words across multiple lines.


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

[Python-ideas] Re: a new data type: NamedValue -- similar to Enum

[Ethan Furman]

On 12/12/20 7:25 PM, Steven D'Aprano wrote:
> On Sat, Dec 12, 2020 at 06:00:17PM -0800, Ethan Furman wrote:

>> Enum is great!  Okay, okay, my opinion might be biased.  ;)
>>
>> There is one area where Enum is not great -- for a bunch of unrelated
>> values.
>
> I don't know how to interpret that. Surely *in practice* enums are
> always going to be related in some sense?

I certainly hope so -- that was one of the points in creating Enum.

> I don't expect to create an enum class like this:
>
>  class BunchOfRandomStuff(Enum):
>  ANIMAL = 'Mustela nivalis (Least Weasel)'
>  PRIME = 503
>  EULER_MASCHERONI_CONSTANT = 0.5772156649015329
>  BEST_PICTURE_1984 = 'Amadeus'
>  DISTANCE_MELBOURNE_SYDNEY = (16040497, "rack mount units")

Which is why I said, "Enum is not great for a bunch of unrelated values".

> If I did create such an unusual collection of enums, what is the
> standard Enum lacking that makes it "not great"? It seems to work fine
> to me.

Lots of things work -- calling `__len__` instead of `len()` works, but `__len__` is not the best way to get the length 
of an object.


Enums are not great for a bunch of unrelated values because:

- duplicate values would all get aliased to one name
- ordinary values should not be compared using `is`
- standard Enums cannot be seamlessly used as their actual value (example in 
other email)

[...]

> I don't understand this. Are you suggesting that NamedValues will have a
> `type` attribute **like Enum**, or **in addition** to what Enum provides
> (value and name)?

To be honest, Enum may have a "type" attribute at this point, I don't remember.  NamedValues would definitely have a 
"type" attribute whose primary purpose is to make the value attribute work.


As an example, consider sre_constant.MAXREPEAT vs sre_constant.MAX_REPEAT (the only difference is the underscore -- took 
me a few moments to figure that out).


The sre_constant._NamedIntConstant class adds a name attribute, and returns 
that as the repr().
```
>>> sre_constants.MAXREPEAT
MAXREPEAT
>>> sre_constants.MAX_REPEAT
MAX_REPEAT
```

Not very illuminating.  I ended up getting the actual value by calling `int()` 
on them.

```
>>> int(sre_constants.MAXREPEAT)
4294967295
>>> int(sre_constants.MAX_REPEAT)
42
```

By adding a "type" attribute, getting something useful becomes a little easier:

```
@property
def value(self):
return self._type_(self)
```
or maybe
```
@property
def value(self):
return self._type_.__repr__(self)
```

>> unlike Enum, duplicates are allowed
>
> Um, do you mean duplicate names? How will that work?

No, duplicate values -- but in an Enum the names given to the duplicate value become aliases to the original name/value, 
while duplicates in NamedValue would remain different objects.


>> unlike Enum, new values can be added after class definition
>
> Is there a use-case for this?

Yes.

> If there is such a use-case, could we not just given Enums an API for
> adding new values, rather than invent a whole new Enum-by-another-name?

While NamedValues have a similarities to Enum (.name, .value, human readable 
repr()), they are not Enums.

>> unlike Enum, a NamedValue can always be used as-is, even if no data type
>> has been mixed in -- in other words, there is no functional difference
>> between MyIntConstants(int, NamedValue) and MyConstants(NamedValue).
>
> Sorry, I don't get that either. How can Enums not be used "as-is"? What
> does that mean?

It means that you can't do things with the actual value of Color.RED, whether that value is an int, a string, or a 
whatever, without going through the value attribute.


> Are you suggesting that NamedValue subclasses will automatically insert
> `int` into their MRO?

No, I'm saying that a NamedValue subclass will have int, or string, or frozenset, or whatever the actual values' types 
are, in their mro:


```
def __new__(cls, value, name):
actual_type = type(value)
new_value_type = type(cls.__name__, (cls, type(value)), {})
obj = actual_type.__new__(new_value_type, value)
obj._name_ = name
obj._type_ = actual_type
return obj
```
The subclasses are created on the fly.  The production code will cache the new 
subclasses so they're only created once.

>> If sre_constants was using a new data type, it should probably be IntEnum
>> instead.  But sre_parse is a good candidate for NamedValues:
>>
>>
>>  class K(NamedValues):
>>  DIGITS = frozenset("0123456789")
> [...snip additional name/value pairs...]
>
>> and in use:
>>
>>  >>> K.DIGITS
>>  K.DIGITS
>>

[Python-ideas] Re: a new data type: NamedValue -- similar to Enum

[Ethan Furman]

On 12/12/20 7:52 PM, Steven D'Aprano wrote:

On Sat, Dec 12, 2020 at 07:01:55PM -0800, Ethan Furman wrote:



That's invalid.  Duplicates allowed means:


```
class K( NamedValue):
  A = 1
  B = 1
```

B is not an alias for A.  Presumably one has the same number with different
meaning.  If that were an Enum:

```

K.B

K.A


Ah! Talking about Boy Looks, I had never noticed that behaviour before.
(But then I don't regularly use duplicate Enum values.)

What is the reason for that behaviour in Enums?


Different names for the same thing, the second names (and third, and ...) are aliases for the first.  For example, if 
you're me and constantly forget to drop the 's', you might have


class Border(Enum):
LINE = 'line'
LINES = 'line'

and then, no matter which I type, I get the right answer.  Silly example, but the point is that Enum members are 
singletons, and there should only be one canonical member to represent a single semantic value -- hence the 
recommendation to compare Enums using `is`.


NamedValues, on the other hand, don't have the concept of set membership and 
one canonical name for a single value.

>> [...]


Class MyEnum(Enum):
 ONE = 1
 TWO = 2

MyEnum.ONE + 3
# TypeError

Class MyValue(NamedValue):
 ONE = 1
 TWO = 2

MyValue.TWO + 3
5


Isn't this the solution to that?


class MyValue(int, Enum):

... ONE = 1
... TWO = 2
...

MyValue.TWO + 3

5


It certainly can be abused for that, but the intended purpose of IntEnum is not to support math operations, but rather 
to interoperate with existing APIs that are using ints as magic numbers.


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

[Python-ideas] Re: a new data type: NamedValue -- similar to Enum

[Ethan Furman]

On 12/12/20 6:40 PM, Guido van Rossum wrote:


unlike Enum, duplicates are allowed



What does this even mean?
```
class K( NamedValue):
     A = 1
     A = 2
```


That's invalid.  Duplicates allowed means:

> ```
> class K( NamedValue):
>  A = 1
>  B = 1
> ```
B is not an alias for A.  Presumably one has the same number with different 
meaning.  If that were an Enum:

```
>>> K.B
K.A


unlike Enum, new values can be added after class definition


Sure, that points to maybe a subclass of Enum?


Not really -- adding a new member to an Enum is a royal pain.



unlike Enum, a NamedValue can always be used as-is, even if no data type has 
been mixed in -- in other words, there is
no functional difference between MyIntConstants(int, NamedValue) and 
MyConstants(NamedValue).


I'm not following this either. Can you give an example of something that doesn't work with Enum (and shouldn't work) but 
should work with NamedValues?


Class MyEnum(Enum):
ONE = 1
TWO = 2

MyEnum.ONE + 3
# TypeError

Class MyValue(NamedValue):
ONE = 1
TWO = 2

MyValue.TWO + 3
5


Finally, why the plural in the name, where Enum and friends all have singular 
names?


Because I constantly forget, and have to go back to remove the plural 's'.

By the way, the use of classes is not strictly required -- we could get everything except for immutable class access by 
using mostly the same method as sre_parse._NamedIntConstant if we want a /slightly/ lighter weight structure -- which is 
to say the NamedValueMeta is no where near as complicated as EnumMeta.


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

[Python-ideas] a new data type: NamedValue -- similar to Enum

[Ethan Furman]

Enum is great!  Okay, okay, my opinion might be biased.  ;)

There is one area where Enum is not great -- for a bunch of unrelated values.  What would be nice is if we had something 
similar to Enum for the


- repr()
- constantness of the name/value relationship

While I was looking in the stdlib for an example, I came across sre_constants, which was chock full of constants -- and 
it even has a minimal version of what I'm proposing:


class _NamedIntConstant(int):
def __new__(cls, value, name):
self = super(_NamedIntConstant, cls).__new__(cls, value)
self.name = name
return self

def __repr__(self):
return self.name


My proposal, compared/contrasted with Enum:

like Enum, NamedValues will be in collections (a class) that will keep those names from being deleted or rebound to 
other values


like Enum, NamedValues will have `value` and `name` attributes, and also a 
`type` attribute

like Enum, NamedValues are attributes of their containing class

like Enum, iterating over the containing class will yield the names/values 
defined

like Enum, a class of NamedValues do not have to all be the same data type 
unless one is mixed in

like Enum, a particular name/value combination is a singleton

unlike Enum, duplicates are allowed

unlike Enum, new values can be added after class definition

unlike Enum, a NamedValue can always be used as-is, even if no data type has been mixed in -- in other words, there is 
no functional difference between MyIntConstants(int, NamedValue) and MyConstants(NamedValue).


If sre_constants was using a new data type, it should probably be IntEnum instead.  But sre_parse is a good candidate 
for NamedValues:



class K(NamedValues):
DIGITS = frozenset("0123456789")

OCTDIGITS = frozenset("01234567")
HEXDIGITS = frozenset("0123456789abcdefABCDEF")
ASCIILETTERS = 
frozenset("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ")

WHITESPACE = frozenset(" \t\n\r\v\f")

_REPEATCODES = frozenset({MIN_REPEAT, MAX_REPEAT})
_UNITCODES = frozenset({ANY, RANGE, IN, LITERAL, NOT_LITERAL, CATEGORY})

and in use:

>>> K.DIGITS
K.DIGITS
>>> K.DIGITS.name
'DIGITS'
>>> K.DIGITS.value
frozenset("0123456789")

Thoughts?

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

[Python-ideas] Re: Typed Python execution mode

[Ethan Furman]

On 12/10/20 2:08 PM, redrad...@gmail.com wrote:


It is also about convenience


It takes a stronger argument than convenience to get something added to the 
stdlib.

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

[Python-ideas] Re: __init__ in module names

[Ethan Furman]

On 12/9/20 12:39 PM, Steven D'Aprano wrote:


I am against changing this behaviour before anyone has identified
*actual bugs* in code caused by it, and before anyone has addressed the
use-case MAL gave for the current behaviour.


+1

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

[Python-ideas] Re: Adding PyInstaller to the standard library

[Ethan Furman]

On 11/20/20 8:41 PM, Brendan Barnwell wrote:

On 2020-11-20 01:51, Steven D'Aprano wrote:



If that's really what you want, you probably should look at making a way
to run Python apps in the browser. Everyone has an OS, everyone has a
browser, GUI browsers have similar looking look-and-feels, the days when
devs assumed Internet Explorer are long gone.


I'm as steadfastly negative about browser apps as Chris A. is about native 
executables.  :-)


+1000

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

[Python-ideas] Re: Enum and the Standard Library (and __str__ and __repr__)

[Ethan Furman]

On 11/3/20 3:58 PM, Steven D'Aprano wrote:

On Tue, Nov 03, 2020 at 11:10:37AM -0800, Ethan Furman wrote:


After discussions with Guido I made a (largely done) PR [3] which:

for stdlib global constants (such as RE)
- repr() -> uses `module.member_name`
- str() -> uses `member_name`


What's `RE`? Do you mean the enums in the re module, `re.I` etc?


Yes, re.RegexFlag.


for stdlib non-global constants, and enums in general
- repr() -> uses `class.member_name`
- str() -> uses `member_name`


How does that work? If I do this:

 class MyEnum(Enum):
 RED = 'red'

 RED = MyEnum.RED

is that a global constant or a non-global constant?


Up to you to decide.  ;-)

RegexFlag is a bit of a special case, so we'll look at socket instead.

Before Enum, socket had global constants such as

  AF_INET
  AF_UNIX
  SOCK_STREAM
  SOCK_DGRAM
  SOCK_RAW

then Enum came along and:

  IntEnum._convert_(
'AddressFamily',
__name__,
lambda C: C.isupper() and C.startswith('AF_'))

  IntEnum._convert_(
'SocketKind',
__name__,
lambda C: C.isupper() and C.startswith('SOCK_'))

which replaces the existing AF_* and SOCK_* constants with enums instead.


 How do I hook into whatever magic is used to decide one way or the other?


The only magic involved is choosing an appropriate `__str__` and `__repr__`.  In 3.10, Enum._convert_ will choose a 
"global" `__str__` and `__repr__`.




The questions I would most appreciate an answer to at this point:

- do you think the change has merit?
- why /shouldn't/ we make the change?


It's not clear to me what the change actually is. You explained what the
behaviour is being changed to but not what it is being changed from.


My apologies.

For `socket` (where Enum is replacing preexisting global constants):

  str(socket.AF_INET)   # from  "AddressFamily.AF_INET"  to  "AF_INET"
  repr(socket.AF_INET)  # from  ""  to  
"socket.AF_INET"


For `uuid`, which has a new Enum, SafeUUID (no preexisting global constants):

  str(SafeUUID.safe)# from  "SafeUUID.safe"  to  "safe"
  repr(SafeUUID.unsafe) # from  ""  to  "SafeUUID.unsafe"



re.I has repr and str both return 're.IGNORECASE'. Will that change?


Yes -- the str would change to 'IGNORECASE'.



MyEnum.RED above has repr "" and str 'MyEnum.RED'.
Presumably that will change to 'MyEnum.RED' and 'RED' respectively.


Assuming that regular Enum is changed (not just stdlib enums), then yes.

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

[Python-ideas] Re: Enum and the Standard Library (and __str__ and __repr__)

[Ethan Furman]

On 11/3/20 11:26 AM, Chris Angelico wrote:

On Wed, Nov 4, 2020 at 6:11 AM Ethan Furman wrote:


TL;DR  Changes may be coming to Enum str() and repr() -- your (informed) 
opinion requested.  :-)



Does this affect my own enums too, or just stdlib ones? I'm not
entirely sure on that point.


That is the primary question under discussion.  Unless somebody has a compelling reason not to change the stdlib enums, 
that is going to happen.



Specifically, will code like this be affected, and if so, what is the
correct way to be compatible with multiple versions?

from enum import IntFlag, auto
class UF(IntFlag):
 SALLY = auto()
 PHASEPING = auto()
...
for flag in UF:
 print("#define %s %d" % (str(flag), int(flag)), file=f)

Currently, str(UF.SALLY) is "UF.SALLY", but this would change. I'm
guessing the recommendation is "don't do that then"? (For instance,
using flag.name to get "SALLY", and type(flag).__name__ to get "UF",
since these flags won't only come from a single class.)


Assuming the change is made for all Enum, `str(UF.SALLY)` would produce `SALLY`.  If that is a common pattern for you 
then you could make your own base class and inherit from that:


  class C_Enum(Enum):
  def __str__(self):
  return f"{self.__class__.__name__}.{self._name_}"


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

[Python-ideas] Enum and the Standard Library (and __str__ and __repr__)

[Ethan Furman]

TL;DR  Changes may be coming to Enum str() and repr() -- your (informed) 
opinion requested.  :-)


Python-Dev thread [0], summary below:


As you may have noticed, Enums are starting to pop up all over the stdlib [1].

To facilitate transforming existing module constants to IntEnums there is
`IntEnum._convert_`.  In Issue36548 [2] Serhiy modified the __repr__ of 
RegexFlag:

  >>> import re
  >>> re.I
  re.IGNORECASE

I think for converted constants that that looks nice.  For anyone that wants the
actual value, it is of course available as the `.value` attribute:

  >>> re.I.value
  2

I'm looking for arguments relating to:

- should _convert_ make the default __repr__ be module_name.member_name?

- should _convert_ make the default __str__ be the same, or be the
  numeric value?


After discussions with Guido I made a (largely done) PR [3] which:

for stdlib global constants (such as RE)
   - repr() -> uses `module.member_name`
   - str() -> uses `member_name`

for stdlib non-global constants, and enums in general
   - repr() -> uses `class.member_name`
   - str() -> uses `member_name`

The questions I would most appreciate an answer to at this point:

- do you think the change has merit?
- why /shouldn't/ we make the change?

As a reminder, the underlying issue is trying to keep at least the stdlib Enum
representations the same for those that are replacing preexisting constants.

--
~Ethan~


[0] 
https://mail.python.org/archives/list/python-...@python.org/message/CHQW6THTDYNPPFWQ2KDDTUYSAJDCZFNP/

[1] I'm working on making their creation faster.  If anyone wanted to convert 
EnumMeta to C I would be grateful.

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

[3] https://github.com/python/cpython/pull/22392
___
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/QOET2GQ4KP22Q4WV6V5P4HZQF7TKPU4T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New feature

[Ethan Furman]

On 10/17/20 10:54 AM, Marco Sulla wrote:


I think that in this case `clear` simply writes N enter chars, until
the terminal is "cleared". IMHO this is the safest option.


'clear' should also leave the cursor in the upper-left position, which cannot 
be gotten by writing a bunch of line feeds.

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

[Python-ideas] Re: New feature

[Ethan Furman]

On 10/13/20 4:46 PM, Steven D'Aprano wrote:


And I [clear my screen] frequently, in both Python and bash. Because I never
remember the name of the bash command to do it (cls or clear?), and
Python doesn't have one, I just hold down the Enter key for a couple of
seconds until there's no clutter visible.


I use `reset` -- particularly handy when you cat a binary file.

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

[Python-ideas] Re: Curious : Why staticmethod if classmethods can do everything a static method can?

[Ethan Furman]

On 9/11/20 7:35 PM, Christopher Barker wrote:
-
> But the real question is why staticmethod at all?
>
> And the answer is that there is very little use for staticmethod in
> Python [...]


On 9/11/20 7:28 PM, Greg Ewing wrote:
-
> IMO, static methods are a kludge only needed in languages that make
> classes do double duty as modules, and also can't have class methods
> because classes aren't first-class objects.

-

I have a base class that holds the logic for converting from one data 
system to another.  The module that holds this base class also imports 
several utility functions from other places.


The subclasses that hold the unique code occasionally have to 
overwrite/extend some of the base class methods, which means also 
needing to import the utility functions (the subclasses live in 
different files).


Rather than having to keep track of the various utility methods, 
including adding more imports if the base class uses more with new 
functionality, I just


  get_fis_table = staticmethod(fisData)
  get_xid_records = staticmethod(get_xid_records)

and then the subclasses can do

  blah = self.get_xid_records(...)

without worrying where `get_xid_records` came from.

Without `staticmethod` I would have to have a thin wrapper around those 
utility methods -- obviously not insurmountable, but annoying; and I 
really like that Python is not usually annoying.


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

[Python-ideas] Re: 'Infinity' constant in Python

[Ethan Furman]

On 9/5/20 1:18 AM, Jeffrey Kintscher wrote:


My point was that importing "everything" into the global namespace


The only global namespace in Python is builtins [1].  Everything else is 
module or local.


and 
then finding that a new version of Python has a new global symbol that 
causes a symbol conflict in your code is not a reason to reject the 
change.


Actually, it is.  The benefit has to be pretty big to overcome backwards 
compatibility concerns.


  If you use a problematic practice and a change to Python causes 
a symbol conflict for you, that's on you, not Python.


An officially supported practice that is broken by Python is on Python. 
Again, the benefits would have to outweigh the code breakage.


--
~Ethan~


[1] `globals()` actually returns the module namespace.
___
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/FUIROFYWS7KLS26BI4TKILI26FFQ75YX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: still more use for pathlib.Path ....

[Ethan Furman]

On 8/20/20 6:06 PM, Christopher Barker wrote:

But for a while is was painful to use, 'cause there was som much code 
that still used strings for paths. That was made a lot better when we 
introduced the __fspath__ protocol, and then updated the standard 
library to use it (everywhere?).


Unfortunately not [1].  The __fspath__ protocol is supported in 
locations where a path is expected as an argument (e.g. os.path.join()); 
anywhere else it is not supported except by accident (meaning it could 
easily become actually unsupported in the future).


--
~Ethan~


[1] https://bugs.python.org/issue39461
___
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/C2N4UZWM7LJCGX46GE2SOJ7OF6TAODSD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Ethan Furman]

On 8/5/20 11:11 AM, Jonathan Goble wrote:

That's literally useless, because after running that there is nothing 
stopping you from doing:


 >>> a = 10

or even:

 >>> a = "python has no constants"

And now a has a value different from 5.

There is nothing even remotely resembling const-ness to that class. In 
order to get const-ness, you would need the ability to overload 
assignments, like C++ can do. And Python can't do that, and that's 
probably a good thing.


--> from aenum import Constant

--> class K(Constant):
...   a = 5
...   b = 'hello'
...

--> K.a


--> K.a == 5
True

--> K.a - 3
2

--> K.a = 9
Traceback (most recent call last):
  ...
AttributeError: cannot rebind constant 

--> del K.a
Traceback (most recent call last):
  ...
AttributeError: cannot delete constant 

However, one can, of course:

del K

There is only so much one can do.  ;-)

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

[Python-ideas] Re: Decorators for class non function properties

[Ethan Furman]

On 8/5/20 10:54 AM, David Mertz wrote:

I'm not advocating it, and I'm not the one that came up with it. But my 
impression is that it is intended to mean:


a = const('a', 5)

This doesn't seem completely pointless:


class const():

...     def __init__(self, name, val):
... self.name = name
...         self.val = val
...     def about(self):
...         print(self.name, '=', self.val)
...

a = const('a', 5)
a.val

5

a.about()

a = 5

There might be a way to subclass, e.g. int, so that you don't need to 
use `a.val` to get the value.  It wasn't obvious to me how to do it in 
pure Python with 3 minutes thought.


--> from aenum import Constant

--> class K(Constant):
...   a = 5
...

--> K.a


--> K.a == 5
True

--> K.a - 3
2

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

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Ethan Furman]

On 7/28/20 10:30 PM, Rob Cliffe via Python-ideas wrote:

A possible, unrelated, future language extension is to allow breaking 
out of more than one loop at a time.


I would think that

break 

would handle that situation.

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

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

[Ethan Furman]

On 7/27/20 5:00 PM, Christopher Barker wrote:


I guess this is the part I find confusing:

when (and why) does __eq__ play a role?


__eq__ is the final authority on whether two objects are equal.  The 
default __eq__ punts and used identity.



On Mon, Jul 27, 2020 at 12:01 PM Ethan Furman wrote:



However, not all objects with the equal hashes compare equal themselves.


That's the one I find confusing -- why is it not "bad" for two objects 
with the same hash (the 42 example above) to not be equal? That seems 
like it would be very dangerous. Is this because it's possible, if very 
unlikely, for ANY hash algorithm to create the same hash for two 
different inputs? So equality always has to be checked anyway?


Well, there are a finite number of integers to be used as hashes, and 
potentially many more than that number of objects needing to be hashed. 
So, yes, hashes can (and will) be shared, and equality must be checked also.


For example, if a hash algorithm decided to use short names, then a 
group of people might be sorted like this:


Bob: Bob, Robert
Chris: Christopher, Christine, Christian, Christina
Ed: Edmund, Edward, Edwin, Edwina

So if somebody draws a name from a hat:

  Christina

You apply the hash to it:

  Chris

Ignore the Bob and Ed buckets, then use equality checks on the Chris 
names to find the right one.



From a practical standpoint, think of dictionaries:


(that's the trick here -- you can't "get" this without knowing something 
about the implementation details of dicts.)


Depends on the person -- I always do better with a concrete application.


adding
--
- objects are sorted into buckets based on their hash
- any one bucket can have several items with equal hashes


is this mostly because there are many more possible hashes than buckets?


Yes.


- those several items (obviously) will not compare equal


So the hash is a fast way to put stuff in buckets, so you only need to 
compare with the others that end up in the same bucket?


Yes.


retrieving
--
- get the hash of the object
- find the bucket that would hold that hash
- find the already stored objects with the same hash
- use __eq__ on each one to find the match


So here's my question: if there is only one object in that bucket, is 
__eq__ checked anyway?


Yes -- just because it has the same hash does not mean it's equal.

So what happens when there is no __eq__?The object can still be hashable 
-- I guess that's because there IS an __eq__ -- it defaults to an id 
check, yes?


Yes.

The default hash, I believe, also defaults to the object id -- so, by 
default, objects are hashable and compare equal only to themselves.


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

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

[Ethan Furman]

On 7/27/20 11:15 AM, Christopher Barker wrote:

On Sun, Jul 26, 2020 at 8:25 PM Guido van Rossum wrote:



In fact, defining `__hash__` as returning the constant `42` is
better, because it is fine if two objects that *don't* compare equal
still have the same hash value (but not the other way around).


Really? can anyone recommend something to read so I can "get" this -- 
it's counter intuitive to me. Is __eq__ always checked?!? I recently was 
faced with dealing with this issue in updating some old code, and I'm 
still a bit confused about the relationship between __hash__ and __eq__, 
and main Python docs did not clarify it for me.


Equal objects must have equal hashes.
Objects that compare equal must have hashes that compare equal.

However, not all objects with the equal hashes compare equal themselves.

From a practical standpoint, think of dictionaries:

adding
--
- objects are sorted into buckets based on their hash
- any one bucket can have several items with equal hashes
- those several items (obviously) will not compare equal

retrieving
--
- get the hash of the object
- find the bucket that would hold that hash
- find the already stored objects with the same hash
- use __eq__ on each one to find the match

So, if an object's hash changes, then it will no longer be findable in 
any hash table (dict, set, etc.).


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

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

[Ethan Furman]

On 7/26/20 10:31 AM, Henry Lin wrote:

You're right, declaring `__eq__` for the class we want to compare would 
solve this issue. However, we have the tradeoff that


  * All classes need to implement the `__eq__` method to compare two
instances;


I usually implement __eq__ sooner or later anyway -- even if just for 
testing.



  * Any class implementing the `__eq__` operator is no longer hashable


One just needs to define a __hash__ method that behaves properly.


  * Developers might not want to leak the `__eq__` function to other
developers; I wouldn't want to invade the implementation of my class
just for testing.


And yet that's exactly what you are proposing with your object compare. 
If two objects are, in fact, equal, why is it bad for == to say so?


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

[Python-ideas] Re: Deprecation of Enum members

[Ethan Furman]

On 7/23/20 12:24 PM, s.williamswynn.m...@gmail.com wrote:


I have run into a situations when an enum member becomes obsolete.
However, I'd like to avoid removing the member from the enum to give time for 
users to catch up to a libraries core types.


This would be good.


I've seen Java has a @Deprecated annotation for their Enums.
Python enum's can also set an _ignore_ attribute which will avoid instantiating 
a member in the list.


The purpose behind _ignore_ is to be able to use temporary variables 
without those variables becoming members.



I've implemented a similar approach to solve deprecating enum members.

You can check it out here: https://github.com/foxyblue/cpython/pull/1


Interesting.  I prefer the approach in my Stackoverflow answer:

  https://stackoverflow.com/a/62309159/208880

Yours is quite similar, but mine is more general-purpose and so easily 
allows for a useful message as well.


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

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Ethan Furman]

On 7/20/20 7:34 AM, Barry Scott wrote:


To avoid the ambiguity of `if` after `for` why not follow `for` with `elif`?

for x in ...:
...

elif break:
# break was called
elif not break:
# looped at least once and break not used
elif pass:
# same as else today
# loop'ed no times

(I always have to think what else means after a for).


Keep thinking... ;)

`else` today /does not/ mean "loop'ed no times".  To copy Steven 
D'Aprano's example:



py> for x in [1,2]:
... print("inside loop")
... else:
... print("elif never looped")
... 
inside loop

inside loop
elif never looped


Mistaking the semantics for "if never looped" is a very common mistake. 
Welcome to the club :-)


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

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Ethan Furman]

On 07/11/2020 09:16 PM, Rob Cliffe via Python-ideas wrote:


My gut feeling (backed by no evidence) is that dealing with the case of zero 
iterations is not needed frequently enough to cater for it.


My personal experience is that the case of no iterations is frequent enough, 
and a big enough pain to deal with, that if we're making changes we should 
include a way to deal with it.  Currently:

if empty_iterable:
# do whatever
else:
for it in iterable:
# do something

or maybe:

obj = object
for obj in some_iterator:
do_stuff()
if obj is object:
# iterator was empty
do_different_stuff()

Either way,

for obj in iterator:
do_stuff
elif empty:
do_other_stuff()

would be much nicer.

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

[Python-ideas] Re: Add builtin function for min(max())

[Ethan Furman]

Operator chaining -- gotcha.

Thanks Dominik and Ronald!

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

[Python-ideas] Re: Add builtin function for min(max())

[Ethan Furman]

On 07/03/2020 05:03 PM, Steven D'Aprano wrote:


 def clamp(value, lower, upper):
 """Clamp value to the closed interval lower...upper.

 The limits lower and upper can be set to None to
 mean -∞ and +∞ respectively.
 """
 if not (lower is None or upper is None):
 if lower > upper:
 raise ValueError('lower must be <= to upper')
 if lower == upper is not None:
 return lower
 if lower is not None and value < lower:
 value = lower
 elif upper is not None and value > upper:
 value = upper
 return value


I'm having a hard time understanding this line:

   if lower == upper is not None:

As near as I can tell, `upper is not None` will be either True or False, 
meaning the condition will only ever be True if `lower` is also either True or 
False, and since I would not expect `lower` to ever be True or False, I expect 
this condition to always fail.  Am I missing something?

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

[Python-ideas] Re: Bringing the print statement back

[Ethan Furman]

On 06/11/2020 01:18 PM, Rob Cliffe via Python-ideas wrote:


If the new super-duper all-singing-and-dancing-and-make-the-tea parser can cope 
with
'print' without parens, it can cope with print followed by nothing. Good 
addition to the proposal, actually. :-)
(Repeated for clarity: I'm in favour of the proposition for 'print' only.)


If
print

prints a blank line, how are you going to access the "print" function as an 
object?

An academic question at this point as Guido has withdrawn the proposal.

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

[Python-ideas] Re: Bringing the print statement back

[Ethan Furman]

On 06/09/2020 05:06 PM, Guido van Rossum wrote:


One thing that the PEG parser makes possible in about 20 lines of code is 
something not entirely different from the old print statement. I have a 
prototype:

>>> print 2+2
4
>>> print "hello world"
hello world



There are downsides too, though. For example, you can't call a method without 
arguments:

>>> print



What happens with "print ," ?  (Just curious.)


No, it's not April 1st. I am seriously proposing this (but I'll withdraw it if the 
response is a resounding "boo, hiss"). After all, we currently have a bunch of 
complexity in the parser just to give a helpful error message to people used to Python 
2's print statement:


While I will happily admit that too many parentheses make it hard to read code, 
for me at least too few is also a problem.  Besides the mental speed-bump of a 
missing parenthesis (that I could possibly get used to) we would then have more 
exceptions to memorize as to when the outer-pair of parentheses are needed and 
when they aren't.

Here's a line of code from one of my code bases:

  Path(table._fnxfs_root) / table._fnxfs_path / column.path

Would I need that first set of parens?

  Path table._fnxfs_root / table._fnxfs_path / column.path

I don't think the extra mental complexity is worth it, and I certainly don't 
mind using parentheses with print.

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

[Python-ideas] Re: Python __main__ function

[Ethan Furman]

On 05/28/2020 01:05 PM, tritium-l...@sdamon.com wrote:


People write main entry points that are not exactly this?

If __name__ == '__main__':
 sys.exit(main(sys.argv[1:]))


I have never written an entry point that looks like that.

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

[Python-ideas] Re: How to propose a change with tests where the failing test case (current behaviour) is bad or dangerous

[Ethan Furman]

On 05/27/2020 05:53 PM, Rob Cliffe via Python-ideas wrote:


No, I downloaded a 3rd-party package.  I'm not sure if that's "specialist 
sotware" by your definition.
I won't name it here, but it was dead easy to install and use and works 
perfectly.
Personally I'd recommend it.


You'd recommend it, but you won't name it?  Hmmm. ;)

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

[Python-ideas] Re: Enhance list.index with a comparison function

[Ethan Furman]

On 05/22/2020 05:11 PM, David Mertz wrote:

On 05/22/2020 04:43 AM, Steven D'Aprano wrote:



i = somelist.index(needle, pred=comparison)



Why not just this (by object, not by its index, but that seems simpler):

  >>> do_something(next(filter(pred, somelist)))
  Something about 55
  >>> somelist
  [3, 4, 29, 23, 46, 55, 90, 81]
  >>> pred
  


Steven, using David's example list, what would `needle` and `comparison` be in 
your proposal?

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

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Ethan Furman]

On 05/20/2020 12:44 AM, Chris Angelico wrote:

On Wed, May 20, 2020 at 4:36 PM Thierry Parmentelat wrote:



I also reckon it is still cumbersome to simply enter Unicode characters
 from a keyboard sometimes; I guess if the big players were located in
 other countries that would maybe be different.But that will change
 over time, no matter the speed, some day that will be for granted.So
again maybe 2020 is the right time to break that barrier ?


The Dvorak keyboard was invented nearly a hundred years ago. How's it
looking as a viable alternative?


Well, 25 years ago I had to write my own Dvorak device driver for use with
MS-DOS, now it's included in at least Windows and Linux (a Dvorak mapping,
not my device driver).

So much more viable.  :)


If you think that a keyboard with fancy arrows on it will take off any
quicker, you're extremely hopeful.


I wouldn't be surprised if it did, although a standard set of keyboard
shortcuts is more likely.


MUCH more practical will be to use vim conceal etc, leave your source
code unchanged, and just change the way it looks to you. There are
similar features available in a number of editors.


I'll have to look into that.

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

[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[Ethan Furman]

On 05/17/2020 12:02 PM, Rob Cliffe via Python-ideas wrote:

On 17/05/2020 19:43, David Mertz wrote:



The API matter is really orthogonal to this.  My point here is that
 Nathan and some other discussants are operating under the assumption
 that: "Everyone really wants strict-zip but they just haven't had a
 way to express it conveniently. They all assume their iterables are
 the same length already, so this just adds a check."

I disagree strongly with that assumption.  I think that the actual
majority of my uses of zip are non-strict.


But a lot of users (including you, in a minority of cases) can, *if
they choose*, benefit from a 'strict' version.
So what is wrong (ceteribus paribus) with making it easy for them to
 do so?


Coefficient of friction.

Importing from a stdlib module is not a hardship, so going from the status quo to "from 
itertools import zip_strict" is already making it "easy for them to do so".

Adding it as a flag makes it too easy (temptingly easy according to the PEP) to 
use zip_strict, so now the pendulum will swing the other direction and we'll 
get spurious errors.  Nothing dissuades from proper safety consciousness like 
spurious errors and excessive warnings. (YMMV)

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

[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[Ethan Furman]

On 05/17/2020 10:18 AM, Alex Hall wrote:


But it's good that we have the assert statement, because it makes it easy to 
write safe code and so people are encouraged to do so.


I could not disagree more strongly with this.  Every time I have seen assert 
used it was in such a way that the program could easily silently produce 
erroneous results or fail far from the error if asserts were turned off.

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

[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[Ethan Furman]

On 05/16/2020 01:16 AM, Steven D'Aprano wrote:

On Fri, May 15, 2020 at 05:46:43PM +0200, Antoine Pitrou wrote:



For me:

* zip(strict=True)   +1
* zip(mode='strict') -0
* itertools.zip_strict() -0.5
* zip.strict()   -1  (but really, I'd like to make this -1e10)


I spent a significant amount of time and mental energy explaining in
detail why a boolean flag is a poor API and is objectively the wrong
interface here. This is not just a matter of personal taste: there are
reasons why a flag is wrong here.


Did you mean for this to go to python-dev where the current discussion is at?

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

[Python-ideas] Re: Equality between some of the indexed collections

[Ethan Furman]

On 05/08/2020 09:36 AM, Alex Hall wrote:

On Fri, May 8, 2020 at 5:51 PM Henk-Jaap Wagenaar wrote:



FYI, it does show in my version on gmail and on the mailman version. 



Weird, did Ethan's client cut it out?


Ah, no.  I thought you were replying to the code quote above the .EQ. one.  The 
.EQ. quote was not white-space separated from the text around it and I missed 
it.

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

[Python-ideas] Re: Equality between some of the indexed collections

[Ethan Furman]

On 05/08/2020 07:50 AM, Alex Hall wrote:

On Fri, May 8, 2020 at 4:46 PM Henk-Jaap Wagenaar wrote:

On Fri, 8 May 2020 at 14:16, Steven D'Aprano mailto:st...@pearwood.info>> wrote:


If you have ever written something like any of these:

     all(x==y for x,y in zip(a, b))


That looks like a zip call that could do with checking its input or strict=True! 


Steven mentioned that originally:


(Aside: if we go down this track, this could be a justification for
zip_strict to be a builtin; see the current thread(s) on having a
version of zip which strictly requires its input to be equal length.) 


But since you probably want these expressions to evaluate to false rather than 
raise an exception when the lengths are different, a strict zip is not 
appropriate.


But if:

short_sequence == long_sequence[:len(short_sequence)]

then you'll get True.

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

[Python-ideas] Re: Equality between some of the indexed collections

[Ethan Furman]

On 05/05/2020 03:05 AM, Alex Hall wrote:

On Tue, May 5, 2020 at 7:36 AM Raymond Hettinger mailto:raymond.hettin...@gmail.com>> wrote:

 >> Isn't a tuple essentially just a frozenlist? I know the intended
 >> semantics of tuples and lists tend to be different, but I'm not sure 
that's
 >> relevant.




Alex, please be careful of your quoting -- Raymond did not say the above 
paragraph.

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

[Python-ideas] Re: zip(x, y, z, strict=True)

[Ethan Furman]

On 05/04/2020 12:07 PM, Alex Hall wrote:


No, I stand by my position for now that "just in case" is a genuine reason


"just in case" is boiler-plate.  One of the huge wins in Python is its low 
boiler-plate requirements.  It's okay if programmers have to think about their code and 
what's required, and it's even more okay to import the correct functions from a module -- 
especially if that module is already in the stdlib.

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

[Python-ideas] Re: zip(x, y, z, strict=True)

[Ethan Furman]

On 05/04/2020 12:35 PM, Alex Hall wrote:


I imagine there are few people who are too lazy to copy code from SO right now, 
and would be too lazy to import from itertools when the feature becomes 
available, but if it's a builtin then they're willing to make changes


Quite frankly, I have zero concern for people who are unwilling to import the 
correct function from the correct module.

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

[Python-ideas] Re: Introduce 100 more built-in exceptions

[Ethan Furman]

On 05/01/2020 02:19 AM, Steven D'Aprano wrote:


Best practice is to put try...except around only a *single* operation
which may raise what you want to catch. Of course that's easier said
than done, especially since nearly anything can raise nearly anything.


The follow-on to that is to only catch what you can recover from.


But in practice, it is surprisingly more practical than it sounds in
theory.


Since not every problem can be recovered from and therefore shouldn't be caught.

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

[Python-ideas] Re: zip(x, y, z, strict=True)

[Ethan Furman]

On 04/30/2020 07:58 AM, Christopher Barker wrote:

On 04/29/2020 10:51 PM, Stephen J. Turnbull wrote:


I think that the issue of searchability and signature are pretty
compelling reasons for such a simple feature to be part of the
function name.


I would absolutely agree with that if all three function were in the same 
namespace (like the string methods referred to earlier), but in this case, one 
is a built in and the others will not be — which makes a huge difference in 
discoverability.

Imagine someone that uses zip() in code that works for a while, and then 
discovers a bug triggered by unequal length inputs.

If it’s a flag, they look at the zip docstring, and find the flag, and their 
problem is solved.


So update the `zip` docstring with a reference to `zip_longest`, `zip_equal`, 
and `zip_whatever`.

-1 on using a flag.

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

[Python-ideas] Re: Adding a "once" function to functools

[Ethan Furman]

On 04/27/2020 11:34 AM, Antoine Pitrou wrote:

On Mon, 27 Apr 2020 09:26:53 -0700 Ethan Furman wrote:



That is what I was saying -- that `once`, all by itself, could mean multiple 
things.


That's a good point.  A more explicit spelling would be `@call_once`,
what do you think?


I think that's a better name.


(that's also the C++ spelling, incidentally, but I suspect most
beginners won't care about that ;-))


Heh.

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

[Python-ideas] Re: Adding a "once" function to functools

[Ethan Furman]

On 04/27/2020 08:26 AM, Barry wrote:

On 27 Apr 2020, at 16:01, Ethan Furman wrote:



I'm objecting to using "beginners" as the basis for name choices for advanced 
topics.

Aside from that, `once` is a fine name.  I'm sure it means that a function can 
only be defined once, and subsequent definitions will either be ignored or 
raise, right?

>>> @once
... def my_unique_function(...):
... do_something_cool()
...
>>> def something_else():
... pass
...
>>> def my_unique_function(...):
... # uh oh, duplicate!
...
RuntimeError - duplicate function name detected



That needs a linter to spot I think.


Indeed.  Linters are great things, although it took me awhile to really 
appreciate them.


Or are you saying that once could be interpreted to mean I cannot do that 2nd 
def?


That is what I was saying -- that `once`, all by itself, could mean multiple 
things.

Although, really, what I am saying is that for a beginner to have the thought, "This 
function always returns the same result, but I can't call it immediately -- I wish there 
was a way to have it run once and then always return that first result," and go from 
there to caches and decorators stretches the bounds of credulity past the breaking point.

Perhaps we have different meanings for "beginners".

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

[Python-ideas] Re: zip(x, y, z, strict=True)

[Ethan Furman]

On 04/26/2020 08:56 PM, Christopher Barker wrote:


that seems not very "there's only one way to do it" to me.


The quote is "one obvious way".



It almost feels like the proponents of the new mode/function are hoping to avoid the 
processing that might need to be "rolled back" in some manner if there is a 
synchronization problem.


There is no way to "roll back" an iterator, unless you are writing custom ones 
-- in which case you'll need a custom zip to do the rolling back.

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

[Python-ideas] Re: Adding a "once" function to functools

[Ethan Furman]

On 04/27/2020 05:09 AM, Steven D'Aprano wrote:

On Sun, Apr 26, 2020 at 07:48:10PM -0700, Ethan Furman wrote:



How many beginners know they want to call a function only once?


More than the number who know about LRU caches.

Ethan, are you objecting to a self-descriptive name because it is too
confusing for beginners and lru_cache isn't? Because that's the argument
you seem to be defending.


I'm objecting to using "beginners" as the basis for name choices for advanced 
topics.

Aside from that, `once` is a fine name.  I'm sure it means that a function can 
only be defined once, and subsequent definitions will either be ignored or 
raise, right?

>>> @once
... def my_unique_function(...):
... do_something_cool()
...
>>> def something_else():
... pass
...
>>> def my_unique_function(...):
... # uh oh, duplicate!
...
RuntimeError - duplicate function name detected

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

[Python-ideas] Re: Adding a "once" function to functools

[Ethan Furman]

On 04/26/2020 05:11 PM, Steven D'Aprano wrote:

On Sun, Apr 26, 2020 at 06:43:06PM +0200, Alex Hall wrote:


It's not clear to me why people prefer an extra function which would be
exactly equivalent to lru_cache in the expected use case (i.e. decorating a
function without arguments). It seems like a good way to cause confusion,
especially for beginners. Based on the Zen, there should be one obvious way
to do it.


Indeed, and if you want to guarantee that a function is executed exactly
*once*, then a decorator called *once* is that Obvious Way.

How many beginners do you know who even know what a LRU cache is?


How many beginners know they want to call a function only once?

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

[Python-ideas] Re: zip(x, y, z, strict=True)

[Ethan Furman]

On 04/22/2020 02:03 PM, Steven D'Aprano wrote:


If they need to be *convinced* to use the new function, then they don't
really need it and didn't want it.


Sadly, it is not human nature to just accept that one needs something when they have been 
getting along "just fine" without it.

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

[Python-ideas] Re: zip should return partial results in StopIteration

[Ethan Furman]

On 04/22/2020 07:08 AM, Soni L. wrote:


I have, more than once, had a desire to use zip to partially consume an 
iterator from a set of iterators, and then pass the rest onto something else. 
it'd fit in with that.

it's a small quality of life improvement that'd make zip even more useful than 
it is today, and I'm pretty sure it can't break anything because zip (as is 
documented) already puts None in the StopIteration. (whether the implementation 
follows that is another story, I haven't checked, but that'd be even more of a 
reason to change this.) not sure why so much pushback from you.


Because it's one more thing that would require support, that would only be 
rarely used.  Specialized bits are usually left to third-parties and not put in 
the stdlib without mitigating circumstances.  In this case there are enough 
possible specialized uses and requirements and desired outcomes that the stdlib 
should stay out of it.

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

[Python-ideas] Re: zip(x, y, z, strict=True)

[Ethan Furman]

On 04/21/2020 07:33 AM, Brandt Bucher wrote:


I know that I, and everyone on my team, would use it frequently!


Have you written your own version that does this check for input iterable 
equality?

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

[Python-ideas] Re: zip(x, y, z, strict=True)

[Ethan Furman]

On 04/21/2020 12:58 PM, David Mertz wrote:


>>> it1 = iter([1,2,3])
>>> it2 = iter([4,5])
>>> it3 = iter([6,7,8, 9])
>>> list(zip(it1, it2, it3))
[(1, 4, 6), (2, 5, 7)]

next(it3)

8




[...] worse is that most versions being discussed here seem to consume the 8 
from it3 before raising the exception [...] in my code it3 remains a perfectly 
good iterator that I can keep around to pull more values from.


it3 may be still usable, but it1 is not:

  >>> next(it1)
  Traceback (most recent call last):
File "", line 1, in 
  StopIteration

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

[Python-ideas] Re: More appropriate behavior for the NotImplemented object

[Ethan Furman]

On 03/11/2020 11:16 AM, Andrew Barnert via Python-ideas wrote:

On Mar 11, 2020, at 02:42, Steve Jorgensen wrote:



Take the following example:

```
def __lt__(self, other):
return not self.__ge__(other):

def __le__(self, other):
return not self.__gt__(other):

def __ge__(self, other):

```


Usually you can just use @total_ordering.


Even @total_ordering suffered from this bug for a number of years.


 [...] you [may] just want `return not self >= other` [in the `__dunder__`]


It's been my experience that when working with `__dunders__`, I'm better off
sticking with `__dunders__`, at least with the rich comparison operators.


[...] you really do need to deal with their API, including testing for
 NotImplemented with it.


Forgetting to deal with `NotImplemented` is a common mistake.  Is there any
context in which `bool(NotImplemented)` actually makes sense?


So this doesn’t seem like much of a problem, much less a problem worth
 breaking fundamental truthiness for a builtin type.


Considering that the stdlib itself has suffered from it, I would say it's more
than a small problem.

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

[Python-ideas] Re: New explicit methods to trim strings

[Ethan Furman]

On 03/07/2020 05:31 AM, Alex Hall wrote:


I've defined functions like this in my own utility library and I use them
 all the time, so I think they're very useful and would like to seem them
 built in. But I have two functions for each end:

def strip_optional_suffix(string, suffix):
 ...

def strip_required_suffix(string, suffix):
 ...

And I know that I use the required versions much more often, because
 usually if the suffix isn't there that indicates a bug somewhere that I
 need to know about. So I'd like to have both the optional and required
 versions implemented in this proposal, and if that's too much to add then
 just the required versions. But I suspect most people will be against the
 idea.


Against only having the required versions, yes.  However, we do have other 
functions that take an extra parameter to determine whether to raise an 
exception, so perhaps:

def strip_suffix(string, /, required=False):
...

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

[Python-ideas] Re: New explicit methods to trim strings

[Ethan Furman]

On 03/06/2020 04:03 PM, Steven D'Aprano wrote:

On Thu, Mar 05, 2020 at 12:45:28PM -0800, Andrew Barnert via Python-ideas wrote:



Well, I like the idea if someone can come up with a good naming
scheme—something that at least reminds me which function is the “set
of chars” stripper and which the “substring” stripper,


You've been a Python programmer for how many years now? Do you currently
have trouble remembering what lstrip and rstrip do?


Speaking for myself, about 13 years.  And, yes, I do occasionally forget that 
the strips are character based.  I can easily imagine it's worse for polyglot 
programmers.



We already have `[l|r]strip` methods. If we want to associate the new
methods with those, I suggest

 strip_prefix
 strip_suffix


Works for me.  Easy to add to bytes, too, if somebody is so inclined.

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

[Python-ideas] Re: New explicit methods to trim strings

[Ethan Furman]

On 03/06/2020 04:07 PM, Steven D'Aprano wrote:

On Fri, Mar 06, 2020 at 03:33:49PM -0800, Ethan Furman wrote:



I think we should have a `stripstr()` as an alias for strip, and a new
`stripchr()`.


Shouldn't they be the other way around?

`strip` removes chars from a set of chars; the proposed method will
remove a prefix/suffix.


Um, yeah.  Thanks for catching that.

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

[Python-ideas] Re: New explicit methods to trim strings

[Ethan Furman]

On 03/06/2020 02:59 PM, Guido van Rossum wrote:

On Fri, Mar 6, 2020 at 2:19 PM Steven D'Aprano wrote:



Can we just fix this?

Obviously there will be a month of bike-shedding arguments about the
names *wink* but can we at least agree that this is a genuine source of
confusion and a useful addition to the string API?


Yes.


Excellent.

I think we should have a `stripstr()` as an alias for strip, and a new 
`stripchr()`.

And I'm perfectly okay with bytes() not having those methods.  ;-)

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

[Python-ideas] Re: Exception for parameter errors

[Ethan Furman]

On 03/04/2020 06:24 AM, Steven D'Aprano wrote:


My earlier use-case still stands: feature detection where a function has
changed its parameter list. More on this below.


It seems like `inspect.signature` is the right way to do this kind of
feature detection.



On Wed, Mar 04, 2020 at 12:19:25PM +0200, Alex Hall wrote:

If you catch ParameterError, how do you know that it came directly from the
line you caught it from and not deeper within?


On 03/04/2020 06:24 AM, Steven D'Aprano wrote:

Does it matter?

If the call aardvark(*args, hovercraft=1) leaks a ParameterError from
deep inside its internals, then even if the feature is technically
available according to a version check, it is too buggy to use and I
need to use my wrapper.


This feels like a separate problem than "the function I'm calling changed
it's signature".



On Wed, Mar 04, 2020 at 12:19:25PM +0200, Alex Hall wrote:

If you want to check that you're passing parameters properly, I suggest
writing code like this:

import inspect

signature = inspect.signature(func)


And what if the function I'm checking doesn't support signature
metadata?

https://docs.python.org/3/library/inspect.html#inspect.signature


Looks like ValueError and TypeError can be raised, so it seems like the question
is how often?  If it only fails rarely or seldom then the case for more built-in
exceptions is weakened.



I can wrap the call to signature() in try...except, but what's my
fallback if I can't check the signature?

 py> inspect.signature(math.gcd)
 Traceback (most recent call last):
 [...]
 TypeError: 'feature_version' is an invalid keyword argument
 for compile()


In those cases you'll need to use the existing TypeError -- and with unit tests 
to
ensure things are working correctly on the different versions you're targeting
you'll know you're good to go.

By the way, `inspect.signature(math.gcd)` works for me on Python 3.8.2 -- which
version were you testing with?

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

[Python-ideas] Communication on mailing lists [was: Add a __valid_getitem_requests__ protocol]

[Ethan Furman]

On 02/23/2020 03:01 PM, Steven D'Aprano wrote:


I've been sitting on this email for the best part of a week. It hasn't
been an easy decision to decide to send it, because I expect it will
ruffle some feathers, including someone who, last time I ruffled his
feathers, banned me from one of the other mailing lists.


The relevant posts from the thread in question:

https://mail.python.org/pipermail/python-list/2018-September/887394.html
https://mail.python.org/pipermail/python-list/2018-September/887398.html
https://mail.python.org/pipermail/python-list/2018-September/887401.html
https://mail.python.org/pipermail/python-list/2018-September/887445.html
https://mail.python.org/pipermail/python-list/2018-September/887493.html
https://mail.python.org/pipermail/python-list/2018-September/887418.html
https://mail.python.org/pipermail/python-list/2018-September/887464.html


But I am part of this community, and if I'm too scared to state my
opinions for fear of retaliation, then I'm not really part of the
community, the supposed community values of being open and welcoming is
a sham, and it's best if I find out now.


That's pretty much what you said then.  Have you not returned to that mailing
list because you no longer feel like part of the community?


When I posted my reply to Rhodri, I wasn't intending to shine the
spotlight on his comment to Soni more than the simple statement I made:


(Rhodri has two 'r's in his name.)


But since Ethan disagreed with me, I should elaborate.


Rhodri James wrote:
--
Language, sunshine.

Steven D'Aprano wrote:
-
What about it?  Just for the record, I had no issues with Soni's language, but
I do object to attempts to shame him for it.

Ethan Furman wrote:
--
Since when is simply drawing one's attention to something shaming?

Steven explains:
---

Of course drawing attention to something can often be shaming and a
disguised attack:

 "You're fat. He's filthy. She's promiscuous. Your language is
 unacceptable and bad (and by implication, so are you)."

Having attention drawn to your social transgression is shaming. That's
why we do it: to stop people from transgressing again.


To me, "shaming" also requires a certain amount of meanness or cruelty (the
"attack" part), often suggested by the tone or body language of the person
commenting.  Hopefully we are all aware that tone is hard to achieve in the
written word, especially across continents and language barriers; body
language is, of course, completely absent.


"Language" is short for "Watch your language", a command, not an
observation or even a suggestion. But I'm pretty sure that you, Ethan,
already knew that. Defending Rhodri on the basis that he's merely stating
a fact is disingenuous.


Had I thought about it that way I would agree with you.  I did not, however, see
his comment as a command, nor do I agree that "Language" is always short for
"Watch your language", especially in the often terse environment of mailing
lists.


In Commonwealth English, calling someone you don't know "sunshine" is a
mock-friendly but actually hostile act, rather like the way "pal" or
"buddy" can be used in American English. Even if you did not know this,
you surely knew that in the context of this email thread, calling
someone "sunshine" is condescending, like calling them "pumpkin" or
"sweety-pie".


No, I did not know that.  And "pal" and "buddy" are no more hostile than any 
other
American English word unless used in a certain way -- a way made explicit by
tone and body language.

In fact, when I first read Rhodri's post I thought it meant something along
the lines of:  programming language -> pie in the sky perfection.  Hence, it
is possible to be too terse.


What Rhodi did was not "simply drawing one's attention", it was a
rebuke. Ethan, I find it difficult to believe that you did not know
that, and that your question was made in good faith.


I'm sorry you think so poorly of me.

Steven previously said:
--
This isn't the Disney Chanel, it's been over 100 years since Victoria was
Queen of England, and we're all adults here.

Ethan had replied:
-
Really?  I didn't realize those under the legal age of majority were not
allowed on this list.


Ethan, you've been involved with the Python community long enough to
know the meaning of "we're all adults here", and it doesn't mean
anything about legal age of majority.


Yes, it means we are responsible for our own code.


The point is, this is not a child-friendly space, this is an space for
adults. We shouldn't be expected to dumb-down our conversation to that
suitable for six year olds.


Using words that accurately describe a situation without using profanity
is not "dumbing down".


If there are any

[Python-ideas] Re: Incremental step on road to improving situation around iterable strings

[Ethan Furman]

On 02/22/2020 04:37 PM, Chris Angelico wrote:


Do any of the core devs agree with those two assertions?


If posts to -Ideas required core dev agreement this would be an empty list 
indeed.

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

[Python-ideas] Re: Add a __valid_getitem_requests__ protocol

[Ethan Furman]

On 02/19/2020 08:55 AM, Soni L. wrote:

On 2020-02-18 5:33 p.m., Soni L. wrote:



Similar to len(). Just a [crappy] wrapper for __valid_getitem_requests__.


Correction: Just a simple wrapper for __valid_getitem_requests__.


Hopefully unsurprisingly, those words do not mean the same:

simple: little if any extra functionality, possibly just a name redirect
crappy: serious performance penalties, weird/incorrect edge cases, different 
order of parameters, hard to understand code, etc.

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

[Python-ideas] Re: Add a __valid_getitem_requests__ protocol

[Ethan Furman]

On 02/18/2020 04:26 PM, Steven D'Aprano wrote:

On Tue, Feb 18, 2020 at 08:44:07PM +, Rhodri James wrote:



Language, sunshine.


What about it?

Just for the record, I had no issues with Soni's language, but I do
object to attempts to shame him for it.


Since when is simply drawing one's attention to something shaming?


This isn't the Disney Chanel,
it's been over 100 years since Victoria was Queen of England, and we're
all adults here.


Really?  I didn't realize those under the legal age of majority were not 
allowed on this list.

At any rate, we should be able to control what we say and how we say it, adult 
or not.

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

[Python-ideas] Re: Add __keys__ or __items__ protocol

[Ethan Furman]

On 02/18/2020 12:24 AM, Serhiy Storchaka wrote:


1. What special method should be added, `__keys__` or `__items__`? The former 
returns keys, it needs to call `__getitem__` repeatedly to get values. The 
latter returns key-value pairs, it does not need to call `__getitem__`, but you 
should always pay the cost of creating a tuple even if you do not need values.


`__items__`



2. What type should they return?

* An iterator.
* An iterable which can be iterated only once. Easy to implement in Python as 
generator methods.
* An iterable which can be iterated multiple times.
* More complex view object which may support other protocols (for example 
support `__or__` and `__and__`).


Whatever `dict.items()` returns, both for consistency and because 
`dict.items()` can become a simple alias for `dict.__items__`.



What do you think about this?


+1

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

[Python-ideas] Re: Traits

[Ethan Furman]

On 02/14/2020 02:24 PM, Soni L. wrote:


   class Foo(Trait):
     def x(self):
   raise NotImplementedError

   class Bar(Trait):
     def x(self):
   raise NotImplementedError

   class Baz(TraitObject):  # "mirrors" class Baz(object):
     @impl(Foo)
     class Foo:
   def x(self):
     pass
     @impl(Bar)
     class Bar:
   def x(self):
     pass


That looks like a lot of extra boiler-plate to me (aka busy-work, aka 
anti-Python).

Can you give us a real example using real code?  You say you've made a library 
-- show us the library being used in real life -- foo, bar, and baz is not 
explaining anything, particularly for those of us who have no knowledge of 
Rust, nor the time/desire to go learn it.

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

[Python-ideas] Re: Traits

[Ethan Furman]

On 02/14/2020 04:53 AM, Soni L. wrote:


That's not traits. That's its own thing. That's not even mixins, it just seems to be 
type-checked attributes. Nobody has implemented actual traits in Python yet, only mixins 
with extra steps and there are 2 libraries providing these type-checked attributes and 
calling them "traits" for whatever reason (they're not).


Probably because the word "traits" can be applied to more than one thing:

- a person's traits
- a family's traits
- a language's traits
- an attribute's traits
- a class' traits
- etc., etc.

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

[Python-ideas] Re: PEP 572: Is it a good ideas that walrus operator can be used in assertions since it causes side effects?

[Ethan Furman]

On 02/12/2020 10:00 AM, Andrew Barnert wrote:

On Feb 12, 2020, at 06:49, Ethan Furman  wrote:


On 02/11/2020 01:49 PM, Steven D'Aprano wrote:


Oh, definitely for the best. This now allows us to write complex
assertions much more easily and efficiently:
 assert log(flag := complex_expression) or flag


That doesn't seem very useful: for that assert to fail, `flag` would have to be 
falsey, and if falsey, then surely the log of it is not helpful?


You’ve never had some rare code path that’s missing a return, and wasted half 
an hour trying to figure out how you could possibly be getting 0 out of that 
calculation before realizing you’re actually getting None?


*sheepish grin*

Point taken.

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

[Python-ideas] Re: PEP 572: Is it a good ideas that walrus operator can be used in assertions since it causes side effects?

[Ethan Furman]

On 02/11/2020 01:49 PM, Steven D'Aprano wrote:


Oh, definitely for the best. This now allows us to write complex
assertions much more easily and efficiently:

 assert log(flag := complex_expression) or flag


That doesn't seem very useful: for that assert to fail, `flag` would have to be 
falsey, and if falsey, then surely the log of it is not helpful?

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

[Python-ideas] Re: PEP 572: Is it a good ideas that walrus operator can be used in assertions since it causes side effects?

[Ethan Furman]

On 02/11/2020 11:49 AM, jdve...@gmail.com wrote:


My point is: is it good to add a new way of causing side effects in assertions?


Good or not, it's not changing now.

It's probably safe to say that every new language feature adds one more way to 
break assertions.  It is our responsibility to have correct code.

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

[Python-ideas] Re: Traits

[Ethan Furman]

On 02/07/2020 01:40 PM, Greg Ewing wrote:

On 8/02/20 5:59 am, Soni L. wrote:



Traits are an alternative to Multiple Inheritance. They solve the problem of 
name conflicts by making them an ambiguity error and requiring you to 
disambiguate (at call site).


This sounds like something that would work better in a statically
typed language, where the compiler can figure it all out. Doing
it in Python would require run-time wrappers and incur overhead.


Or a metaclass.

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

[Python-ideas] Re: `raise as` to raise with current exception as cause

[Ethan Furman]

On 02/07/2020 09:06 AM, Anders Hovmöller wrote:




On 7 Feb 2020, at 16:59, Ethan Furman  wrote:

On 02/07/2020 07:44 AM, Anders Hovmöller wrote:


If the only difference is the text between the stack traces, why aren't you 
suggesting to change that text?


Because the text is important in what it implies.  See my other message for 
details.


Sorry but I still don't understand.

I agree the difference in text is a vast improvement. But I don't understand 
why the implicit case should have the bad text. Is that text actually better 
ever?


The original text is not bad -- it says, "hey!  you're error handler is busted!"

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

[Python-ideas] Re: `raise as` to raise with current exception as cause

[Ethan Furman]

On 02/07/2020 07:44 AM, Anders Hovmöller wrote:


If the only difference is the text between the stack traces, why aren't you 
suggesting to change that text?


Because the text is important in what it implies.  See my other message for 
details.

--
~Ethan~


Aside: please trim the parts of your previous post you are not replying to.  It 
makes following threads much easier.
___
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/PB5WVP3BCCQLB6GCYEZD3GGX4GZPODYU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: `raise as` to raise with current exception as cause

[Ethan Furman]

On 02/07/2020 07:33 AM, Serhiy Storchaka wrote:

07.02.20 16:28, Ram Rachum пише:

The idea is to add `raise as` syntax, that raises an exception while setting 
the currently caught exception to be the cause. It'll look like this:

     try:
         1/0
     except ZeroDivisionError:
         raise as ValueError('Whatever')

What it does is a shorter version of this:

     try:
         1/0
     except ZeroDivisionError as error:
         raise ValueError('Whatever') from error


How does it differ from

     try:
     1/0
     except ZeroDivisionError:
     raise ValueError('Whatever')


Here's a diff:

$ diff no_from.py with_from.py
3,4c3,4
- ... except ZeroDivisionError:
- ... raise ValueError('Whatever')
---
+ ... except ZeroDivisionError as e:
+ ... raise ValueError('Whatever') from e
10c10
- During handling of the above exception, another exception occurred:
---
+ The above exception was the direct cause of the following exception:


To me the difference between "raise from" and "raise" is the implicit meaning:

- "During handling of ..." implies that the second exception should not have 
occurred and there is a bug in the exception handling code

- "The above exception ..." implies that this code path is normal and extra 
information is being supplied

Personally, my main use of "raise from" is "raise from None".


I'm -1 on the new syntax: to me it looks much more like a "raise ... from None".

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

[Python-ideas] Re: addition of "nameof" operator

[Ethan Furman]

On 01/21/2020 02:08 PM, Chris Angelico wrote:


Yes, that's exactly what I mean, and exactly why self.__class__ is
used here. If you actually want "Person" even if it's actually a
Martian, you can use __class__.__name__ rather than
self.__class__.__name__ to get that.


Gotcha, thanks.  I'm still unsure what the OP wants, though.

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

[Python-ideas] Re: addition of "nameof" operator

[Ethan Furman]

On 01/21/2020 11:25 AM, Chris Angelico wrote:


I'm not sure how this compares to what nameof(Person) should return,
but the above idiom (or something like it) is very common in Python,
as it allows repr to acknowledge a subclass. If you create "class
Martian(Person): pass", then a Martian's repr will say "Martian". On
the other hand, if you actually want "the name of the surrounding
class", then that can be spelled __class__.__name__, and that will
always be Person even if it's been subclassed. Not nearly as common,
but available if you need it.


I'm not sure what you mean, but:

--> class Person:
... def __init__(self, name):
... self.name = name
... def __repr__(self):
... return '%s(name=%r)' % (self.__class__.__name__, self.name)
...

--> class Martian(Person):
... pass
...

--> p = Person('Ethan')
--> m = Martian('Allen')

--> p
Person(name='Ethan')

--> m
Martian(name='Allen')

(Same results with f-strings.  Whew!)

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

[Python-ideas] Re: Argumenting in favor of first()

[Ethan Furman]

On 12/05/2019 03:11 PM, Josh Rosenberg wrote:


"Also, the for-loop version quits the moment it finds a Product type, while the 
`first` version has to first process the entire jsonld_items structure."

The first version doesn't have to process the whole structure; it's written 
with a generator expression, so it only tests and produces values on demand, 
and next stops demanding them as soon as it gets a single result.


Ah, thanks.  My genexp foo is weak.  :(

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

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

[Ethan Furman]

On 12/04/2019 08:39 AM, Random832 wrote:

On Wed, Dec 4, 2019, at 08:26, Serhiy Storchaka wrote:

03.12.19 20:43, Brett Cannon пише:

-1 from me. I can see someone not realizing an operator was changed,
assuming it's standard semantics, and then having things break subtly.
And debugging this wouldn't be fun either. To me this is monkeypatching
without an explicit need for it, i.e. if you really want different
semantics in your module then define a function and use that instead of
influence-at-a-distance overriding of syntax.


This will also add a significant performance penalty to any code (even
if you do not use any hooks). -1 from me too.


My proposal was that any module that never uses any hooks compiles to the exact 
same bytecode, and executes exactly the same way, as it does now.


Are the low-level details, such as following the mro, in the bytecode?  If not, 
the bytecode would be the same either 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/5EW56XW24HFCCC2ZYZHJX6AWJR5S3EBQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Archiving Threads / Closing Threads

[Ethan Furman]

On 12/04/2019 04:44 AM, Abdur-Rahmaan Janhangeer wrote:


An advantage. If the topic goes round several times, the mods closing the topic 
freezes the thread so that the thread does not gets filled with unnecessary 
details.


By the time the topic has gone around  several times, it is already filled with 
unnecessary details.


The idea behind is that list threads are gem mines for Python programmers. If 
you've followed the thread as it was unspun, that's great. Else if you are 
reading the archives, you have to untangle the right thread from a mess.


It's still a mess even if following it in real-time.


Another advantage of the proposed idea might be to make programmers more 
responsible by writing what is necessary and as in depth as possible.


I have not seen that happen in /any/ method of discussion.

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

[Python-ideas] Re: Allow Path object instances in subprocess.Popen

[Ethan Furman]

On 11/03/2019 02:31 AM, Anders Hovmöller wrote:


Side note!


When switching subjects mid-thread, please re-title the subject.  This 
side-note sub-thread is now nearly as long as the original thread.

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

[Python-ideas] Re: Suggestion for behaviour change import mechanics

[Ethan Furman]

On 10/29/2019 06:33 AM, mer...@gmx.net wrote:


Anyways, just failing later would not hurt the Python language I think ;)


It would, as Stephen D'Aprano explained.

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

[Python-ideas] Re: add a .with_stem() method to pathlib objects

[Ethan Furman]

On 10/29/2019 10:41 AM, Paul Moore wrote:

On Tue, 29 Oct 2019 at 17:38, Ethan Furman  wrote:


On 10/29/2019 10:17 AM, Brian Skinn wrote:


I feel like the semantics of PurePath.suffix 
(https://docs.python.org/3/library/pathlib.html#pathlib.PurePath.suffix) and 
PurePath.stem define this pretty unambiguously.


It does indeed -- it declares the last bit to be the suffix.  So 
correspondingly, .with_stem() should be everything before the last bit, or:

[corrected examples]

p = Path("foo.bar.txt")
p.with_stem("quux")

  "quux.bar.txt"


Um,


Path("foo.bar.txt").suffix

'.txt'

So if ".txt" is the suffix, then with_stem("quux") should be "quux.txt", surely?


Argh.  Can I plead lack of coffee?  And since I don't drink coffee, that 
explains a lot.  ;-)

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

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

[Ethan Furman]

On 10/23/2019 01:08 PM, Steven D'Aprano wrote:

On Wed, Oct 23, 2019 at 11:59:44AM -0400, Todd wrote:


Compare that to:

colors2 = "cyan,forest green,burnt umber".split(',')


Sure, that's not going away. But consider that you're using this inside
a tight loop:

 for something in lots_of_items:
 for another in more_items:
 function(spam, eggs, "cyan,forest green,burnt umber".split(','))


If you have a tight loop that is a performance bottleneck (you did measure, 
right?), then you trade readability for performance.  This is not news.


That's easy to fix, you say. Move the list outside the loop:

 L = "cyan,forest green,burnt umber".split(','))
 for something in lots_of_items:
 for another in more_items:
 function(spam, eggs, L)

What's wrong with this picture?


Other than you're now using one list for all calls, and the function could by 
modifying that list?  You do know if the function modifies the list, right?  I 
give up, what is wrong with that picture?

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

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

[Ethan Furman]

On 10/23/2019 01:36 PM, Steven D'Aprano wrote:


Virtually overnight, the Python community got used to the opposite
change, with f-strings . . .


* citation needed

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

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

[Ethan Furman]

On 10/24/2019 04:03 AM, Steven D'Aprano wrote:

The current "obvious" solution is tedious, annoying, verbose (about a 
third longer than it need be) and error-prone.^1


--> print("So should we have syntax for sentence literals"
...   "so we don't forget spaces, too?")



^1 I'm gratified to see that nobody yet has noticed the error in my
earlier example involving the strings 'zero' through 'thirty', which
supports my point that the status quo is sub-optimal.


You said it was actual code, so I didn't pay close attention.  Does this mean 
you have now fixed an error in your code?  Your welcome.  ;-)


^2 On my computer the split idiom is about forty percent slower:

$ ./python -m timeit "['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h']"
20 loops, best of 5: 1.44 usec per loop

$ ./python -m timeit "'a b c d e f g h'.split()"
10 loops, best of 5: 2.05 usec per loop

so it's not a trivial slowdown, even if this is unlikely to be a
bottleneck in many programs.


I hope you're not declaring that a 0.6 usec slowdown on a single import is 
worth optimizing.

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

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

[Ethan Furman]

On 10/24/2019 07:07 AM, Steven D'Aprano wrote:

On Thu, Oct 24, 2019 at 02:00:50PM +0100, Rhodri James wrote:


The fact is, %w[...] doesn't look like anything else
Python does


It looks like a list display [...] with a prefix.


It looks like gobbledygook.

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

[Python-ideas] Re: Ability to set precedence of classdict (returned from __prepare__) for a metaclass type

[Ethan Furman]

On 10/22/2019 03:13 PM, Steve Jorgensen wrote:

Ethan Furman wrote:


Experimenting is good!  However, you'll want to either build your own metaclass

and/or prepared dict, or do some work on your __new__/__init__
methods for building enum members.  Currently, you are reassigning _value_ in
__init__, which leaves some internal structures not matching the Enum.
--> class Food(ChoiceEnum):
... APPLE = ()
... ICED_TEA = ()
...
--> Food['APPLE']

--> Food.APPLE

--> Food('APPLE')
Traceback (most recent call last):
...
ValueError: 'APPLE' is not a valid Food


Thanks for that info.

Per the example in 
https://docs.python.org/3/library/enum.html#when-to-use-new-vs-init, it looks 
like I can properly set the `_value_` property in the `__new__` method of the 
`Enum` subclass without needing to subclass `EnumMeta`. Am I understanding that 
correctly?


Yes, you are.  The fun part for you is that the value can sometimes be the 
name, and the name is not passed into `__new__`.

The name /is/ passed into `_generate_next_value_`, but if any value is supplied 
then `_generate_next_value_` isn't called.

I haven't had enough space cycles to either find a solution or rule any out, 
but I know the limitations above are baked into EnumMeta and _EnumDict, so if 
you rolled your own you could simply not put them in.

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

[Python-ideas] Re: Ability to set precedence of classdict (returned from __prepare__) for a metaclass type

[Ethan Furman]

On 10/21/2019 10:33 PM, Steve Jorgensen wrote:


 class ChoiceEnum(Enum):
 def __init__(self, src=None, label=None):
 super().__init__()
 
 if isinstance(src, Label):

 value = None
 label = str(src)
 else:
 value = src
 
 self._value_ = self.name if value is None else value

 self.label = label or _label_from_name(self.name)


Experimenting is good!  However, you'll want to either build your own metaclass 
and/or prepared dict, or do some work on your `__new__`/`__init__` methods for 
building enum members.  Currently, you are reassigning `_value_` in `__init__`, 
which leaves some internal structures not matching the Enum.

--> class Food(ChoiceEnum):
... APPLE = ()
... ICED_TEA = ()
...

--> Food['APPLE']


--> Food.APPLE


--> Food('APPLE')
Traceback (most recent call last):
  ...
ValueError: 'APPLE' is not a valid Food

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

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

[Ethan Furman]

On 10/20/2019 10:08 PM, Andrew Barnert via Python-ideas wrote:

On Oct 20, 2019, at 21:10, Stephen J. Turnbull wrote:



I'm not against having an operator for updating dicts, but "+" is not
it.  "|" is fine, though.


It seems like people who don’t really like this feature and don’t plan to use 
it mostly really want it to be spelled | if it has to be added. But people who 
are dying for it mostly want + (except for the ones who want all the set 
operators). I’m not sure what that means…


I really don't want it as '+'.  I'm happy to use it as '|'.  :)

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

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

[Ethan Furman]

On 10/20/2019 03:06 PM, Guido van Rossum wrote:

So the choice is really only three way.




1) Add d1 + d2 and d1 += d2 (using similarity with list + and +=)
2) Add d1 | d2 and d1 |= d2 (similar to set | and |=)
3) Do nothing



In the end I'm +0.5 on | and |=, +0 on + and +=, and -0 on doing nothing.


One of the things I really enjoy about Python is its consistency:

- dicts and sets are both hash tables
- dicts and sets both disallow duplicates
- dicts and sets both use .update()

Adding '|' to dict to be consistent with '|' on sets seems a reasonable, and 
not a foolish, consistency.


+1 on '|' and '|='


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

[Python-ideas] Re: Ability to set precedence of classdict (returned from __prepare__) for a metaclass type

[Ethan Furman]

On 10/19/2019 11:25 PM, Andrew Barnert via Python-ideas wrote:

On Oct 19, 2019, at 22:57, Steve Jorgensen wrote:


The idea is to use a class as a singleton collection of choices where every 
choice appears both as an attribute of the class/singleton and as a value/label 
pair when treating it as a sequence.


What you’re looking for is a way to auto-assign attributes on lookup during 
class definition. Which is an idea that was actually brought up for enums, and 
specifically rejected in PEP 435, but there’s a proof of concept implementation 
of it anyway if you want it.


It is actually implemented in the `aenum`* library.  The code in question is in 
_EnumDict, and my workaround for the problem was another variable (IIRC, 
_ignore_) that listed any names that were outside the Enum's scope.

--
~Ethan~


* disclosure: I'm the one to hold responsible for the stdlib enum, enum34, and 
aenum.
___
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/QZUKIRRV7KOOBS2FN4KNLA7QEOBAUFGB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Ability to set precedence of classdict (returned from __prepare__) for a metaclass type

[Ethan Furman]

On 10/19/2019 07:56 PM, Steve Jorgensen wrote:


When using a custom classdict to implement a DSL or use in the body of a class 
definition, from what I can tell by experiment, the classdict takes priority, 
and the surrounding context is only referenced if trying to get an item from 
the classdict raises `KeyError`.


An example would work wonders for explaining what you are asking.  It sounds 
like an interesting problem, but I can't tell exactly what you need.

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

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

[Ethan Furman]

On 10/18/2019 10:25 AM, Steven D'Aprano wrote:

On Fri, Oct 18, 2019 at 09:17:54AM -0700, Ethan Furman wrote:


That result just doesn't match up with the '+' operator.


Why not?


Pretty sure I answered that question in my OP.  Here it is again since you 
conveniently stripped it out:


The problem is that dicts are complex objects with two pieces of
information, and the results of + and += don't match what happens
 when two dicts are combined.  For an easy demonstration of this:

--> a = {'some_key': 'some value}

--> a += {'some_key': 'another value'}

--> a
{'some_key': 'another value'}


That result just doesn't match up with the '+' operator.  For what
 it's worth, I don't think the '|' operator works any better.




Before answering, please check the PEP to see if your objection has
already been raised.


What do you know, it had been!

PEP 584:
---

Dict addition is lossy
Dict addition can lose data (values may disappear); no other form
of addition is lossy.

Response:

It isn't clear why the first part of this argument is a problem.
dict.update() may throw away values, but not keys; that is expected
behavior, and will remain expected behavior regardless of whether
it is spelled as update() or +.


It's a problem because the method is named "update", not "add", "join", or "combine".  
The dict "+" operator is being turned into a deduplication operator - as if, for example:

--> [1, 2, 3] + [3, 4, 5]
[1, 2, 3, 4, 5]  # not what happens



The second definition of "add" in Webster's dictionary is "to join or
unite", which matches dict merging very well.


No, it doesn't -- not in the case of duplicate keys.  If we had two people named 
"Steve" and joined them into a group, would you expect one of them to just 
disappear?  Even better, if we had two engineers (key) named Anita and Carolyn (values) 
and combined them into a group, do you expect one of them to vanish?



It is perfectly natural and obvious for English speakers to think of
addition as more than just the narrow definition of numeric addition.


Indeed it is, and indeed I do.  You may notice, however, that I didn't use that 
argument.


If you're going to deny that standard, common understanding of "plus" as
combining, and claim that it "just doesn't match up" in defiance of
common practice, you ought to have a good reason why all those who refer
to dict addition or adding dicts are wrong to do so.


As I'm sure you are aware, natural language is inherently ambiguous.  Python is not a 
natural language.  It is my contention that the operation of combining two data 
structures together that results in data loss should not be called "+".  As it 
happens, the Python set() agrees:

Python 3.6.5 (default, Apr  1 2018, 05:46:30) 
[GCC 7.3.0] on linux

Type "help", "copyright", "credits" or "license" for more information.
--> set([1, 2, 3]) + set([2, 3, 4])
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unsupported operand type(s) for +: 'set' and 'set'


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

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

[Ethan Furman]

On 10/16/2019 10:35 PM, Brandt Bucher wrote:


At long last, Steven D'Aprano and I have pushed a second draft of PEP 584 
(dictionary addition):



Please let us know what you think – we'd love to hear any *new* feedback that 
hasn't yet been addressed in the PEP or the related discussions it links to! We 
plan on updating the PEP at least once more before review.


My apologies if this feedback is not new; I did not follow the first round.

Looking at the codebase I support (OpenERP 7.0), I see extensive use of the 
update() method.  I went through and replaced a few of them with += to try and 
get a feel for it.

+ and += are a cognitive mismatch for update().

The problem is that dicts are complex objects with two pieces of information, 
and the results of + and += don't match what happens when two dicts are 
combined.  For an easy demonstration of this:

--> a = {'some_key': 'some value}

--> a += {'some_key': 'another value'}

--> a
{'some_key': 'another value'}


That result just doesn't match up with the '+' operator.  For what it's worth, 
I don't think the '|' operator works any better.

Reviewing my code base, I do see a benefit in replacing the updates() with an operator, 
but I'm not aware of any operator that captures the "update" results.

-1 on the PEP.

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

[Python-ideas] Re: RFC: PEP xxx: Python Compatibility Version

[Ethan Furman]

On 10/17/2019 06:02 PM, Victor Stinner wrote:


I propose the following PEP to add
sys.set_python_compat_version(version) to introduce a partial
compatibility with Python 3.8 in the next Python 3.9 version.


-1


If possible, please try to read the whole PEP before replying.


Done.

TL;DR  Besides being a maintenance burden, and one more source of bugs, it will be a 
debugging nightmare -- especially if different levels of "back-compatibility" 
have been selected.



Rationale
=

The need to evolve frequently
-

To remain relevant and useful, Python has to evolve frequently. Some
enhancements require incompatible changes. Any incompatible change can
break an unknown number of Python projects.  Developers can decide to
not implement a feature because of that.


Is "developer" an app developer or a library developer?  Either way, such 
developers are constrained by the lowest python version they support.

How many versions back are we going to allow?  If we don't support each and every 
breaking change then some application/library is going to be inoperable at the latest 
Python version, even with "back compatibility".



Users want to get the latest Python version to get new features and
better performance. A few incompatible changes prevent them to use their
applications on the latest Python version.


If they have to enable back-compatibility mode they still aren't getting the 
latest features/performance.  Also, if the app isn't using these new features 
(even without back-compatibility), how are they benefiting the user?



Partial compatibility to minimize the Python maintenance burden
---

Backward compatibility code will be dropped at each Python release, on a
case by case basis. Each compatibility function can be supported for a
different number of Python releases depending on its maintenance cost
and the estimated risk (number of broken projects) if it's removed.


How will we estimate this number?  What's the minimum?  Is that minimum number 
dependent on the user base of those projects?  How do we estimate that?



Upgrade a project to a newer Python
---

Without backward compatibility, all incompatible changes must be fixed
at once, which can be a blocker issue. It is even worse when a project
is upgraded to a newer Python which is separated by multiple releases
from the old Python.

Postponing an upgrade only makes things worse: each skipped release adds
more incompatible changes. The technical debt is only steadily
increasing.

With backward compatibility, it becomes possible to upgrade Python
increamentally in a project, without having to fix all issues at once.


Because the technical debt is now burdening Python instead.



The "all-or-nothing" is a showstopper to port large Python 2 code bases
to Python 3. The list of incompatible changes between Python 2 and
Python 3 is long, and it's getting longer at each Python 3.x release.


Are you saying we are going to add a Python2.7 compatibility layer?


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