[Python-ideas] Re: Dict unpacking assignment
Nice!
On Sun, Oct 25, 2020 at 9:59 PM Dennis Sweeney
wrote:
> What if the mapping assignment were more harmonious with the pattern
> matching PEP? Something like this:
>
> items = {'eggs': 2, 'cheese': 3, 'spam': 1}
> {'eggs': eggs, 'spam': i_dont_need_to_name_this_spam, **rest} = items
> assert i_dont_need_to_name_this_spam == 1
> assert eggs == 2 and cheese == 3
> assert rest == {'cheese': 3}
>
> The keys here could be arbitrary hashables and the "values" could be
> arbitrary assignment targets (assigned all-or-nothing). This wouldn't need
> the right-hand-side double-star, and I think it more closely resembles the
> sequence unpacking assignment syntax. You can assign to a (thing that looks
> like a) tuple or to a (thing that looks like a) list or to a sequence
> subscript or object attribute, why not be able to assign to a (thing that
> looks like a) dictionary? This also avoids polluting the local namespace in
> case one of your keys is the string "range" or something. It also feels
> less magical to me, albeit more verbose.
>
> Calls to a hypothetical parse/sscanf function could closely mirror some
> str.format() calls:
>
> text = "{a}, {b}, {c}".format(**{'a': a0, 'b': b0, 'c': c0})
> {'a': a1, 'b': b1, 'c': c1} = "{a}, {b}, {c}".parse(text)
> assert (a1, b1, c1) == (a0, b0, c0)
>
> Alternative positional parsing would be useful as well, as in:
>
> text = "{}, {}, {}".format(a0, b0, c0)
> a1, b1, c1 = "{}, {}, {}".parse(text)
> assert (a1, b1, c1) == (a0, b0, c0)
>
> This way, pattern.format() and pattern.parse() would be trying to be
> inverses of each other (as much as is reasonable, probably limited to
> parsing strings, floats and ints).
>
> Then maybe people could get used to a format-string-like mini-language for
> parsing, and eventually, the f-string assignment might be better received,
> and we could propose something like
>
> text = f"{a0}, {b0}, {c0}"
> f"{a1}, {b1}, {c1}" = text
> assert (a1, b1, c1) == (a0, b0, c0)
>
> as well, where we lose some of the flexibility but gain better D.R.Y. and
> more visual locality, useful in the simple cases. I see the potential for a
> strong analogy:
>
> positional format() : keyword-based format() : fstrings
> ::
> positional parse() : keyword-based parse(): assignment to fstrings
> ___
> 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/H5252OAGH2IWEVQ26F2OWNQZCGMVNZWP/
> 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: Dict unpacking assignment
What if the mapping assignment were more harmonious with the pattern matching
PEP? Something like this:
items = {'eggs': 2, 'cheese': 3, 'spam': 1}
{'eggs': eggs, 'spam': i_dont_need_to_name_this_spam, **rest} = items
assert i_dont_need_to_name_this_spam == 1
assert eggs == 2 and cheese == 3
assert rest == {'cheese': 3}
The keys here could be arbitrary hashables and the "values" could be arbitrary
assignment targets (assigned all-or-nothing). This wouldn't need the
right-hand-side double-star, and I think it more closely resembles the sequence
unpacking assignment syntax. You can assign to a (thing that looks like a)
tuple or to a (thing that looks like a) list or to a sequence subscript or
object attribute, why not be able to assign to a (thing that looks like a)
dictionary? This also avoids polluting the local namespace in case one of your
keys is the string "range" or something. It also feels less magical to me,
albeit more verbose.
Calls to a hypothetical parse/sscanf function could closely mirror some
str.format() calls:
text = "{a}, {b}, {c}".format(**{'a': a0, 'b': b0, 'c': c0})
{'a': a1, 'b': b1, 'c': c1} = "{a}, {b}, {c}".parse(text)
assert (a1, b1, c1) == (a0, b0, c0)
Alternative positional parsing would be useful as well, as in:
text = "{}, {}, {}".format(a0, b0, c0)
a1, b1, c1 = "{}, {}, {}".parse(text)
assert (a1, b1, c1) == (a0, b0, c0)
This way, pattern.format() and pattern.parse() would be trying to be inverses
of each other (as much as is reasonable, probably limited to parsing strings,
floats and ints).
Then maybe people could get used to a format-string-like mini-language for
parsing, and eventually, the f-string assignment might be better received, and
we could propose something like
text = f"{a0}, {b0}, {c0}"
f"{a1}, {b1}, {c1}" = text
assert (a1, b1, c1) == (a0, b0, c0)
as well, where we lose some of the flexibility but gain better D.R.Y. and more
visual locality, useful in the simple cases. I see the potential for a strong
analogy:
positional format() : keyword-based format() : fstrings
::
positional parse() : keyword-based parse(): assignment to fstrings
___
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/H5252OAGH2IWEVQ26F2OWNQZCGMVNZWP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: TextIOWrapper support for null-terminated lines
On Mon, Oct 26, 2020 at 10:47 AM Cameron Simpson wrote: > > On 26Oct2020 09:45, Chris Angelico wrote: > >On Mon, Oct 26, 2020 at 8:44 AM Cameron Simpson wrote: > >> On 24Oct2020 13:37, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote: > >> >Spaces in filenames are just as bad, and much more common: > >> > >> But much easier to handle in simple text listings, which are newline > >> delimited. > >> You're really running into a horrible behaviour from xargs, which is one > >> reason why GNU parallel exists. > > > >I don't consider the behaviour horrible, and xargs isn't the only > >thing to do this - other tools can be put into zero-termination mode > >too. > > I'm not talking about -print0 and -0, which I merely dislike as a hack > to accomodate badly named filenames, but xargs' non-0 behaviour, which > splits on whitespace. Instead of newlines. That pissed me off enough to > write my own. > Ohh, I see what you mean. Yeah, newlines would be a better default for a lot of situations. Can't be changed now. 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/OCQ6OTLSWBPOHHVBZFK3Z35RIOSK35PO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: TextIOWrapper support for null-terminated lines
On 26Oct2020 09:45, Chris Angelico wrote: >On Mon, Oct 26, 2020 at 8:44 AM Cameron Simpson wrote: >> On 24Oct2020 13:37, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote: >> >Spaces in filenames are just as bad, and much more common: >> >> But much easier to handle in simple text listings, which are newline >> delimited. >> You're really running into a horrible behaviour from xargs, which is one >> reason why GNU parallel exists. > >I don't consider the behaviour horrible, and xargs isn't the only >thing to do this - other tools can be put into zero-termination mode >too. I'm not talking about -print0 and -0, which I merely dislike as a hack to accomodate badly named filenames, but xargs' non-0 behaviour, which splits on whitespace. Instead of newlines. That pissed me off enough to write my own. [...] >If you actually DO need to read null-terminated records from a file >that's too big for memory, it's probably worth just rolling your own >buffering, reading a chunk at a time and splitting off the interesting >parts. It's not hugely difficult, and it's a good exercise to do now >and then. Aye. That's what my cs.buffer.CornuCopyBuffer class does for me: https://pypi.org/project/cs.buffer/ aimed particularly at parsing binary data easily (it takes any iterable of bytes, and has a few factories to start from a file etc). Parsing a NUL terminated string from binary data isn't too bad given such a thing. Cheers, Cameron Simpson ___ 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/2G5RBMJYUWKFC7R5CO2VKODKJ2GZPA2H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: execute function on iterator items without changing or consuming iterator
this seems nice. It just seems that the obvious way to do it would be: def tap(iter_, func): for item in iter_: func(item) yield item I think it can be nice, but more as cookbook material than an actual itertools function. On Sun, 25 Oct 2020 at 14:38, <2qdxy4rzwzuui...@potatochowder.com> wrote: > On 2020-10-25 at 16:34:14 +, > George Harding wrote: > > > some_iter = map(lambda x: x if print(x) else x, some_iter) > > > > The tuple has a ~50% overhead, the case statement ~15%, compared to the > > generator. > > def print_first(x): > print(x) > return x > new_iter = map(print_first, some_iter) > > No extranous tuple, no extranous case stament. Newlines are cheap these > days. The call to print, however, is possibly unbounded in time and > space. > > If you really want to go overboard, put something like the following > peeker function into your personal toolbox (untested): > > def peeker(function): > def peeker(x): > function(x) > return x > return peeker > > And use it like this: > > new_iter = map(peeker(print), some_iter) > ___ > 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/RG2ZQD5NNU2BKVTC2AZGSQNVZA2CV2UJ/ > 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/RUNCSDTTB5NTGYUUQAFZZI33XBZSEWUZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: TextIOWrapper support for null-terminated lines
On Sun, Oct 25, 2020, at 18:45, Chris Angelico wrote: > If you actually DO need to read null-terminated records from a file > that's too big for memory, it's probably worth just rolling your own > buffering, reading a chunk at a time and splitting off the interesting > parts. It's not hugely difficult, and it's a good exercise to do now > and then. And yes, I can see the temptation to get Python to do it, > but unfortunately, newline support is such a weird mess of > cross-platform support that I don't think it needs to be made more > complicated :) Maybe a getdelim method that ignores all the newline support complexity and just reads until it reaches the specified character? It would make sense on binary files too. The problem with rolling your own buffering is that there's not really a good way to put back the unused data after the delimiter if you're mixing this processing with something else. You'd have to do it a character at a time, which would be very inefficient in pure 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/CXZWUKIIJNGP7EDXG7P3CHZKF3XW2P6P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: TextIOWrapper support for null-terminated lines
On Mon, Oct 26, 2020 at 8:44 AM Cameron Simpson wrote: > > On 24Oct2020 13:37, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote: > >On 2020-10-24 at 12:29:01 -0400, > >Brian Allen Vanderburg II via Python-ideas wrote: > > > >> ... Find can output it's filenames in null-terminated lines since it > >> is possible to have newlines in a filename(yuck) ... > > > >Spaces in filenames are just as bad, and much more common: > > But much easier to handle in simple text listings, which are newline > delimited. > > You're really running into a horrible behaviour from xargs, which is one > reason why GNU parallel exists. > I don't consider the behaviour horrible, and xargs isn't the only thing to do this - other tools can be put into zero-termination mode too. But it's pretty rare to consume huge amounts of data in this way (normally it'll just be a list of file names), so what I would do is simply read the entire thing, then split on "\0". It's not like reading a gigabyte of log file, where you really want to work line by line and not read in more than you need; it's easily going to fit into memory. If you actually DO need to read null-terminated records from a file that's too big for memory, it's probably worth just rolling your own buffering, reading a chunk at a time and splitting off the interesting parts. It's not hugely difficult, and it's a good exercise to do now and then. And yes, I can see the temptation to get Python to do it, but unfortunately, newline support is such a weird mess of cross-platform support that I don't think it needs to be made more complicated :) 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/5VGYDJ4RZRWQWHBMSQZUD5QJUHVF2J66/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: TextIOWrapper support for null-terminated lines
On 24Oct2020 13:37, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote: >On 2020-10-24 at 12:29:01 -0400, >Brian Allen Vanderburg II via Python-ideas wrote: > >> ... Find can output it's filenames in null-terminated lines since it >> is possible to have newlines in a filename(yuck) ... > >Spaces in filenames are just as bad, and much more common: But much easier to handle in simple text listings, which are newline delimited. You're really running into a horrible behaviour from xargs, which is one reason why GNU parallel exists. Cheers, Cameron Simpson ___ 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/6EO37LQLQWTZDJQA3FRD4FQSC7IOHKYU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: execute function on iterator items without changing or consuming iterator
On 2020-10-25 at 16:34:14 +, George Harding wrote: > some_iter = map(lambda x: x if print(x) else x, some_iter) > > The tuple has a ~50% overhead, the case statement ~15%, compared to the > generator. def print_first(x): print(x) return x new_iter = map(print_first, some_iter) No extranous tuple, no extranous case stament. Newlines are cheap these days. The call to print, however, is possibly unbounded in time and space. If you really want to go overboard, put something like the following peeker function into your personal toolbox (untested): def peeker(function): def peeker(x): function(x) return x return peeker And use it like this: new_iter = map(peeker(print), some_iter) ___ 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/RG2ZQD5NNU2BKVTC2AZGSQNVZA2CV2UJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: execute function on iterator items without changing or consuming iterator
less awkward is: some_iter = map(lambda x: x if print(x) else x, some_iter) The tuple has a ~50% overhead, the case statement ~15%, compared to the generator. I think that the less awkward syntax solves the problem fine (if you can come up with it). I like that it's explicit rather than requiring someone to know what itertools.tap does. On Sun, Oct 25, 2020 at 4:27 PM Samuel Freilich via Python-ideas < python-ideas@python.org> wrote: > This seems like it might be a reasonable thing to have in intertools? It's > not hard to write this sort of thing with map: > > some_iter = map(lambda x: (print(x), x)[1], some_iter) > > But it's a little awkward. (Though maybe I'm missing a less awkward way to > do that.) > > Java has Stream.peek for similar functionality, while Stream.forEach is > analogous to Python's map. > > On Sun, Oct 25, 2020 at 9:02 AM wrote: > >> Python has many tools for iteration, such as map and filter, that change >> an iterator into another iterator without consuming the iterator. These >> make it simple to deal with many items in a list without consuming >> excessive memory. >> >> Occasionally it is useful to be able to tap into iterator items and >> execute a function (such as a side effect to validate elements or print >> them) without making any changes to the overall iterator. This is similar >> to the idea of a tap in rxjs: >> https://rxjs-dev.firebaseapp.com/api/operators/tap. >> >> The proposed interface would be: >> def generate_items() -> list[int]: >> some_iter = range(10) >> some_iter = tap(assert_int, some_iter) >> some_iter = tap(print, some_iter) >> return list(some_iter) >> >> This would be useful to (for example): >> 1. Debug chained iterators without a debugger (at the moment you would >> have to convert the list and then print the whole list or include a print >> statement in one of the chained functions) >> 2. Check that items in an iterator conform to assumptions and raising >> exceptions if they do not >> 3. Improve type hints in editors since after the assert is executed all >> items conform to the assert in the tap (for example, they are an integer) >> >> The implementation would be quite simple (at least in python): >> def tap(func: typing.Callable[[T], typing.Any], iter: typing.Iterable[T]) >> -> typing.iterable[T]: >> for item in iter: >> func(item) >> yield item >> >> Thoughts? >> ___ >> 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/7Q3NR4SKUC72PVQ3APK2HL2HNX3HP2IE/ >> 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/7AUUGTM77ZJFJ4PSZUYHB2PW2VJKBYYT/ > 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/XJQMJU3PJ3AWOTB5MTGNHLNVAVIZG7K6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: execute function on iterator items without changing or consuming iterator
This seems like it might be a reasonable thing to have in intertools? It's not hard to write this sort of thing with map: some_iter = map(lambda x: (print(x), x)[1], some_iter) But it's a little awkward. (Though maybe I'm missing a less awkward way to do that.) Java has Stream.peek for similar functionality, while Stream.forEach is analogous to Python's map. On Sun, Oct 25, 2020 at 9:02 AM wrote: > Python has many tools for iteration, such as map and filter, that change > an iterator into another iterator without consuming the iterator. These > make it simple to deal with many items in a list without consuming > excessive memory. > > Occasionally it is useful to be able to tap into iterator items and > execute a function (such as a side effect to validate elements or print > them) without making any changes to the overall iterator. This is similar > to the idea of a tap in rxjs: > https://rxjs-dev.firebaseapp.com/api/operators/tap. > > The proposed interface would be: > def generate_items() -> list[int]: > some_iter = range(10) > some_iter = tap(assert_int, some_iter) > some_iter = tap(print, some_iter) > return list(some_iter) > > This would be useful to (for example): > 1. Debug chained iterators without a debugger (at the moment you would > have to convert the list and then print the whole list or include a print > statement in one of the chained functions) > 2. Check that items in an iterator conform to assumptions and raising > exceptions if they do not > 3. Improve type hints in editors since after the assert is executed all > items conform to the assert in the tap (for example, they are an integer) > > The implementation would be quite simple (at least in python): > def tap(func: typing.Callable[[T], typing.Any], iter: typing.Iterable[T]) > -> typing.iterable[T]: > for item in iter: > func(item) > yield item > > Thoughts? > ___ > 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/7Q3NR4SKUC72PVQ3APK2HL2HNX3HP2IE/ > 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/7AUUGTM77ZJFJ4PSZUYHB2PW2VJKBYYT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] execute function on iterator items without changing or consuming iterator
Python has many tools for iteration, such as map and filter, that change an iterator into another iterator without consuming the iterator. These make it simple to deal with many items in a list without consuming excessive memory. Occasionally it is useful to be able to tap into iterator items and execute a function (such as a side effect to validate elements or print them) without making any changes to the overall iterator. This is similar to the idea of a tap in rxjs: https://rxjs-dev.firebaseapp.com/api/operators/tap. The proposed interface would be: def generate_items() -> list[int]: some_iter = range(10) some_iter = tap(assert_int, some_iter) some_iter = tap(print, some_iter) return list(some_iter) This would be useful to (for example): 1. Debug chained iterators without a debugger (at the moment you would have to convert the list and then print the whole list or include a print statement in one of the chained functions) 2. Check that items in an iterator conform to assumptions and raising exceptions if they do not 3. Improve type hints in editors since after the assert is executed all items conform to the assert in the tap (for example, they are an integer) The implementation would be quite simple (at least in python): def tap(func: typing.Callable[[T], typing.Any], iter: typing.Iterable[T]) -> typing.iterable[T]: for item in iter: func(item) yield item Thoughts? ___ 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/7Q3NR4SKUC72PVQ3APK2HL2HNX3HP2IE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Conditional function/method/dict arguments assignments
I've been toying with a similar idea myself. I've felt the pain
described by Brian, and I share Marco's dislike for the suggested
syntax. Moreover, I dislike the idea that the conditional should
somehow refer to the function's default arguments.
My half-baked idea is along the lines of
f(val1, val2, if cond3: val3, if cond4: arg4=val4)
with the sense that if a condition is not met, the argument is just not
passed; this would be equivalent to
f(
val1, val2,
*[_ for _ in [val3] if cond3],
**{'arg4': _ for _ in [val4] if cond4}
)
As presented, this would work for list and set literals as well, but
the syntax is not good for dict literals; "{if cond: key: value}" feels
completely wrong. Alternative "{key if cond: value}" looks palatable at
first glance, but doesn't feel quite "in line" with the rest of the
proposal, and for my taste, looks too similar to the already valid
"{key1 if cond else key2: value}".
That last similarity is also why I don't like the syntax
f(arg1, arg2, arg3 if cond3, arg4=cond4 if cond4)
I've been thinking about alternatives such as
f(arg1, if (cond2) arg2)
f(arg1, (if cond2) arg2)
or just marking the if as a "special if", e.g.
f(arg1, arg2 if* cond2)
But I'm not really pleased with any of them.
Have fun,
Shai.
___
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/ZRDK3Z55MMTVZOLMYSKC32WE7DTZYNFS/
Code of Conduct: http://python.org/psf/codeofconduct/
