Disclaimer: I've not recently read any discussions of this topic. And everything I say is my own opinion. SUMMARY The syntax of Python's string join operator are a consequence of Python's core design decisions and coding principles, together with the semantics of join. I'll explain this in a series of posts. Why str.join? Wouldn't list.join be better? =============================== Python variables don't have types. Python objects do have types. When writing Python, don't test for the type of an object, unless you have to. Instead, test to see if the object has the methods you need. Eg help(dict.update) update(...) D.update([E, ]**F) -> None. Update D from dict/iterable E and F. If E is present and has a .keys() method, then does: for k in E: D[k] = E[k] If E is present and lacks a .keys() method, then does: for k, v in E: D[k] = v In either case, this is followed by: for k in F: D[k] = F[k] Now for the semantics of string join. By Python principles From a str and an iterable The string join operator Produces a str You question amounts to this. Should the signature be (str, iterable) -> str # Informal type signature of join. or should it be (iterable, str) -> str At first glance, there's no way of choosing. But in Python we prefer aaa.join(bbb) to from somewhere import join join(aaa, bbb) So the question now becomes: Choose between str.join(iterable) iterable.join(str) There is some sense in having list.join. But in Python, we can't join the elements of a list without getting an iterable from the list (unless there's something like very special short-cut-semantics built into Python). So in Python the choice is between str.join(iterable) iterable.join(str) Now str.join looks more attractive. But I said, without thinking ahead, that the syntax of Python's string join operator is a consequence of Python's core design decisions and coding principles, together with the semantics of join. I'm not quite there yet, there's a gap to fill. I'll pause for a day or two now, just in case someone else wants to JOIN in the discussion, and perhaps fill the gap. -- Jonathan

SUMMARY I think we're about to have a discussion of what's appropriate to have on this list, so I've started a new thread. I formulate the question as: Is this list an appropriate place for the discovery, discussion and application of Python's core design decisions and coding principles? Or in other words, is a PEP an appropriate place to record the outcome of such activities? If you want to discuss further, this thread I suggest is the place to do it. But I'd rather you suspended such contributions, until I have elsewhere by example shown what I mean by the discover etc of Python's core principles. BACKGROUND In "Why not ['a','b','c'].join(',') ?" Chris Angelico wrote:

this is a topic for python-list, not python-ideas, unless someone

is proposing a change. In response, I made and stated a bold statement. Namely that the Python syntax for string join is a consequence of Python's core design decisions and coding principles, together with the semantics of join. When I made this statement, I was confident it was true. ABOUT PYTHON PRINCIPLES After further reflection, I realised that it applies more widely. I've also discovered, applying the principle, a gap in the Python string module. Right now and here is not a good time to talk about it, but YES, someone will be proposing a change. I've said recently on this list, at least once, that I'm a pure mathematician. And that I'm trained to find a small, simple and elegant system of rules which determine the behaviour of a large number of examples. AN EXAMPLE - Roman and Arabic numbers The Hindu-Arabic numeral system 1, 2, 3, 4, 5, ..., 9, 10, 11, ... were developed in 1st to 4th centuries by Indian mathematicians. Addition and multiplication of numbers, using this numeral system is much simpler than using the earlier Roman numeral system I, II, III, IV, V, ..., IX, X, XI, ... . This is part of the story of how the discovery and introduction of new concepts made addition and multiplication much easier. By the way, from about 500 to 630 a symbol that we now would call zero was introduced, and understood. And today zero is mathematics for children, if not exactly child's play. While writing this, I consulted https://en.wikipedia.org/wiki/Hindu%E2%80%93Arabic_numeral_system#History FACTS, AXIOMS and THEOREM Chris Angelico wrote:

It's way WAY simpler than all this. "Iterable" isn't a type, it's a protocol; in fact, "iterable" just means "has an __iter__ method".

I think that for Chris this is a FACT about Python. This is the way Python is. My mathematical approach is to find simple AXIOMS for which have this FACT is a logical consequence, or in other words a THEOREM. (Also we want the axioms not to have wrong statements as a logical consequence.) Here's an example to show how FACTS, AXIOMS and THEOREMS fit together. For most of us, at grade school statements such are 2 + 2 = 4 and 7 * 8 = 56 are FACTS when summoned from memory. And 1 + 2 + 3 + 4 + 5 = 15 is a THEOREM that arises from knowing how to add numbers (which for most students is a collection of FACTS). Now consider X = 1 + 2 + 3 + 4 + 5 + .... + 99 + 100 That X == 5050 is a THEOREM based on the FACT of addition, together with a laborious calculation. Once, a grade school teacher gave the calculation of X as work for his student to do. To the teacher's surprise, one of the students very soon came up to his desk with the correct answer 5050. This grade school student had discovered for himself the THEOREM, based on the fundamental properties of counting number, that 1 + 2 + 3 + ... + (N-1) + N == N (N + 1) / 2 This student went on to be the greatest pure and mathematician and theoretical physicist of his day. https://en.wikipedia.org/wiki/Carl_Friedrich_Gauss#Early_years ASIDE Mathematics is a special skill. All of us have our own special skills and experiences, and most of us are not mathematicians. Our community code of conduct encourages collaboration, so that all of our experiences and skill sets can contribute "to the whole of our efforts". With good will, we can overcome friction and misunderstanding between the X and non-X communities, for the benefit of all. For all every special skill X. Or in other words, many hands make light work, and many eyes find many more bugs. SUMMARY I have argued that Python's core design decisions and coding principles can, at least in part, be reduced to a system of AXIOMS that can be useful applied. I have argued mainly based on analogy with the Hindu-Arabic numeral system, and the life and work of Gauss.

Guido van Rossum wrote:

I think this belongs in a personal blog, not on python-ideas and definitely not in a PEP.

I don't agree, but I will accept that judgement, as if Guido still had BDFL status. -- Jonathan

On 24/03/2019 17:44, Christopher Barker wrote:

Jonathan,

This is the glory of open source projects -- if you have a great idea, you can simply do it:

- Start a document that describes Python's Core design principles - Put it up somewhere (gitHub would be good) where others can contribute to it - If it becomes a wonderful thing, then propose that it be published somewhere "official" -- as a meta-PEP or whatever.

And of course people have.I'd like to thank Victor Stinner and Eli Bendersky for their articles about aspects of Python and its implementation. I've found both useful to go back to. Others may like to bookmark these: https://pythondev.readthedocs.io/ https://eli.thegreenplace.net/tag/python I looked briefly for an article on .join(), but amusingly all I found was further evidence that the question that started this thread is a recurring one (https://eli.thegreenplace.net/2008/06/06/python-impressions). Jeff Allen

On Mon, Mar 25, 2019 at 4:16 AM Jonathan Fine <jfine2358@gmail.com> wrote:

FACTS, AXIOMS and THEOREM

Chris Angelico wrote:

...

It's way WAY simpler than all this. "Iterable" isn't a type, it's a protocol; in fact, "iterable" just means "has an __iter__ method".

I think that for Chris this is a FACT about Python. This is the way Python is.

"For me"? No. It is, pure and simply, a fact about Python. That is how the language is defined. It's not "for me" a fact, as if facts might not be facts for other people. That isn't how facts work, and it isn't how Python works. Here's some documentation on the iterator protocol, and if you want to discuss further, python-list hasn't had a long and rambling thread on "why are iterators the way they are" for a while... have fun. https://docs.python.org/3/library/stdtypes.html#typeiter ChrisA

I think is was a couple years ago that someone on this list suggested a “commonly suggested and rejected ideas” PEP. I don’t know that it should be a PEP, but it would be a good idea to have such a document in an “official” place. We could start with this one. Interestingly (to me), Chris’s explanation is a good one, but I don’t think historically accurate. IIRC, the join method was added to strings pretty early on, when most of the other methods were added. Back in the day (1.5 anyway), strings were pretty simple objects, and you did most string manipulation with functions in the string module, e.g. import string a_string = string.upper(a_string) The string module had a join() function -- lists did not have a join method. Strings themselves had (I think) no methods -- the only "functionality" they had was what other sequences had (slicing, "in", etc), and the % formatting operator. Which makes antoher point -- strings ARE sequences, so if sequences had a join() method, then strings should have a join() method, too, but it would join the items ini the sequence -- i.e. characters -- not really that useful ;-) When the string object was introduced (expanded) to have a full set of methods, it grew most of the functions in the string module, so naturally, join() was one of them. ( https://docs.python.org/3/whatsnew/2.0.html#string-methods). NOTE that a promary motivator for making stringoperations methods was that then unicode and "Old style" strings could have the same interface. As it turns out, str.join() works with any iterable, which is really nice, but back in the day, Python was more about sequences than iterables [1], and it still made sense that join really belonged with str, as it is inherently a string operation -- sure, any python object can be stringified, but not all objects actually produce a useful string representation, so a "stringify_and_join" method on every sequence is pretty out of place. And, as Chris points out, impossible for every iterable. [1] String methods were introduced in 2.0, and the iteration protocol was introduced in 2.1: https://www.python.org/dev/peps/pep-0234/ -CHB On Sun, Mar 24, 2019 at 9:02 AM Chris Angelico <rosuav@gmail.com> wrote:

On Mon, Mar 25, 2019 at 12:28 AM Jonathan Fine <jfine2358@gmail.com> wrote:

...

Disclaimer: I've not recently read any discussions of this topic. And

everything I say is my own opinion.

...

SUMMARY The syntax of Python's string join operator are a consequence of

Python's core design decisions and coding principles, together with the semantics of join. I'll explain this in a series of posts.

...

Why str.join? Wouldn't list.join be better? =============================== Python variables don't have types. Python objects do have types. When

writing Python, don't test for the type of an object, unless you have to. Instead, test to see if the object has the methods you need.

...

Eg help(dict.update) update(...) D.update([E, ]**F) -> None. Update D from dict/iterable E and F. If E is present and has a .keys() method, then does: for k in E:

D[k] = E[k]

...

If E is present and lacks a .keys() method, then does: for k, v in

E: D[k] = v

...

In either case, this is followed by: for k in F: D[k] = F[k]

Now for the semantics of string join. By Python principles From a str and an iterable The string join operator Produces a str

You question amounts to this. Should the signature be (str, iterable) -> str # Informal type signature of join. or should it be (iterable, str) -> str

At first glance, there's no way of choosing. But in Python we prefer aaa.join(bbb) to from somewhere import join join(aaa, bbb)

So the question now becomes: Choose between str.join(iterable) iterable.join(str)

There is some sense in having list.join. But in Python, we can't join

the elements of a list without getting an iterable from the list (unless there's something like very special short-cut-semantics built into Python).

...

So in Python the choice is between str.join(iterable) iterable.join(str)

Now str.join looks more attractive. But I said, without thinking ahead,

that the syntax of Python's string join operator is a consequence of Python's core design decisions and coding principles, together with the semantics of join.

...

I'm not quite there yet, there's a gap to fill. I'll pause for a day or

two now, just in case someone else wants to JOIN in the discussion, and perhaps fill the gap.

...

It's way WAY simpler than all this. "Iterable" isn't a type, it's a protocol; in fact, "iterable" just means "has an __iter__ method". Adding a method to iterables means adding that method to every single object that wants to be iterable, but adding a method to strings just means adding it to the str type.

And, this is a topic for python-list, not python-ideas, unless someone is proposing a change.

ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On Sun, Mar 24, 2019 at 10:40 AM Abdur-Rahmaan Janhangeer < arj.python@gmail.com> wrote:

I'm up for writing it,

I encourage you to look in the archives of this list for the previous discussion -- there are some good starting points there. Also -- rather than a series of posts, a community-written document on gitHub or something would be good. I suspect you'll get contributions. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

skeleton here: https://github.com/Abdur-rahmaanJ/py-mailing-list-summary On Sun, Mar 24, 2019 at 9:50 PM Christopher Barker <pythonchb@gmail.com> wrote:

I encourage you to look in the archives of this list for the previous discussion -- there are some good starting points there.

Also -- rather than a series of posts, a community-written document on gitHub or something would be good. I suspect you'll get contributions.

-CHB

-- Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Garanti sans virus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Disclaimer: I've not recently read any discussions of this topic. And everything I say is my own opinion. SUMMARY The syntax of Python's string join operator are a consequence of Python's core design decisions and coding principles, together with the semantics of join. I'll explain this in a series of posts. Why str.join? Wouldn't list.join be better? =============================== Python variables don't have types. Python objects do have types. When writing Python, don't test for the type of an object, unless you have to. Instead, test to see if the object has the methods you need. Eg help(dict.update) update(...) D.update([E, ]**F) -> None. Update D from dict/iterable E and F. If E is present and has a .keys() method, then does: for k in E: D[k] = E[k] If E is present and lacks a .keys() method, then does: for k, v in E: D[k] = v In either case, this is followed by: for k in F: D[k] = F[k] Now for the semantics of string join. By Python principles From a str and an iterable The string join operator Produces a str You question amounts to this. Should the signature be (str, iterable) -> str # Informal type signature of join. or should it be (iterable, str) -> str At first glance, there's no way of choosing. But in Python we prefer aaa.join(bbb) to from somewhere import join join(aaa, bbb) So the question now becomes: Choose between str.join(iterable) iterable.join(str) There is some sense in having list.join. But in Python, we can't join the elements of a list without getting an iterable from the list (unless there's something like very special short-cut-semantics built into Python). So in Python the choice is between str.join(iterable) iterable.join(str) Now str.join looks more attractive. But I said, without thinking ahead, that the syntax of Python's string join operator is a consequence of Python's core design decisions and coding principles, together with the semantics of join. I'm not quite there yet, there's a gap to fill. I'll pause for a day or two now, just in case someone else wants to JOIN in the discussion, and perhaps fill the gap. -- Jonathan

SUMMARY I think we're about to have a discussion of what's appropriate to have on this list, so I've started a new thread. I formulate the question as: Is this list an appropriate place for the discovery, discussion and application of Python's core design decisions and coding principles? Or in other words, is a PEP an appropriate place to record the outcome of such activities? If you want to discuss further, this thread I suggest is the place to do it. But I'd rather you suspended such contributions, until I have elsewhere by example shown what I mean by the discover etc of Python's core principles. BACKGROUND In "Why not ['a','b','c'].join(',') ?" Chris Angelico wrote:

this is a topic for python-list, not python-ideas, unless someone

is proposing a change. In response, I made and stated a bold statement. Namely that the Python syntax for string join is a consequence of Python's core design decisions and coding principles, together with the semantics of join. When I made this statement, I was confident it was true. ABOUT PYTHON PRINCIPLES After further reflection, I realised that it applies more widely. I've also discovered, applying the principle, a gap in the Python string module. Right now and here is not a good time to talk about it, but YES, someone will be proposing a change. I've said recently on this list, at least once, that I'm a pure mathematician. And that I'm trained to find a small, simple and elegant system of rules which determine the behaviour of a large number of examples. AN EXAMPLE - Roman and Arabic numbers The Hindu-Arabic numeral system 1, 2, 3, 4, 5, ..., 9, 10, 11, ... were developed in 1st to 4th centuries by Indian mathematicians. Addition and multiplication of numbers, using this numeral system is much simpler than using the earlier Roman numeral system I, II, III, IV, V, ..., IX, X, XI, ... . This is part of the story of how the discovery and introduction of new concepts made addition and multiplication much easier. By the way, from about 500 to 630 a symbol that we now would call zero was introduced, and understood. And today zero is mathematics for children, if not exactly child's play. While writing this, I consulted https://en.wikipedia.org/wiki/Hindu%E2%80%93Arabic_numeral_system#History FACTS, AXIOMS and THEOREM Chris Angelico wrote:

It's way WAY simpler than all this. "Iterable" isn't a type, it's a protocol; in fact, "iterable" just means "has an __iter__ method".

I think that for Chris this is a FACT about Python. This is the way Python is. My mathematical approach is to find simple AXIOMS for which have this FACT is a logical consequence, or in other words a THEOREM. (Also we want the axioms not to have wrong statements as a logical consequence.) Here's an example to show how FACTS, AXIOMS and THEOREMS fit together. For most of us, at grade school statements such are 2 + 2 = 4 and 7 * 8 = 56 are FACTS when summoned from memory. And 1 + 2 + 3 + 4 + 5 = 15 is a THEOREM that arises from knowing how to add numbers (which for most students is a collection of FACTS). Now consider X = 1 + 2 + 3 + 4 + 5 + .... + 99 + 100 That X == 5050 is a THEOREM based on the FACT of addition, together with a laborious calculation. Once, a grade school teacher gave the calculation of X as work for his student to do. To the teacher's surprise, one of the students very soon came up to his desk with the correct answer 5050. This grade school student had discovered for himself the THEOREM, based on the fundamental properties of counting number, that 1 + 2 + 3 + ... + (N-1) + N == N (N + 1) / 2 This student went on to be the greatest pure and mathematician and theoretical physicist of his day. https://en.wikipedia.org/wiki/Carl_Friedrich_Gauss#Early_years ASIDE Mathematics is a special skill. All of us have our own special skills and experiences, and most of us are not mathematicians. Our community code of conduct encourages collaboration, so that all of our experiences and skill sets can contribute "to the whole of our efforts". With good will, we can overcome friction and misunderstanding between the X and non-X communities, for the benefit of all. For all every special skill X. Or in other words, many hands make light work, and many eyes find many more bugs. SUMMARY I have argued that Python's core design decisions and coding principles can, at least in part, be reduced to a system of AXIOMS that can be useful applied. I have argued mainly based on analogy with the Hindu-Arabic numeral system, and the life and work of Gauss.

Guido van Rossum wrote:

I think this belongs in a personal blog, not on python-ideas and definitely not in a PEP.

I don't agree, but I will accept that judgement, as if Guido still had BDFL status. -- Jonathan

On 24/03/2019 17:44, Christopher Barker wrote:

Jonathan,

This is the glory of open source projects -- if you have a great idea, you can simply do it:

- Start a document that describes Python's Core design principles - Put it up somewhere (gitHub would be good) where others can contribute to it - If it becomes a wonderful thing, then propose that it be published somewhere "official" -- as a meta-PEP or whatever.

And of course people have.I'd like to thank Victor Stinner and Eli Bendersky for their articles about aspects of Python and its implementation. I've found both useful to go back to. Others may like to bookmark these: https://pythondev.readthedocs.io/ https://eli.thegreenplace.net/tag/python I looked briefly for an article on .join(), but amusingly all I found was further evidence that the question that started this thread is a recurring one (https://eli.thegreenplace.net/2008/06/06/python-impressions). Jeff Allen

On Mon, Mar 25, 2019 at 4:16 AM Jonathan Fine <jfine2358@gmail.com> wrote:

FACTS, AXIOMS and THEOREM

Chris Angelico wrote:

...

It's way WAY simpler than all this. "Iterable" isn't a type, it's a protocol; in fact, "iterable" just means "has an __iter__ method".

I think that for Chris this is a FACT about Python. This is the way Python is.

"For me"? No. It is, pure and simply, a fact about Python. That is how the language is defined. It's not "for me" a fact, as if facts might not be facts for other people. That isn't how facts work, and it isn't how Python works. Here's some documentation on the iterator protocol, and if you want to discuss further, python-list hasn't had a long and rambling thread on "why are iterators the way they are" for a while... have fun. https://docs.python.org/3/library/stdtypes.html#typeiter ChrisA

I think is was a couple years ago that someone on this list suggested a “commonly suggested and rejected ideas” PEP. I don’t know that it should be a PEP, but it would be a good idea to have such a document in an “official” place. We could start with this one. Interestingly (to me), Chris’s explanation is a good one, but I don’t think historically accurate. IIRC, the join method was added to strings pretty early on, when most of the other methods were added. Back in the day (1.5 anyway), strings were pretty simple objects, and you did most string manipulation with functions in the string module, e.g. import string a_string = string.upper(a_string) The string module had a join() function -- lists did not have a join method. Strings themselves had (I think) no methods -- the only "functionality" they had was what other sequences had (slicing, "in", etc), and the % formatting operator. Which makes antoher point -- strings ARE sequences, so if sequences had a join() method, then strings should have a join() method, too, but it would join the items ini the sequence -- i.e. characters -- not really that useful ;-) When the string object was introduced (expanded) to have a full set of methods, it grew most of the functions in the string module, so naturally, join() was one of them. ( https://docs.python.org/3/whatsnew/2.0.html#string-methods). NOTE that a promary motivator for making stringoperations methods was that then unicode and "Old style" strings could have the same interface. As it turns out, str.join() works with any iterable, which is really nice, but back in the day, Python was more about sequences than iterables [1], and it still made sense that join really belonged with str, as it is inherently a string operation -- sure, any python object can be stringified, but not all objects actually produce a useful string representation, so a "stringify_and_join" method on every sequence is pretty out of place. And, as Chris points out, impossible for every iterable. [1] String methods were introduced in 2.0, and the iteration protocol was introduced in 2.1: https://www.python.org/dev/peps/pep-0234/ -CHB On Sun, Mar 24, 2019 at 9:02 AM Chris Angelico <rosuav@gmail.com> wrote:

On Mon, Mar 25, 2019 at 12:28 AM Jonathan Fine <jfine2358@gmail.com> wrote:

...

Disclaimer: I've not recently read any discussions of this topic. And

everything I say is my own opinion.

...

SUMMARY The syntax of Python's string join operator are a consequence of

Python's core design decisions and coding principles, together with the semantics of join. I'll explain this in a series of posts.

...

Why str.join? Wouldn't list.join be better? =============================== Python variables don't have types. Python objects do have types. When

writing Python, don't test for the type of an object, unless you have to. Instead, test to see if the object has the methods you need.

...

Eg help(dict.update) update(...) D.update([E, ]**F) -> None. Update D from dict/iterable E and F. If E is present and has a .keys() method, then does: for k in E:

D[k] = E[k]

...

If E is present and lacks a .keys() method, then does: for k, v in

E: D[k] = v

...

In either case, this is followed by: for k in F: D[k] = F[k]

Now for the semantics of string join. By Python principles From a str and an iterable The string join operator Produces a str

You question amounts to this. Should the signature be (str, iterable) -> str # Informal type signature of join. or should it be (iterable, str) -> str

At first glance, there's no way of choosing. But in Python we prefer aaa.join(bbb) to from somewhere import join join(aaa, bbb)

So the question now becomes: Choose between str.join(iterable) iterable.join(str)

There is some sense in having list.join. But in Python, we can't join

the elements of a list without getting an iterable from the list (unless there's something like very special short-cut-semantics built into Python).

...

So in Python the choice is between str.join(iterable) iterable.join(str)

Now str.join looks more attractive. But I said, without thinking ahead,

that the syntax of Python's string join operator is a consequence of Python's core design decisions and coding principles, together with the semantics of join.

...

I'm not quite there yet, there's a gap to fill. I'll pause for a day or

two now, just in case someone else wants to JOIN in the discussion, and perhaps fill the gap.

...

It's way WAY simpler than all this. "Iterable" isn't a type, it's a protocol; in fact, "iterable" just means "has an __iter__ method". Adding a method to iterables means adding that method to every single object that wants to be iterable, but adding a method to strings just means adding it to the str type.

And, this is a topic for python-list, not python-ideas, unless someone is proposing a change.

ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On Sun, Mar 24, 2019 at 10:40 AM Abdur-Rahmaan Janhangeer < arj.python@gmail.com> wrote:

I'm up for writing it,

I encourage you to look in the archives of this list for the previous discussion -- there are some good starting points there. Also -- rather than a series of posts, a community-written document on gitHub or something would be good. I suspect you'll get contributions. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

skeleton here: https://github.com/Abdur-rahmaanJ/py-mailing-list-summary On Sun, Mar 24, 2019 at 9:50 PM Christopher Barker <pythonchb@gmail.com> wrote:

I encourage you to look in the archives of this list for the previous discussion -- there are some good starting points there.

Also -- rather than a series of posts, a community-written document on gitHub or something would be good. I suspect you'll get contributions.

-CHB

-- Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Garanti sans virus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>