Re: [Python-ideas] What are the strong use cases for str.rindex()? (John Lin)
IMO, there're lots of use cases in parsing related stuffs, which requires
rindex a lot, say, when you have generated a tokenizer which might across
multiple lines:
line 8: X """
line 9:
line 10: """
In this case, we need to extract 2 tokens X and , a multiline whitespace
string. After getting each token we're to compute/update the current column
and line number. If the line number gets advanced then we use rindex('\n')
to help with updating the new column number, otherwise, col_offset +=
len(current_token) .
However, the reason why we don't need list.rindex but do for str.rindex is
simple I'd say: str is immutable and has no O(1) reverse method.
On the other hand, when it comes to list, you can use list.index after
list.reverse, and after a bunch of operations you can resume the state by
invoking list.reverse again.
On Wed, Apr 24, 2019, 12:11 AM Send Python-ideas mailing list submissions to
> python-ideas@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.python.org/mailman/listinfo/python-ideas
> or, via email, send a message with subject or body 'help' to
> python-ideas-requ...@python.org
>
> You can reach the person managing the list at
> python-ideas-ow...@python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-ideas digest..."
> Today's Topics:
>
>1. What are the strong use cases for str.rindex()? (???)
>
>
>
> -- Forwarded message --
> From: "林自均"
> To: python-ideas@python.org
> Cc:
> Bcc:
> Date: Tue, 23 Apr 2019 14:44:25 +0800
> Subject: [Python-ideas] What are the strong use cases for str.rindex()?
> Hi all,
>
> I found that there are str.index() and str.rindex(), but there is only
> list.index() and no list.rindex(). So I filed the issue
> https://bugs.python.org/issue36639 to provide list.rindex(). However, the
> issue was rejected and closed with the comment:
>
> > There were known, strong use cases for str.rindex(). The list.rindex()
> method was intentionally omitted. AFAICT no compelling use cases have
> arisen, so we should continue to leave it out. In general, we don't grow
> the core APIs unnecessarily.
>
> However, I am not sure what the known, strong use cases for str.rindex()
> are. Why doesn't the strong use cases apply on list.rindex()? Could anyone
> give me some examples? Thanks.
>
> Best,
> John Lin
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add recordlcass to collections module
> > > -- Forwarded message -- > From: Martin Bammer > To: python-ideas@python.org > Cc: > Bcc: > Date: Sat, 1 Sep 2018 09:47:04 +0200 > Subject: [Python-ideas] Add recordlcass to collections module > Hi, > > what about adding recordclass > (https://bitbucket.org/intellimath/recordclass) to the collections module > > It is like namedtuple, but elements are writable and it is written in C > and thus much faster. > > And for convenience it could be named as namedlist. > > Regards, > > Martin > > There are a problem which prevent you to reach your goals. As list in Python is already that efficient, a wrapper of this list in C to supply so-called namedlist interface could not be that efficient. Member accessing in Python bytecode requires looking up corresponding attribute in a hashtable, if you want to access a list by attribute, actually there is an overhead. This is nothing to do with C implementation. See https://docs.python.org/3/library/dis.html#opcode-LOAD_ATTR ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)
> Hey! I did not propose "?". Read the explanation in parenthesis. > My whole idea that any option could be viable, as long as > it does not propose reversed order notation. Dear Mikhail, so sorry about my misunderstanding, I should read the post with fewer presuppositions... Back to the topic, this thread seems to be closed now, and in my opinion `:=` could be synthetically the best. 2018-04-17 15:11 GMT+08:00 Mikhail V <mikhail...@gmail.com>: > On Tue, Apr 17, 2018 at 6:09 AM, Thautwarm Zhao <yaoxiansa...@gmail.com> > wrote: > > > > > > 3) "target ? expr" (where ? is some other word/character - IIRC > > > "target from expr" was proposed once) > > > > A more popular convention is to mark `?` as handling boolean variables, > so > > `target ? expr` could mean `expr if target else target`. Other proposal > for > > null/boolean checking might need `?`, let's preserve `?` character for > > further development. > > Hey! I did not propose "?". Read the explanation in parenthesis. > My whole idea that any option could be viable, as long as > it does not propose reversed order notation. > > But anyway ":=" is better than any keyword imo. > > > Mikhail > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)
> We have ways of cheating a bit if we want to reinterpret the semantics > of something that nevertheless parses cleanly - while the parser is > limited to single token lookahead, it's straightforward for the > subsequent code generation stage to look a single level down in the > parse tree and see that the code that parsed as "with expr" is > actually "with subexpr as target". It does work, however I think it does sound like a patch, and definitely it will block us to make other extensions in the future. > 3) "target ? expr" (where ? is some other word/character - IIRC > "target from expr" was proposed once) A more popular convention is to mark `?` as handling boolean variables, so `target ? expr` could mean `expr if target else target`. Other proposal for null/boolean checking might need `?`, let's preserve `?` character for further development. > How about "name being expression" - this avoids the already used "as" > while being searchable, reasonably short and gives a reasonably clear, > (at least to English speakers), indication of what is going on. It can > also be typed on an ASCII keyboard without having to have a helper > program or memorising Unicode codes and can be displayed or printed > without having to install specialised fonts. It makes sense, if we don't have a long history in Python programming... A new keyword would be something very dangerous, because it just causes the crash of some existed library using the keyword as identifier. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)
> > > 0. > > while (items[i := i+1] := read_next_item()) is not None: > print(r'%d/%d' % (i, len(items)), end='\r') > > 1. > > while (read_next_item() -> items[(i+1) -> i]) is not None: > print(r'%d/%d' % (i, len(items)), end='\r') > > 2. > > while (item := read_next_item()) is not None: > items[i := (i+1)] = item > print(r'%d/%d' % (i, len(items)), end='\r') > > 3. > > while (read_next_item() -> item) is not None: > items[(i+1) -> i] = item > print(r'%d/%d' % (i, len(items)), end='\r') > > 4. > > while (item := read_next_item()) is not None: > i = i+1 > items[i] = item > print(r'%d/%d' % (i, len(items)), end='\r') > > 5. > > while (read_next_item() -> item) is not None: > i = i+1 > items[i] = item > print(r'%d/%d' % (i, len(items)), end='\r') > > Also 2 or 3. The 3rd one is in the order of natural language, just like: while get then next item and assign it to `item`, if it's not None, do some stuff. However just as we have pointed out, the semantics of '->' is quite different from the cases it's currently used at, so it should be handled much more carefully. I think maybe we can use unicode characters like ≜ (\triangleq) and add the support of unicode completion to python repl. The unicode completion of editors or ides has been quite mature. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)
> To me, "from" strongly suggests that an element is being obtained from a container/collection of > elements. This is how I conceptualize "from module import name": "name" refers to an object > INSIDE the module, not the module itself. If I saw > > if (match from pattern.search(data)) is not None: ... > I would guess that it is equivalent to > > m = next(pattern.search(data)) > if m is not None: ... +1, although unpacking seems to be reasonable `[elem1, *elems] from contains`. Now we have - "expr as name" - "name := expr" - "expr -> name" - "name from expr" Personally I prefer "as", but I think without a big change of python Grammar file, it's impossible to avoid parsing "with expr as name" into "with (expr as name)" because "expr as name" is actually an "expr". I have mentioned this in previous discussions and it seems it's better to warn you all again. I don't think people of Python-Dev are willing to implement a totally new Python compiler. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 572: Assignment Expressions (post #4)
> None if var:= function() is None else var.method() Make sense. In some specific scenes(maybe general, I'm not sure), var.method() if var:=function() else var looks cool although it's not really null checking. It works for Python, just like use `if lst` to check if the list `lst` is empty. 2018-04-13 11:22 GMT+08:00 David Mertz <me...@gnosis.cx>: > Yes, I should have added ternary expressions to if statements. I can > definitely see the use there. > > However, your example is not null checking. You'd have to modify it > slightly to get that: > > None if var:= function() is None else var.method() > > Still not bad looking. > > On Thu, Apr 12, 2018, 11:01 PM Thautwarm Zhao <yaoxiansa...@gmail.com> > wrote: > >> >> > You're looking at a very early commit there. I suggest looking at the >> > most recent commits on one of two branches: >> >> https://github.com/Rosuav/cpython/blob/statement-local- >> variables/Grammar/Grammar >> https://github.com/Rosuav/cpython/blob/assignment- >> expressions/Grammar/Grammar >> >> > Those are the two most recent states in my progress towards (a) >> > statement-local name bindings with "EXPR as NAME", and (b) assignment >> > expressions with "target := value". >> >> Okay, and the syntax "target := value" seems to be much easier to handle >> with. >> >> I do support this feature, but now I'm worried about the meaning of ':=', >> it seems to be a lazy assignment in some degree. I'm not sure using ':=' is >> proper here. >> >> >> > Inasmuch as I might like assignment expressions, it would only be in >> while or if statements, personally. >> >> Not exactly, assignment expression also works for "if expression", we can >> now have null checking. >> >> var.method() if var:= function() else None >> >> Null checking is importance enough to have a specific syntax in many >> other languages(C#, kotlin, Ruby and so on), and we can even have more than >> null checking by adding expression assignment. >> >> >> >> >> ___ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Python-ideas Digest, Vol 137, Issue 67
> Makes sense. However, couldn't you prevent that by giving with
> priority over the binding ? As in "(with simple_cm) as value", where
> we consider the "as" as binding operator instead of part of the with
> statement ? Sure, you could commit suicide by parenthesis, but by
> default it'd do exactly what the "with simple_cm as value" currently
> does. This does require use of as instead of :=, though. (which was
> the point I was trying to make, apologies for the confusion)
Does "(with simple_cm) as value" means "with (simple_cm as value)"?
If so, it's impossible to let the priority of "with ... as ..." over `as`
binding.
This is the grammar of current syntax related to with statement:
with_stmt: 'with' with_item (',' with_item)* ':' suite
with_item: test ['as' expr]
If `as` binding could be used in a general expression, just as
`test` is the top of expression, an expression using `as` binding must be
in the structure `test`.
In other words, if you write
with expr as name:
# do stuff
Without doubt it's equivalent to `with (expr as name)`.
Or you want to completely change the grammar design of CPython :)
thautwarm
2018-04-12 21:41 GMT+08:00 :
> Send Python-ideas mailing list submissions to
> python-ideas@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.python.org/mailman/listinfo/python-ideas
> or, via email, send a message with subject or body 'help' to
> python-ideas-requ...@python.org
>
> You can reach the person managing the list at
> python-ideas-ow...@python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-ideas digest..."
>
> Today's Topics:
>
>1. Re: PEP 572: Assignment Expressions (post #4) (Chris Angelico)
>2. Re: PEP 572: Assignment Expressions (post #4) (Chris Angelico)
>3. Re: PEP 572: Assignment Expressions (post #4) (Nick Coghlan)
>4. Re: PEP 572: Assignment Expressions (post #4) (Jacco van Dorp)
>5. Re: PEP 572: Assignment Expressions (post #4) (Chris Angelico)
>
>
> -- 已转发邮件 --
> From: Chris Angelico
> To: python-ideas
> Cc:
> Bcc:
> Date: Thu, 12 Apr 2018 23:08:06 +1000
> Subject: Re: [Python-ideas] PEP 572: Assignment Expressions (post #4)
> On Thu, Apr 12, 2018 at 9:09 PM, Paul Moore wrote:
> > On 11 April 2018 at 22:28, Chris Angelico wrote:
> >> On Thu, Apr 12, 2018 at 1:22 AM, Nick Coghlan
> wrote:
> >>> This argument will be strengthened by making the examples used in the
> >>> PEP itself more attractive, as well as proposing suitable additions to
> >>> PEP 8, such as:
> >>>
> >>> 1. If either assignment statements or assignment expressions can be
> >>> used, prefer statements
> >>> 2. If using assignment expressions would lead to ambiguity about
> >>> execution order, restructure to use statements instead
> >>
> >> Fair enough. Also adding that chained assignment expressions should
> >> generally be avoided.
> >
> > Another one I think should be included (I'm a bit sad that it's not so
> > obvious that no-one would ever even think of it, but the current
> > discussion pretty much killed that hope for me).
> >
> > * Assignment expressions should never be used standalone - assignment
> > statements should *always* be used in that case.
>
> That's covered by the first point. If it's a standalone statement,
> then the statement form could be used, ergo you should prefer the
> statement form.
>
> ChrisA
>
>
>
> -- 已转发邮件 --
> From: Chris Angelico
> To: python-ideas
> Cc:
> Bcc:
> Date: Thu, 12 Apr 2018 23:14:34 +1000
> Subject: Re: [Python-ideas] PEP 572: Assignment Expressions (post #4)
> On Thu, Apr 12, 2018 at 7:21 PM, Kirill Balunov
> wrote:
> >
> > I gain readability! I don't see any reason to use it in other contexts...
> > Because it makes the code unreadable and difficult to perceive while
> giving
> > not so much benefit. I may be wrong, but so far I have not seen a single
> > example that at least slightly changed my mind.
>
> This is, in effect, your entire argument for permitting assignments
> only in certain contexts. "I can't think of any useful reason for
> doing this, so we shouldn't do it". But that means making the language
> grammar more complicated (both in the technical sense of the parser's
> definitions, and in the colloquial sense of how you'd explain Python
> to a new programmer), because there are these magic constructs that
> can be used anywhere in an expression, but ONLY if that expression is
> inside an if or while statement. You lose the ability to refactor your
> code simply to satisfy an arbitrary restriction to appease someone's
> feeling of "it can't be useful anywhere else".
>
> There are basically two clean ways to do this:
>
> 1) Create actual
Re: [Python-ideas] Python-ideas Digest, Vol 137, Issue 40
I think Guido has given a direct answer why dict unpacking is not supported
in syntax level,
I can take it and I think it's better to implement a function for dict
unpacking in standard library, just like
from dict_unpack import dict_unpack, pattern as pat
some_dict = {'a': {'b': {'c': 1}, 'd':2}, 'e': 3}
extracted = dict_unpack(some_dict, schema = {'a': {'b': {'c':
pat('V1')}, 'd': pat('V2')}, 'e': pat('V3')})
# extract to a flatten dictionary
v1, v2, v3 = (extracted[k] for k in ('V1', 'V2', 'V3'))
assert (v1, v2, v3) == (1, 2, 3)
As for Steve's confusion,
> > {key: value_pattern, **_} = {key: value, **_}
> If I saw that, I would have no idea what it could even possibly do.
> Let's pick the simplest concrete example I can think of:
>
> {'A': 1, **{}} = {'A': 0, **{}}
>
> I cannot interpret what that should do. Is it some sort of
> pattern-matching? An update? What is the result? It is obviously some
> sort of binding operation, an assignment, but an assignment to what?
{'A': 1, **{}} = {'A': 0, **{}} should be just wrong because for any k-v
pair at LHS, the key should be a expression and the value is for unpacking.
{'A': [*a, b]} = {'A': [1, 2, 3]} is welcome, but {'A': 1} = {'A': '1'} is
also something like pattern matching which is out of our topic.
Anyway, this feature will not come true, let's forget it...
I think Jacco is totally correct in following words.
> I think most of these problems could be solved with pop and the
> occasional list comprehension like this:
>
> a, b, c = [{'a':1,'b':2,'c':3}.pop(key) for key in ('a', 'b', 'c')]
>
> or for your example:
>
> c = {'a': 1, **{'b': 2}} # I suppose this one would generally
> # be dynamic, but I need a name here.
> a, b = [c.pop(key) for key in ('a', 'b')]
>
> would extract all the keys you need, and has the advantage that
> you don't need hardcoded dict structure if you expand it to nested
> dicts. It's even less writing, and just as extensible to nested dicts.
> And if you dont actually want to destruct (tuples and lists aren't
> destroyed either), just use __getitem__ access instead of pop.
But pop cannot work for a nested case.
Feel free to end this topic.
thautwarm
2018-04-10 23:20 GMT+08:00 <python-ideas-requ...@python.org>:
> Send Python-ideas mailing list submissions to
> python-ideas@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.python.org/mailman/listinfo/python-ideas
> or, via email, send a message with subject or body 'help' to
> python-ideas-requ...@python.org
>
> You can reach the person managing the list at
> python-ideas-ow...@python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-ideas digest..."
>
> Today's Topics:
>
>1. Re: Is there any idea about dictionary destructing?
> (Steven D'Aprano)
>2. Re: Is there any idea about dictionary destructing?
> (Jacco van Dorp)
>3. Re: Start argument for itertools.accumulate() [Was: Proposal:
> A Reduce-Map Comprehension and a "last" builtin] (Guido van Rossum)
>4. Re: Is there any idea about dictionary destructing?
> (Guido van Rossum)
>
>
> -- 已转发邮件 --
> From: "Steven D'Aprano" <st...@pearwood.info>
> To: python-ideas@python.org
> Cc:
> Bcc:
> Date: Tue, 10 Apr 2018 19:21:35 +1000
> Subject: Re: [Python-ideas] Is there any idea about dictionary destructing?
> On Tue, Apr 10, 2018 at 03:29:08PM +0800, Thautwarm Zhao wrote:
>
> > I'm focused on the consistency of the language itself.
>
> Consistency is good, but it is not the only factor to consider. We must
> guard against *foolish* consistency: adding features just for the sake
> of matching some other, often barely related, feature. Each feature must
> justify itself, and consistency with something else is merely one
> possible attempt at justification.
>
>
> > {key: value_pattern, **_} = {key: value, **_}
>
> If I saw that, I would have no idea what it could even possibly do.
> Let's pick the simplest concrete example I can think of:
>
> {'A': 1, **{}} = {'A': 0, **{}}
>
> I cannot interpret what that should do. Is it some sort of
> pattern-matching? An update? What is the result? It is obviously some
> sort of binding operation, an assignment, but an assignment to what?
>
> Sequence binding and unpacking was obvious the first time I saw it. I
> had no problem guessing what:
>
> a, b, c = 1, 2, 3
>
> meant, and once I had seen that, it wasn't hard to guess what
>
> a, b, c = *sequence
>
> meant. From there it is easy to predict exte
Re: [Python-ideas] Is there any idea about dictionary destructing?
Your library seems difficult to extract values from nested dictionary, and
when the key is not an identifier it's also embarrassed.
For sure we can have a library using graphql syntax to extract data from
the dict of any schema, but that's not my point.
I'm focused on the consistency of the language itself.
{key: value_pattern, **_} = {key: value, **_}
The reason why it's important is that, when destructing/constructing for
built-in data structures are not supported completely,
people might ask why "[a, *b] = c" is ok but "{"a": a, **b} = c" not.
If only multiple assignment is supported, why "(a, (b, c)) = d" could be
ok? It's exactly destructing!
And then if people think destructing of data structures is ok, they might
be curious about what's the boundary of this feature.
If you just tell them, "oh, it's just special, it just works for iterables,
even you can partially destruct the dict in argument passing, you cannot
use it in a simple statement!"
>> def f(a, b, **c):
print (a, b, c)
>> f(a=1, **{'b': 2})
1 2 {}
>> {'a': a, 'b': b, **c} = {'a': 1, **{'b': 2}}
SyntaxError: can't assign to literal
Above example could be confusing in some degree, I think. If we don't have
so many convenient helpers for function call,
in terms of consistency, it might be even better...
2018-04-10 9:23 GMT+08:00 Joao S. O. Bueno :
> On 9 April 2018 at 22:10, Brett Cannon wrote:
> >
> >
> > On Mon, 9 Apr 2018 at 05:18 Joao S. O. Bueno
> wrote:
> >>
>
> >> we could even call this approach a name such as "function call".
> >
> >
> > The harsh sarcasm is not really called for.
>
> Indeed - on rereading, I have to agree on that.
>
> I do apologize for the sarcasm. - really, I not only stand corrected:
> I recognize i was incorrect to start with.
>
> But my argument that this feature is needless language bloat stands.
>
> On the othe hand, as for getting variable names out of _shallow_ mappings,
> I've built that feature in a package I authored, using a context manager
> to abuse the import mechanism -
>
> In [96]: from extradict import MapGetter
>
> In [97]: data = {"A": None, "B": 10}
>
> In [98]: with MapGetter(data):
>...: from data import A, B
>...:
>
> In [99]: A, B
> Out[99]: (None, 10)
>
>
> That is on Pypi and can be used by anyone right now.
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Fwd: Is there any idea about dictionary destructing?
I'm sorry that I didn't send a copy of the discussions here.
-- Forwarded message --
From: Thautwarm Zhao <yaoxiansa...@gmail.com>
Date: 2018-04-09 1:24 GMT+08:00
Subject: Re: [Python-ideas] Is there any idea about dictionary destructing?
To: "Eric V. Smith" <e...@trueblade.com>
Thank you, Eric. Your links really help me and I've investigated it
carefully.
After reading them, I found the discussion almost focused on a non-nested
data structure.
The flatten key-value pairs might be easily replaced by something like
x, y, z = [some_dict[k] for k in ('a', 'b', 'c')]
I couldn't agree more but, when it comes to nested,
some_dict = {
'a': {
'b': {
'c': V1},
'e': V2
},
'f': V3
}
I agree that there could be other ways as intuitive as the dict destructing
to
get `V1, V2, V3` instead, however dict destructing refers to the
consistency of Python language behaviours.
When I'm writing these codes:
[a, *b] = [1, 2, 3]
The LHS is actually equals to RHS, and if we implement a way to apply this
on dictionary
{'a': a, 'b': b, '@': c, **other} = {'a': 1, 'b': 2, '@': 3, '*': 4}
It also presents that LHS equals to RHS. Dict destructing/constructing is
totally compatible to Python unpack/pack,
just as what iterable destructing/constructing does. It's neat when we talk
about Python's data structures we can talk about
the consistency, readability and the expression of intuition.
In the real world, the following one could really help when it comes to the
field of data storage.
some_dict = {'a': [1, 2, 3, {"d": 4, "f": 5}]}
{'a': [b, *c, {"d": e, **_}]} = some_dict
The LHS doesn't only show the structure of some variable intuitively(this
makes review easier, too), but also supplies a way to access data in fewer
codes.
In the previous talk people have shown multiple usages of dict destructing
in real world:
- Django Rest Framework validate
- Load config files and use them, specifically Yaml/JSON data
access.
In fact, any other operation on dictionary than simply getting a value from
a key might needs dict destructing, just when the task is complicated
enough.
I do think the usages are general enough now to make us allow similar
syntax to do above tasks.
P.S:
Some other advices in the previous talk like the following:
'a' as x, 'b' as y, 'c' as z = some_dict
'a': x, 'b': y, 'c': z = some_dict
mode, height, width = **prefs
Either of them conflicts against the current syntax, or does mismatch the
consistency of Python language(LHS != RHS).
thautwarm
2018-04-08 5:39 GMT+08:00 Eric V. Smith <e...@trueblade.com>:
> There was a long thread last year on a subject, titled "Dictionary
> destructing and unpacking.":
> https://mail.python.org/pipermail/python-ideas/2017-June/045963.html
>
> You might want to read through it and see what ideas and problems were
> raised then.
>
> In that discussion, there's also a link to an older pattern matching
> thread:
> https://mail.python.org/pipermail/python-ideas/2015-April/032907.html
>
> Eric
>
> On 4/7/2018 1:26 PM, thautwarm wrote:
>
>> We know that Python support the destructing of iterable objects.
>>
>> m_iter= (_for _in range(10))
>> a,*b, c= m_iter
>>
>> That's pretty cool! It's really convenient when there're many corner
>> cases to handle with iterable collections.
>> However destructing in Python could be more convenient if we support
>> dictionary destructing.
>>
>> In my opinion, dictionary destructing is not difficult to implement and
>> makes the syntax more expressive. A typical example is data access on
>> nested data structures(just like JSON), destructing a dictionary makes the
>> logic quite clear:
>>
>> data= {
>> "direct": "some data",
>> "nested": {
>> "lst_data": [1,2,3],
>> "int_data": 1
>> }
>> }
>> {
>> "direct": direct,
>> "nested": {
>> "lst_data": [a, b, c],
>> }
>> }= data
>>
>>
>> Dictionary destructing might not be very well-known but it really helps.
>> The operations on nested key-value collections are very frequent, and the
>> codes for business logic are not readable enough until now. Moreover Python
>> is now popular in data processing which must be enhanced by the entire
>> support of data destructing.
>>
>> Here are some implementations of other languages:
>> Elixir, which is also a popular dynamic language nowadays.
>>
>> |iex> %{} = %{:a =&g
