[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.
On Tue, Oct 22, 2019 at 11:39:59AM -0700, Mike Miller wrote: > > On 2019-10-18 10:23, Ricky Teachey wrote: > >but i'm -0 because i am very concerned it will not be obvious to new > >learners, without constantly looking it up, whether adding two mappings > >together would either: > > The big trade off I'm gathering from this mega-thread is that the |, |= > operators are more accurate, but less obvious to newcomers, who will first > try +, += instead. I'm surprised by that description. I don't think it is just newcomers who either suggest or prefer plus over pipe, and I don't think that pipe is "more accurate". As I pointed out in the PEP, plus often gets used for non-commutative operations (such as concatenation and ordinal arithmetic) but I am unaware of the union operator ∪ or | as spelled in Python ever being used for a non-commutative operation. Contrary to the views of many people upset that dict + would be non- commutative, it is arguably *more natural* to use plus for a non- commutative operation than it would be to use pipe. The biggest advantage of pipe is that it naturally lends itself to the rest of the set operations. But using pipe for a non-commutative operator is far less common than using plus. > I've tried them in this order myself several times over the years. > > Had an idea, why not choose the more accurate syntax: |, |= after all? > Then, to help newcomers and forgetful pros a custom error message is > implemented for +, +=. In pseudo C/Python, something like this: > > class dict: > > def __add__(self, other): > > if isinstance(other, dict): > raise TypeError( > 'unsupported operand type(s) for +: … ' > 'Dictionary merging leads to last-value-wins data ' > 'loss. If acceptable, use the union "|" operator.' > ) I think that is patronising to anyone, newbies and experienced programmers alike, who know and expect that merging dicts with an operator will have the same semantics as merging them with the update method. > I think it is worth it to lead the newcomer to a moment's reflection on why > dictionary combining/merging is potentially lossy. Should we also force newcomers to give a moment's reflection on why item assignment ``mydict[key] = value`` is potentially "lossy"? How about ``mystring.replace(old, new)`` or opening a file for writing? I think that we should trust that when the programmer asks to update a dict with new values (either in-place or as a copy), it is because they don't want the old values any more. Even if they don't know what they are doing, it is not the place of the interpreter to treat them as an ignoramus that needs to be forced into reflecting on the consequences of their action, as if they were a naughty little schoolboy being told off by their headmaster. -- Steven ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6IXSSNMF3BUFOVRKBRMULWDHZ5PZDZYO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.
I'm not crazy about advertising APIs this way ("did you mean ..."), and
even if we would eventually decide to do this, I'm not sure that dict+dict
is the place to start. (Okay, we already started, with "print x" saying
"Did you mean print(x)?" -- but that shows how rare this should be IMO.)
Anyway, __add__ should return NotImplemented in the else branch, to give
C.__radd__ a chance in the case dict()+C() where C does not subclass dict.
I *think* it should then be safe but there are some traps here (e.g.
__radd__ sometimes gets called before __add__, if the right operand's class
is a subclass of the left operand's class).
On Tue, Oct 22, 2019 at 3:18 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> On Oct 22, 2019, at 11:39, Mike Miller wrote:
> >
> > Had an idea, why not choose the more accurate syntax: |, |= after all?
> Then, to help newcomers and forgetful pros a custom error message is
> implemented for +, +=. In pseudo C/Python, something like this:
> >
> >class dict:
> >
> >def __add__(self, other):
> >
> >if isinstance(other, dict):
> >raise TypeError(
> >'unsupported operand type(s) for +: … '
> >'Dictionary merging leads to last-value-wins data '
> >'loss. If acceptable, use the union "|" operator.'
> >)
> >else:
> >raise TypeError(std_err_msg)
> >
>
> This seems nifty—but will it break the __radd__ protocol? In other words:
>
> class FancyDict(dict):
> def __add__(self, other):
> # handles other being a plain dict just fine
> def __radd__(self, other):
> # handles other being a plain dict just fine
>
> … you want to make sure that adding a dict (or other dict subclass) and a
> FancyDict in either order calls the FancyDict method.
>
> Off the top of my head, I think it’s safe—and if not it would be safe to
> move your logic to dict.__radd__ and have __add__ either not there or
> return NotImplemented, because there’s a rule that if one object is an
> instance of a subclass of the other object’s type it gets first dibs. But
> someone needs to read the data model docs carefully—and also check what
> happens if both types are C extensions (since dict is).
>
> Anyway, while I don’t know if there is precedent for anything like this in
> a builtin type’s methods, there is precedent in builtin functions, like
> sum, so I think if it’s doable it might be acceptable. The only question is
> whether you’d want the same error for adding instances of subclasses of
> dict that don’t override the method(s)—and I think the answer there is yes,
> you would.
>
> ___
> 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/5N67XBNGAEQK2OF3XALT4TPUTMLJYNUF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
[Python-ideas] Re: [Python-Dev] 4 first-time contributions that need core review.
Wrong reply sorry. ___ 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/5SOHXIX4MSCKH7262KOXHDM5ZEEIDEK2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] 4 first-time contributions that need core review.
> https://github.com/python/cpython/pull/16680: bpo-38419: fix > "check-c-globals" path This PR was merged by Carol today :) 2019년 10월 23일 (수) 오전 3:53, Brandt Bucher 님이 작성: > > Hi all. There are a few *very simple* PRs from first-time contributors that > have been sitting un-core-reviewed for several weeks. > > https://github.com/python/cpython/pull/16680: bpo-38419: fix > "check-c-globals" path > https://github.com/python/cpython/pull/16678: bpo-38421: Update email.utils > documentation > https://github.com/python/cpython/pull/16557: bpo-38361: syslog: fixed making > default "ident" from sys.argv[0] > https://github.com/python/cpython/pull/16438: bpo-38293: Allow shallow and > deep copying of property objects > > I've reviewed them and they look good. If somebody has a small bit of time to > look at these, I'm sure the authors would appreciate it! > ___ > Python-Dev mailing list -- python-...@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-...@python.org/message/BT5QELS56DHDXUPQVU6NFBFXB3EAXHJ2/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Software Development Engineer at Kakao corp. Tel: +82 010-3353-9127 Email: donghee.n...@gmail.com | denn...@kakaocorp.com Linkedin: https://www.linkedin.com/in/dong-hee-na-2b713b49/ ___ 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/3ZUH3C33TKJWGLUOYZNGEZL5CGJSSNYZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby
On Oct 22, 2019, at 17:47, Chris Angelico wrote: > > Currently, the CPython optimizer can recognize constructs like "if x > in [1,2,3,4]" or "for x in [1,2,3,4]" and use a literal tuple instead > of building a list. Recognizing the splitting of a string as another > equivalent literal could be done the same way. > > Whether it's worthwhile or not is another question, but if the > performance penalty of the run-time splitting is a problem, that CAN > be fixed even without new syntax. This would be relatively easy to do in an AST-processing import hook. Then people could experiment with it and if someone finds real-life performance benefits, file a bug to add it to CPython (which should be a lot easier nowadays than it was a few versions ago). ___ 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/4RNXFDYEHUA2ZVA2UGSQ5GHFNEQN5WI4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby
On Tue, Oct 22, 2019 at 7:57 PM Steven D'Aprano wrote:
> On Tue, Oct 22, 2019 at 04:11:45PM -0400, Todd wrote:
> > On Tue, Oct 22, 2019 at 3:54 PM Steve Jorgensen
> wrote:
> >
> > > See
> > >
> https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Literals#The_%_Notation
> > > for what Ruby offers.
> > >
> > > For me, the arrays are the most useful aspect.
> > >
> > > %w{one two three}
> > > => ["one", "two", "three"]
>
>
> I would expect %w{ ... } to return a set, not a list:
>
> %w[ ... ] # list
> %w{ ... ] # set
> %w( ... ) # tuple
>
This is growing into an entire new group of constructors for a very, very
limited number of operations that have been privileged for some reason.
Should %{a=b c=d} create dicts, too? Why not? Why should strings be
privileged over, say, numbers? Why should %w[1 2 3] make ['1', '2', '3']
instead of [1, 2, 3]? And why whitespace instead of a comma? We have
general ways to handle all of this stuff that doesn't lock us into a single
special case.
> and I would describe them as list/set/tuple "word literals". Unlike
> list etc displays [spam, eggs, cheese] these would actually be true
> literals that can be determined entirely at compile-time.
>
I don't know enough about the internals to say whether this would be
possible or not.
> > I am not seeing the advantage of this. Can you provide some specific
> > examples that you think would benefit from this syntax?
>
> I would use this feature, or something like it, a lot, especially in
> doctests where there is a premium in being able to keep examples short
> and on one line.
>
> Here is a small selection of examples from my code that would be
> improved by something like the suggested syntax. I have trimmed some of
> them for brevity, and to keep them on one line. (Anything with an
> ellipsis ... has been trimmed.) I have dozens more, but they'll all
> pretty similar and I don't want to bore you.
>
>
> __slots__ = ('key', 'value', 'prev', 'next', 'count')
>
> __all__ = ["Mode_Estimators", "Location", "mfv", ...]
>
> The "string literal".split() idiom is especially common, especially for
> data tables of strings. Here are some examples:
>
> NUMBERS = ('zero one two three ... twenty-eight twenty-nine').split()
>
> _TOKENS = set("indent assign addassign subassign ...".split())
>
> __all__ = 'loopup loopdown reduce whileloop recursive product'.split()
>
> for i, colour in enumerate('Black Red Green Yellow Blue Magenta Cyan
> White'.split()):
>
> for methodname in 'pow add sub mul truediv'.split():
>
> attrs = "__doc__ __version__ __date__ __author__ __all__".split()
>
> names = 'meta private dunder ignorecase invert'.split()
>
> unsorted = "The quick brown Fox jumps over the lazy Dog".split()
>
> blocks = chaff.pad('flee to south'.split(), key='george')
>
> minmax('aa c ddd e f g'.split(), key=len)
>
>
> My estimate is that I would use this "string literal".split() idiom:
>
> - about 60-70% in doctests;
> - about 5-10% in other tests;
> - about 25% in non-test code.
>
>
> Anyone who has had to write out a large, or even not-so-large, list of
> words could benefit from this. Why quote each word individually like a
> drudge, when the compiler could do it for you at compile-time?
>
> Specifically as a convenience for this "list of words" use-case,
> namedtuple splits a single string into words, e.g.
>
> namedtuple('Parameter', 'name alias default')
>
> I do the same in some of my functions as well, to make it easier to pass
> lists of words.
>
> Similarly, support for keyword arguments in the dict constructor was
> specifically added to ease the case where your keys were single words:
>
> # {'spam': 1, 'eggs': 2}
> dict(spam=1, eggs=2)
>
>
> Don't underestimate the annoyance factor of having to write out things
> by hand when the compiler could do it for you. Analogy: we have list
> displays to make it easy to construct a list:
>
> mylist = [2, 7, -1]
>
> but that's strictly unnecessary, since we could construct it like
> this:
>
> mylist = list()
> mylist.append(2)
> mylist.append(7)
> mylist.append(-1)
>
> If you think I'm being fascious about the list example, you've probably
> never used standard Pascal, which had arrays but no syntax to initialise
> them except via a sequence of assignments. That wasn't too bad if you
> could put the assignments in a loop, but was painful if the initial
> entries were strings or floats.
>
Yes, I understand that Python has syntactic sugar. But any new syntactic
sugar necessarily has an uphill battle due people having to learn it, books
and classes having to be updated, linters updated, new pep8 guidelines
written, etc. We already have a way to split strings. So the question is
why we need this in addition to what we already have, especially
considering it is so radically different than anything else in Python. If
the primary use-case is docstrings, then this is
[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby
On Wed, Oct 23, 2019 at 10:59 AM Steven D'Aprano wrote: > > For the example you gave, besides saving a few characters I don't see the > > advantage over the existing way we have to do that: > > > > 'one two three'.split() > > One of the reasons why Python is "slow" is that lots of things that can > be done at compile-time are deferred to run-time. I doubt that splitting > short strings will often be a bottle-neck, but idioms like this cannot > help to contribute (even if only a little bit) to the extra work the > Python interpreter does at run-time: > > load a pre-allocated string constant > look up the "split" attribute in the instance (not found) > look up the "split" attribute in the class > call the descriptor protocol which returns a method > call the method > build and return a list > garbage collect the string constant > > versus: > > build and return a list from pre-allocated strings > > (Or something like this, I'm not really an expert on the Python > internals, I just pretend to know what I'm talking about.) > This could be done as an optimization without changing syntax or semantics.. As long as the initial string is provided as a literal, it should be possible to call the method at compile time, since (as far as I know) every string method is a pure function. It's made a little more complicated by the problem of mutable return values (str.split() returns a list, and if you call it again, you have to get a new unique list in case one of them gets mutated), but if you immediately iterate over it, that won't be a problem. Currently, the CPython optimizer can recognize constructs like "if x in [1,2,3,4]" or "for x in [1,2,3,4]" and use a literal tuple instead of building a list. Recognizing the splitting of a string as another equivalent literal could be done the same way. Whether it's worthwhile or not is another question, but if the performance penalty of the run-time splitting is a problem, that CAN be fixed even without new syntax. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WBGO662XIAWQ7UZF6D5LDNHZT7DLMB4B/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby
On Tue, Oct 22, 2019 at 04:11:45PM -0400, Todd wrote:
> On Tue, Oct 22, 2019 at 3:54 PM Steve Jorgensen wrote:
>
> > See
> > https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Literals#The_%_Notation
> > for what Ruby offers.
> >
> > For me, the arrays are the most useful aspect.
> >
> > %w{one two three}
> > => ["one", "two", "three"]
I would expect %w{ ... } to return a set, not a list:
%w[ ... ] # list
%w{ ... ] # set
%w( ... ) # tuple
and I would describe them as list/set/tuple "word literals". Unlike
list etc displays [spam, eggs, cheese] these would actually be true
literals that can be determined entirely at compile-time.
> I am not seeing the advantage of this. Can you provide some specific
> examples that you think would benefit from this syntax?
I would use this feature, or something like it, a lot, especially in
doctests where there is a premium in being able to keep examples short
and on one line.
Here is a small selection of examples from my code that would be
improved by something like the suggested syntax. I have trimmed some of
them for brevity, and to keep them on one line. (Anything with an
ellipsis ... has been trimmed.) I have dozens more, but they'll all
pretty similar and I don't want to bore you.
__slots__ = ('key', 'value', 'prev', 'next', 'count')
__all__ = ["Mode_Estimators", "Location", "mfv", ...]
The "string literal".split() idiom is especially common, especially for
data tables of strings. Here are some examples:
NUMBERS = ('zero one two three ... twenty-eight twenty-nine').split()
_TOKENS = set("indent assign addassign subassign ...".split())
__all__ = 'loopup loopdown reduce whileloop recursive product'.split()
for i, colour in enumerate('Black Red Green Yellow Blue Magenta Cyan
White'.split()):
for methodname in 'pow add sub mul truediv'.split():
attrs = "__doc__ __version__ __date__ __author__ __all__".split()
names = 'meta private dunder ignorecase invert'.split()
unsorted = "The quick brown Fox jumps over the lazy Dog".split()
blocks = chaff.pad('flee to south'.split(), key='george')
minmax('aa c ddd e f g'.split(), key=len)
My estimate is that I would use this "string literal".split() idiom:
- about 60-70% in doctests;
- about 5-10% in other tests;
- about 25% in non-test code.
Anyone who has had to write out a large, or even not-so-large, list of
words could benefit from this. Why quote each word individually like a
drudge, when the compiler could do it for you at compile-time?
Specifically as a convenience for this "list of words" use-case,
namedtuple splits a single string into words, e.g.
namedtuple('Parameter', 'name alias default')
I do the same in some of my functions as well, to make it easier to pass
lists of words.
Similarly, support for keyword arguments in the dict constructor was
specifically added to ease the case where your keys were single words:
# {'spam': 1, 'eggs': 2}
dict(spam=1, eggs=2)
Don't underestimate the annoyance factor of having to write out things
by hand when the compiler could do it for you. Analogy: we have list
displays to make it easy to construct a list:
mylist = [2, 7, -1]
but that's strictly unnecessary, since we could construct it like
this:
mylist = list()
mylist.append(2)
mylist.append(7)
mylist.append(-1)
If you think I'm being fascious about the list example, you've probably
never used standard Pascal, which had arrays but no syntax to initialise
them except via a sequence of assignments. That wasn't too bad if you
could put the assignments in a loop, but was painful if the initial
entries were strings or floats.
> For the example you gave, besides saving a few characters I don't see the
> advantage over the existing way we have to do that:
>
> 'one two three'.split()
One of the reasons why Python is "slow" is that lots of things that can
be done at compile-time are deferred to run-time. I doubt that splitting
short strings will often be a bottle-neck, but idioms like this cannot
help to contribute (even if only a little bit) to the extra work the
Python interpreter does at run-time:
load a pre-allocated string constant
look up the "split" attribute in the instance (not found)
look up the "split" attribute in the class
call the descriptor protocol which returns a method
call the method
build and return a list
garbage collect the string constant
versus:
build and return a list from pre-allocated strings
(Or something like this, I'm not really an expert on the Python
internals, I just pretend to know what I'm talking about.)
> Python usually uses [ ] for list creation or indexing. Co-opting it for a
> substantially different purpose of string processing like this doesn't
> strike me as a good idea, especially since we have two string identifiers
> already, ' and ".
I'm not sure why you describe
[Python-ideas] Re: Ability to set precedence of classdict (returned from __prepare__) for a metaclass type
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: Percent notation for array and string literals, similar to Perl, Ruby
Andrew Barnert wrote: > On Oct 22, 2019, at 15:06, Steve Jorgensen ste...@stevej.name wrote: > > Actually, in Ruby, the surrounding character pair can > > be pretty much anything `, and in practice, curly braces are often used. > This seems like a prime example of “Ruby is Perl done right, Python is not > doing > Perl.” That's valid. Just throwing this out there to see how people feel about it — or maybe spark other more Pythonic ideas that might provide a similar convenience. ___ 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/ZWMINUVUJZIUPFG6Y34RURA7TPVENBMO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby
On Oct 22, 2019, at 15:06, Steve Jorgensen wrote: > > Actually, in Ruby, the surrounding character pair can be pretty much anything > `, and in practice, curly braces are often used. This seems like a prime example of “Ruby is Perl done right, Python is not doing Perl.” ___ 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/SO6CNRE22LYZ25RNLZBWTMFE7RCTBA6F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.
On Oct 22, 2019, at 11:39, Mike Miller wrote: > > Had an idea, why not choose the more accurate syntax: |, |= after all? Then, > to help newcomers and forgetful pros a custom error message is implemented > for +, +=. In pseudo C/Python, something like this: > >class dict: > >def __add__(self, other): > >if isinstance(other, dict): >raise TypeError( >'unsupported operand type(s) for +: … ' >'Dictionary merging leads to last-value-wins data ' >'loss. If acceptable, use the union "|" operator.' >) >else: >raise TypeError(std_err_msg) > This seems nifty—but will it break the __radd__ protocol? In other words: class FancyDict(dict): def __add__(self, other): # handles other being a plain dict just fine def __radd__(self, other): # handles other being a plain dict just fine … you want to make sure that adding a dict (or other dict subclass) and a FancyDict in either order calls the FancyDict method. Off the top of my head, I think it’s safe—and if not it would be safe to move your logic to dict.__radd__ and have __add__ either not there or return NotImplemented, because there’s a rule that if one object is an instance of a subclass of the other object’s type it gets first dibs. But someone needs to read the data model docs carefully—and also check what happens if both types are C extensions (since dict is). Anyway, while I don’t know if there is precedent for anything like this in a builtin type’s methods, there is precedent in builtin functions, like sum, so I think if it’s doable it might be acceptable. The only question is whether you’d want the same error for adding instances of subclasses of dict that don’t override the method(s)—and I think the answer there is yes, you would. ___ 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/5N67XBNGAEQK2OF3XALT4TPUTMLJYNUF/ 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 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?
___
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/CERSFF3I4IAFXFSWOEA45EGKMVXTKOU4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby
Todd wrote:
> On Tue, Oct 22, 2019 at 3:54 PM Steve Jorgensen ste...@stevej.name wrote:
> > See
> I am not seeing the advantage of this. Can you provide some specific
> examples that you think would benefit from this syntax?
> For the example you gave, besides saving a few characters I don't see the
> advantage over the existing way we have to do that:
> 'one two three'.split()
No. It really doesn't provide much benefit beyond that.
> Python usually uses [ ] for list creation or indexing. Co-opting it for a
> substantially different purpose of string processing like this doesn't
> strike me as a good idea, especially since we have two string identifiers
> already, ' and ".
Actually, in Ruby, the surrounding character pair can be pretty much anything
`, and in practice, curly braces are often used. From
https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Literals#The_%_Notation :
> Any single non-alpha-numeric character can be used as the delimiter,
> `%[including these]`, `%?or these?`, `%~or even these things~`. By using
> this notation, the usual string delimiters `"` and `'` can appear in the
> string
> unescaped, but of course the new delimiter you've chosen does need to be
> escaped. However, if you use `%(parentheses)`, `%[square brackets]`,
> `%{curly brackets}` or `%` as delimiters then those same
> delimiters can appear unescaped in the string as long as they are in balanced
> pairs…
___
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/U2LHHFXXQLWJ7JABIFE5HPIYXI427PV6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Ability to set precedence of classdict (returned from __prepare__) for a metaclass type
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: Percent notation for array and string literals, similar to Perl, Ruby
On Tue, Oct 22, 2019 at 3:54 PM Steve Jorgensen wrote:
> See
> https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Literals#The_%_Notation
> for what Ruby offers.
>
> For me, the arrays are the most useful aspect.
>
> %w{one two three}
> => ["one", "two", "three"]
>
> I did a search, and I don't see that this has been suggested before, but I
> might have missed something. I'm guessing I'm not the first person to ask
> whether this seems like a desirable feature to add to Python.
>
I am not seeing the advantage of this. Can you provide some specific
examples that you think would benefit from this syntax?
For the example you gave, besides saving a few characters I don't see the
advantage over the existing way we have to do that:
'one two three'.split()
Python usually uses [ ] for list creation or indexing. Co-opting it for a
substantially different purpose of string processing like this doesn't
strike me as a good idea, especially since we have two string identifiers
already, ' and ".
Python does have something similar in function although different in
syntax, its string prefixes. For example f-strings, r-strings, byte
literals, etc. There have been proposals for supporting custom string
prefixes, but none have gone anywhere. Other hard-coded string prefixes
could, in principle, be done, but a strong case would need to be made for
them.
If we went with string prefixes, the only one I could see maybe having any
traction would be a regex one, but I personally wouldn't see that as being
common enough to warrant it. Converting strings to names is something I
think should be discouraged rather than encouraged (we have dictionaries to
handle arbitrary names), shell commands are complicated enough that I would
think having a dedicated function is necessary and I think it would be an
abuse of string literals, and the others duplicate features python already
has as far as I can tell.
So I would be -100 on using [ ] for strings in any way, +0 on a regex
string prefix, and -1 on all the other corresponding string prefixes.
___
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/DWYVZPBXTOHAXCQ4B2KMV4Q3YR3YTHHJ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby
"one two three".split()
On Tue, Oct 22, 2019, 3:56 PM Steve Jorgensen wrote:
> See
> https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Literals#The_%_Notation
> for what Ruby offers.
>
> For me, the arrays are the most useful aspect.
>
> %w{one two three}
> => ["one", "two", "three"]
>
> I did a search, and I don't see that this has been suggested before, but I
> might have missed something. I'm guessing I'm not the first person to ask
> whether this seems like a desirable feature to add to Python.
> ___
> 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/D5RMXPN3NXVM2OJIAJ2NSBII6UJGDVDZ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/B2EAKB66YQUDYYXO5KA4IIZWY6GUR3EL/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Percent notation for array and string literals, similar to Perl, Ruby
See
https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Literals#The_%_Notation
for what Ruby offers.
For me, the arrays are the most useful aspect.
%w{one two three}
=> ["one", "two", "three"]
I did a search, and I don't see that this has been suggested before, but I
might have missed something. I'm guessing I'm not the first person to ask
whether this seems like a desirable feature to add to Python.
___
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/D5RMXPN3NXVM2OJIAJ2NSBII6UJGDVDZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.
I really like this idea. Once you've already decided to raise an exception, does it really cost much to try to raise a more helpful one? And helpful exception messages make programming a lot less painful, and a lot more of a joy. On Tue, Oct 22, 2019 at 2:43 PM Mike Miller wrote: > > On 2019-10-18 10:23, Ricky Teachey wrote: > > but i'm -0 because i am very concerned it will not be obvious to new > learners, > > without constantly looking it up, whether adding two mappings together > would either: > > The big trade off I'm gathering from this mega-thread is that the |, |= > operators are more accurate, but less obvious to newcomers, who will first > try > +, += instead. > > I've tried them in this order myself several times over the years. > > Had an idea, why not choose the more accurate syntax: |, |= after all? > Then, to > help newcomers and forgetful pros a custom error message is implemented > for +, > +=. In pseudo C/Python, something like this: > > class dict: > > def __add__(self, other): > > if isinstance(other, dict): > raise TypeError( > 'unsupported operand type(s) for +: … ' > 'Dictionary merging leads to last-value-wins data ' > 'loss. If acceptable, use the union "|" operator.' > ) > else: > raise TypeError(std_err_msg) > > > I think it is worth it to lead the newcomer to a moment's reflection on > why > dictionary combining/merging is potentially lossy. Everyone is informed > with > the proper mental model, then on their way and left alone afterward. > > Thoughts? > -Mike > ___ > 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/43T52R223GYPHIDP3CHTIS3JTQYUNCVL/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "python-ideas" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/python-ideas/puGRBmzVl9c/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > python-ideas+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python-ideas/3ac803c4-f703-67bf-c4c9-a37bbe0c61d8%40mgmiller.net > . > ___ 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/3UGDM5QPUYVABW35MM7DGACWBYFBK2CT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.
On 2019-10-18 10:23, Ricky Teachey wrote: but i'm -0 because i am very concerned it will not be obvious to new learners, without constantly looking it up, whether adding two mappings together would either: The big trade off I'm gathering from this mega-thread is that the |, |= operators are more accurate, but less obvious to newcomers, who will first try +, += instead. I've tried them in this order myself several times over the years. Had an idea, why not choose the more accurate syntax: |, |= after all? Then, to help newcomers and forgetful pros a custom error message is implemented for +, +=. In pseudo C/Python, something like this: class dict: def __add__(self, other): if isinstance(other, dict): raise TypeError( 'unsupported operand type(s) for +: … ' 'Dictionary merging leads to last-value-wins data ' 'loss. If acceptable, use the union "|" operator.' ) else: raise TypeError(std_err_msg) I think it is worth it to lead the newcomer to a moment's reflection on why dictionary combining/merging is potentially lossy. Everyone is informed with the proper mental model, then on their way and left alone afterward. Thoughts? -Mike ___ 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/43T52R223GYPHIDP3CHTIS3JTQYUNCVL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.
On 22/10/2019 06:43, Richard Musil wrote:
It is not a "concatenation" though, because you lost {"key1": "val1"}
in the process. The concatenation is not _just_ "writing something
after something", you can do it with anything, but the actual
operation, producing the result.
My point is that if I saw {"key1": "val1", "key2": "val2"} + {"key1":
"val3"}, I would expect that it would be equivalent to {"key1": "val1",
"key2": "val2", "key1": "val3"}.
Similarly, I would expect that
deque([1, 2, 3], maxlen=4) + deque([4, 5]) == deque([1, 2, 3, 4, 5],
maxlen=4) == deque([2, 3, 4, 5], maxlen=4)
which indeed is true.
___
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/YSSTR2ZQWTDUXM25OHHTCEWKY5LJXLPE/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: RFC: PEP xxx: Python Compatibility Version
Hi,
Just bear in mind that I have read only a couple sentences in the PEP.
But as soon as you propose to offer only "partial compatibility" with
a previous version, then I think it's worse than useless. You are
introducing an additional Python version, i.e. "3.9 bended towards 3.8
partial compatibility", which is neither fully 3.8 nor fully 3.9. It
won't make life any easier for third-party library maintainers, on the
contrary: it will make it worse.
Regards
Antoine.
On Fri, 18 Oct 2019 03:02:50 +0200
Victor Stinner wrote:
> Hi,
>
> 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.
>
> I also propose this PEP in a pull request:
> https://github.com/python/peps/pull/1209
> (Please avoid using the temporary PEP number until this PR is merged:
> officially, the PEP has no number yet.)
>
> If possible, please try to read the whole PEP before replying. I would
> prefer to avoid knee-jerk reactions :-) The backward compatibility is
> complex topic where things are not black or white: it's more a
> grayscale.
>
> IMHO with the incoming end of Python 2 support, it's the right time to
> propose this PEP!
>
> Victor
>
>
> PEP: xxx
> Title: Python Compatibility Version
> Author: Victor Stinner
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 18-Oct-2019
> Python-Version: 3.9
>
>
> Abstract
>
>
> Add ``sys.set_python_compat_version(version)`` to enable partial
> compatibility with requested Python version. Add
> ``sys.get_python_compat_version()``.
>
> Modify a few functions of the standard library to implement a partial
> compatibility with Python 3.8.
>
> Add ``sys.set_python_min_compat_version(version)`` to deny backward
> compatibility with Python older than *version*.
>
> Add ``-X compat_version=VERSION`` and ``-X min_compat_version=VERSION``
> command line options. Add ``PYTHONCOMPATVERSION`` and
> ``PYTHONCOMPATMINVERSION`` environment variables.
>
>
> 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.
>
> 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.
>
> This PEP proposes to add a partial compatibility with old Python
> versions as a tradeoff to fit both use cases.
>
> The main issue with the migration from Python 2 to Python 3 is not that
> Python 3 is backward incompatible, but how incompatible changes were
> introduced.
>
>
> Partial compatibility to minimize the Python maintenance burden
> ---
>
> While technically it would be possible to provide a full compatibility
> with old Python versions, this PEP proposes to minimize the number of
> functions handling backward compatibility to reduce the maintenance
> burden of the Python project ("CPython").
>
> Each change introducing backport compatibility to a function should be
> properly discussed to estimate the maintenance cost in the long-term.
>
> 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.
>
> The maintenance cost does not only come from the code implementing the
> backward compatibility, but come also from additional tests.
>
>
> Cases excluded from backward compatibility
> --
>
> The performance overhead of a compatibility code must be low when
> ``sys.set_python_compat_version()`` is not called.
>
> The C API is out of the scope of this PEP: ``Py_LIMITED_API`` macro and
> the stable ABI are solving this problem differently, see the `PEP 384:
> Defining a Stable ABI `_).
>
> The Python language does not provide backward compatibility.
>
> Changes which are not clearly incompatible are not covered by this PEP.
> For example,
[Python-ideas] Re: Extending @ syntax to allow expressions
22.10.19 06:41, Andrew Barnert via Python-ideas пише: 2: I'm not sure what this would to to uses of "@" as an operator, as has been suggested various times for various laudable reasons; remember that an @decorator or other function definition is just another statement, and arbitrary expressions are already statements. I don’t understand this. @ already exists as an operator, and already takes arbitrary expressions for the left and right operands, with no parser ambiguity. What future worthwhile suggestions to that existing syntax are you imagining that might break that? There is a difference between @deco1@deco2 def func(): and @deco1 @deco2 def func(): But in some sense they look similar, and with more complex multiline expressions they can look indistinguishable. ___ 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/44P57YC7PEKDNTPTUSTF4EN52CVVL5NM/ Code of Conduct: http://python.org/psf/codeofconduct/
