[issue32177] spammers mine emails from bugs.python.org

[Jörn Hees]

Jörn Hees <nrej9...@joernhees.de> added the comment:

oh, how convenient... as a logged in user i can just see every other user's 
email... but there's more, I can just go to 
https://bugs.python.org/user?@startwith=0&@pagesize=3&@sort=username and 
see all "obfuscated" emails. A low hanging fruits approach very likely will 
return most of the real emails:
'.'.join(s.split()[:-1]) + '@' + s.split()[-1] + '.com'

Let me provide you with a preliminary free analysis of the 50 most frequent 
email domains of all 21803 users on bugs.python.org:

10554, "gmail"
3663, "sourceforge"
411, "yahoo"
179, "googlemail"
176, "co"  # low hanging fruits as i said
167, "gmx"
98, "hotmail"
92, "com"  # low hanging fruits as i said
81, "google"
69, "163"
62, "redhat"
57, "mail"
51, "ac"
51, "me"
50, "web"
43, "free"
41, "mit"
41, "qq"
40, "org"
33, "iki"
30, "yandex"
28, "python"
25, "comcast"
25, "edu"
25, "pobox"
23, "id"
22, "ibm"
21, "acm"
21, "fastmail"
20, "live"
19, "mac"
18, "mailinator"
18, "net"
17, "126"
17, "gentoo"
17, "seznam"
16, "protonmail"
15, "aol"
15, "intel"
14, "debian"
13, "canonical"
13, "email"
13, "laposte"
12, "inbox"
12, "ubuntu"
12, "verizon"
12, "xs4all"
11, "icloud"
11, "ieee"
11, "posteo"

Please make this a bit harder!

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32177>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32177] spammers mine emails from bugs.python.org

[Jörn Hees]

New submission from Jörn Hees <nrej9...@joernhees.de>:

On every platform that i create an account on, i use a new randomized email 
address. This allows me to track which platforms sell my account info to 
spammers.

The one i used for bugs.python.org now receives astonishing amounts of spam 
(mostly bitcoin spam atm).

I hope you don't sell the account information of your contributors to third 
parties, but instead believe in a design flaw of your bug tracking system and 
some way that spammers can currently harvest the email addresses of all of your 
contributors.

Please investigate how this is possible and ways to protect your user's data.

--
components: email
messages: 307280
nosy: barry, joern, r.david.murray
priority: normal
severity: normal
status: open
title: spammers mine emails from bugs.python.org
type: security

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32177>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32027] argparse allow_abbrev option also controls short flag combinations

[Jörn Hees]

Change by Jörn Hees <nrej9...@joernhees.de>:


--
keywords: +patch
pull_requests: +4344
stage:  -> patch review

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32027>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32027] argparse allow_abbrev option also controls short flag combinations

[Jörn Hees]

New submission from Jörn Hees <nrej9...@joernhees.de>:

The allow_abbrev option (default True) currently is documented like this 
(https://docs.python.org/3/library/argparse.html#allow-abbrev):
> Normally, when you pass an argument list to the parse_args() method of an 
> ArgumentParser, it recognizes abbreviations of long options.

However, it also controls combinations of short options and especially the 
combination of flags (store_const) like `-a -b` as `-ab`.

Example snippet for testing:

import argparse
import sys

parser = argparse.ArgumentParser(
allow_abbrev=False
)
parser.add_argument('-a', action='store_true')
parser.add_argument('-b', action='store_true')
parser.add_argument('x', nargs='*')
parser.parse_args('-a -b foo bar'.split())
parser.parse_args('-ab foo bar'.split())


As you can see the 2nd parse will fail if allow_abbrev=False.

This issue is either a doc issue only or an unintended combination of long 
option shortening and (the way more common) flag combinations. When i 
deactivated this in my code, i wanted to disable the (nice to have) long option 
shortening, but i unintentionally also deactivated (MUST have) short flag 
combinations.

--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 306229
nosy: docs@python, joern
priority: normal
severity: normal
status: open
title: argparse allow_abbrev option also controls short flag combinations
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32027>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12910] urrlib.quote quotes too many chars, e.g., '()'

[Jörn Hees]

Changes by Jörn Hees <nrej9...@joernhees.de>:


--
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12910>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12910] urrlib.quote quotes too many chars, e.g., '()'

[Jörn Hees]

Jörn Hees added the comment:

It's been a while... nowadays I would mostly change the documentation of the 
quote function to point out that it is likely to quote more characters than 
absolutely necessary by SPEC. The function is in place for so long, (even in 
py3) that people will rely on the behavior.

I made an attempt to update the docstring accordingly in 
https://github.com/python/cpython/pull/2568


What i think is most confusing is the current docs mentioning the reserved 
chars (which are btw. definitely wrong wrt. RFC3986). Actually as one can see 
in the code the reserved chars don't play any role for quote, but much more the 
unreserved chars (called _ALWAYS_SAFE 
https://github.com/python/cpython/blob/master/Lib/urllib/parse.py#L716 ).

   unreserved= ALPHA / DIGIT / "-" / "." / "_" / "~"

The current quote function's approach is to simply quote everything that is not 
in unreserved + safe (per arg).

In that aspect it is quite close to the old javascript.escape function: 
https://www.w3schools.com/jsref/jsref_escape.asp


quick links
py2.7: https://github.com/python/cpython/blob/2.7/Lib/urllib.py#L1261
py3: https://github.com/python/cpython/blob/master/Lib/urllib/parse.py#L745
RFC3986: https://tools.ietf.org/html/rfc3986#appendix-A

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12910>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12910] urrlib.quote quotes too many chars, e.g., '()'

[Jörn Hees]

Changes by Jörn Hees <nrej9...@joernhees.de>:


--
pull_requests: +2638

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12910>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23509] Speed up Counter operators

[Jörn Hees]

Jörn Hees added the comment:

 I'm closing this because the OP's original concern about wanting an in-place 
 operation was already solved

Was it? Are you referring to http://bugs.python.org/issue13121 ?

My main concern was that += is considerably slower than .update(), kind of 
catching me off-guard. As you closed this, i'd be very happy if you could maybe 
add a note to the docs 
https://docs.python.org/3/_sources/library/collections.txt that points this 
behavior out. Maybe by changing this:

* The multiset methods are designed only for use cases with positive values.
  The inputs may be negative or zero, but only outputs with positive values
  are created.  There are no type restrictions, but the value type needs to
  support addition, subtraction, and comparison.

* The :meth:`elements` method requires integer counts.  It ignores zero and
  negative counts.


to this:

* The multiset methods (``+``, ``-`` and ``+=``, ``-=``) are designed only
  for use cases with positive values.
  The inputs may be negative or zero, but only outputs with positive values
  are created.  There are no type restrictions, but the value type needs to
  support addition, subtraction, and comparison.

* Because of the necessary additional checks for positive values, a ``c += 
d``
  can be considerably slower than a ``c.update(d)``.

* The :meth:`elements` method requires integer counts.  It ignores zero and
  negative counts.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23509
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23509] Speed up Counter operators

[Jörn Hees]

Jörn Hees added the comment:

cool

minor question:
- in the given patch __add__ uses __iadd__, but __sub__ doesn't use __isub__, 
which seems a bit weird.

maybe off-topic, but maybe not, because of _keep_positive(self):
- is there place for a non multi-set centric Stats object which is like 
Counter but with + and - actually behaving without the (in my use cases of 
Counter often counter intuitive)  0 stuff? (pun intended ;) ) Counter feels 
like a sub-class of Stats with the added _keep_positive(self).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23509
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13887] defaultdict.get does not default to initial default but None

[Jörn Hees]

New submission from Jörn Hees nrej9...@joernhees.de:

I wanted to create a function registrar d using a defaultdict. The library 
that this registrar is passed to expects it to return functions taking 3 args. 
Now if the first call is d.get(x) it seems that in contrast to d[x] the default 
arg of get is returned (None) instead of the defaultdicts default. If i call 
d[x] first and then d.get(x) i get what i expected.

Example:

In [1]: def foo(a,b,c):
   ...: return (a,b,c)
   ...: 

In [2]: from collections import defaultdict

In [3]: d = defaultdict(lambda:foo)

In [4]: d.get(1)

In [5]: d[1]
Out[5]: function foo at 0x1015a2ed8

In [6]: d.get(1)
Out[6]: function foo at 0x1015a2ed8

In [7]: d.get(2)(1,2,3)
---
TypeError Traceback (most recent call last)

/Users/joern/ipython console in module()

TypeError: 'NoneType' object is not callable

In [8]: d[2](1,2,3)
Out[8]: (1, 2, 3)

In [9]: d.get(2)(1,2,3)
Out[9]: (1, 2, 3)


I'm not sure this is the desired behavior, but it wasn't quite what i expected 
from a dictionary with a default.
If it is the desired behavior the documentation of defaultdict should include 
an explanation what happens.

--
components: Extension Modules, Library (Lib)
messages: 152083
nosy: joern
priority: normal
severity: normal
status: open
title: defaultdict.get does not default to initial default but None
type: behavior
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13887
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12910] urrlib.quote quotes too many chars, e.g., '()'

[Jörn Hees]

New submission from Jörn Hees nrej9...@joernhees.de:

urllib.quote('()')
returns '%28%29'

Looking into its code it tries to follow RFC 2396 (which is good even though it 
should follow rfc3986 nowadays), but it doesn't:

http://tools.ietf.org/html/rfc2396 (see Appendix A, p.27): ( and ) are in 
mark and therefore unreserved, so why are they quoted?

--
components: Library (Lib)
messages: 143592
nosy: joern
priority: normal
severity: normal
status: open
title: urrlib.quote quotes too many chars, e.g., '()'
type: behavior
versions: Python 2.6, Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12910
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com