Hello, I would like to propose adding literal syntax to allow creation of an empty set without the need to call the type constructor. I believe the best choice for such a literal, and one that has been proposed before, is `{,}`. I know this idea has surfaced a few times before, but I cannot find any serious consideration since the 3K ideas chain with the closest to a pronouncement here https://mail.python.org/pipermail/python-3000/2006-May/001599.html. In that thread the idea of a new syntax for the empty set did not seem to be rejected outright, but more that the idea of set literals at all was still in question and as empty sets were not implemented for 2.7 they were ultimately still left out of 3k, intentionally or unintentionally. Within cpython itself `set()` is used just over 200 times to assign a variable the value of an empty set. As a comparison `dict()` is used only 15 times, and all but one of those are within the test module, mostly for testing dict. On the other hand, `{}` is used for assignment a little over 1300 times; I think there is a clear preference for using literal over type construction when possible. I have a working implementation of this new syntax at https://github.com/ucodery/cpython/tree/empty-set which includes a few changes. Python from this branch allows `{,} == set()` but also `[,] == list()` and `(,) == tuple`. Partly this was because the grammar changes were easier to do all three but also because I personally liked keeping some symmetry between these collection literals. The main point of starting this thread is to gather opinions on adding `{,}` to the language, but I would like to discuss the other two as well. As a secondary point, I do think that this new tuple syntax would make teaching python easier. Those new to python often believe that parentheses are what make a tuple and only later, if ever, realize that it is only value(s) followed by a comma that construct a tuple and that parentheses are places around it mainly for readability. This misunderstanding often leads to a bug like `iter((4))`, assuming the programmer meant `iter((4,))`. I believe this confusion about whether it is the parentheses or the commas that construct a tuple is deepened because two parentheses surrounding nothing _does_ specifically create the empty tuple but `empty = ,` is a SyntaxError. With this literal tuple change, those new to the language can be told that parentheses containing at least one comma always creates a tuple (at least anywhere is is grammatically valid to have a tuple). Jeremy
08.04.21 19:58, ucodery@gmail.com пише:
I would like to propose adding literal syntax to allow creation of an empty set without the need to call the type constructor. I believe the best choice for such a literal, and one that has been proposed before, is `{,}`.
You can now use `{*()}` as a syntax for empty set.
You can now use `{*()}` as a syntax for empty set.
I saw that in the ast module and think it's clever, mainly in a good way.
I don't think it is the same as having dedicated syntax for the empty set partly because I think it needs to be taught. I don't think a new pythonista would turn to empty tuple unpacking to get the empty set, where I do think that either set() or {,} would be natural, at least after some trial and exceptions. It also doesn't give quite the optimization as {,}. $ def comma_set():
return {,}
$ dis.dis(comma_set) 2 0 BUILD_SET 0 2 RETURN_VALUE $ def unpack_set():
return {*()}
$ dis.dis(unpack_set) 2 0 BUILD_SET 0 2 LOAD_CONST 1 (()) 4 SET_UPDATE 1 6 RETURN_VALUE although it is better than recommendations I have seen for 2.7 code $ def and_set():
return {1} & {2}
$ dis.dis(and_set) 2 0 LOAD_CONST 1 (1) 2 BUILD_SET 1 4 LOAD_CONST 2 (2) 6 BUILD_SET 1 8 BINARY_AND 10 RETURN_VALUE Part of the problem here might be the teaching; if {*()} had been talked about since 3.0 and pointed out in documentation and tutorials I likely would never have thought to raise this proposal. But I don't think it is well known, and not often used. I gave examples of where in cpython set() is used, however {*()} is only used once, as a string in ast.py; not even set repr uses this fancy syntax but instead returns "set()" for the empty set, even though braces are used to repr sets of any non-zero length.
09.04.21 19:08, micro codery пише:
Do you think that {,} does not need to be taught? It is a new special syntax which needs paragraphs in tutorial and language reference. In contrary, {*()} is a simple combination of already described syntax elements.
It also doesn't give quite the optimization as {,}.
It is a trivial optimization. It was not implemented yet only because such code is never used in tight loops, empty set creation is very rare operation at all. We prefer to keep the compiler simpler and focus on optimizing common operations which has significant effect.
On Fri, Apr 9, 2021 at 3:20 AM Serhiy Storchaka <storchaka@gmail.com> wrote:
Interestingly, Raymond Hettinger recently had a post on twitter specifically deriding this usage as obfuscatory, and expressing his preference that people not do it (and use set() instead). https://twitter.com/raymondh/status/1372376414184296448 I tend to agree with him on that... I have no opinion on whether set should be given its own "empty repr literal", but I don't think {*()} is a useful suggestion to give people who want one. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
I don't do twitter, so hadn't seen Raymond's comment. But I agree that `{*()}` is too-clever-by-half. Moreover, it's the same character count as `set()`, so it doesn't even save anything. Using five characters to create an empty `set()` really isn't that many. I do that all the time. Proposals to get that down to three characters don't feel like any big win. Actually, I've largely gotten in the habit of writing `list()` and `dict()` as well when I want to start with empty ones. I suppose the fact I do that is influenced by having to do it with `set()`; but even beyond that, I find it jumps out in intent more than the display forms. The pattern of "Create an empty collection, then add stuff in a loop" is quite common, and emphasizing which type of collection is being used is useful. Moreover, the type might be `Queue()`, or `deque()` or `Counter()` as well, and I don't expect or want literals for every possible collection. On Fri, Apr 9, 2021 at 5:43 PM Ricky Teachey <ricky@teachey.org> wrote:
-- 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.
On Fri, Apr 9, 2021 at 1:30 PM David Mertz <mertz@gnosis.cx> wrote:
Devil's advocate: it might be nice to not have to import all of those highly useful collection classes from collections all the time. What about creating syntax that looks something like: Counter() < ---- > c{} Queue() < ---- > q{} deque() < ---- > dq{} ChainMap() < ---- > cm{} OrderedDict() < ---- > od{} defaultdict(list) < ---- > dd{list} # this one is admittedly a little weird And similarly, while you're at it you could do something like: set() < ---- > s{} To be clear: I am not proposing a new "alt call" syntax... these are to be new LITERALS. I see this as sort of analogous to f-string syntax: f"" One benefit is this could greatly shorten the reprs for ALL of these types. Consider: defaultdict(<class 'list'>, {}) rather than: dd{list} --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
On Fri, Apr 9, 2021, 3:23 PM Peter Ludemann <peter.ludemann@gmail.com> wrote:
Only for the very simplest cases of that pattern. Of course I use comprehensions in such cases. In many other cases, the loop that adds stuff to collections also has conditional branches to add this vs that, calls to other functions to get more data or make decisions, nested loops, temporary variables, side-effects, and so on. ... Yes, of course with enough contortions, some of that can be worked into comprehensions. But usually it is better not to, and sometimes it is impossible.
In August 2020, in the context of PEP 472 I suggested >>> {-} for the empty set literal. At present the closest we can do for an empty set literal is >>> {0} - {0} set() The context for this is whether PEP 472 should make >>> something[] a syntax error. If we do then, what about the workarounds >>> something[*argv] >>> something[**kwargs] which so to speak convert the syntax error to a run-time error. Because >>> something[] was ugly and easily misunderstood I suggested >>> something[-] and hence >>> {-} as new syntax. The thread from August 2020 can be found (with >>> prompts as quotes) at https://mail.python.org/archives/list/python-ideas@python.org/thread/2QANGFB... -- Jonathan
I think the best alias for "empty set" would be the Unicode character "Empty set" or U+2205, i.e. "∅". Alas, it's not a valid identifier in Python:
It works with the similarly looking "ϕ" or 'GREEK PHI SYMBOL' (U+03D5)
But it's less than ideal. I think it's an error from the Unicode standard to list the empty set as a "Mathematical Operator" ( https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode#...) and not as a "Letterlike Symbol" like ℝ or ℕ ( https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode#... ). Ex:
So yes, the language would need to be changed to allow the proper empty set unicode symbol to be used. S. On Thu, Apr 8, 2021 at 11:27 PM <ucodery@gmail.com> wrote:
-- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/
Oh god, Stephane, you're giving me flashbacks to PEP 3117 ( https://www.python.org/dev/peps/pep-3117/). But not in a good way. Please pretty please let's keep unicode characters out of our code. With regards to the original proposal, for what it's worth, I like it well enough. I think sets are the only type in the builtins module without a dedicated literal syntax? So it would provide, let's say, *pleasing symmetry* in that regard. I think literals also have some (minor) performance benefits compared to their equivalent type constructors. As long as no one can think of any objections (or perhaps an alternate syntax), it seems like a reasonable enough backwards-compatible change. On Fri, Apr 9, 2021 at 9:54 AM Chris Angelico <rosuav@gmail.com> wrote:
09.04.21 12:50, Matt del Valle пише:
I think sets are the only type in the builtins module without a dedicated literal syntax?
Not only. bytearray, frozenset, slice. It is difficult to create some complex objects without using constructor. Not counting range, memoryview and dict views, descriptors (staticmethod, classmethod, property), exceptions, iterators (filter, map, zip, enumerate, reversed and numerous collection iterators). All these types are defined in the builtins module.
Sorry, I really should have had my morning coffee before making that reply. Big-time thinko :) What I meant to say is that the other comparable builtin types (comma-delimited containers of some description) that have literals built into the language (list, tuple, dict) also have a literal that represents an empty version of themselves, except for set. It's not really much of an argument, but I figured I'd mention it. On Fri, Apr 9, 2021 at 1:23 PM Serhiy Storchaka <storchaka@gmail.com> wrote:
On Fri, Apr 9, 2021 at 6:06 AM Matt del Valle <matthewgdv@gmail.com> wrote:
To emphasize that point, sets DO have a literal (or display, or whatever we want to call it) for non-empty sets, so there is a real asymmetry there. I like {,} alright, and then maybe allowing [,] and (,) for lists and tuple, but where does dict fit in? maybe: {:,} ? kinda ugluy, but provides more symmetry The fact that () creates a tuple, but (2) does not is problematic -- way too late to change anything there, but adding (,) as an optional empty tuple might help a tiny bit in the future. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
Chris Angelico writes:
Not to mention everyone's keyboards. Python != APL. Err, I mean, Python ≠ APL.
I am really tired of this argument. set() is not going to go away. And it's easy enough to install input methods (aka "keyboards") on any modern system that allow you to enter these if you want to. Most programmer's editors allow you to define abbreviations that will do the same. It's just not that hard if you want to do it, and there's no way forcing you to do it will make it past the backward-compatibility requirement. I'm perfectly happy with the TOOWTDI/YAGNI argument: you don't buy much clarity with ∅ over set(), with math.π over math.pi, or λx: x over lambda x: x, so let's just don't.[1] But let's not introduce the purely English native problem of undeveloped muscle memory when we're discussing whether Python should allow these aliases (and aliases they have to be for backward compatibility). On the flip side of the TOOWTDI argument, I'm pretty sure most programmers will have no trouble understanding any of the aliases mentioned above. Sickly sweet syntactic sugar, yes, but not a barrier to understanding. Since many of the usual identifiers actually work already: >>> import math >>> π = math.pi; π 3.141592653589793 >>> τ = math.tau; τ 6.283185307179586 >>> γ = math.gamma; γ(1) 1.0 we are going to start seeing them. I'm -1 on putting these in the stdlib; programmers who want to do this can do it already. I don't think that fact that >>> γ <built-in function gamma> uses the English spelling rather than the Greek letter is a big deal, and isn't justification for adding them to the stdlib. To me, the question here is if we should enable this compact, traditional mathematical style for those who want it in their own code by (a) special-casing some characters that are "mis-classified" by Unicode, such as ∞ and ∅, or perhaps (b) add a function that allows users to override the Unicode standard classification and add these characters to the set allowed in identifiers. lambda is a different issue. We'd have to special-case the Greek letter version and probably add it to the grammar, so that's pretty clearly out on TOOWTDI/YAGNI grounds IMO. Note that (b) might induce a security issue since depending on implementation it could allow overriding compatible and confusable normalization. I don't think we do such normalization, but if we do, that would be something to think about. Steve Footnotes: [1] It's amusing that lambda is a binding *operator* in Python (thus the lack of a space in "λx" above), but "λ" is not an operator in Unicode -- the opposite of the issue with "∅", except that you can't add operator symbols in Python so aliasing by the user can't work anyhow.
08.04.21 19:58, ucodery@gmail.com пише:
I would like to propose adding literal syntax to allow creation of an empty set without the need to call the type constructor. I believe the best choice for such a literal, and one that has been proposed before, is `{,}`.
You can now use `{*()}` as a syntax for empty set.
You can now use `{*()}` as a syntax for empty set.
I saw that in the ast module and think it's clever, mainly in a good way.
I don't think it is the same as having dedicated syntax for the empty set partly because I think it needs to be taught. I don't think a new pythonista would turn to empty tuple unpacking to get the empty set, where I do think that either set() or {,} would be natural, at least after some trial and exceptions. It also doesn't give quite the optimization as {,}. $ def comma_set():
return {,}
$ dis.dis(comma_set) 2 0 BUILD_SET 0 2 RETURN_VALUE $ def unpack_set():
return {*()}
$ dis.dis(unpack_set) 2 0 BUILD_SET 0 2 LOAD_CONST 1 (()) 4 SET_UPDATE 1 6 RETURN_VALUE although it is better than recommendations I have seen for 2.7 code $ def and_set():
return {1} & {2}
$ dis.dis(and_set) 2 0 LOAD_CONST 1 (1) 2 BUILD_SET 1 4 LOAD_CONST 2 (2) 6 BUILD_SET 1 8 BINARY_AND 10 RETURN_VALUE Part of the problem here might be the teaching; if {*()} had been talked about since 3.0 and pointed out in documentation and tutorials I likely would never have thought to raise this proposal. But I don't think it is well known, and not often used. I gave examples of where in cpython set() is used, however {*()} is only used once, as a string in ast.py; not even set repr uses this fancy syntax but instead returns "set()" for the empty set, even though braces are used to repr sets of any non-zero length.
09.04.21 19:08, micro codery пише:
Do you think that {,} does not need to be taught? It is a new special syntax which needs paragraphs in tutorial and language reference. In contrary, {*()} is a simple combination of already described syntax elements.
It also doesn't give quite the optimization as {,}.
It is a trivial optimization. It was not implemented yet only because such code is never used in tight loops, empty set creation is very rare operation at all. We prefer to keep the compiler simpler and focus on optimizing common operations which has significant effect.
On Fri, Apr 9, 2021 at 3:20 AM Serhiy Storchaka <storchaka@gmail.com> wrote:
Interestingly, Raymond Hettinger recently had a post on twitter specifically deriding this usage as obfuscatory, and expressing his preference that people not do it (and use set() instead). https://twitter.com/raymondh/status/1372376414184296448 I tend to agree with him on that... I have no opinion on whether set should be given its own "empty repr literal", but I don't think {*()} is a useful suggestion to give people who want one. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
I don't do twitter, so hadn't seen Raymond's comment. But I agree that `{*()}` is too-clever-by-half. Moreover, it's the same character count as `set()`, so it doesn't even save anything. Using five characters to create an empty `set()` really isn't that many. I do that all the time. Proposals to get that down to three characters don't feel like any big win. Actually, I've largely gotten in the habit of writing `list()` and `dict()` as well when I want to start with empty ones. I suppose the fact I do that is influenced by having to do it with `set()`; but even beyond that, I find it jumps out in intent more than the display forms. The pattern of "Create an empty collection, then add stuff in a loop" is quite common, and emphasizing which type of collection is being used is useful. Moreover, the type might be `Queue()`, or `deque()` or `Counter()` as well, and I don't expect or want literals for every possible collection. On Fri, Apr 9, 2021 at 5:43 PM Ricky Teachey <ricky@teachey.org> wrote:
-- 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.
On Fri, Apr 9, 2021 at 1:30 PM David Mertz <mertz@gnosis.cx> wrote:
Devil's advocate: it might be nice to not have to import all of those highly useful collection classes from collections all the time. What about creating syntax that looks something like: Counter() < ---- > c{} Queue() < ---- > q{} deque() < ---- > dq{} ChainMap() < ---- > cm{} OrderedDict() < ---- > od{} defaultdict(list) < ---- > dd{list} # this one is admittedly a little weird And similarly, while you're at it you could do something like: set() < ---- > s{} To be clear: I am not proposing a new "alt call" syntax... these are to be new LITERALS. I see this as sort of analogous to f-string syntax: f"" One benefit is this could greatly shorten the reprs for ALL of these types. Consider: defaultdict(<class 'list'>, {}) rather than: dd{list} --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
On Fri, Apr 9, 2021, 3:23 PM Peter Ludemann <peter.ludemann@gmail.com> wrote:
Only for the very simplest cases of that pattern. Of course I use comprehensions in such cases. In many other cases, the loop that adds stuff to collections also has conditional branches to add this vs that, calls to other functions to get more data or make decisions, nested loops, temporary variables, side-effects, and so on. ... Yes, of course with enough contortions, some of that can be worked into comprehensions. But usually it is better not to, and sometimes it is impossible.
In August 2020, in the context of PEP 472 I suggested >>> {-} for the empty set literal. At present the closest we can do for an empty set literal is >>> {0} - {0} set() The context for this is whether PEP 472 should make >>> something[] a syntax error. If we do then, what about the workarounds >>> something[*argv] >>> something[**kwargs] which so to speak convert the syntax error to a run-time error. Because >>> something[] was ugly and easily misunderstood I suggested >>> something[-] and hence >>> {-} as new syntax. The thread from August 2020 can be found (with >>> prompts as quotes) at https://mail.python.org/archives/list/python-ideas@python.org/thread/2QANGFB... -- Jonathan
I think the best alias for "empty set" would be the Unicode character "Empty set" or U+2205, i.e. "∅". Alas, it's not a valid identifier in Python:
It works with the similarly looking "ϕ" or 'GREEK PHI SYMBOL' (U+03D5)
But it's less than ideal. I think it's an error from the Unicode standard to list the empty set as a "Mathematical Operator" ( https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode#...) and not as a "Letterlike Symbol" like ℝ or ℕ ( https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode#... ). Ex:
So yes, the language would need to be changed to allow the proper empty set unicode symbol to be used. S. On Thu, Apr 8, 2021 at 11:27 PM <ucodery@gmail.com> wrote:
-- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/
Oh god, Stephane, you're giving me flashbacks to PEP 3117 ( https://www.python.org/dev/peps/pep-3117/). But not in a good way. Please pretty please let's keep unicode characters out of our code. With regards to the original proposal, for what it's worth, I like it well enough. I think sets are the only type in the builtins module without a dedicated literal syntax? So it would provide, let's say, *pleasing symmetry* in that regard. I think literals also have some (minor) performance benefits compared to their equivalent type constructors. As long as no one can think of any objections (or perhaps an alternate syntax), it seems like a reasonable enough backwards-compatible change. On Fri, Apr 9, 2021 at 9:54 AM Chris Angelico <rosuav@gmail.com> wrote:
09.04.21 12:50, Matt del Valle пише:
I think sets are the only type in the builtins module without a dedicated literal syntax?
Not only. bytearray, frozenset, slice. It is difficult to create some complex objects without using constructor. Not counting range, memoryview and dict views, descriptors (staticmethod, classmethod, property), exceptions, iterators (filter, map, zip, enumerate, reversed and numerous collection iterators). All these types are defined in the builtins module.
Sorry, I really should have had my morning coffee before making that reply. Big-time thinko :) What I meant to say is that the other comparable builtin types (comma-delimited containers of some description) that have literals built into the language (list, tuple, dict) also have a literal that represents an empty version of themselves, except for set. It's not really much of an argument, but I figured I'd mention it. On Fri, Apr 9, 2021 at 1:23 PM Serhiy Storchaka <storchaka@gmail.com> wrote:
On Fri, Apr 9, 2021 at 6:06 AM Matt del Valle <matthewgdv@gmail.com> wrote:
To emphasize that point, sets DO have a literal (or display, or whatever we want to call it) for non-empty sets, so there is a real asymmetry there. I like {,} alright, and then maybe allowing [,] and (,) for lists and tuple, but where does dict fit in? maybe: {:,} ? kinda ugluy, but provides more symmetry The fact that () creates a tuple, but (2) does not is problematic -- way too late to change anything there, but adding (,) as an optional empty tuple might help a tiny bit in the future. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
Chris Angelico writes:
Not to mention everyone's keyboards. Python != APL. Err, I mean, Python ≠ APL.
I am really tired of this argument. set() is not going to go away. And it's easy enough to install input methods (aka "keyboards") on any modern system that allow you to enter these if you want to. Most programmer's editors allow you to define abbreviations that will do the same. It's just not that hard if you want to do it, and there's no way forcing you to do it will make it past the backward-compatibility requirement. I'm perfectly happy with the TOOWTDI/YAGNI argument: you don't buy much clarity with ∅ over set(), with math.π over math.pi, or λx: x over lambda x: x, so let's just don't.[1] But let's not introduce the purely English native problem of undeveloped muscle memory when we're discussing whether Python should allow these aliases (and aliases they have to be for backward compatibility). On the flip side of the TOOWTDI argument, I'm pretty sure most programmers will have no trouble understanding any of the aliases mentioned above. Sickly sweet syntactic sugar, yes, but not a barrier to understanding. Since many of the usual identifiers actually work already: >>> import math >>> π = math.pi; π 3.141592653589793 >>> τ = math.tau; τ 6.283185307179586 >>> γ = math.gamma; γ(1) 1.0 we are going to start seeing them. I'm -1 on putting these in the stdlib; programmers who want to do this can do it already. I don't think that fact that >>> γ <built-in function gamma> uses the English spelling rather than the Greek letter is a big deal, and isn't justification for adding them to the stdlib. To me, the question here is if we should enable this compact, traditional mathematical style for those who want it in their own code by (a) special-casing some characters that are "mis-classified" by Unicode, such as ∞ and ∅, or perhaps (b) add a function that allows users to override the Unicode standard classification and add these characters to the set allowed in identifiers. lambda is a different issue. We'd have to special-case the Greek letter version and probably add it to the grammar, so that's pretty clearly out on TOOWTDI/YAGNI grounds IMO. Note that (b) might induce a security issue since depending on implementation it could allow overriding compatible and confusable normalization. I don't think we do such normalization, but if we do, that would be something to think about. Steve Footnotes: [1] It's amusing that lambda is a binding *operator* in Python (thus the lack of a space in "λx" above), but "λ" is not an operator in Unicode -- the opposite of the issue with "∅", except that you can't add operator symbols in Python so aliasing by the user can't work anyhow.
participants (14)
-
Chris Angelico -
Christopher Barker -
David Mertz -
Guido van Rossum -
Jonathan Fine -
Matt del Valle -
micro codery -
Peter Ludemann -
Ricky Teachey -
Serhiy Storchaka -
Skip Montanaro -
Stephen J. Turnbull -
Stéfane Fermigier -
ucodery＠gmail.com