Anyone else gotten bizarre personal replies to mailing list posts?
I just got the reply below sent directly to my personal account, and I'm confused about what's going on. If it's just a one off I'll chalk it up to random internet weirdness, but if other folks are getting these too it might be something the list admins should look into? Or... something? ---------- Forwarded message --------- From: Hoi lam Poon <gillcovid19@gmail.com> Date: Fri, Apr 23, 2021, 02:01 Subject: Re: [Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST] To: Nathaniel Smith <njs@pobox.com> Stop pretending, I can definitely get the key control file, your working group, all past actions and instructions cannot be cleared in front of me at all. You have been playing around for a few days, and I won’t stop you. Your face? I won’t, you know, you can’t drive me away, and that file is all, after I get it, you will be convicted even if you disband, I swear 在 2021年4月23日 週五 16:23，Nathaniel Smith <njs@pobox.com> 寫道：
On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum <guido@python.org> wrote:
On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith <njs@pobox.com> wrote:
Sure. This was in my list of reasons why the backwards compatibility tradeoffs are forcing us into awkward compromises. I only elaborated on it b/c in your last email you said you didn't understand why this was a problem :-). And except* is definitely useful. But I think there are options for 'except' that haven't been considered fully.
Do you have any suggestions, or are you just telling us to think harder? Because we've already thought as hard as we could and within all the constraints (backwards compatibility and otherwise) we just couldn't think of a better one.
The main possibility that I don't think we've examined fully is to make 'except' blocks fire multiple times when there are multiple exceptions. We ruled it out early b/c it's incompatible with nested EGs, but if flat EGs are better anyway, then the balance shifts around and it might land somewhere different. it's a tricky discussion though, b/c both the current proposal and the alternative have very complex implications and downsides. So we probably shouldn't get too distracted by that until after the flat vs nested discussion has settled down more.
I'm not trying to filibuster here -- I really want some form of EGs to land. I think python has the potential to be the most elegant and accessible language around for writing concurrent programs, and EGs are a key part of that. I don't want to fight about anything; I just want to work together to make sure we have a full picture of our options, so we can be confident we're making the best choice.
The real cost here is that we would need a new "TracebackGroup" concept, since the internal data structures and APIs keep the traceback chain and the exception object separated until the exception is caught. In our early design stages we actually explored this and the complexity of the data structures was painful. We eventually realized that we didn't need this concept at all, and the result is much clearer, despite what you seem to think.
I'm not talking about TracebackGroups (at least, I think I'm not?). I think it can be done with exactly our current data structures, nothing new.
- When an EG is raised, build the traceback for just that EG while it's unwinding. This means if any C code peeks at exc_info while it's in flight, it'll only see the current branch of the traceback tree, but that seems fine. - When the exception is caught and we go to write back the traceback to its __traceback__ attribute, instead "peek through" the EG and append the built-up traceback entries onto each of the constituent exceptions.
You could get cleverer for efficiency, but that basic concept seems pretty simple and viable to me. What am I missing?
-n
-- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VOBOWZGW... Code of Conduct: http://python.org/psf/codeofconduct/
I got a few of these too. I'm not sure anything can be done about it, since the mailing list is publicly archived, so anyone could send emails to anyone who posts here. El vie, 23 abr 2021 a las 8:42, Nathaniel Smith (<njs@pobox.com>) escribió:
I just got the reply below sent directly to my personal account, and I'm confused about what's going on. If it's just a one off I'll chalk it up to random internet weirdness, but if other folks are getting these too it might be something the list admins should look into? Or... something?
---------- Forwarded message --------- From: Hoi lam Poon <gillcovid19@gmail.com> Date: Fri, Apr 23, 2021, 02:01 Subject: Re: [Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST] To: Nathaniel Smith <njs@pobox.com>
Stop pretending, I can definitely get the key control file, your working group, all past actions and instructions cannot be cleared in front of me at all. You have been playing around for a few days, and I won’t stop you. Your face? I won’t, you know, you can’t drive me away, and that file is all, after I get it, you will be convicted even if you disband, I swear
在 2021年4月23日 週五 16:23，Nathaniel Smith <njs@pobox.com> 寫道：
On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith <njs@pobox.com> wrote:
Sure. This was in my list of reasons why the backwards compatibility tradeoffs are forcing us into awkward compromises. I only elaborated on it b/c in your last email you said you didn't understand why this was a problem :-). And except* is definitely useful. But I think there are options for 'except' that haven't been considered fully.
Do you have any suggestions, or are you just telling us to think harder? Because we've already thought as hard as we could and within all
On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum <guido@python.org> wrote: the constraints (backwards compatibility and otherwise) we just couldn't think of a better one.
The main possibility that I don't think we've examined fully is to make 'except' blocks fire multiple times when there are multiple exceptions. We ruled it out early b/c it's incompatible with nested EGs, but if flat EGs are better anyway, then the balance shifts around and it might land somewhere different. it's a tricky discussion though, b/c both the current proposal and the alternative have very complex implications and downsides. So we probably shouldn't get too distracted by that until after the flat vs nested discussion has settled down more.
I'm not trying to filibuster here -- I really want some form of EGs to land. I think python has the potential to be the most elegant and accessible language around for writing concurrent programs, and EGs are a key part of that. I don't want to fight about anything; I just want to work together to make sure we have a full picture of our options, so we can be confident we're making the best choice.
The real cost here is that we would need a new "TracebackGroup" concept, since the internal data structures and APIs keep the traceback chain and the exception object separated until the exception is caught. In our early design stages we actually explored this and the complexity of the data structures was painful. We eventually realized that we didn't need this concept at all, and the result is much clearer, despite what you seem to think.
I'm not talking about TracebackGroups (at least, I think I'm not?). I think it can be done with exactly our current data structures, nothing new.
- When an EG is raised, build the traceback for just that EG while it's unwinding. This means if any C code peeks at exc_info while it's in flight, it'll only see the current branch of the traceback tree, but that seems fine. - When the exception is caught and we go to write back the traceback to its __traceback__ attribute, instead "peek through" the EG and append the built-up traceback entries onto each of the constituent exceptions.
You could get cleverer for efficiency, but that basic concept seems pretty simple and viable to me. What am I missing?
-n
-- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VOBOWZGW... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4BAOL763... Code of Conduct: http://python.org/psf/codeofconduct/
I had I and still don't know what's going on. Mine was in a response to a release announcement so it was extra weird. Here is what I received: I have now formally filed a final lawsuit against the manager of the python
program company, because all of him is also a criminal act, and GNU has EU legal certification, only my key can log in, and the key must be recycled after the death of the holder, and gitlab allows to change It’s the most basic and important crime to log in by people who support the snatching of the key. I have to explain to you that the key is to be registered and authenticated. My girlfriend wants to authenticate me with this key, and my information is also there. The key is authenticated, so I will not log in now, and I have submitted a lawsuit against him and the authority of the key holder to the U.S. Supreme Court and the European Union. I will not log in until there is a judgment or the U.S. Supreme Court allows me. People will be litigated, and the information that has been changed online will be found out, and I have library files, I have all the original materials, please cooperate with me, my key is called the Boss key, all websites of the program, companies, Institutions, banks, third-party platforms, and only my keys can have them, including patents and copyrights.
On Fri, 23 Apr 2021 at 16:44, Nathaniel Smith <njs@pobox.com> wrote:
I just got the reply below sent directly to my personal account, and I'm confused about what's going on. If it's just a one off I'll chalk it up to random internet weirdness, but if other folks are getting these too it might be something the list admins should look into? Or... something?
---------- Forwarded message --------- From: Hoi lam Poon <gillcovid19@gmail.com> Date: Fri, Apr 23, 2021, 02:01 Subject: Re: [Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST] To: Nathaniel Smith <njs@pobox.com>
Stop pretending, I can definitely get the key control file, your working group, all past actions and instructions cannot be cleared in front of me at all. You have been playing around for a few days, and I won’t stop you. Your face? I won’t, you know, you can’t drive me away, and that file is all, after I get it, you will be convicted even if you disband, I swear
在 2021年4月23日 週五 16:23，Nathaniel Smith <njs@pobox.com> 寫道：
On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith <njs@pobox.com> wrote:
Sure. This was in my list of reasons why the backwards compatibility tradeoffs are forcing us into awkward compromises. I only elaborated on it b/c in your last email you said you didn't understand why this was a problem :-). And except* is definitely useful. But I think there are options for 'except' that haven't been considered fully.
Do you have any suggestions, or are you just telling us to think harder? Because we've already thought as hard as we could and within all
On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum <guido@python.org> wrote: the constraints (backwards compatibility and otherwise) we just couldn't think of a better one.
The main possibility that I don't think we've examined fully is to make 'except' blocks fire multiple times when there are multiple exceptions. We ruled it out early b/c it's incompatible with nested EGs, but if flat EGs are better anyway, then the balance shifts around and it might land somewhere different. it's a tricky discussion though, b/c both the current proposal and the alternative have very complex implications and downsides. So we probably shouldn't get too distracted by that until after the flat vs nested discussion has settled down more.
I'm not trying to filibuster here -- I really want some form of EGs to land. I think python has the potential to be the most elegant and accessible language around for writing concurrent programs, and EGs are a key part of that. I don't want to fight about anything; I just want to work together to make sure we have a full picture of our options, so we can be confident we're making the best choice.
The real cost here is that we would need a new "TracebackGroup" concept, since the internal data structures and APIs keep the traceback chain and the exception object separated until the exception is caught. In our early design stages we actually explored this and the complexity of the data structures was painful. We eventually realized that we didn't need this concept at all, and the result is much clearer, despite what you seem to think.
I'm not talking about TracebackGroups (at least, I think I'm not?). I think it can be done with exactly our current data structures, nothing new.
- When an EG is raised, build the traceback for just that EG while it's unwinding. This means if any C code peeks at exc_info while it's in flight, it'll only see the current branch of the traceback tree, but that seems fine. - When the exception is caught and we go to write back the traceback to its __traceback__ attribute, instead "peek through" the EG and append the built-up traceback entries onto each of the constituent exceptions.
You could get cleverer for efficiency, but that basic concept seems pretty simple and viable to me. What am I missing?
-n
-- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VOBOWZGW... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4BAOL763... Code of Conduct: http://python.org/psf/codeofconduct/
Perhaps an unconventional artistic performance ;-) But more probably some kind of loony with a lot of free time... On Fri, 23 Apr 2021 16:49:15 +0100 Pablo Galindo Salgado <pablogsal@gmail.com> wrote:
I had I and still don't know what's going on. Mine was in a response to a release announcement so it was extra weird. Here is what I received:
I have now formally filed a final lawsuit against the manager of the python
program company, because all of him is also a criminal act, and GNU has EU legal certification, only my key can log in, and the key must be recycled after the death of the holder, and gitlab allows to change It’s the most basic and important crime to log in by people who support the snatching of the key. I have to explain to you that the key is to be registered and authenticated. My girlfriend wants to authenticate me with this key, and my information is also there. The key is authenticated, so I will not log in now, and I have submitted a lawsuit against him and the authority of the key holder to the U.S. Supreme Court and the European Union. I will not log in until there is a judgment or the U.S. Supreme Court allows me. People will be litigated, and the information that has been changed online will be found out, and I have library files, I have all the original materials, please cooperate with me, my key is called the Boss key, all websites of the program, companies, Institutions, banks, third-party platforms, and only my keys can have them, including patents and copyrights.
On Fri, 23 Apr 2021 at 16:44, Nathaniel Smith <njs@pobox.com> wrote:
I just got the reply below sent directly to my personal account, and I'm confused about what's going on. If it's just a one off I'll chalk it up to random internet weirdness, but if other folks are getting these too it might be something the list admins should look into? Or... something?
---------- Forwarded message --------- From: Hoi lam Poon <gillcovid19@gmail.com> Date: Fri, Apr 23, 2021, 02:01 Subject: Re: [Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST] To: Nathaniel Smith <njs@pobox.com>
Stop pretending, I can definitely get the key control file, your working group, all past actions and instructions cannot be cleared in front of me at all. You have been playing around for a few days, and I won’t stop you. Your face? I won’t, you know, you can’t drive me away, and that file is all, after I get it, you will be convicted even if you disband, I swear
在 2021年4月23日 週五 16:23，Nathaniel Smith <njs@pobox.com> 寫道：
On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith <njs@pobox.com> wrote:
Sure. This was in my list of reasons why the backwards compatibility tradeoffs are forcing us into awkward compromises. I only elaborated on it b/c in your last email you said you didn't understand why this was a problem :-). And except* is definitely useful. But I think there are options for 'except' that haven't been considered fully.
Do you have any suggestions, or are you just telling us to think harder? Because we've already thought as hard as we could and within all
On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum <guido@python.org> wrote: the constraints (backwards compatibility and otherwise) we just couldn't think of a better one.
The main possibility that I don't think we've examined fully is to make 'except' blocks fire multiple times when there are multiple exceptions. We ruled it out early b/c it's incompatible with nested EGs, but if flat EGs are better anyway, then the balance shifts around and it might land somewhere different. it's a tricky discussion though, b/c both the current proposal and the alternative have very complex implications and downsides. So we probably shouldn't get too distracted by that until after the flat vs nested discussion has settled down more.
I'm not trying to filibuster here -- I really want some form of EGs to land. I think python has the potential to be the most elegant and accessible language around for writing concurrent programs, and EGs are a key part of that. I don't want to fight about anything; I just want to work together to make sure we have a full picture of our options, so we can be confident we're making the best choice.
The real cost here is that we would need a new "TracebackGroup" concept, since the internal data structures and APIs keep the traceback chain and the exception object separated until the exception is caught. In our early design stages we actually explored this and the complexity of the data structures was painful. We eventually realized that we didn't need this concept at all, and the result is much clearer, despite what you seem to think.
I'm not talking about TracebackGroups (at least, I think I'm not?). I think it can be done with exactly our current data structures, nothing new.
- When an EG is raised, build the traceback for just that EG while it's unwinding. This means if any C code peeks at exc_info while it's in flight, it'll only see the current branch of the traceback tree, but that seems fine. - When the exception is caught and we go to write back the traceback to its __traceback__ attribute, instead "peek through" the EG and append the built-up traceback entries onto each of the constituent exceptions.
You could get cleverer for efficiency, but that basic concept seems pretty simple and viable to me. What am I missing?
-n
-- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VOBOWZGW... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4BAOL763... Code of Conduct: http://python.org/psf/codeofconduct/
This reads like a much worse variation on GPT-3. On Fri, Apr 23, 2021, 11:52 AM Pablo Galindo Salgado <pablogsal@gmail.com> wrote:
I had I and still don't know what's going on. Mine was in a response to a release announcement so it was extra weird. Here is what I received:
I have now formally filed a final lawsuit against the manager of the
python program company, because all of him is also a criminal act, and GNU has EU legal certification, only my key can log in, and the key must be recycled after the death of the holder, and gitlab allows to change It’s the most basic and important crime to log in by people who support the snatching of the key. I have to explain to you that the key is to be registered and authenticated. My girlfriend wants to authenticate me with this key, and my information is also there. The key is authenticated, so I will not log in now, and I have submitted a lawsuit against him and the authority of the key holder to the U.S. Supreme Court and the European Union. I will not log in until there is a judgment or the U.S. Supreme Court allows me. People will be litigated, and the information that has been changed online will be found out, and I have library files, I have all the original materials, please cooperate with me, my key is called the Boss key, all websites of the program, companies, Institutions, banks, third-party platforms, and only my keys can have them, including patents and copyrights.
On Fri, 23 Apr 2021 at 16:44, Nathaniel Smith <njs@pobox.com> wrote:
I just got the reply below sent directly to my personal account, and I'm confused about what's going on. If it's just a one off I'll chalk it up to random internet weirdness, but if other folks are getting these too it might be something the list admins should look into? Or... something?
---------- Forwarded message --------- From: Hoi lam Poon <gillcovid19@gmail.com> Date: Fri, Apr 23, 2021, 02:01 Subject: Re: [Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST] To: Nathaniel Smith <njs@pobox.com>
Stop pretending, I can definitely get the key control file, your working group, all past actions and instructions cannot be cleared in front of me at all. You have been playing around for a few days, and I won’t stop you. Your face? I won’t, you know, you can’t drive me away, and that file is all, after I get it, you will be convicted even if you disband, I swear
在 2021年4月23日 週五 16:23，Nathaniel Smith <njs@pobox.com> 寫道：
On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith <njs@pobox.com> wrote:
Sure. This was in my list of reasons why the backwards compatibility tradeoffs are forcing us into awkward compromises. I only elaborated on it b/c in your last email you said you didn't understand why this was a problem :-). And except* is definitely useful. But I think there are options for 'except' that haven't been considered fully.
Do you have any suggestions, or are you just telling us to think harder? Because we've already thought as hard as we could and within all
On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum <guido@python.org> wrote: the constraints (backwards compatibility and otherwise) we just couldn't think of a better one.
The main possibility that I don't think we've examined fully is to make 'except' blocks fire multiple times when there are multiple exceptions. We ruled it out early b/c it's incompatible with nested EGs, but if flat EGs are better anyway, then the balance shifts around and it might land somewhere different. it's a tricky discussion though, b/c both the current proposal and the alternative have very complex implications and downsides. So we probably shouldn't get too distracted by that until after the flat vs nested discussion has settled down more.
I'm not trying to filibuster here -- I really want some form of EGs to land. I think python has the potential to be the most elegant and accessible language around for writing concurrent programs, and EGs are a key part of that. I don't want to fight about anything; I just want to work together to make sure we have a full picture of our options, so we can be confident we're making the best choice.
The real cost here is that we would need a new "TracebackGroup" concept, since the internal data structures and APIs keep the traceback chain and the exception object separated until the exception is caught. In our early design stages we actually explored this and the complexity of the data structures was painful. We eventually realized that we didn't need this concept at all, and the result is much clearer, despite what you seem to think.
I'm not talking about TracebackGroups (at least, I think I'm not?). I think it can be done with exactly our current data structures, nothing new.
- When an EG is raised, build the traceback for just that EG while it's unwinding. This means if any C code peeks at exc_info while it's in flight, it'll only see the current branch of the traceback tree, but that seems fine. - When the exception is caught and we go to write back the traceback to its __traceback__ attribute, instead "peek through" the EG and append the built-up traceback entries onto each of the constituent exceptions.
You could get cleverer for efficiency, but that basic concept seems pretty simple and viable to me. What am I missing?
-n
-- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VOBOWZGW... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4BAOL763... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5YN6BO4B... Code of Conduct: http://python.org/psf/codeofconduct/
Am 23.04.21 um 17:38 schrieb Nathaniel Smith:
I just got the reply below sent directly to my personal account, and I'm confused about what's going on. If it's just a one off I'll chalk it up to random internet weirdness, but if other folks are getting these too it might be something the list admins should look into? Or... something?
I also got one of these from the same sender, Same rambling, incoherent style, which I have always connected to mental issues. To protect both the sender and other list members, I would suggest to the list owners to manually unsubscribe the sender from the mailing list. - Sebastian
Yes, I got one from the same address today. Thanks for pointing out these are individual peformances: it was annoying when I thought it was spam to the list. Although Hoi Lam Poon is a real (female) name, it may signify a generated lampoon. Jeff Allen On 23/04/2021 16:38, Nathaniel Smith wrote:
I just got the reply below sent directly to my personal account, and I'm confused about what's going on. If it's just a one off I'll chalk it up to random internet weirdness, but if other folks are getting these too it might be something the list admins should look into? Or... something?
---------- Forwarded message --------- From: *Hoi lam Poon* <gillcovid19@gmail.com <mailto:gillcovid19@gmail.com>>
I just got one now from the same person on the dependabot thread. Entirely in Chinese except for "GNU license" in the middle, along with an attached jpeg of a random SciPy-related tweet (according to Gmail's preview thumbnail; I didn't actually open the attachment for obvious reasons). On Sun, May 2, 2021, 5:08 AM Jeff Allen <ja.py@farowl.co.uk> wrote:
Yes, I got one from the same address today. Thanks for pointing out these are individual peformances: it was annoying when I thought it was spam to the list.
Although Hoi Lam Poon is a real (female) name, it may signify a generated lampoon.
Jeff Allen
On 23/04/2021 16:38, Nathaniel Smith wrote:
I just got the reply below sent directly to my personal account, and I'm confused about what's going on. If it's just a one off I'll chalk it up to random internet weirdness, but if other folks are getting these too it might be something the list admins should look into? Or... something?
---------- Forwarded message --------- From: Hoi lam Poon <gillcovid19@gmail.com>
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3EA53I3Y... Code of Conduct: http://python.org/psf/codeofconduct/
FYI, I just force-unsubscribed this member (Hoi Lam Poon) from python-dev. Normally I don't do things like that, since, e.g, we have no way to know whether the sender address was spoofed in emails we get. But in this case Hoi's name has come up several times as the sender of individual spam, and if Hoi is actually a legit member they should have noticed and spoken up. Of course this can't stop them from spamming. Just intended to increase the effort for them, if they're determined to continue. [nothing new below[ On Tue, May 4, 2021 at 11:34 AM Jonathan Goble <jcgoble3@gmail.com> wrote:
I just got one now from the same person on the dependabot thread. Entirely in Chinese except for "GNU license" in the middle, along with an attached jpeg of a random SciPy-related tweet (according to Gmail's preview thumbnail; I didn't actually open the attachment for obvious reasons).
On Sun, May 2, 2021, 5:08 AM Jeff Allen <ja.py@farowl.co.uk> wrote:
Yes, I got one from the same address today. Thanks for pointing out these are individual peformances: it was annoying when I thought it was spam to the list.
Although Hoi Lam Poon is a real (female) name, it may signify a generated lampoon.
Jeff Allen
On 23/04/2021 16:38, Nathaniel Smith wrote:
I just got the reply below sent directly to my personal account, and I'm confused about what's going on. If it's just a one off I'll chalk it up to random internet weirdness, but if other folks are getting these too it might be something the list admins should look into? Or... something?
---------- Forwarded message --------- From: Hoi lam Poon <gillcovid19@gmail.com>
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3EA53I3Y... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JNYRFZ4F... Code of Conduct: http://python.org/psf/codeofconduct/
Thanks Tim. On Tue, May 4, 2021, 11:13 AM Tim Peters <tim.peters@gmail.com> wrote:
FYI, I just force-unsubscribed this member (Hoi Lam Poon) from python-dev. Normally I don't do things like that, since, e.g, we have no way to know whether the sender address was spoofed in emails we get. But in this case Hoi's name has come up several times as the sender of individual spam, and if Hoi is actually a legit member they should have noticed and spoken up.
Of course this can't stop them from spamming. Just intended to increase the effort for them, if they're determined to continue.
[nothing new below[
On Tue, May 4, 2021 at 11:34 AM Jonathan Goble <jcgoble3@gmail.com> wrote:
I just got one now from the same person on the dependabot thread.
Entirely in Chinese except for "GNU license" in the middle, along with an attached jpeg of a random SciPy-related tweet (according to Gmail's preview thumbnail; I didn't actually open the attachment for obvious reasons).
On Sun, May 2, 2021, 5:08 AM Jeff Allen <ja.py@farowl.co.uk> wrote:
Yes, I got one from the same address today. Thanks for pointing out
these are individual peformances: it was annoying when I thought it was spam to the list.
Although Hoi Lam Poon is a real (female) name, it may signify a
generated lampoon.
Jeff Allen
On 23/04/2021 16:38, Nathaniel Smith wrote:
I just got the reply below sent directly to my personal account, and
I'm confused about what's going on. If it's just a one off I'll chalk it up to random internet weirdness, but if other folks are getting these too it might be something the list admins should look into? Or... something?
---------- Forwarded message --------- From: Hoi lam Poon <gillcovid19@gmail.com>
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/3EA53I3Y...
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JNYRFZ4F... Code of Conduct: http://python.org/psf/codeofconduct/
Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LFULZM6G... Code of Conduct: http://python.org/psf/codeofconduct/
participants (10)
-
Antoine Pitrou -
Carol Willing -
David Mertz -
Jeff Allen -
Jelle Zijlstra -
Jonathan Goble -
Nathaniel Smith -
Pablo Galindo Salgado -
Sebastian Rittau -
Tim Peters