Dear fellows,
\nwhat do you think about the PEP 8 Style Guide limiting us to 79 characters per line?
\nFor general purpose & coding projects: Sure, absolutely reasonable!
I think the major difference in Kaggle is that we are not only coding stuff here, but many people are creating Data-Stories or educational notebooks.
\n… so I would definitely enjoy some more characters which avoid line-breaks (lowering readability) in verbosely written or commented (which is ok for education purposes!) notebooks.
\nWant to see examples? See attachments.
\nOne is taken by @cdeotte's famous TPU notebook.
I also think that most people are using at least 15\", probably the average is up to more than 21\"; so letting have of the screen being white and introducing unnecessary line breaks seems not too reasonable.
\nPlease let me know your thoughts, as I guess there will be a lot of controversy.
", "messages": [ { "id": "972106", "postDate": "08/16/2020 08:37:19", "content": "Dear fellows,
\nwhat do you think about the PEP 8 Style Guide limiting us to 79 characters per line?
\nFor general purpose & coding projects: Sure, absolutely reasonable!
I think the major difference in Kaggle is that we are not only coding stuff here, but many people are creating Data-Stories or educational notebooks.
\n… so I would definitely enjoy some more characters which avoid line-breaks (lowering readability) in verbosely written or commented (which is ok for education purposes!) notebooks.
\nWant to see examples? See attachments.
\nOne is taken by @cdeotte's famous TPU notebook.
I also think that most people are using at least 15\", probably the average is up to more than 21\"; so letting have of the screen being white and introducing unnecessary line breaks seems not too reasonable.
\nPlease let me know your thoughts, as I guess there will be a lot of controversy.
", "rawMarkdown": "Dear fellows,\n\nwhat do you think about the PEP 8 Style Guide limiting us to 79 characters per line?\nFor general purpose & coding projects: Sure, absolutely reasonable!\n\nI think the major difference in Kaggle is that we are not only coding stuff here, but many people are creating Data-*Stories* or educational notebooks.\n\n… so I would definitely enjoy some more characters which avoid line-breaks (lowering readability) in verbosely written or commented (which is ok for education purposes!) notebooks.\n\nWant to see examples? See attachments.\nOne is taken by @cdeotte's famous TPU notebook.\n\nI also think that most people are using at least 15\", probably the average is up to more than 21\"; so letting have of the screen being white and introducing unnecessary line breaks seems not too reasonable. \n\nPlease let me know your thoughts, as I guess there will be a lot of controversy.", "votes": null }, { "id": "972155", "postDate": "08/16/2020 09:19:28", "content": "@matthewmasters, we had some cool discussions in the Wheathead detection competition and I value your opinion highly. What are your thoughts on this?
", "rawMarkdown": "matthewmasters, we had some cool discussions in the Wheathead detection competition and I value your opinion highly. What are your thoughts on this?", "votes": null }, { "id": "972272", "postDate": "08/16/2020 12:20:30", "content": "Hi, obviously PEP-8 itself is a very useful tool, its 80-characters-length rule isn't an exception. However, it's just a recommendation, not a strict rule. In my opinion, this is what we should focus on.
\nWriting more or less serious projects I always stick to PEP-8 including that rule. However, when I came to ML I noticed that notebooks code culture is not the same as the typical code culture. Some PEP-8 rules are omitted, in particular 80-characters-length rule. This is done for better readability of the code and a low threshold for entering the code itself, since working with notebooks, authors often have to change entire blocks of code, and people who read these notebooks must quickly understand them.
\nGoogle Colab developers understand this and don't interfere with the free culture code. However, at the same time, Kaggle Kernels developers don't understand them or just pretend. I think they should allow users to write the free culture code. And the first, and at the same time the most important step for this is removing the fixed limit on the string length.
", "rawMarkdown": "Hi, obviously PEP-8 itself is a very useful tool, its 80-characters-length rule isn't an exception. However, it's just a recommendation, not a strict rule. In my opinion, this is what we should focus on.\n\nWriting more or less serious projects I always stick to PEP-8 including that rule. However, when I came to ML I noticed that notebooks code culture is not the same as the typical code culture. Some PEP-8 rules are omitted, in particular 80-characters-length rule. This is done for better readability of the code and a low threshold for entering the code itself, since working with notebooks, authors often have to change entire blocks of code, and people who read these notebooks must quickly understand them.\n\nGoogle Colab developers understand this and don't interfere with the free culture code. However, at the same time, Kaggle Kernels developers don't understand them or just pretend. I think they should allow users to write the free culture code. And the first, and at the same time the most important step for this is removing the fixed limit on the string length.", "votes": null }, { "id": "972283", "postDate": "08/16/2020 12:30:42", "content": "Thanks for your opinion!
", "rawMarkdown": "Thanks for your opinion!", "votes": null }, { "id": "972312", "postDate": "08/16/2020 13:07:38", "content": "I much prefer reading code following pep-8. I am used to it and read it faster.
\nWhen working in a team, having everyone following the same code style is much better for that reason: one can rech ech other code much more effectively.
\nThe first thing I do when reusing someone else code is to break long lines with a new line after each argument comma. I find long lines as the ones you show to be extremely hard, the more so as people don't use a space after comma.
", "rawMarkdown": "I much prefer reading code following pep-8. I am used to it and read it faster. \n\nWhen working in a team, having everyone following the same code style is much better for that reason: one can rech ech other code much more effectively.\n\nThe first thing I do when reusing someone else code is to break long lines with a new line after each argument comma. I find long lines as the ones you show to be extremely hard, the more so as people don't use a space after comma.", "votes": null }, { "id": "972513", "postDate": "08/16/2020 15:53:26", "content": "i stick with pep8 whenever i can. it's not a difficult task, yapf, autopep8 and black packages offer auto-formatting.
\ni was looking for an ultra-widescreen, even with that, i'd stick with 80 lines.
", "rawMarkdown": "i stick with pep8 whenever i can. it's not a difficult task, yapf, autopep8 and black packages offer auto-formatting.\n\ni was looking for an ultra-widescreen, even with that, i'd stick with 80 lines.", "votes": null }, { "id": "973317", "postDate": "08/17/2020 08:34:03", "content": "Does it make sense for story-telling-Data-Science-Notebooks?
", "rawMarkdown": "Does it make sense for story-telling-Data-Science-Notebooks?", "votes": null } ], "comments": [ { "id": 972155, "author_name": "ChristianDenich", "author_url": "", "post_date": "08/16/2020 09:19:28", "content": "@matthewmasters, we had some cool discussions in the Wheathead detection competition and I value your opinion highly. What are your thoughts on this?
", "votes": null, "replies": [] }, { "id": 972272, "author_name": "vadimtimakin", "author_url": "", "post_date": "08/16/2020 12:20:30", "content": "Hi, obviously PEP-8 itself is a very useful tool, its 80-characters-length rule isn't an exception. However, it's just a recommendation, not a strict rule. In my opinion, this is what we should focus on.
\nWriting more or less serious projects I always stick to PEP-8 including that rule. However, when I came to ML I noticed that notebooks code culture is not the same as the typical code culture. Some PEP-8 rules are omitted, in particular 80-characters-length rule. This is done for better readability of the code and a low threshold for entering the code itself, since working with notebooks, authors often have to change entire blocks of code, and people who read these notebooks must quickly understand them.
\nGoogle Colab developers understand this and don't interfere with the free culture code. However, at the same time, Kaggle Kernels developers don't understand them or just pretend. I think they should allow users to write the free culture code. And the first, and at the same time the most important step for this is removing the fixed limit on the string length.
", "votes": null, "replies": [ { "id": 972283, "author_name": "ChristianDenich", "author_url": "", "post_date": "08/16/2020 12:30:42", "content": "Thanks for your opinion!
", "votes": null, "replies": [] } ] }, { "id": 972312, "author_name": "cpmpml", "author_url": "", "post_date": "08/16/2020 13:07:38", "content": "I much prefer reading code following pep-8. I am used to it and read it faster.
\nWhen working in a team, having everyone following the same code style is much better for that reason: one can rech ech other code much more effectively.
\nThe first thing I do when reusing someone else code is to break long lines with a new line after each argument comma. I find long lines as the ones you show to be extremely hard, the more so as people don't use a space after comma.
", "votes": null, "replies": [] }, { "id": 972513, "author_name": "yimacs", "author_url": "", "post_date": "08/16/2020 15:53:26", "content": "i stick with pep8 whenever i can. it's not a difficult task, yapf, autopep8 and black packages offer auto-formatting.
\ni was looking for an ultra-widescreen, even with that, i'd stick with 80 lines.
", "votes": null, "replies": [ { "id": 973317, "author_name": "ChristianDenich", "author_url": "", "post_date": "08/17/2020 08:34:03", "content": "Does it make sense for story-telling-Data-Science-Notebooks?
", "votes": null, "replies": [] } ] } ], "raw_markdown_by_id": { "972106": "Dear fellows,\n\nwhat do you think about the PEP 8 Style Guide limiting us to 79 characters per line?\nFor general purpose & coding projects: Sure, absolutely reasonable!\n\nI think the major difference in Kaggle is that we are not only coding stuff here, but many people are creating Data-*Stories* or educational notebooks.\n\n… so I would definitely enjoy some more characters which avoid line-breaks (lowering readability) in verbosely written or commented (which is ok for education purposes!) notebooks.\n\nWant to see examples? See attachments.\nOne is taken by @cdeotte's famous TPU notebook.\n\nI also think that most people are using at least 15\", probably the average is up to more than 21\"; so letting have of the screen being white and introducing unnecessary line breaks seems not too reasonable. \n\nPlease let me know your thoughts, as I guess there will be a lot of controversy.", "972155": "matthewmasters, we had some cool discussions in the Wheathead detection competition and I value your opinion highly. What are your thoughts on this?", "972272": "Hi, obviously PEP-8 itself is a very useful tool, its 80-characters-length rule isn't an exception. However, it's just a recommendation, not a strict rule. In my opinion, this is what we should focus on.\n\nWriting more or less serious projects I always stick to PEP-8 including that rule. However, when I came to ML I noticed that notebooks code culture is not the same as the typical code culture. Some PEP-8 rules are omitted, in particular 80-characters-length rule. This is done for better readability of the code and a low threshold for entering the code itself, since working with notebooks, authors often have to change entire blocks of code, and people who read these notebooks must quickly understand them.\n\nGoogle Colab developers understand this and don't interfere with the free culture code. However, at the same time, Kaggle Kernels developers don't understand them or just pretend. I think they should allow users to write the free culture code. And the first, and at the same time the most important step for this is removing the fixed limit on the string length.", "972283": "Thanks for your opinion!", "972312": "I much prefer reading code following pep-8. I am used to it and read it faster. \n\nWhen working in a team, having everyone following the same code style is much better for that reason: one can rech ech other code much more effectively.\n\nThe first thing I do when reusing someone else code is to break long lines with a new line after each argument comma. I find long lines as the ones you show to be extremely hard, the more so as people don't use a space after comma.", "972513": "i stick with pep8 whenever i can. it's not a difficult task, yapf, autopep8 and black packages offer auto-formatting.\n\ni was looking for an ultra-widescreen, even with that, i'd stick with 80 lines.", "973317": "Does it make sense for story-telling-Data-Science-Notebooks?" }, "source": "meta" }