Re: [Python-ideas] CoC violation
On Fri, Sep 21, 2018 at 01:55:03PM -0400, Franklin? Lee wrote: > On Fri, Sep 21, 2018 at 10:52 AM Elazar wrote: > > > > > > > > On Fri, Sep 21, 2018, 16:56 Philipp A. wrote: > >> > >> The main clause differentiating bad, weaponizable CoCs from good ones is > >> > >> "Assume good faith" > >> > >> Everything will be OK if good faith can reasonably be assumed (E.g. when > >> someone uses a word which is only offensive based on context) > >> On the other hand, e.g. obvious racial slurs never have a place on a > >> discussion board about a programming language. How can one possibly say > >> them in good faith? > > > > > > Here's how: as a demonstration that words that are considered slurs in > > certain contexts (such as the word "Negro" in America) might be considered > > perfectly legitimate day-to-day words in another context. Even if the > > example was incorrect, it is still legitimate. > > I didn't report him, and I don't agree with the ban, but I assume I'm > missing something if they felt the need to act so strongly, days after > the discussion died down. Hi folks, we have a committee-based process for making these decisions, so it necessarily takes some time. Brett and I can make urgent decisions but everything goes through the process. best, --titus ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause
Hi everyone, on behalf of the moderators… please, let’s stop discussing who accused whom of what, and either stick to the discussion at hand or be silent. If you can’t make a point without aggression or name calling, then it’s not a point you should be making. (That’s a general statement about this list and this thread, not about any one particular recent e-mail.) thanks, —titus > On Sep 17, 2018, at 3:16 AM, Abdur-Rahmaan Janhangeer > wrote: > > if (out.of.subject).pingpong: > time to let the thread go > > Abdur-Rahmaan Janhangeer > Mauritius > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Meta question: python-ideas HOWTO (re Re: PEP's shouldn't require a sponsor)
Hi folks, one of the list admins here, my eye was caught by this ongoing discussion. I’m responding to this message out of several on this topic, because it brings up an interesting point - do we have good documents on this process that are attached to python-ideas and/or core mentoring lists? I did some googling about, and the most specific thing I found was this description of python-ideas: “”" This list is to contain discussion of speculative language ideas for Python for possible inclusion into the language. If an idea gains traction it can then be discussed and honed to the point of becoming a solid proposal to put to python-dev as appropriate. “”” which seems insufficient... Should we provide a more explicit or detailed rationale for python-ideas, based on this thread? We could make some or all of the following points — * python-ideas is for discussion of speculative ideas * the process is, (1) refine ideas here, (2) after broad acceptance of basic premise, develop an informal writeup, (3) find a core dev sponsor who will back turning this into a PEP * pointers to PEP 1, https://www.python.org/dev/peps/pep-0001/, and Python governance, https://www.python.org/dev/peps/pep-0013/ * pointers to core mentorship list, https://www.python.org/dev/core-mentorship/, and python developer documentation, https://devguide.python.org * pointers to this thread * please note that the burden for adding features to the language is high because you’re affecting so many people, increasing support burden, etc. etc. * note that everyone working on python is a volunteer, please respect their time and effort. I could try drafting something and passing it by people on this list to see what they think, but I’m wondering if I’m missing an obvious resource that I could just link to in the python-ideas description. best, —titus > On Jul 26, 2019, at 10:49 PM, Kyle Stanley wrote: > > Eric V. Smith wrote: >> In addition, I find it hard to believe someone couldn't find a sponsor >> for a well-written PEP. I'm happy to sponsor such a PEP, even if I think >> it will be rejected. Rejected PEPs serve a useful purpose, too, if only >> to point to when the same issue comes up in the future. > > Do most of the other core developers also share this perspective? Even > though PEPs were not intended to be intimidating, they definitely can be > for those who are less familiar with the process. I can imagine that many > people would think that a "sponsor" would mean fully convincing someone > to be completely on board with their idea. > > As someone who only more recently began contributing to Python, my previous > perception of PEPs were these monolithic technical > documents that were well approved by the entire community. I'm slowly > starting to see them more as simply being well structured proposals after > having seen more of them. > > To many outside of the development community though, such as those proposing > ideas, their impression of a PEP is probably based on the > massive ones such as PEP 8. Although it was purely comical, I think PEP 401 > helped me quite a lot to see them as less intimidating. PEP 581 is a good > example of an actual approved one that's easily digestible. > ___ > 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/4WVJMMCFKQOUBSO452K45KIARIJ2Y6KB/ > 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/DJV477F6MCFK34A2L7YPJHLCJTB533XD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Meta question: python-ideas HOWTO (re Re: PEP's shouldn't require a sponsor)
+1 Will implement and circle back around to this list. best, --titus On Mon, Jul 29, 2019 at 08:38:22AM -0700, Guido van Rossum wrote: > I suggest to put this in the devguide and deep-link there from the > python-ideas (and python-dev?) description. The more we have under version > control the better. There shouldn't be a need for too much bikeshedding on > the first iteration -- just get a simple PR (along the lines of what you > wrote) up (you can ping me for review) and once it's merged you can link to > it; we can then easily iterate on the contents if there seems to be a need > for additional suggestions. > > On Mon, Jul 29, 2019 at 8:13 AM Ai mu wrote: > > > Hosting? I suggest Python wiki > > > > Abdur-Rahmaan Janhangeer > > ___ > > 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/NBILWWRZ46G2WUB3EHSZMII5V7B4IYD6/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > > -- > --Guido van Rossum (python.org/~guido) > *Pronouns: he/him/his **(why is my pronoun here?)* > <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> > ___ > 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/DVUIY3FCDB5VXD65NEXSVPZL5WEZRDWC/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- C. Titus Brown, ctbr...@ucdavis.edu ___ 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/WZJUBHEDUG6OE2T3T6S7KYMLDJ46RB4N/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Meta question: python-ideas HOWTO (re Re: PEP's shouldn't require a sponsor)
+1, will circle back around to this list with news. best, —titus > On Jul 29, 2019, at 11:38 AM, Guido van Rossum wrote: > > I suggest to put this in the devguide and deep-link there from the > python-ideas (and python-dev?) description. The more we have under version > control the better. There shouldn't be a need for too much bikeshedding on > the first iteration -- just get a simple PR (along the lines of what you > wrote) up (you can ping me for review) and once it's merged you can link to > it; we can then easily iterate on the contents if there seems to be a need > for additional suggestions. > > On Mon, Jul 29, 2019 at 8:13 AM Ai mu wrote: > Hosting? I suggest Python wiki > > Abdur-Rahmaan Janhangeer > ___ > 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/NBILWWRZ46G2WUB3EHSZMII5V7B4IYD6/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > > -- > --Guido van Rossum (python.org/~guido) > Pronouns: he/him/his (why is my pronoun here?) > ___ > 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/DVUIY3FCDB5VXD65NEXSVPZL5WEZRDWC/ > 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/UBKILVKBBYEZBHUYSXNTMUXO546HP2YE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python should take a lesson from APL: Walrus operator not needed
Hi folks, moderator here. I’d (strongly) suggest no further replies, unless there’s something Python specific to discuss. I’ll put the list into emergency moderation for a bit. thanks, —titus > On Nov 11, 2019, at 9:05 AM, Ricky Teachey wrote: > > > I have found that trying to explain the value of true notation to people who > lack the experience and training is always a losing proposition. I'm already > regretting having started this thread, simply because I know how this works. > Frankly, it's almost like trying to engage with a religious person while > trying to discuss the lack of evidence for the existence of supernatural > beings. They "know" what they "know" and it is a very rare case that someone > is actually going to get out of that box and comprehend what you are saying. > > > > I am done with this thread. It has received nothing but close-minded > hostility. Which is fine. I understand. That's the way the world works. > I've seen this kind of thing happen in many domains, not just programming. > > > > I intend this response in the most friendly and kind way possible: > > Approaching discussion in such a manner-- i.e., with the assumption that > other people, who see things differently than your (in your view) grounded, > logical, thought through, and deeply held standpoint, must "lack" things like > experience, training, or comprehension (in the example of your interlocution > with religious people) if they continue to differ with you-- could be one > reason people have reacted with what you are interpreting as hostility. > > People often naturally react hostile way when they detect the person they are > talking with believes they are lacking in some way. > > Furthermore, speaking as a religious person who is coming from a tradition > that is deeply introspective, and has grappled for centuries with other > points of view, I suggest that disparaging the ability of religious people to > "comprehend" your views doesn't make the point you think it does. Might want > to find a new example. My two cents. > > --- > Ricky. > > "I've never met a Kentucky man who wasn't either thinking about going home or > actually going home." - Happy Chandler > > ___ > 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/VLSRRZXV4IVT4K77WVNZMGVEEDQMNFCZ/ > 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/JUJ4PBZEJUWZE4EDJCJ3AUEEGM3XKNGX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: COMBINE operator
Hi all, moderator here. Saw this. No need to respond. thanks, --titus On Mon, Nov 18, 2019 at 07:30:05PM -, tonycst...@gmail.com wrote: > OMG people, no one said its a replacement for + > Its an addition. that does nothing but combining data. > It does not perform any mathematical operations whats so ever. It simply puts > things together regardless of their data type. > (1.1 & 5 & "word") results in 1.15word > That fact that you say "will be far more misleading" is because its > fundamentally misleading and needs to be fixed. > > Look at autoit code, even monkeys understand that & combines and + does math. > ___ > 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/FIEXDBO47QRKX4O7OSNTJRGDCYH5YJKU/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- C. Titus Brown, ctbr...@ucdavis.edu ___ 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/QX3CPGS4XQNVDW5VGBUMQNSCTUK6VH46/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Where should we put the python-ideas HOWTO?
Hi folks, sorry, took me more than a few months, but I wrote a draft of a python-ideas HOWTO here, https://hackmd.io/@-6xkuCDkTrSFptQEimAdcg/B1noEGh2H Thanks to Eric Smith and Chris Barker for their link suggestions, and Chris Angelico and Guido van Rossum for their additional thoughts in a brief off-list thread. SO. The question becomes, where do we host this? I received the strong suggestion from both Guido and Stephen Turnbull that it should be in the devguide (see quoted message from GvR below). But, when I finished this draft and went to look at the devguide repo, realized that the devguide at https://devguide.python.org/ may not be the best place to host it, because (as written) the dev guide is VERY focused on code development. I think this HOWTO is a bit more community and process oriented than the current top-level materials in the dev guide. So instead of submitting a PR, I am appealing to the list for your thoughts. The three easiest options I see are: 1. Put it on python.org, perhaps replacing the content here: https://www.python.org/dev/. I can’t figure out where that content is hosted (it’s not in https://github.com/python/pythondotorg/ !?) 2. put it in the current dev guide somewhere, just so it lands in version control. Then iterate on both it and the dev guide. My first thought would be to merge the content with this document, https://github.com/python/devguide/blob/master/langchanges.rst. 3. put it somewhere near the front of the current dev guide, and do more work to adjust the dev guide. Thoughts? Am I missing am obvious location? Should I just get on with a PR and we’ll sort it out later? :) best, —titus > On Jul 29, 2019, at 8:38 AM, Guido van Rossum wrote: > > I suggest to put this in the devguide and deep-link there from the > python-ideas (and python-dev?) description. The more we have under version > control the better. There shouldn't be a need for too much bikeshedding on > the first iteration -- just get a simple PR (along the lines of what you > wrote) up (you can ping me for review) and once it's merged you can link to > it; we can then easily iterate on the contents if there seems to be a need > for additional suggestions. > > On Mon, Jul 29, 2019 at 8:13 AM Ai mu wrote: > Hosting? I suggest Python wiki > > Abdur-Rahmaan Janhangeer > ___ > 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/NBILWWRZ46G2WUB3EHSZMII5V7B4IYD6/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > > -- > --Guido van Rossum (python.org/~guido) > Pronouns: he/him/his (why is my pronoun here?) > ___ > 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/DVUIY3FCDB5VXD65NEXSVPZL5WEZRDWC/ > 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/CO2673SSPEIQNCRYRAPH5VITQ7KQOOGQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Where should we put the python-ideas HOWTO?
> On Dec 1, 2019, at 8:15 AM, Jonathan Goble wrote: > > On Sun, Dec 1, 2019, 11:06 AM Ned Batchelder wrote: > On 12/1/19 10:45 AM, C. Titus Brown wrote: > > Hi folks, > > > > sorry, took me more than a few months, but I wrote a draft of a > > python-ideas HOWTO here, > > > > https://hackmd.io/@-6xkuCDkTrSFptQEimAdcg/B1noEGh2H [ munch of good discussion ] > > Thoughts? Am I missing am obvious location? Should I just get on with a PR > > and we’ll sort it out later? :) > > There is a page that catalogs the mailing lists: > https://www.python.org/community/lists/ . A new page linked from the > Python-Ideas description (which is very brief!) sounds good to me. > > Thanks again for doing this! > > --Ned. > > I'd suggest putting the full text on the list sign up page above the > subscription form (to encourage reading before signing up) and perhaps even > in the body of an automated welcome email upon subscribing. > > The goal is to have as many new subscribers read it as possible, and that > requires making it as visible as possible. Text will be read if easily seen > and not buried "below the fold". Links are much less likely to be followed. Thanks Ned & Jonathan! I forgot to include some information in the original e-mail — I changed the python-ideas list so that new subscribers are by default under moderation. This was initially in response to the increase in spam, but also provides the opportunity to serve as a gate that lets me and other moderators respond to a first-post with “hey, have you read ? You really should!” So, in addition to being linked in to the appropriate places, I’m hoping to point to this document in a response to newcomers posting to the list. That seems like another high-conversion target location in addition to having it be on the list signup page and in a welcome message. best, —titus ___ 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/EE6PYVUIX455NE3ZD7P4XH5XTTNUHCK4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Request: pointers to exemplar threads from python-ideas?
Hi folks, I’m working on some help documentation for python-ideas and first-time contributors, and I’d like to include a few examples of discussions that were productive and led to changes. I browsed through the archives and found a few positive and negative examples (below) but didn’t find one that led to a full PEP proposal (I know they’re rare!) I’d like to crowdsource this and get some good examples from y’all, if you don’t mind. If people have any exemplar discussions in mind, could you drop them to me privately? Thanks in advance! (Threads from python-dev also welcome, but my intent is to show people new to the python-ideas list what they should expect.) best, —titus —— ** Brief thread about bad fit with Python philosophy: Specific equality method for hashable objects https://mail.python.org/archives/list/python-ideas@python.org/thread/X2FXOYZ4GMA7CGEVQRZQDKSG2QNNHBQQ/ ** Brief thread about a simple fix that could be implemented without a PEP: Add a `dir_fd` parameter to `os.truncate`? https://mail.python.org/archives/list/python-ideas@python.org/thread/RLW76DIEBUS5XGFA32223UUSFRXWQT5V/ ** Brief thread about not using undocumented Windows APIs in the stdlib: Add subprocess.Popen suspend() and resume() https://mail.python.org/archives/list/python-ideas@python.org/thread/NNNCG4IKUB4XYC7ZXLY4BCUG533MQJQY/ ** A long discussion of small changes that adjusted PEPs but did not require a new one: PEP: Dict addition and subtraction https://mail.python.org/archives/list/python-ideas@python.org/thread/KLDQAPOIJEANCKYCHQZ536WHQ45I6UVW/ ** Clarification of behavior leading to documentation fix, no PEP required: Fix documentation for __instancecheck__ https://mail.python.org/archives/list/python-ideas@python.org/thread/5BPDKWIBO3B4A7WPDGYR3YVCFQTFIBDX/ ___ 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/KUH6UQVT3LKLHTNPP6RSZZ4J2YLSM33K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a __valid_getitem_requests__ protocol
WHATS WRONG WITH TOP POSTING IN ALL CAPS AND NO PUNCTUATION!?!?!?! :) No one has complained to the moderators that CoC is being violated. and if they did, there’s a whole bunch of safeguards to ensure that it’s not being misused. I do occasionally (once or twice a year?) place specific members back on moderate temporarily so that I can intercept heated discussions before they spiral out of control, but I’ve tried to keep moderation rapid enough that I don’t think it’s intrusive. Nothing on this list is time critical, IMO, and I also note that new members are moderated _by default_. Also, if someone thinks that the CoC is being over applied (!?) or the list moderation is too heavy handed (!?) on this list, this list is also not the place to discuss it. That place would be conduct...@python.org, and I’m sure they would appreciate any concerns anyone has to convey. best, —titus > On Feb 23, 2020, at 5:38 PM, Chris Angelico wrote: > > On Mon, Feb 24, 2020 at 10:04 AM Steven D'Aprano wrote: >>> At any rate, we should be able to control what we say and how we say it, >>> adult or not. >> >> Indeed we should. And if that means we want to call a shitty piece of >> software a shitty piece of software, especially when it's our own >> software, we shouldn't need fear that somebody will tell us off for it. >> > > For the record, I think Soni's original description (implying that the > thin wrappers like iter(x) calling x.__iter__() etc are in some way > bad) was rude, but not a CoC violation or anything. It's the sort of > rude that colours someone's posts and thus other people's views of > their arguments, but shouldn't get the person banned. > > But it WAS rude, and I don't think Rhodri was wrong to call that out. > If you're going to rail on the code patterns that currently exist > (profane language is mostly irrelevant here), that really doesn't do > your arguments any favours, and it's fine IMO to call someone out for > it just as much as you'd call someone out for posting their entire > feature request in all-caps with no punctuation or line breaks. > > 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/X7ZTNCVEW7XZLQCI3LRR5HNPPYQ2YUAE/ > 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/GN6JZCH4MRS3VWZMH47XJBE4IDH5UMAY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Traits
Hi folks, moderator here. I’m calling it for this discussion. No further discussion is called for, IMO, although I’m sure Brett and I would be happy to be overridden by private request. Stephen, thank for providing an excellent summary post on which to lay this thread to rest :) :) best, --titus > On Feb 15, 2020, at 7:57 AM, Stephen J. Turnbull > wrote: > > All: If you're not interested in the back and forth, read my parallel > post with a different subject. > > Soni L. writes: > >> I'm just gonna say learn rust since you actively refuse to accept >> my explanation of rust traits. don't reply again until you've >> learned rust. > > OK, done. > >> you don't want me to be rude > > I don't actually care (cf. http://www.jwz.org/gruntle/rbarip.html), > except that we've all agreed to the Code of Conduct, and I hate to see > folks ignored, or worse, banned, for non-conformance. > >> but when I literally explain rust traits > > So far, from what you've written, they seemed to be what in Python I > would call "zope.interface interfaces." And in fact, both you and the > 3 Rust-specific sources cited below emphasize this aspect of traits. > Sadly, you did a very poor job of explaining what Rust traits are, and > their advantages over strait. Possibly because there aren't any > advantages that aren't strait implementation details. At least, I > can't find any. > >> you throw me an "that's not traits" > > No, I'm throwing you an "I don't understand what you want." I was not > going to say "they're not traits" until I understood them. I told you > what I understood them to be *from your descriptions*, which turned out > to be incomplete in rather important ways. > > Now that I understand them better, they do seem to be traits à la > Schärli et al., except that arbitrarily nested traits are allowed in > Rust, and Rust allows unimplemented methods. (This is not a > restriction in Schärli et al's version of traits: the implementation > of a trait method can simply call a method provided by the class > incorporating the trait.) > > In the TOSWidget example, as I understand it, in Rust: > > 1. In the trivial case where exactly one of TOSWidget, Pack, and >Place implements 'config', you get that implementation, and >any code that's not happy with that is incorrect. > 2. In the case TOSWidget implements 'config', and Pack or Place or >both implements it, you get TOSWidget's implementation, but >anything expecting Pack or Place behavior will not get it, and is >incorrect. > 3. If both Pack and Place implement 'config', but TOSWidget does not, >you get a compile-time error. > > I still don't understand your comment implying that the fact that > >something that expects Place behavior will get Pack behavior from >TOSWidget > > means strait is inferior to Rust's version. I don't see how Rust can > do better that that -- any code that expects Place behavior from the 6 > methods defined in TOSWidget is just plain incorrect code in Rust as > well as in strait. I guess you're implicitly appealing to Rust's UFCS > (universal function call syntax)? That's kind of unfair: it should be > easy to implement a UFCS for strait traits, although it might need a > clumsy syntax. As pointed out in Rust documentation and bug reports, > UFCS is only rarely needed, so clumsy syntax is not such a problem. > >> "and fuck you for ..." > > Not at all. I was mostly inviting you to correct my understanding by > explaining the details of Rust's implementation and pointing out where > it differs. I gather you aren't interested in trying, but I'm always > happy to help. > >> "... trying to get me to think." > > I put 2 hours into composing that post, and another 2 into this one. > If that's your definition of "refusing to think," you're wrong. > > Good luck, anyway. > > Regards, > ___ > 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/CPFW6C6MJTAVQNFUANYITVJM57LCDPNS/ > 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/GW7OSZPQMQABJ5BPLMFCKQ5CEJDGZXXC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Change List Metadata
On Tue, Jan 14, 2020 at 10:03:24PM -0600, Hunter Jones wrote: > Hey everyone, > > I recently used list.count() in a coding interview and the question arose > about how scale-able this solution was for sufficiently large input. > Currently, list.count iterates through the list, incrementing the count as > it goes and returning the value at the end. This does not lend itself well > to large inputs. > > I propose either modifying the list struct to include a map of item -> > count, or implementing a new structure with this information that is > allocated separately when a list is instantiated. > > Maybe I'm just seeing this since it's an edge case that I recently dealt > with, but I believe it would be a useful enhancement overall. > > Thoughts? Hi Hunter, does collections.Counter meet your needs? https://docs.python.org/3.8/library/collections.html#collections.Counter best, --titus -- C. Titus Brown, ctbr...@ucdavis.edu ___ 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/D4GW3BTZCMI472BTH66WPA6I4HSHALN5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Argumenting in favor of first()
Hi folks, moderator here. No need to respond. thanks, --titus On Fri, Dec 27, 2019 at 03:37:14PM -, Marco Sulla via Python-ideas wrote: > Eric Fahlgren wrote: > > You apparently did not read the posts, because the point was whether it > > raises or returns a default value, not whether it saves one line or ten. > > You apparently don't know Python: > > ``` > next(iterator) # raises an exception if no more elements > next(iterator, _sentinel) # returns _sentinel if no more elements > ``` > > So, what's the advantage of having `first()`? Furthermore, **how can you be > sure this is the __real first element__ of the iterable, if you pass an > iterator?** > > The disadvantage is that you hide the iterator, that could be useful later in > the code. > > KISSes. > ___ > 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/VJMO4HOZGFCAKY2WA2RACHITPECFDKQ7/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- C. Titus Brown, ctbr...@ucdavis.edu ___ 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/KV4K4KS4MYTP5T5W5XKZYENGHCJYWOFR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dunder methods for encoding & prettiness aware formal & informal representations
(no reason to moderate a topic that wanders off what you think is the linear
path, Rob… no one is violating CoC and that’s mostly what I care about)
> On Mar 16, 2020, at 6:11 PM, Rob Cliffe via Python-ideas
> wrote:
>
> This makes on my count 6 messages on arcane mathematical topics that have
> nothing to do with the original proposition, which was to do with
> prettyprinting.
>
> Don't get me wrong - I enjoy such discussions as much as anyone, considering
> myself a mathematician of sorts. But it must be frustrating for the OP,
> looking for some genuine feedback, to see the discussion wander off-track.
> (And time-wasting for anyone with a genuine interest in the OP's suggestion
> who, at some future time, reads through the thread.) And this is far from
> the first time I have seen this sort of thing happen.
>
> May I humbly suggest that contributors to a thread might make a little more
> effort to discipline themselves to reply to the OP rather than waxing lyrical
> on some unrelated topic? (And, very tentatively, suggest that there might
> even be a role for the Moderator here?). I intend absolutely no offence to
> anyone involved.
>
> Rob Cliffe
>
> On 16/03/2020 17:33, Andrew Barnert via Python-ideas wrote:
>> On Mar 16, 2020, at 02:54, Stephen J. Turnbull
>> wrote:
>>> Andrew Barnert writes:
>>>
Well, there are an infinite number of ever larger infinite
ordinals, ω or ω_0 being the first one, and likewise an infinite
number of infinite cardinal, aleph_0 being the first one, and
people rarely use the ∞ symbol for any of them.
>>> s/people/mathematicians/ and I'd agree with you. But I did write
>>> "people".
>> But people rarely talk about infinite ordinals or cardinals. Anyone who’s
>> talking about, e.g., whether there’s a set larger than the naturals but
>> smaller than the reals isn’t calling either one of those sets’ cardinalities
>> ∞.
>>
There are a few different obvious ways you could build an
IEEE-float-style complex out of IEEE floats, but the one that C99
and C++ both use is probably the simplest: just model then as the
Cartesian product of IEEE float with itself, applying the usual
arithmetic rules over IEEE float.
>>> FVO "simple" = "simplistic". :-)
>> What does FVO mean?
>>
>> At any rate, there’s nothing wrong with simplistic. Our usual addition on
>> natural numbers is simplistic, and there are all kinds of other
>> sort-of-addition-like things you could define on top of successor instead of
>> it that are less simplistic, but none of them are nearly as useful, natural,
>> or intuitive.
>>
And that means these odd things make sense:
>>> FVO of "sense" = "derived from an arbitrary model (as long as we're
>>> consistent)". (This time I'm not trolling.)
>> But it’s not an arbitrary model (except in the sense that every number
>> system like Z is an arbitrary model), it’s a model that falls out of the
>> natural composition of “build C from R” and “build R-bar from R and then
>> build IEEE from R-bar”, in either order. And it’s one that preserves all the
>> properties you’d hope—most importantly, continuation. The fact that 2+3=5,
>> etc., when you use complex addition instead of real addition—is the reason
>> we call complex addition “addition” in the first place. And C-bar built in
>> this way continues R-bar in the same way C continues R. And the C-style
>> approximation of C-bar with IEEE float approximately continues IEEE float in
>> the same way (albeit sadly not always with the same bounds of
>> approximation). Which is why we can call C/Python/etc. complex addition
>> “addition”: complex.__add__(complex(2.0), complex(3.0)) == 2.0+3.0 (in this
>> case exactly so, but in general you need isclose and it’s not always easy to
>> calculate the cutoff…).
>>
complex("inf")
> (inf+0j)
>
> Oof. ;-)
What else would you expect?
>>> I don't "expect" anything when there are several competing
>>> interpretations. I would *like* it to be 'complex("inf")' FVO inf =
>>> projective complex plane infinity.
>> If you’re suggesting that our reals should be projectively extended and then
>> our complexes should also be projectively extended, that would make sense.
>> But then our reals wouldn’t be modeled by IEEE floats.
>>
>
>> If you’re suggesting that our complexes should be projectively extended even
>> though our reals are affinely extended, then you’re giving up the
>> continuation property; complex is no longer an extension of real.
>>
>>> My reasoning is the available
>>> *mathematical* values we model should make sense as expressing the set
>>> of possible limits in polar coordinates as well as in Cartesian
>>> coordinates (and as the limits of arbitrary lines). But these are in
>>> some sense distinct, with a couple of exceptions.
>> But the infinite values we’re trying to model aren’t distinct between the
>> two coordinate systems.
>>
>> The finite
[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)
(Folks, sorry for letting this spam slip through! It was reasonably clever compared to most of the stuff we get :) best, —titus > On Apr 2, 2020, at 12:49 AM, gstindianews.i...@gmail.com wrote: > > ya that's what I also get for quickly whipping something up and not > testing it. Good catch from the end. I found another similar at > https://gstindianews.info. But you get the idea - a simple wrapper around > a list is going to be way better than a wrapper around StringIO. i > > jayesh > ___ > 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/3DR32EZ3DQFL67A6JGUQSP7YMIXOJC23/ > 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/3O4CQDWSHVMLFWI26T3J42BTVEJVRVYE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] MODERATOR - in re "Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments"
Hello everyone, the above referenced thread is getting heated and unfriendly; I’ve already rejected a message as inappropriately ad hominem. Please take some time to (re)consider the content of your e-mails before sending them. We may turn on default moderation if it continues. As a reminder: The code of conduct that governs this list (and all Python spaces) is here, https://www.python.org/psf/conduct/. If you want to discuss the python code of conduct and its applicability to this thread (or anything else), python-ideas is not the place to do so. You may do so privately with the moderators (python-ideas-ow...@python.org should reach us), or with the CoC working group, at conduct...@python.org. thanks, —titus ___ 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/YDE3PDS24UX352RA3MUK47IX3N2R4WNU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments
Hi all, as a moderator of python-ideas, I’ve asked postmaster to place python-ideas into emergency moderation. (I do not have the tools to do so myself.) I’m willing to review messages individually as needed. best, —titus > On Jun 29, 2020, at 9:24 AM, Abdur-Rahmaan Janhangeer > wrote: > > Threads like these are meaningless, does not provide any learning > value and is nowhere near the single vs double quote thread. > > It opens the gap for people who are not concerned about development > jump in the game shifting the focus away while nurturing a culture of thrash > I mean you tend to ignore threads from python-dev and python-ideas which > is not probably why you subscribed in the first place > > This is not the first time i am saying that you can fly around the world on > official > Python mailing lists. But it's regrettable that it's the first time i am > seeing people > telling that they should educate others and things like that. It can be based > on the > argument and circle around it but personal attacks are off limit > > If this was a Github issue, i don't think you list moderators would have > dragged it > around that much. Worst case scenario, someone would have been pinged and > the issue taken care of. A PR or closing and you are done. > > I raised the issue of closing a mail thread before and the impractical nature > of > it was discussed but maybe warnings and continued posting after the warning > results in ban can be enforced > > And it's annoying that it got dragged to two mailing lists. I respect Python > people > and i am always eager to follow some C code discussions, deprecating this C > API > etc. It's a new world for me. > > Maybe active list members should sign a convention or a vetting process can > be setup > before we can discuss it on the lists. Not ideal but might be useful. > > Kind Regards, > > Abdur-Rahmaan Janhangeer > compileralchemy | blog > github > Mauritius > > > On Mon, Jun 29, 2020 at 8:11 PM David Mertz wrote: > The commit message is simply silly. It introduces numerous contentious and > false claims that have nothing whatsoever to do with the small wording > change. It misunderstands how language, culture, history, and indeed white > supremacism, work. > > I would recommend amending the commit message. > > The underlying change itself is reasonable, and to my mind a small > improvement. There was unnecessary specificity in using Strunk and White as > reference, and not, say, William Zinsser's _On Writing Well_, which is almost > as well known. In the concrete, it would be exceedingly rare for these to > provide conflicting advice on a specific code comment. > > On Mon, Jun 29, 2020 at 7:34 AM Richard Damon > wrote: > On 6/29/20 6:22 AM, Nathaniel Smith wrote: > > and describes the > > old text as a "relic", which is another way of saying that the > > problems were only there by historical accident, rather than by anyone > > intentionally keeping it there. > > I would say that say that I have seen the term "relic" being used as a > 'weaponized' word to imply that the old thing WAS there intentionally as > a repressive measure. I am not saying that this usage was intended to be > used that way, but just as the old wording was taken as offensive to > some due to implication, I can see that message as offensive to others > due to implication, all because some people are easy to offend. > > -- > Richard Damon > ___ > Python-Dev mailing list -- python-...@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-...@python.org/message/6EN5RNF5CFDKCF3ZYQV53XH5KTBCSAQ6/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > > -- > The dead increasingly dominate and strangle both the living and the > not-yet born. Vampiric capital and undead corporate persons abuse > the lives and control the thoughts of homo faber. Ideas, once born, > become abortifacients against new conceptions. > ___ > Python-Dev mailing list -- python-...@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-...@python.org/message/AMH7WMUOOZ4KAFYPVZO2BA5AQLWTCDR6/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ > Python-Dev mailing list -- python-...@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-...@python.org/message/B426T6LT3TAFJHDNWBBAEWPTZKAFEM2K/ > Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Context manager for csv module 'reader' and 'DictReader'?
Hi all, the product of Sunday morning idle curiosity... I’ve been using the csv module a lot, and I’m wondering if there would be value in adding a standard mechanism for opening a CSV file (correctly) using a context manager? So, instead of with open(filename, newline=“”) as fp: r = csv.DictReader(fp) for row in r: … support something like with csv.DictReader.open(filename) as r: for row in r: … ? And something similar for ‘csv.reader’? I’m not wedded to the details here. The two main reasons I think this might be a positive addition are - * you wouldn’t have to know or remember the right way to open a CSV file (newline=“”). * it elides very common code. but perhaps there are things I’m missing here? As a side note, I think ‘csv.reader’ could usefully be renamed to something else (maybe just Reader?), since it’s kind of out of sync with the CamelCase used in ‘DictReader’. But maybe that’s just an attempt at foolish consistency :). best, —titus ___ 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/EKHYCTYMXZG3VI4JYFA3Y3LD3ZNMI3IX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Context manager for csv module 'reader' and 'DictReader'?
Thanks for your comments, everyone! Right, I’m struggling to figure out Greg's example :). Maybe Greg missed that DictReader.open didn’t exist and was in fact what I was asking for! (contextlib.closing is great, thank you for that!) Anyway, just to re-up the original points and add a few - * opening a CSV file with the right newline setting and then applying csv.reader and csv.DictReader is super common. * newline=“” has important ramifications for Windows functionality, as we recently discovered when we tried to extend sourmash with windows compat. * yes it’s very easy to write my own utility function to do this, and in fact I have done so …repeatedly. :) * no one is proposing to remove any functionality. * I like Chris Barker’s comment, “”” it ended with the idea that maybe there should be a PEP for a common interface for all “file” readers — eg JSON, CSV, etc.. And that interface could be supported by third party libs. That interface *maybe* would include a single step load from a path-like functionality. “”” I’m +0 on David Mertz’s suggestion, “”" Most Pandas read methods take either a path-like argument or a file-like argument, and figure out which it is by introspection when called. Actually, most of them even accept a URL-like argument as well I don't think this is a terrible approach. It doesn't make things quite as explicit as the standard library generally does. But it's convenient, and there's no real ambiguity. “”” mostly because when we’ve done this in our own packages, I've struggled to figure out the best method to figure out if something is file-like. For example, it looks like ‘csv.DictReader’ will take any iterable, which means passing in a string is problematic; perhaps we could be looking for read or readline instead? Codifying that in some standard way could be nice. best, —titus > On Sep 5, 2021, at 5:30 PM, Oscar Benjamin wrote: > > On Mon, 6 Sept 2021 at 01:13, Greg Ewing wrote: >> >> On 6/09/21 3:07 am, C. Titus Brown via Python-ideas wrote: >>> with csv.DictReader.open(filename) as r: >>>for row in r: >>> … >> >> You can do this now: >> >> from contextlib import closing >> with closing(csv.DictReader.open(filename)) as r: >>... > > What version of Python are you using? > >>>> import csv >>>> csv.DictReader.open > Traceback (most recent call last): > File "", line 1, in > AttributeError: type object 'DictReader' has no attribute 'open' > >> IMO this is preferable than going around adding context manager >> methods to everything that has open-like functionality. > > I disagree. It would be better if resource acquisition (e.g. opening a > file) always took place in an __enter__ method so that it could always > be under control of a with statement. Having closing as a separate > function negates that because there has to be a separate function that > acquires the resource before the closing function is called and hence > before __enter__ is called. > > -- > Oscar > ___ > 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/AR6IHZ2HY4TKZXKANUGA7HTPDQMBCLRC/ > 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/CNMK76RBWQKVP6F3IZIDTCPFDTFI7HV4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] PEP-671 thread - let's take a break, please.
Hi all, the PEP-671 thread is starting to accumulate an awful lot of heat. I’ve placed the list into emergency moderation for the day to give everyone a chance to take a step back and (re)consider their next e-mails. Thank you! best, —titus (list moderator) ___ 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/PPZIULPIVZNI7YYCTRHWT5UKU7VB6LGZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] 'frozen set' discussion - please consider taking some time off.
Hi all, python-ideas moderator here. It’d be great if y’all could take a few days to cool off the frozen set discussion, which is veering off the rails a little bit into emotional language. I’ll keep an eye on it and put emergency moderation into effect if I must, but it’d be nicer if I didn’t feel the need to do that. thanks, —titus ___ 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/W5MS2FTUMSKYIFXDPPYJPIS3CFW43JYP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Idea: Tagged strings in python
> On Dec 17, 2022, at 10:08 AM, e...@emilstenstrom.se wrote: > > Bruce Leban wrote: >>> Try googling "python-ideas string prefixes". Doing mimimal diligence is a >>> reasonable expectation before writing up an idea. > > Thanks for the query "string prefixes". I tried other queries but not that > one. I ended my first message with "I hope I didn't break any unspoken rules" > and it seems I have. My two cents (speaking as long-term observer, not as the moderator, or perhaps in addition to the moderator ;) - I think your ask was appropriate, and I think the response of “here’s the search you should do!” was great. Personally I think we could do without the implication that you should have done more due diligence. python-ideas is PRECISELY for this kind of question. Other forums should have a higher barrier to entry (like python-dev), but not python-ideas. best, —titus ___ 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/HOY4DYOSV5723735LI3BOJY7UUKD6NGK/ Code of Conduct: http://python.org/psf/codeofconduct/
