Re: [Python-Dev] Deciding against the CLA
Steven D'Aprano writes: > On 13/04/13 20:30, Ben Finney wrote: > > "Stephen J. Turnbull" writes: > >> A failure to sign the CLA is already a decision not to contribute > >> to the distribution > > > > As someone who cannot in good faith sign the CLA, that > > characterisation is far from accurate: I would very much like to > > contribute to the Python distribution, and so have not decided as > > you describe. > > Could you explain, briefly, why you cannot sign the CLA? Because software freedom in a work is undermined when any recipient is granted special legal privilege in the work. As it currently stands, the Contributor Agreement grants special legal privilege in the work (the power to unilaterally re-license the work) to the PSF. By “special privilege”, I mean that this power is granted specially to some but denied to all other recipients of the work. Hence to sign the Contributor Agreement as it currently stands is to undermine software freedom in the resulting work. -- \“Choose mnemonic identifiers. If you can't remember what | `\mnemonic means, you've got a problem.” —Larry Wall | _o__) | Ben Finney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Sharing docstrings between the Python and C implementations of a module
Recently I helped out on issue16954 which involved filling in docstrings for methods and classes in ElementTree.py While doing so, I tried to test my work in the interpreter like this... >>> from xml.etree.ElementTree import Element >>> help(Element) ...but found that help() showed nothing but empty strings! After some debugging, I found that the culprit was the `from _elementtree import *` near the bottom of the module. Not wanting to copy & paste docstrings around, I thought one solution might be to just reassign Element.__doc__ with the right docstring. But, it seems that you can't do that for C extensions: >>> from _elementtree import Element as cElement >>> cElement.__doc__ = 'correct docstring' Traceback (most recent call last): File "", line 1, in TypeError: can't set attributes of built-in/extension type 'xml.etree.ElementTree.Element' --- Q. Is there way to maintain the same docstring without resorting to copying and pasting it in two places? I tried to find an example in the source which addressed this, but found that the docstrings in similar cases to be largely duplicated. For instance, _datetimemodule.c, decimal_.c and _json.c all seem to exhibit this docstring copy and pastage. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deciding against the CLA
On 4/15/2013 12:15 AM, Ben Finney wrote: Steven D'Aprano writes: On 13/04/13 20:30, Ben Finney wrote: "Stephen J. Turnbull" writes: A failure to sign the CLA is already a decision not to contribute to the distribution As someone who cannot in good faith sign the CLA, that characterisation is far from accurate: I would very much like to contribute to the Python distribution, and so have not decided as you describe. Could you explain, briefly, why you cannot sign the CLA? Because software freedom in a work is undermined when any recipient is granted special legal privilege in the work. As it currently stands, the Contributor Agreement grants special legal privilege in the work (the power to unilaterally re-license the work) to the PSF. By “special privilege”, I mean that this power is granted specially to some but denied to all other recipients of the work. Hence to sign the Contributor Agreement as it currently stands is to undermine software freedom in the resulting work. Easily curable by granting that right to all recipients of the contributions you make to PSF, no? Of course, the contributor's agreement has no particular need to include such a clause, but you can include it in a separately published version of the contributions, to keep freedom free... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deciding against the CLA
Ben Finney writes: > As it currently stands, the Contributor Agreement grants special > legal privilege in the work (the power to unilaterally re-license > the work) to the PSF. "I hate to disagree, Sir, but that turns out to be incorrect."[0] First, it's not the Contributor Agreement, it's the approved Initial Licenses that grant the power to sublicense (the technical term in US law for the kind of "re-licensing" being discussed here). The AFL does so explicitly. I'm not sure about the Apache license, but it does so at least implicitly. (That's the main feature of a "permissive license".) I agree the wording is a little vague, but in fact the Contributor Agreement simply affirms that the Initial License has been granted and that it provides for sublicensing. It then *takes away* power from the PSF, by requiring it to use an open source license, which the Initial Licenses (AFL and Apache) do not. Second, although in theory the PSF might change its license, at the moment the current PSF license also (implicitly) permits some form of "re-licensing" because it requires only preservation of copyright notice (clause 2) and a list of changes (clause 3). In particular it implicitly grants the right to use a proprietary license for works derived from the contribution, which is denied to the PSF under the Contributor Agreement.[1] I think that is very unlikely to change. So the PSF Contributor Agreement grants no special privileges to the PSF not available in practice to any Python user. Footnotes: [0] IANAL, but I'm on pretty firm ground on this one. [1] Technically speaking, that proprietary license may not apply to the portion of code copied from Python. In practice, to the extent that proprietary original code is mixed with PSF Python, it can effectively prevent copying any part of the derived work. Cf. the infamous "non-permission" statement on O'Reilly's _The X Window System_ series. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sharing docstrings between the Python and C implementations of a module
On Mon, Apr 15, 2013 at 9:56 AM, David Lam wrote: > Recently I helped out on issue16954 which involved filling in docstrings > for methods and classes in ElementTree.py > > While doing so, I tried to test my work in the interpreter like this... > > >>> from xml.etree.ElementTree import Element > >>> help(Element) > > ...but found that help() showed nothing but empty strings! > > After some debugging, I found that the culprit was the > `from _elementtree import *` near the bottom of the module. > > Not wanting to copy & paste docstrings around, I thought one solution > might be to just reassign Element.__doc__ with the right docstring. > But, it seems that you can't do that for C extensions: > > >>> from _elementtree import Element as cElement > >>> cElement.__doc__ = 'correct docstring' > Traceback (most recent call last): > File "", line 1, in > TypeError: can't set attributes of built-in/extension type > 'xml.etree.ElementTree.Element' > > --- > > Q. Is there way to maintain the same docstring without > resorting to copying and pasting it in two places? > > I tried to find an example in the source which addressed this, but > found that the docstrings in similar cases to be largely duplicated. > For instance, _datetimemodule.c, decimal_.c and _json.c all seem to > exhibit this docstring copy and pastage. > Hi NumPy uses a hack to deal with this problem. It has a small C function that would mutate the docstring under your feet. Personally I would prefer some sort of tagging in C source that can copy-paste stuff instead, honestly. It does sound like a good idea to share docstrings. Seems also relatively trivial to write a test that checks that they stay the same. Cheers, fijal ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sharing docstrings between the Python and C implementations of a module
On Mon, Apr 15, 2013 at 8:17 PM, Maciej Fijalkowski wrote: > On Mon, Apr 15, 2013 at 9:56 AM, David Lam wrote: >> I tried to find an example in the source which addressed this, but >> found that the docstrings in similar cases to be largely duplicated. >> For instance, _datetimemodule.c, decimal_.c and _json.c all seem to >> exhibit this docstring copy and pastage. >> > > Hi > > NumPy uses a hack to deal with this problem. It has a small C function > that would mutate the docstring under your feet. Personally I would > prefer some sort of tagging in C source that can copy-paste stuff > instead, honestly. It does sound like a good idea to share docstrings. > Seems also relatively trivial to write a test that checks that they > stay the same. It's actually even worse than that - if a subclass overrides a method, it has to completely duplicate the docstring, even if the original docstring was still valid. So, for example, ABCs can't provide docstrings for abstract methods. So yeah, we end up not only duplicating between the C and Python versions, but sometimes we end up duplicating between different subclasses as well (datetime.datetime, datetime.date and datetime.time are the worst offenders here). I like the idea of at least adding a test that checks the Python docstring and the C docstring are the same in the duplicated cases - that should be a lot easier than adjusting the build process to let the C version use the Python docstrings or vice-versa (even the argument clinic DSL in PEP 434 doesn't try to achieve that - it just tries to cut down on the duplication within the C code itself). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #17693: CJK encoders now use the new Unicode API (PEP 393)
On Mon, Apr 15, 2013 at 3:36 AM, Victor Stinner wrote: > Hi, > > 2013/4/14 Nick Coghlan : >> On Sun, Apr 14, 2013 at 10:06 AM, victor.stinner >> wrote: >>> http://hg.python.org/cpython/rev/d621bdaed7c3 >>> changeset: 83317:d621bdaed7c3 >>> user:Victor Stinner >>> date:Sun Apr 14 02:06:32 2013 +0200 >>> summary: >>> Issue #17693: CJK encoders now use the new Unicode API (PEP 393) >> >> I'm going to run with the wild theory that there's a reference link in >> here somewhere... :) >> >> results for 0ee785c9d1b4 on branch "default" >> -- >> -- >> >> test_codecencodings_cn leaked [16133, 16133, 16133] references, sum=48399 >> test_codecencodings_cn leaked [28992, 28994, 28994] memory blocks, sum=86980 >> ... > > Oh thanks for the report. My laptop is too slow to run the test suite using > -R. It's thanks to Antoine, really - I don't make a habit of running with -R either, I just watch for the leak reporting emails that look like real leaks rather than random noise :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deciding against the CLA
Can we get this discussion off python-dev? It's not going to change, and this is not the forum to express your disagreement. On Mon, Apr 15, 2013 at 12:15 AM, Ben Finney wrote: > Steven D'Aprano writes: > >> On 13/04/13 20:30, Ben Finney wrote: >> > "Stephen J. Turnbull" writes: >> >> A failure to sign the CLA is already a decision not to contribute >> >> to the distribution >> > >> > As someone who cannot in good faith sign the CLA, that >> > characterisation is far from accurate: I would very much like to >> > contribute to the Python distribution, and so have not decided as >> > you describe. >> >> Could you explain, briefly, why you cannot sign the CLA? > > Because software freedom in a work is undermined when any recipient is > granted special legal privilege in the work. > > As it currently stands, the Contributor Agreement grants special legal > privilege in the work (the power to unilaterally re-license the work) to > the PSF. > > By “special privilege”, I mean that this power is granted specially to > some but denied to all other recipients of the work. Hence to sign the > Contributor Agreement as it currently stands is to undermine software > freedom in the resulting work. > > -- > \“Choose mnemonic identifiers. If you can't remember what | > `\mnemonic means, you've got a problem.” —Larry Wall | > _o__) | > Ben Finney > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sharing docstrings between the Python and C implementations of a module
On Mon, Apr 15, 2013 at 3:45 AM, Nick Coghlan wrote: > On Mon, Apr 15, 2013 at 8:17 PM, Maciej Fijalkowski > wrote: > > On Mon, Apr 15, 2013 at 9:56 AM, David Lam > wrote: > >> I tried to find an example in the source which addressed this, but > >> found that the docstrings in similar cases to be largely duplicated. > >> For instance, _datetimemodule.c, decimal_.c and _json.c all seem to > >> exhibit this docstring copy and pastage. > >> > > > > Hi > > > > NumPy uses a hack to deal with this problem. It has a small C function > > that would mutate the docstring under your feet. Personally I would > > prefer some sort of tagging in C source that can copy-paste stuff > > instead, honestly. It does sound like a good idea to share docstrings. > > Seems also relatively trivial to write a test that checks that they > > stay the same. > > It's actually even worse than that - if a subclass overrides a method, > it has to completely duplicate the docstring, even if the original > docstring was still valid. So, for example, ABCs can't provide > docstrings for abstract methods. > > So yeah, we end up not only duplicating between the C and Python > versions, but sometimes we end up duplicating between different > subclasses as well (datetime.datetime, datetime.date and datetime.time > are the worst offenders here). > > I like the idea of at least adding a test that checks the Python > docstring and the C docstring are the same in the duplicated cases - > that should be a lot easier than adjusting the build process to let > the C version use the Python docstrings or vice-versa (even the > argument clinic DSL in PEP 434 doesn't try to achieve that - it just > tries to cut down on the duplication within the C code itself). > Would it make sense to think about adding this in the scope of the argument clinic work, or is it too unrelated? This seems like a commonly needed thing for large parts of the stdlib (where the C accelerator overrides Python code). Eli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sharing docstrings between the Python and C implementations of a module
On 15 April 2013 13:31, Eli Bendersky wrote: > > > > On Mon, Apr 15, 2013 at 3:45 AM, Nick Coghlan wrote: >> >> On Mon, Apr 15, 2013 at 8:17 PM, Maciej Fijalkowski >> wrote: >> > On Mon, Apr 15, 2013 at 9:56 AM, David Lam >> > wrote: >> >> I tried to find an example in the source which addressed this, but >> >> found that the docstrings in similar cases to be largely duplicated. >> >> For instance, _datetimemodule.c, decimal_.c and _json.c all seem to >> >> exhibit this docstring copy and pastage. >> >> >> > >> > Hi >> > >> > NumPy uses a hack to deal with this problem. It has a small C function >> > that would mutate the docstring under your feet. Personally I would >> > prefer some sort of tagging in C source that can copy-paste stuff >> > instead, honestly. It does sound like a good idea to share docstrings. >> > Seems also relatively trivial to write a test that checks that they >> > stay the same. >> >> It's actually even worse than that - if a subclass overrides a method, >> it has to completely duplicate the docstring, even if the original >> docstring was still valid. So, for example, ABCs can't provide >> docstrings for abstract methods. >> >> So yeah, we end up not only duplicating between the C and Python >> versions, but sometimes we end up duplicating between different >> subclasses as well (datetime.datetime, datetime.date and datetime.time >> are the worst offenders here). >> >> I like the idea of at least adding a test that checks the Python >> docstring and the C docstring are the same in the duplicated cases - >> that should be a lot easier than adjusting the build process to let >> the C version use the Python docstrings or vice-versa (even the >> argument clinic DSL in PEP 434 doesn't try to achieve that - it just >> tries to cut down on the duplication within the C code itself). > > > Would it make sense to think about adding this in the scope of the argument > clinic work, or is it too unrelated? This seems like a commonly needed thing > for large parts of the stdlib (where the C accelerator overrides Python > code). +1 It is a problem I was met with when building extensions as well - when one would like to keep the C parts to a minimum and dynamically populate de doc-strings from another source with a Python script, for example. > > Eli > > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sharing docstrings between the Python and C implementations of a module
> Would it make sense to think about adding this in the scope of the argument > clinic work, or is it too unrelated? This seems like a commonly needed thing > for large parts of the stdlib (where the C accelerator overrides Python > code). Or maybe separate doc strings from both code bases altogether and insert them where appropriate as part of the build process? That said, I haven't any idea how you might accomplish that. Maybe this general problem should be thrown over the python-ideas to cook for awhile... Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sharing docstrings between the Python and C implementations of a module
On Mon, Apr 15, 2013 at 12:56 AM, David Lam wrote: > I tried to find an example in the source which addressed this, but > found that the docstrings in similar cases to be largely duplicated. > I find this annoying too. It would be nice to have a common way to share docstrings between C and Python implementations of the same interface. One roadblock though is functions in C modules often document their parameters in their docstring. >>> import _json >>> help(_json.scanstring) scanstring(...) scanstring(basestring, end, encoding, strict=True) -> (str, end) Scan the string s for a JSON string. End is the index of the character in s after the quote that started the JSON string. [...] Argument clinic will hopefully lift this roadblock soon. Perhaps, we could add something to the clinic DSL a way to fetch the docstring directly from the Python implementation. And as an extra, it would be easy to add verification step as well that checks the both implementations provide a similar interfaces once we have this in place. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sharing docstrings between the Python and C implementations of a module
On 04/15/2013 09:31 AM, Eli Bendersky wrote: Would it make sense to think about adding this in the scope of the argument clinic work, or is it too unrelated? This seems like a commonly needed thing for large parts of the stdlib (where the C accelerator overrides Python code). From my perspective, the C accelerator doesn't override the Python code; the Python code is in charge, and elects to call the C accelerator. To answer your question, Clinic could help but I think it'd kind of suck. We'd have to use Clinic to preprocess the .py file and copy the docstring there, which would mean slurping in the C file. Clumsy but workable. We can talk about it once I finish the revised implementation, which should make processes like this much easier. /arry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sharing docstrings between the Python and C implementations of a module
On 4/15/2013 4:21 PM, Larry Hastings wrote: On 04/15/2013 09:31 AM, Eli Bendersky wrote: Would it make sense to think about adding this in the scope of the argument clinic work, or is it too unrelated? This seems like a commonly needed thing for large parts of the stdlib (where the C accelerator overrides Python code). From my perspective, the C accelerator doesn't override the Python code; the Python code is in charge, and elects to call the C accelerator. To answer your question, Clinic could help but I think it'd kind of suck. We'd have to use Clinic to preprocess the .py file and copy the docstring there, which would mean slurping in the C file. Clumsy but workable. We can talk about it once I finish the revised implementation, which should make processes like this much easier. Since Clinic is mostly aimed at making C usage work with python, isn't the above backwards? Wouldn't it be better to have Clinic slurp in the Python code to find the docstrings, and then put them in the C code? Then no need to preprocess the python file, just read it to obtain the docstrings. You are already preprocessing the C code... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] mimetypes broken on Windows
Hi folks,
The built-in mimetypes module is broken on Windows, and it has been since
Python 2.7 alpha 1. On all Windows systems I've tried, guess_type() returns
the wrong mime type for common types like .png and .jpg. For example (on
Python 2.7.4 and 3.3.1):
>>> import mimetypes
>>> mimetypes.guess_type('f.png')
('image/x-png', None)
>>> mimetypes.guess_type('f.jpg')
('image/pjpeg', None)
These should be 'image/png' and 'image/jpeg', respectively.
There's an open issue for this: http://bugs.python.org/issue15207. However,
it hasn't gotten any love in the last few months, so per r.david.murray's
comment, I'm posting it here.
Dave Chambers, who opened the bug, has proposed a fix, which is
significantly better (i.e., not totally broken for common types). However,
as I mentioned in http://bugs.python.org/issue15207#msg177030, using the
Windows registry for this at all is basically a bad idea, because:
1) Important keys like .jpg and .png aren't in the registry anyway.
2) Some that do exist are wrong in the Windows registry. This includes
.zip, which is "application/x-zip-compressed" (at least in my registry) but
should be "application/zip".
3) It makes the first call to guess_type() slow (~100ms), which isn't
terrible, but with the above concerns, not worth it.
4) Perhaps most importantly: the keys in the Windows registry depend on
what programs you have installed. And the users and programs can change
registry keys at will.
Obviously one can work around this bug, either by calling
mimetypes.init(files=[]) before any calls to guess_type, or calling init()
with your own mime types file. However, "broken out of the box" is going to
cause a lot of people headaches. :-)
So my proposal is simply to get rid of read_windows_registry() altogether,
and fall back to the default type mapping in mimetypes.py on Windows
systems. This is correct and fast, even if not complete. As always, folks
can always use their own mimetypes file if they want.
In summary: the current behaviour is buggy and broken, the behaviour
proposed in Issue 15207 is problematic, getting this from the Windows
registry is bad idea, and we should revert the whole registry thing. :-)
If folks agree with my reasoning above, I can provide a patch to fix this,
along with a patch to the Windows unit tests.
-Ben
P.S. Kind of proving my point about the fragility of using the registry,
the Python 2.7.4 unit test test_registry_parsing in test_mimetypes.py fail
on my machine. It's because I've installed some SQL server, and text/plain
is my registry is mapped from .sql (instead of .txt), causing this:
Traceback (most recent call last):
File "C:\python27\lib\test\test_mimetypes.py", line 85, in
test_registry_parsing
eq(self.db.guess_type("foo.txt"), ("text/plain", None))
AssertionError: Tuples differ: (None, None) != ('text/plain', None)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Destructors and Closing of File Objects
Brian Curtin writes: > On Fri, Apr 12, 2013 at 12:04 AM, Nikolaus Rath wrote: >> [ Note: I already asked this on >> http://stackoverflow.com/questions/15917502 but didn't get any >> satisfactory answers] > > Sorry, but that's not a reason to repost your question to this list. > If you have to ask somewhere else, it would be python-list, aka, > comp.lang.python. I figured it belonged here because the question is really about the internal implementation of file objects, which to me didn't seem like a question about using Python. But I'll give it a few days and send another mail there if still haven't found the answer by then. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Destructors and Closing of File Objects
You got your snswer 16 hours ago on S.O. On Monday, April 15, 2013, Nikolaus Rath wrote: > Brian Curtin > writes: > > On Fri, Apr 12, 2013 at 12:04 AM, Nikolaus Rath > > > > wrote: > >> [ Note: I already asked this on > >> http://stackoverflow.com/questions/15917502 but didn't get any > >> satisfactory answers] > > > > Sorry, but that's not a reason to repost your question to this list. > > If you have to ask somewhere else, it would be python-list, aka, > > comp.lang.python. > > I figured it belonged here because the question is really about the > internal implementation of file objects, which to me didn't seem like a > question about using Python. But I'll give it a few days and send > another mail there if still haven't found the answer by then. > > Best, > >-Nikolaus > > -- > »Time flies like an arrow, fruit flies like a Banana.« > > PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
