[Python-ideas] Adding str.remove()

[David Mertz]

I was actually thinking about this before the recent "string comprehension"
thread.  I wasn't really going to post the idea, but it's similar enough
that I am nudged to.  Moreover, since PEP 616 added str.removeprefix() and
str.removesuffix(), this feels like a natural extension of that.

I find myself very often wanting to remove several substrings of similar
lines to get at "the good bits" for my purpose.  Log files are a good
example of this, but it arises in lots of other contexts I encounter.
Let's take a not-absurd hypothetical:

GET [http://example.com/picture] 200 image/jpeg
POST [http://nowhere.org/data] 200 application/json
PUT [https://example.org/page] 200 text/html

For each of these lines, I'd like to see the URL and the MIME type only.
The new str.removeprefix() helps some, but not as much as I would like
since the "remove a tuple of prefixes" idea was rejected for PEP 616.  But
even past that, very often much of what I want to remove is in the middle,
not at the start or the end.

I know I can use regular expressions here.  However, they are definitely a
higher cognitive burden, and especially so for those who haven't taught
them and written about them a lot, as I have.  Even for me, I'd rather not
think about regexen if I don't *have to*.  So probably I'll do something
like this:

for line in lines:
for noise in ('GET', 'POST', 'PUT', '200', '[', ']'):
line = line.replace(noise, '')
process_line(line)

That's not horrible, but it would be nicer to write:

for line in lines:
process_line(line.remove(('GET', 'POST', 'PUT', '200', '[', ']'))

Of course, if I really needed this as much as I seem to be suggesting, I
know how to write a function `remove_strings()`... and I confess I have not
done that. Or at least I haven't done it in some standard "my_utils" module
I always import.  Nonetheless, a string method would feel even more natural
than a function taking the string as an argument.

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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/L2MZHRJX7TTKY7LY2R7GKQMU4D46RQPK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: String comprehension

[Steven D'Aprano]

I thought I had sent a response to this a few hours ago, but it seems to 
have been eaten by the email gremlins.

Apologies if this ends up as a duplicate.

On Fri, Apr 30, 2021 at 12:03:15PM -0400, David Álvarez Lombardi wrote:
> I propose a syntax for constructing/filtering strings analogous to the one
> available for all other builtin iterables.

*All* others?

The builtin interables bytearray, bytes, enumerate, filter frozenset, 
map, memoryview, range, reversed, tuple and zip suggest differently.

It isn't that str is the exceptional case, it is that dict, list and set 
are the exceptional cases. In fact, there is a sense that this is a 
historical accident, that list comprehensions happened to have been 
invented first. If we were re-designing Python from scratch today, it is 
quite likely that we would have only generator comprehensions:

list(expression for x in iterable)
set(expression for x in iterable)
dict((key, value) for x in iterable)


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

[Python-ideas] Re: String comprehension

[Steven D'Aprano]

On Sat, May 01, 2021 at 03:05:51AM -, Valentin Berlier wrote:

> It's kind of weird that people seem to be missing the point about 
> this. Python already has comprehensions for all the iterable builtins 
> except strings.

No it doesn't.

I count 15 builtin iterables, only three have comprehensions.


> The argument that we can already do this with the "".join() 
> idiom is backwards. It's something we have to do _because_ there's no 
> way to write a string comprehensions directly. Comprehensions express 
> intent.

Okay. What string comprehension do I write to express my intent to write 
a string containing words separated by commas?

What string comprehension do I write to express my intent to write a 
string containing lines separated by newlines?

What string comprehension do I write to express my intent to write a 
string containing substrings separated by ' - ' (space, hyphen, space)?

`str.join` can express the intent of every single one of those, as well 
as the intent to write a string containing substrings separated by the 
empty string.


> Joining a generator expression with an empty string doesn't 
> convey the intent that you're building a string where each character 
> is derived from another iterable.

Of course it does. What else could `''.join(expression)` mean, if not to 
build a string with the substrings derived from expression separated by 
the empty string?


> Also I haven't seen anyone acknowledge the potential performance 
> benefits of string comprehensions. The "".join() idiom needs to go 
> through the entire generator machinery to assemble the final string, 
> whereas a decent implementation of string comprehensions would enable 
> some pretty significant optimizations.

Do you know what's worse than premature optimization? Accepting a new 
special-case language feature on the basis that, maybe some day, it 
might possibly enable a premature optimization.

If you're going to claim a micro-optimization benefit, I think you need 
more than just to hand-wave that "a decent implementation" would allow 
it. Let's start with the simplest case:

c'substring for substring in expression'

What optimizations are available for that?


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

[Python-ideas] Re: String comprehension

[Chris Angelico]

On Sat, May 1, 2021 at 1:43 PM Valentin Berlier  wrote:
>
> > the ONLY predicate that can be expressed about a single character is it 
> > being a member of a subset of all Unicode characters
>
> You seem to be assuming that the comprehension would be purposefully 
> restricted to iterating over strings. The original author already provided 
> examples with predicates that don't involve checking for a subset of 
> characters.
>
> old = [0, 1, None, 2]
> new = c"str(x + 1) for x in old if isinstance(x, int)"
>
> The existing "".join() idiom isn't restricted to iterating over an existing 
> string. You also have to account for nested comprehensions. There's nothing 
> that would prevent you from having arbitrary complexity in string 
> comprehension predicates, just like nothing prevents you from having 
> arbitrary predicates when you join a generator expression.
>

Rather than toy examples, how about scouring the Python standard
library for some real examples? Find some actual existing code and
show how it would be improved by this new construct. Consistency on
its own is not a sufficient goal; you have to demonstrate that the
change would be of material value.

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

[Python-ideas] Re: String comprehension

[2QdxY4RzWzUUiLuE]

On 2021-05-01 at 03:05:51 -,
Valentin Berlier  wrote:

> Also I haven't seen anyone acknowledge the potential performance
> benefits of string comprehensions. The "".join() idiom needs to go
> through the entire generator machinery to assemble the final string,
> whereas a decent implementation of string comprehensions would enable
> some pretty significant optimizations.

In certain special cases, maybe.  In the general case, no.  How much
optimization can you do on something like the following:

c"f(c) for c in some_string if g(c)"

I'll even let you assume that f and g are pure functions (i.e., no side
effects), but you can't assume that f always returns a string of length
1.  Even the simpler c"c + c for c in some_string" at some point has to
decide whether (a) to collect all the pieces in a temporary container
and join them at the end, or (b) to suffer quadratic (or worse) behavior
by appending the pieces to an intermediate accumulator as it iterates.

Also, how often do any of the use cases come up in inner loops, where
performance is important?
___
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/4PMGNOW2OOKAJBZMULWB3FU6JA4IS3KR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: String comprehension

[David Mertz]

Ok... If the suggestion is trying concatenation of arbitrary objects that
aren't strings, I go from thinking it's unnecessary to thinking it's a
massively horrible idea.

On Fri, Apr 30, 2021, 11:43 PM Valentin Berlier  wrote:

> > the ONLY predicate that can be expressed about a single character is it
> being a member of a subset of all Unicode characters
>
> You seem to be assuming that the comprehension would be purposefully
> restricted to iterating over strings. The original author already provided
> examples with predicates that don't involve checking for a subset of
> characters.
>
> old = [0, 1, None, 2]
> new = c"str(x + 1) for x in old if isinstance(x, int)"
>
> The existing "".join() idiom isn't restricted to iterating over an
> existing string. You also have to account for nested comprehensions.
> There's nothing that would prevent you from having arbitrary complexity in
> string comprehension predicates, just like nothing prevents you from having
> arbitrary predicates when you join a generator expression.
> ___
> 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/6T7NQT5HFVYSI3RHUCBDDCEWKJ7HDPZG/
> 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/JU46RLGQVB4HKR3PNKC6AJUV2NODNG6S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: String comprehension

[Valentin Berlier]

> the ONLY predicate that can be expressed about a single character is it being 
> a member of a subset of all Unicode characters

You seem to be assuming that the comprehension would be purposefully restricted 
to iterating over strings. The original author already provided examples with 
predicates that don't involve checking for a subset of characters.

old = [0, 1, None, 2]
new = c"str(x + 1) for x in old if isinstance(x, int)"

The existing "".join() idiom isn't restricted to iterating over an existing 
string. You also have to account for nested comprehensions. There's nothing 
that would prevent you from having arbitrary complexity in string comprehension 
predicates, just like nothing prevents you from having arbitrary predicates 
when you join a generator expression.
___
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/6T7NQT5HFVYSI3RHUCBDDCEWKJ7HDPZG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: String comprehension

[David Mertz]

Strings are VERY different from other iterables. Every item in a string is
itself an (iterables) string. In many ways, strings are more like scalars,
and very often we treat them as such.

You could make an argument that e.g. a NumPy array of homogenous scalars is
similar. However, that would be a wrong argument.

Quite literally the ONLY predicate that can be expressed about a single
character is it being a member of a subset of all Unicode characters. Yes,
you could express that in convoluted ways like it's ord() being in a
certain range, but it boils down to subset membership.

In contrast, predicates of unlimited complexity can be expressed of
numbers. You can ask if an integer is prime. You can ask is the sine of the
square of a float is more than pi/4. Arbitrary predicates make sense of
arbitrary iterables. This is not so of the characters making up strings
strings.

On Fri, Apr 30, 2021, 11:08 PM Valentin Berlier  wrote:

> It's kind of weird that people seem to be missing the point about this.
> Python already has comprehensions for all the iterable builtins except
> strings. The proposed syntax doesn't introduce any new concept and would
> simply make strings more consistent with the rest of the builtins.  The
> argument that we can already do this with the "".join() idiom is backwards.
> It's something we have to do _because_ there's no way to write a string
> comprehensions directly. Comprehensions express intent. Joining a generator
> expression with an empty string doesn't convey the intent that you're
> building a string where each character is derived from another iterable.
>
> Also I haven't seen anyone acknowledge the potential performance benefits
> of string comprehensions. The "".join() idiom needs to go through the
> entire generator machinery to assemble the final string, whereas a decent
> implementation of string comprehensions would enable some pretty
> significant optimizations.
> ___
> 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/CYCM35RAKL7PMPGE2VYQ2ZPKK5RSMEZM/
> 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/SOJOYZJPPYBHGASVDWZKHDQEITRAV5X4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: String comprehension

[Valentin Berlier]

It's kind of weird that people seem to be missing the point about this. Python 
already has comprehensions for all the iterable builtins except strings. The 
proposed syntax doesn't introduce any new concept and would simply make strings 
more consistent with the rest of the builtins.  The argument that we can 
already do this with the "".join() idiom is backwards. It's something we have 
to do _because_ there's no way to write a string comprehensions directly. 
Comprehensions express intent. Joining a generator expression with an empty 
string doesn't convey the intent that you're building a string where each 
character is derived from another iterable.

Also I haven't seen anyone acknowledge the potential performance benefits of 
string comprehensions. The "".join() idiom needs to go through the entire 
generator machinery to assemble the final string, whereas a decent 
implementation of string comprehensions would enable some pretty significant 
optimizations.
___
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/CYCM35RAKL7PMPGE2VYQ2ZPKK5RSMEZM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: String comprehension

[David Mertz]

Given that there is very little you can test about a single character, a
new construct feels excessive. Basically, the only possible question is "is
it in this subset of codepoints?"

However, that use is perfectly covered by the str.translate() method
already. Regular expressions also cover this well.

On Fri, Apr 30, 2021, 12:08 PM David Álvarez Lombardi 
wrote:

> I propose a syntax for constructing/filtering strings analogous to the one
> available for all other builtin iterables. It could look something like
> this.
>
> >>> dirty = "f8sjGe7"
> >>> clean = c"char for char in dirty if char in string.ascii_letters"
> >>> clean
> 'fsjGe'
>
> Currently, the best way to do this (in the general case) seems to be the
> following.
> >>> clean = "".join(char for char in dirty if char in string.ascii_letters)
>
> But I think the proposed syntax would be superior for two main reasons.
>
>- Consistency with the comprehension style for all other iterables
>(which seems to be one of the most beloved features of python)
>- Confusion surrounding the str.join(iter) syntax is very well
>documented
>
> 
>and I believe it is particularly unintuitive when the string is empty
>
> I also believe the following reasons carry some weight.
>
>- Skips unnecessary type switching from str to iter and back to str
>- Much much MUCH more readable/intuitive
>
> Please let me know what you all think. It was mentioned (by @rhettinger)
> in the PBT issue  that this will
> likely require a PEP which I would happily write if there is a positive
> response.
>
> --
>
> *David Álvarez Lombardi*
> Machine Learning Spanish Linguist
> Amazon | Natural Language Understanding
>   Boston, Massachusetts
>   alvarezdqal 
> ___
> 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/MVQGP4GGTIWQRJTSY5S6SDYES6JVOOGK/
> 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/E7OJDOS6OMZIR6DB6RTDT57IZ646PPLS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: String comprehension

[Chris Angelico]

On Sat, May 1, 2021 at 6:23 AM Rob Cliffe via Python-ideas
 wrote:
> Yes I agree your examples read nicely, without the usual boilerplate.  
> Whether this is worth adding to the language is a moot point.  Every addition 
> increases the size of the compiler/interpreter, increases the maintenance 
> burden, and adds to the learning curve for newbies (and not-so-newbies).  As 
> far as I can see in every case
> c'SOMETHING'
> can be replaced by
> ''.join(SOMETHING)
> or
> str.join('', (SOMETHING))
> Having many ways to do the same thing is not a plus.
>

(We can ignore the str.join('', THING) option, as that's just a
consequence of the way that instance method lookups work, and
shouldn't happen in people's code (although I'm sure it does).)

If people want a more intuitive way to join things, how about this?

>>> class Str(str):
... __rmul__ = str.join
...
>>> ["a", "b", "c"] * Str(",")
'a,b,c'

Or perhaps:

... def __rmul__(self, iter):
... return self.join(str(x) for x in iter)
...
>>> ["a", 123, "b"] * Str(" // ")
'a // 123 // b'

If you want an intuitive way to join strings, surely multiplying a
collection by a string makes better sense than wrapping it up in a
literal-like thing. A string-literal-like-thing already exists for
complex constructions - it's the f-string. The c-string doesn't really
add anything above that.

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

[Python-ideas] Re: String comprehension

[Rob Cliffe via Python-ideas]

On 30/04/2021 19:14, David Álvarez Lombardi wrote:
I appreciate the feedback, but I don't think the proposed ideas 
address any of my points.


 1. *Consistency *(with other comprehensions)

You're actually adding an inconsistency: having a comprehension inside 
string quotes instead of not.


 1. *Intuitiveness *(as opposed to str.join(iter)which is widely
deemed to be confusing and seemingly-backwards)

Yes I agree your examples read nicely, without the usual boilerplate.  
Whether this is worth adding to the language is a moot point.  Every 
addition increases the size of the compiler/interpreter, increases the 
maintenance burden, and adds to the learning curve for newbies (and 
not-so-newbies).  As far as I can see in every case

    c'SOMETHING'
can be replaced by
    ''.join(SOMETHING)
or
    str.join('', (SOMETHING))
Having many ways to do the same thing is not a plus.


 1. *Efficiency *(with respect to line count and function calls...
though perhaps the cpython implementation could actually avoid the
type switching and improve time complexity)

It seems to me it would probably save a function call.  That seems like 
a minor consideration.


 1. *Readability *(due to /much /clearer typing and lack of
highly-nested function calls ( f"[{','.join('0123')}]" ) and
higher-order functions ( genjoin('', '', '')('0123') )


This seems to me to be making the same point as "Intuitiveness".
Best wishes
Rob Cliffe
(I can't hack your heading auto-numbering so they've all ended up being 
numbered 1.)
I would also like readers/commenters to consider the fact that, though 
I have only provided one use-case, the proposed enhancement would 
serve as the primary syntax for constructing or filtering a string 
*when dependent on any other iterable or condition*. I believe this to 
be an extremely common (almost universal) use-case. Here are just a 
couple more examples.


new = c"x.lower() for x in old if x in HARDCODED_LIST"  # 
filter-in chars that appear in earlier-defined HARDCODED_LIST and 
convert to lower
new = c"x for x in old if not x.isprintable()"  # filter-in 
non-printable chars
new = c"str(int(x) + 1) for x in old if isinstance(x, int)"  # 
increment all integers by 1


To me, it is hard to see how any argument against this design (for 
anything other than implementation-difficulty or something along these 
lines) can be anything but an argument against iter comprehensions in 
general... but if someone disagrees, please say so.


My goal is to /decrease/ complexity, and personal/higher-order/nested 
procedures do not accomplish this in my eyes.


Thank you.

DQAL

On Fri, Apr 30, 2021 at 1:10 PM Jonathan Fine > wrote:


On Fri, Apr 30, 2021 at 6:00 PM Chris Angelico mailto:ros...@gmail.com>> wrote:

For those cases where you're merging literal parts and generated
parts, it may be of value to use an f-string:

>>> f"[{','.join('0123')}]"
'[0,1,2,3]'

The part in the braces is evaluated as Python code, and the
rest is
simple literals.


For readability, reuse and testing I think it often helps to have
a function (whose name is meaningful). We can get this via
   as_list_int_literal = gensep(',', '[', ']')

It would also be nice to allow as_list_int_literal to have a
docstring (which could also be used for testing).

I accept that in some cases Chris's ingenious construction has
benefits.

-- 
Jonathan

___
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/UVTLPOK4S663GIMSTUWBDMFSFHUEYHGJ/


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/QXDXJ3G6MU4OZTHYOD25EKRIFKHOTZQZ/
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 

[Python-ideas] TACE16 text encoding for Tamil language

[பா . மு . செல்வக்குமார்]

Hi,

I want to use this encoding
[1]
for Tamil language text because it is more consistent with the language's
nature, and Unicode encoding severely damages(read more here[2]
) the intrinsic
features of the fusion of alphabets.

a specific example would be when dealing with regex. *'^[சிகு]'* is the
intended expression for lines that starts with either 'சி' or 'கு' just
like how in English '^[ab]' matches lines that start with either 'a' or
'b'. But since Unicode represents some of the eastern languages with
multiple code points, '^[சிகு]' basically translates to  '^[ச,ி,க,ு]'
(using the commas for clarity) சி -> ச,ி and கு -> க,ு . Running the
expression over a few words in python, gives the results as shown in the
attached image.

Note: expected results can be obtained by using this expression '^(சி|கு)'
but this works for this specific case, but there should be a way to write
expressions to match சிசிசிகுகுசிகு?

regex in tamil is not a python issue. it is a unicode issue. I suppose if I
can encode Tamil text in TACE16 encoding, I can use regex directly over it
since (as I understand) re module runs matching over bytes.

Two basic questions,

   1. How do I approach writing a new text encoding codec for python and
   register it with the codec module.
   2. How would I convert utf-8 encoded pattern for regex into the custom
   codec so that the pattern and input string for re.match/search is
   consistent.


Links:
[1]
https://github.com/vanangamudi/tace16-utf8-converter/blob/master/tace16.py
[2] https://en.wikipedia.org/wiki/Tamil_All_Character_Encoding

-- 
Thanks,
வணங்காமுடி
(vanangamudi)
___
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/FMZUFWAGSZJV5NCVUGRQX3RLCW2EUWL6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: String comprehension

[2QdxY4RzWzUUiLuE]

On 2021-04-30 at 14:14:50 -0400,
David Álvarez Lombardi  wrote:

[...]

> new = c"x.lower() for x in old if x in HARDCODED_LIST"  # filter-in chars
> that appear in earlier-defined HARDCODED_LIST and convert to lower
> new = c"x for x in old if not x.isprintable()"  # filter-in
> non-printable chars
> new = c"str(int(x) + 1) for x in old if isinstance(x, int)"  # increment
> all integers by 1

[...]

> My goal is to *decrease* complexity, and personal/higher-order/nested
> procedures do not accomplish this in my eyes.

Embedding a[nother] domain specific language in a string also doesn't
decrease complexity; look at all the regular expression builders.

Unless you're a core developer (or perhaps not even then), I suspect
that most library functions started as "personal" functions.  Hey,
here's something I need for this project ... hey, I just wrote that for
the last project ... how many times will I write this before I stick it
in general_utilities ... let's see what python-ideas thinks ...

Add the following to your personal library and see how many times you
use it in the coming weeks or months:

def string_from_iterable_of_characters(iterable):
return ''.join(iterable)

I haven't tested anything, but string_from_iterable_of_characters should
take everything inside your c-strings unchanged.
___
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/SCPXXP4QC5MKGCOIVHDZIAY5PDQM2DXN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: String comprehension

[David Álvarez Lombardi]

Small correction: isinstance(x, int) should be x.isdigit() in the last
example.

On Fri, Apr 30, 2021 at 2:14 PM David Álvarez Lombardi <
alvarezd...@gmail.com> wrote:

> I appreciate the feedback, but I don't think the proposed ideas address
> any of my points.
>
>1. *Consistency *(with other comprehensions)
>2. *Intuitiveness *(as opposed to str.join(iter) which is widely
>deemed to be confusing and seemingly-backwards)
>3. *Efficiency *(with respect to line count and function calls...
>though perhaps the cpython implementation could actually avoid the type
>switching and improve time complexity)
>4.  *Readability *(due to *much *clearer typing and lack of
>highly-nested function calls ( f"[{','.join('0123')}]" ) and
>higher-order functions ( genjoin('', '', '')('0123') )
>
> I would also like readers/commenters to consider the fact that, though I
> have only provided one use-case, the proposed enhancement would serve as
> the primary syntax for constructing or filtering a string *when dependent
> on any other iterable or condition*. I believe this to be an
> extremely common (almost universal) use-case. Here are just a couple more
> examples.
>
> new = c"x.lower() for x in old if x in HARDCODED_LIST"  # filter-in chars
> that appear in earlier-defined HARDCODED_LIST and convert to lower
> new = c"x for x in old if not x.isprintable()"  # filter-in
> non-printable chars
> new = c"str(int(x) + 1) for x in old if isinstance(x, int)"  # increment
> all integers by 1
>
> To me, it is hard to see how any argument against this design (for
> anything other than implementation-difficulty or something along these
> lines) can be anything but an argument against iter comprehensions in
> general... but if someone disagrees, please say so.
>
> My goal is to *decrease* complexity, and personal/higher-order/nested
> procedures do not accomplish this in my eyes.
>
> Thank you.
>
> DQAL
>
> On Fri, Apr 30, 2021 at 1:10 PM Jonathan Fine  wrote:
>
>> On Fri, Apr 30, 2021 at 6:00 PM Chris Angelico  wrote:
>>
>> For those cases where you're merging literal parts and generated
>>> parts, it may be of value to use an f-string:
>>>
>>> >>> f"[{','.join('0123')}]"
>>> '[0,1,2,3]'
>>>
>>> The part in the braces is evaluated as Python code, and the rest is
>>> simple literals.
>>>
>>
>> For readability, reuse and testing I think it often helps to have a
>> function (whose name is meaningful). We can get this via
>>as_list_int_literal = gensep(',', '[', ']')
>>
>> It would also be nice to allow as_list_int_literal to have a docstring
>> (which could also be used for testing).
>>
>> I accept that in some cases Chris's ingenious construction has benefits.
>>
>> --
>> Jonathan
>>
>> ___
>> 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/UVTLPOK4S663GIMSTUWBDMFSFHUEYHGJ/
>> 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/DR5GHAJPJ3GBOPWLHWQGJHB6OTEIZANM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: String comprehension

[David Álvarez Lombardi]

I appreciate the feedback, but I don't think the proposed ideas address any
of my points.

   1. *Consistency *(with other comprehensions)
   2. *Intuitiveness *(as opposed to str.join(iter) which is widely deemed
   to be confusing and seemingly-backwards)
   3. *Efficiency *(with respect to line count and function calls... though
   perhaps the cpython implementation could actually avoid the type switching
   and improve time complexity)
   4.  *Readability *(due to *much *clearer typing and lack of
   highly-nested function calls ( f"[{','.join('0123')}]" ) and
   higher-order functions ( genjoin('', '', '')('0123') )

I would also like readers/commenters to consider the fact that, though I
have only provided one use-case, the proposed enhancement would serve as
the primary syntax for constructing or filtering a string *when dependent
on any other iterable or condition*. I believe this to be an
extremely common (almost universal) use-case. Here are just a couple more
examples.

new = c"x.lower() for x in old if x in HARDCODED_LIST"  # filter-in chars
that appear in earlier-defined HARDCODED_LIST and convert to lower
new = c"x for x in old if not x.isprintable()"  # filter-in
non-printable chars
new = c"str(int(x) + 1) for x in old if isinstance(x, int)"  # increment
all integers by 1

To me, it is hard to see how any argument against this design (for anything
other than implementation-difficulty or something along these lines) can be
anything but an argument against iter comprehensions in general... but if
someone disagrees, please say so.

My goal is to *decrease* complexity, and personal/higher-order/nested
procedures do not accomplish this in my eyes.

Thank you.

DQAL

On Fri, Apr 30, 2021 at 1:10 PM Jonathan Fine  wrote:

> On Fri, Apr 30, 2021 at 6:00 PM Chris Angelico  wrote:
>
> For those cases where you're merging literal parts and generated
>> parts, it may be of value to use an f-string:
>>
>> >>> f"[{','.join('0123')}]"
>> '[0,1,2,3]'
>>
>> The part in the braces is evaluated as Python code, and the rest is
>> simple literals.
>>
>
> For readability, reuse and testing I think it often helps to have a
> function (whose name is meaningful). We can get this via
>as_list_int_literal = gensep(',', '[', ']')
>
> It would also be nice to allow as_list_int_literal to have a docstring
> (which could also be used for testing).
>
> I accept that in some cases Chris's ingenious construction has benefits.
>
> --
> Jonathan
>
> ___
> 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/UVTLPOK4S663GIMSTUWBDMFSFHUEYHGJ/
> 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/QXDXJ3G6MU4OZTHYOD25EKRIFKHOTZQZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: String comprehension

[Jonathan Fine]

On Fri, Apr 30, 2021 at 6:00 PM Chris Angelico  wrote:

For those cases where you're merging literal parts and generated
> parts, it may be of value to use an f-string:
>
> >>> f"[{','.join('0123')}]"
> '[0,1,2,3]'
>
> The part in the braces is evaluated as Python code, and the rest is
> simple literals.
>

For readability, reuse and testing I think it often helps to have a
function (whose name is meaningful). We can get this via
   as_list_int_literal = gensep(',', '[', ']')

It would also be nice to allow as_list_int_literal to have a docstring
(which could also be used for testing).

I accept that in some cases Chris's ingenious construction has benefits.

-- 
Jonathan
___
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/UVTLPOK4S663GIMSTUWBDMFSFHUEYHGJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: String comprehension

[Chris Angelico]

On Sat, May 1, 2021 at 2:52 AM Jonathan Fine  wrote:
>
> Hi David
>
> I see where you are coming from. I find it helps to think of sep.join as a 
> special case. Here's a more general join, with sep.join equivalent to 
> genjoin(sep, '', '').
>
> def genjoin(sep, left, right):
> def fn(items):
> return left + sep.join(items) + right
> return fn
>
> Here's how it works
>
> genjoin('', '', '')('0123') == '0123'
> genjoin(',', '', '')('0123') == '0,1,2,3'
> genjoin(',', '[', ']')('0123') == '[0,1,2,3]'
>
> All of these examples of genjoin can be thought of as string comprehensions. 
> But they don't fit into your pattern for a string comprehension literal.
>

For those cases where you're merging literal parts and generated
parts, it may be of value to use an f-string:

>>> f"[{','.join('0123')}]"
'[0,1,2,3]'

The part in the braces is evaluated as Python code, and the rest is
simple literals.

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

[Python-ideas] Re: String comprehension

[Jonathan Fine]

Hi David

I see where you are coming from. I find it helps to think of sep.join as a
special case. Here's a more general join, with sep.join equivalent to
genjoin(sep, '', '').

def genjoin(sep, left, right):
def fn(items):
return left + sep.join(items) + right
return fn

Here's how it works

genjoin('', '', '')('0123') == '0123'
genjoin(',', '', '')('0123') == '0,1,2,3'
genjoin(',', '[', ']')('0123') == '[0,1,2,3]'

All of these examples of genjoin can be thought of as string
comprehensions. But they don't fit into your pattern for a string
comprehension literal.

By the way, one might want something even more general. Sometimes one wants
a fn such that

fn('') == '[]'
fn('0') == '[0,]'
fn('01') == '[0,1,]'

which is again a string comprehension.

I hope this helps.

-- 
Jonathan
___
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/PFWPDN2XA4VK3K6TALKU4TWRXSML65P5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] String comprehension

[David Álvarez Lombardi]

I propose a syntax for constructing/filtering strings analogous to the one
available for all other builtin iterables. It could look something like
this.

>>> dirty = "f8sjGe7"
>>> clean = c"char for char in dirty if char in string.ascii_letters"
>>> clean
'fsjGe'

Currently, the best way to do this (in the general case) seems to be the
following.
>>> clean = "".join(char for char in dirty if char in string.ascii_letters)

But I think the proposed syntax would be superior for two main reasons.

   - Consistency with the comprehension style for all other iterables
   (which seems to be one of the most beloved features of python)
   - Confusion surrounding the str.join(iter) syntax is very well documented
   

   and I believe it is particularly unintuitive when the string is empty

I also believe the following reasons carry some weight.

   - Skips unnecessary type switching from str to iter and back to str
   - Much much MUCH more readable/intuitive

Please let me know what you all think. It was mentioned (by @rhettinger) in
the PBT issue  that this will likely
require a PEP which I would happily write if there is a positive response.

-- 

*David Álvarez Lombardi*
Machine Learning Spanish Linguist
Amazon | Natural Language Understanding
  Boston, Massachusetts
  alvarezdqal 
___
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/MVQGP4GGTIWQRJTSY5S6SDYES6JVOOGK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[Rob Cliffe via Python-ideas]

On 30/04/2021 07:06, Abdur-Rahmaan Janhangeer wrote:



The Masonite docs for example is quite
nice:
https://docs.masoniteproject.com/ 



I read as far as the 4th sentence:
    "Use it for your next SaaS!" [no link atached] What on earth (I 
wanted to use a stronger expression) is an SaaS? I'd never heard of it. 
OK, Google told we what it stood for, but I don't feel any the wiser. 
Rob Cliffe
___
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/67UXHHXIE2E24YAY2GUPGXEDDAUYC3MX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[Abdur-Rahmaan Janhangeer]

Greetings,

That was an upto the point, precise and deep answer.
Seems a design agency (who are Python programmers
themselves, else they miss a thing or two) might
do a nice job. Maybe what's missing is a design code (set
of rules for headers, links, buttons etc)

Well i subscribed to d...@python.org and waiting for mod approval,
Will raise it over there. Thanks for input.

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius
___
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/NBBRICX5KVJBU77QB44MFAZL5KZ44KMA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[M.-A. Lemburg]

Hi Abdur-Rahmaan,

while I don't think our docs look particularly bad, freshening
up the looks a bit every now and then certainly is something
which should be considered to better show case the quality
of the product "Python".

In particular, it would make sense to bring the themes of the
main www.python.org website and the docs.python.org site closer
together, as there is a fairly dramatic break between the
two at the moment.

The same goes for the devguide.python.org and the wiki.python.org.

pypi.python.org is already a lot closer to the www.python.org
design and looks even fresher (it was launched in 2017, some time
after www.python.org, which was relaunched in 2014).

All this is mostly about marketing, though, so I'm not sure whether
this ML is the right place to discuss.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Apr 30 2021)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/


On 30.04.2021 08:06, Abdur-Rahmaan Janhangeer wrote:
> Greetings,
> 
> A proposal to change the theme of the 
> Python docs. Great softwares are not 
> distinguished by docs crankiness and
> unpleasantness. 
> 
> Though what's more important is the 
> content, nevertheless it can be made 
> more enjoyable to read.
> 
> The Masonite docs for example is quite
> nice: 
> https://docs.masoniteproject.com/
> 
> Kind Regards,
> 
> Abdur-Rahmaan Janhangeer
> about  | blog 
>  
> github 
> Mauritius
> 
> ___
> 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/TMK7ROBHGDFBPHXID7R3FAD23VSGK7FH/
> 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/BVP7LGR2JTNJKNPALXHRQAHX3XC4BPKQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[Abdur-Rahmaan Janhangeer]

Greetings,

Interesting, i don't remember getting answers from you
all this time i was posting to this list

Normally you'd expect Mr Chris quipping along these lines:
"Well you can have your *own* version of the docs locally,
just do this and that" or the 'regular' folks posting

> Great softwares are not
distinguished by docs crankiness and
unpleasantness.

That was intended to be humourous but if it hurts, i'm
sorry, next time posting i'll be sure to write a page-full of
respectful content. I withdraw my mail above and rephrase
it below:

Greetings list,

I have been reading the Python docs since long.
I have enjoyed it, it has great pieces of information.
You have how-tos, faqs etc. Really awesome to read.

However, I feel that the style is a bit bland and off putting
for newcomers. I suggest we consider changing the theme
to a crisper and cleaner look. I find docs such as Masonite
really enjoyable to read: https://docs.masoniteproject.com/

I do hope we can advance something along these lines.


Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius


On Fri, Apr 30, 2021 at 10:34 AM Paul Bryan  wrote:

> A recipe to have an idea be marginalized or ignored:
>
> 1. Start by denigrating the work of others with pejoratives like "cranky"
> and "unpleasant".
> 2. Do not provide any support to back such a claim, or call out any
> specific usability issue.
> 3. Imply that the content is deficient, without qualification.
> 4. Point to something that you just seem to like better, without
> comparison.
> 5. (Probably) expect others to implement your idea. Your work here is done.
>
> Paul
>
> On Fri, 2021-04-30 at 10:06 +0400, Abdur-Rahmaan Janhangeer wrote:
>
> Greetings,
>
> A proposal to change the theme of the
> Python docs. Great softwares are not
> distinguished by docs crankiness and
> unpleasantness.
>
> Though what's more important is the
> content, nevertheless it can be made
> more enjoyable to read.
>
> The Masonite docs for example is quite
> nice:
> https://docs.masoniteproject.com/
>
> Kind Regards,
>
> Abdur-Rahmaan Janhangeer
> about  | blog
> 
> github 
> Mauritius
> ___
> 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/TMK7ROBHGDFBPHXID7R3FAD23VSGK7FH/
> 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/U4ISS6PKQCZ2E5U2VYFSXJN4V6IWVXGV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing The Theme of Python Docs Site

[Paul Bryan]

A recipe to have an idea be marginalized or ignored:

1. Start by denigrating the work of others with pejoratives like
"cranky" and "unpleasant".
2. Do not provide any support to back such a claim, or call out any
specific usability issue. 
3. Imply that the content is deficient, without qualification.
4. Point to something that you just seem to like better, without
comparison.
5. (Probably) expect others to implement your idea. Your work here is
done.

Paul

On Fri, 2021-04-30 at 10:06 +0400, Abdur-Rahmaan Janhangeer wrote:
> Greetings,
> 
> A proposal to change the theme of the 
> Python docs. Great softwares are not 
> distinguished by docs crankiness and
> unpleasantness. 
> 
> Though what's more important is the 
> content, nevertheless it can be made 
> more enjoyable to read.
> 
> The Masonite docs for example is quite
> nice: 
> https://docs.masoniteproject.com/
> 
> Kind Regards,
> 
> Abdur-Rahmaan Janhangeer
> about | blog 
> github
> Mauritius
> ___
> 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/TMK7ROBHGDFBPHXID7R3FAD23VSGK7FH/
> 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/KS2MKJVC7PPNAAQUMDDKP5XKZHUSWYQ3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Changing The Theme of Python Docs Site

[Abdur-Rahmaan Janhangeer]

Greetings,

A proposal to change the theme of the
Python docs. Great softwares are not
distinguished by docs crankiness and
unpleasantness.

Though what's more important is the
content, nevertheless it can be made
more enjoyable to read.

The Masonite docs for example is quite
nice:
https://docs.masoniteproject.com/

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius
___
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/TMK7ROBHGDFBPHXID7R3FAD23VSGK7FH/
Code of Conduct: http://python.org/psf/codeofconduct/