Mailman 3 Why not ['a','b','c'].join(',') ? - Python-ideas

newer
Re: [Python-ideas] Simpler thread...

Why not ['a','b','c'].join(',') ?

Juancarlo Añez

24 Mar 2019 24 Mar '19

5:05 a.m.

I know it has been discussed endlessly, so just a gentle reminder about the final arguments would be good. I think I remember it was discussed recently, mentioning that join() doesn't convert elements to strings? This came up while reading this speculative article about how programmers migrate from one programming language to the other (I call it speculative because there's no hard data, but the conclusions and comments pretty much match my experience and my observations over decades [I would add an arrow from Python3 to Rust]). https://apenwarr.ca/log/20190318 In that sense, I think it wouldn't hurt to make Python more familiar/friendly to people coming from other languages, even if it breaks "There should be one-- and preferably only one --obvious way to do it." -- Juancarlo *Añez*

Attachments:

attachment.htm (text/html — 1.2 KB)

Show replies by thread

Terry Reedy

24 Mar 24 Mar

8:49 a.m.

On 3/23/2019 7:35 PM, Juancarlo Añez wrote:

...

I know it has been discussed endlessly,

So please read any of the endless discussions either on this list or python-list. I myself have answered multiple times. -- Terry Jan Reedy

Jonathan Fine

2:41 p.m.

I'm willing to provide some useful information, if you're willing to write it up into a good blog post. -- Jonathan

Juancarlo Añez

4:58 p.m.

On Sun, Mar 24, 2019 at 5:11 AM Jonathan Fine wrote:

...

I'm willing to provide some useful information, if you're willing to write it up into a good blog post.

... or a PEP for rejection. Deal! -- Juancarlo *Añez*

Jonathan Fine

6:57 p.m.

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

Chris Angelico

9:31 p.m.

On Mon, Mar 25, 2019 at 12:28 AM Jonathan Fine 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

Jonathan Fine

10:46 p.m.

New subject: META: Is a PEP a good place to record Python's core design decisions and coding principles?

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

10:49 p.m.

New subject: META: Is a PEP a good place to record Python's core design decisions and coding principles?

I think this belongs in a personal blog, not on python-ideas and definitely not in a PEP. On Sun, Mar 24, 2019 at 10:18 AM Jonathan Fine wrote:

...

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.

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

-- --Guido van Rossum (python.org/~guido)

Chris Angelico

10:53 p.m.

New subject: META: Is a PEP a good place to record Python's core design decisions and coding principles?

On Mon, Mar 25, 2019 at 4:16 AM Jonathan Fine 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

Christopher Barker

10:53 p.m.

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 wrote:

...

On Mon, Mar 25, 2019 at 12:28 AM Jonathan Fine 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/

Jonathan Fine

11:02 p.m.

New subject: META: Is a PEP a good place to record Python's core design decisions and coding principles?

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

Abdur-Rahmaan Janhangeer

11:09 p.m.

I'm up for writing it, in fact i'm planning on a series of posts/mini books for the threads, too many, i repeat again too many gems are hidden away in the arc-hive. Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius On Sun, 24 Mar 2019, 13:12 Jonathan Fine, wrote:

...

I'm willing to provide some useful information, if you're willing to write it up into a good blog post. -- Jonathan

Christopher Barker

11:14 p.m.

New subject: META: Is a PEP a good place to record Python's core design decisions and coding principles?

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. (you can do something similar with a package that you may think should be in the stdlib, or a proposal that you might think should be a PEP, or...) In short, you don't need approval for an idea ahead of time -- if you demonstrate its worth, then it may be included later. If not, then maybe it wasn't a great idea, or it is a great idea that can live on outside the official project. -CHB On Sun, Mar 24, 2019 at 10:33 AM Jonathan Fine wrote:

...

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

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

-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

Christopher Barker

11:19 p.m.

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

Abdur-Rahmaan Janhangeer

11:22 p.m.

in markdown i guess, @vstinner and @matrixise initiative to rewrite a tuto for cpython beginners is really awesome according to me, yes, that's the right idea! Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius On Sun, 24 Mar 2019, 21:50 Christopher Barker, wrote:

...

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

Abdur-Rahmaan Janhangeer

25 Mar 25 Mar

2:25 a.m.

skeleton here: https://github.com/Abdur-rahmaanJ/py-mailing-list-summary On Sun, Mar 24, 2019 at 9:50 PM Christopher Barker 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>

Jeff Allen

3:58 a.m.

New subject: META: Is a PEP a good place to record Python's core design decisions and coding principles?

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

Brett Cannon

11:57 p.m.

New subject: META: Is a PEP a good place to record Python's core design decisions and coding principles?

On Sun, Mar 24, 2019 at 10:34 AM Jonathan Fine wrote:

...

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.

To help add more weight to what Guido said, it doesn't belong here and it only belongs in a PEP if that PEP is justifying the feature to begin with. IOW we don't need a PEP justifying every design decision that we have prior to the PEP process. -Brett

...

-- Jonathan

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

Ethan Furman

26 Mar 26 Mar

2:26 a.m.

New subject: META: Is a PEP a good place to record Python's core design decisions and coding principles?

Chris replied

...

Jonathan Fine opined:

...
Chris Angelico stated:

Chris -----

...

...
...
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".

Jonathan --------

...

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

Jonathan, you just lost some serious credibility. You really should do more research before posting. Chris -----

...

"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.

And if you want some examples, try here: https://stackoverflow.com/a/7542261/208880 -- ~Ethan~

1858

Age (days ago)

1860

Last active (days ago)

List overview

Download

18 comments

10 participants

participants (10)

Abdur-Rahmaan Janhangeer
Brett Cannon
Chris Angelico
Christopher Barker
Ethan Furman
Guido van Rossum
Jeff Allen
Jonathan Fine
Juancarlo Añez
Terry Reedy

Why not ['a','b','c'].join(',') ?

tags

participants (10)