Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?
On Jul 22 2015, Nick Coghlan ncogh...@gmail.com wrote: On 22 July 2015 at 13:23, Nikolaus Rath nikol...@rath.org wrote: If it were up to me, I'd focus all the resources of the PSF on reducing this backlog - be that by hiring some core developers to work full-time on just the open bugtracker issues, or by financing development of better code review and commit infrastructure. Ah, but the PSF can't do that without infringing on python-dev's autonomy - switching to my PSF Director's hat, while we'd certainly be prepared to help with funding a credible grant proposal for something like the Twisted technical fellowship, we wouldn't *impose* help that the core developers haven't asked for. I don't understand. If I would hire a core developer myself to work on this (theoretically, I have no plans to do that), would that also be infringing python-dev's authority? If so, how is that different from me doing the work? If not, why is it different if the PSF decides to hire someone? The current situation looks like a downward spiral to me. New contributors are frustrated and leave because they feel their contribution is not welcome, and core developers get burned out by the gigantic backlog and the interaction with frustrated patch submitters - thus further reducing the available manpower. We actually still have a lot of paid core developer (and potential core developer) time locked up in facilitating the Python 2 - 3 migration, as we didn't fully appreciate the extent to which Python had been adopted in the Linux ecosystem and elsewhere until folks started seeking help upgrading. Interesting. Is this information available publically somewhere? I'm curious what exactly is being worked on. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 447 (type.__getdescriptor__)
On 7/22/2015 3:25 AM, Ronald Oussoren wrote: Hi, Another summer with another EuroPython, which means its time again to try to revive PEP 447… I’ve just pushes a minor update to the PEP and would like to get some feedback on this, arguably fairly esoteric, PEP. Yeh, a bit too esoteric for most of us to review. For instance, it is not obvious to me, not familiar with internal details, after reading the intro, why a custom __getattribute__ is not enough and why __getdescriptor__ would be needed. If Guido does not want to review this, you need to find a PEP BDFL for this. There are two fairly obvious non-esoteric questions: 1. How does this impact speed (updated section needed)? 2. Is this useful, that you can think of, for anything other than connecting to Objective C? -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 447 (type.__getdescriptor__)
Terry Reedy wrote: On 7/22/2015 3:25 AM, Ronald Oussoren wrote: Hi, Another summer with another EuroPython, which means its time again to try to revive PEP 447… I’ve just pushes a minor update to the PEP and would like to get some feedback on this, arguably fairly esoteric, PEP. Yeh, a bit too esoteric for most of us to review. For instance, it is not obvious to me, not familiar with internal details, after reading the intro, why a custom __getattribute__ is not enough and why __getdescriptor__ would be needed. If Guido does not want to review this, you need to find a PEP BDFL for this. There are two fairly obvious non-esoteric questions: 1. How does this impact speed (updated section needed)? Agreed, this is important. But hopefully it's just a C indirection (or better yet, a null check) for objects that don't override __getdescriptor__. 2. Is this useful, that you can think of, for anything other than connecting to Objective C? There are other object models that would benefit from this, but I don't recall that we came up with uses other than helps proxy to objects where listing all members eagerly is expensive and/or potentially incorrect. Maybe once you list all the operating systems that are now using dynamic object-oriented APIs rather than flat APIs (Windows, iOS, Android, ... others?) this is good enough? FWIW, I'm still +1 on this, pending performance testing. Cheers, Steve -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 447 (type.__getdescriptor__)
On 22 Jul 2015, at 19:12, Steve Dower steve.do...@microsoft.com wrote: Terry Reedy wrote: On 7/22/2015 3:25 AM, Ronald Oussoren wrote: Hi, Another summer with another EuroPython, which means its time again to try to revive PEP 447… I’ve just pushes a minor update to the PEP and would like to get some feedback on this, arguably fairly esoteric, PEP. Yeh, a bit too esoteric for most of us to review. For instance, it is not obvious to me, not familiar with internal details, after reading the intro, why a custom __getattribute__ is not enough and why __getdescriptor__ would be needed. If Guido does not want to review this, you need to find a PEP BDFL for this. There are two fairly obvious non-esoteric questions: 1. How does this impact speed (updated section needed)? Agreed, this is important. But hopefully it's just a C indirection (or better yet, a null check) for objects that don't override __getdescriptor__. Not a null check, but a check for a specific function pointer. That way you can be sure that super classes always have the slot which IMHO gives a nicer user experience. 2. Is this useful, that you can think of, for anything other than connecting to Objective C? There are other object models that would benefit from this, but I don't recall that we came up with uses other than helps proxy to objects where listing all members eagerly is expensive and/or potentially incorrect. Maybe once you list all the operating systems that are now using dynamic object-oriented APIs rather than flat APIs (Windows, iOS, Android, ... others?) this is good enough? FWIW, I'm still +1 on this, pending performance testing. The PEP on the website contains performance test data, but that’s out of data. I don’t think the implementation of attribute lookup has changed enough to really invalidate those test results, but I will rerun the tests once I’ve updated the patch because hunches don’t count when evaluating performance. Ronald Cheers, Steve -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org mailto:Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 447 (type.__getdescriptor__)
On 22 Jul 2015, at 18:02, Terry Reedy tjre...@udel.edu wrote: On 7/22/2015 3:25 AM, Ronald Oussoren wrote: Hi, Another summer with another EuroPython, which means its time again to try to revive PEP 447… I’ve just pushes a minor update to the PEP and would like to get some feedback on this, arguably fairly esoteric, PEP. Yeh, a bit too esoteric for most of us to review. I noticed that in my previous attempts as well. There is only a limited number of people the really grok how Python’s attribute lookup works, and a smaller subset of those understand how that’s implemented in CPython. For instance, it is not obvious to me, not familiar with internal details, after reading the intro, why a custom __getattribute__ is not enough and why __getdescriptor__ would be needed. That means the PEP text needs some more work. Using __getattribute__ works for normal attribute access, but not when you look for a superclass implementation using super() because super currently *only* looks in the __dict__ of classes further along the MRO and offers no way to influence the search. That’s a problem when classes can grow methods dynamically. If Guido does not want to review this, you need to find a PEP BDFL for this. I’ll see if I can corner him at EP :-). Its surprisingly hard to find people at conferences. There are two fairly obvious non-esoteric questions: 1. How does this impact speed (updated section needed)? The speed impact should be minimal, the initial version of the patch (which needs some updating which I’ll try to do during the EP sprints) uses shortcuts to avoid actually calling the __getdescriptor__ method in the usual case. 2. Is this useful, that you can think of, for anything other than connecting to Objective C? Not immediately. But then again, I initially thought that decorators would have limited appeal as well :-). I guess this could be useful for other proxy-like objects as well, especially when preloading the __dict__ is relatively expensive. Apart from direct usefulness this closes a hole in the way you can influence attribute lookup. Ronald -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4.3 on RedHat 6.6 s390x make fails with: make: *** [sharedmods] Error 139
Hi Jo, Terry has right, however, if you launch this command before the compilation, it should work: https://github.com/saghul/pythonz/blob/master/README.rst#rpm-family-centos-rhel In case of it doesn't work, please contact me privately to avoid to pollute this mailing list. Have a nice day. Ludovic Gasc (GMLudo) http://www.gmludo.eu/ On 22 Jul 2015 08:23, Terry Reedy tjre...@udel.edu wrote: On 7/21/2015 6:20 PM, Vitale, Joseph wrote: Hello, Trying to install Python 3.4.3 on Red Hat 6.6 zLinux(s390x) but “make” fails and core dumps. Not using OpenSSL and did not configure for it. Questions about installing current Python should be directed to python-list. pydev is for developing future releases and versions of Python. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/gmludo%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
Since I started this thread: I like mock's magic I appreciate plain language extra features (.called, .reset_mock(), .side_effect, etc) [1] I even appreciate assert* error magic [2] assret* is just puzzling, unexpected. [1] those who want clear separation like `._assert_called_with()` are going too far IMO. Personally I'd rather use pytest style `assert m.call_count` than `m.assert_called_with()` but that's just me [2] that caught another developer's bug in my codebase On 16 July 2015 at 22:29, Michael Foord fuzzy...@gmail.com wrote: On Tuesday, 14 July 2015, Christie Wilson bobcatf...@gmail.com wrote: If people do misspell it, I think they do learn not to in after it happens a few times. Unless the line silently executes and they don't notice the mistake for years :'( Indeed. This has been a problem with mock, misspelled (usually misremembered) assert methods silently did nothing. With this fix in place several failing tests were revealed in code bases! As for assret, it's the common misspelling people have told me about. It seems a ridiculous thing for people to get worked up about, but people enjoy getting worked up. Michael On Tue, Jul 14, 2015 at 9:15 AM, Ron Adam ron3...@gmail.com wrote: On 07/14/2015 09:41 AM, Steven D'Aprano wrote: On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote: https://bugs.python.org/issue21238 introduces detection of missing/misspelt mock.assert_xxx() calls on getattr level in Python 3.5 Michael and Kushal are of the opinion that assret is a common typo of assert and should be supported in a sense that it also triggers AttributeError and is not silently ignored like a mocked user attribute. I disagree I must admit I don't use mock so don't quite understand what is going on in this bug report. But I don't imagine that anything good will come out of treating*one* typo differently from all the other possible typos. Why should assret be treated differently from other easy-to-make typos like asert, assrt, asset? Or assort, which is not only a standard and common English word, but e and o are right next to each other on Dvorak keyboards, making it an easy typo to make. Surely this is an obvious case where the Zen should apply. Special cases aren't special enough... -- either all such typos raise AttributeError, or they are all silent. I agree with Steven that it doesn't seem correct to not raise AttributeError here. For what it's worth, I have a life long sleep disorder and am a tarrable (-- like this) speller because of it. I still don't want spell, or grammar, checkers to not report my mistakes. And I don't recall ever making the particular error of using assret in place of assert. I'd be more likely to mispell it as assirt if I wasn't already so familiar with assert. If people do misspell it, I think they do learn not to in after it happens a few times. Regards, Ron ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/bobcatfish%40gmail.com -- Christie Wilson -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/dimaqq%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 447 (type.__getdescriptor__)
Hi, Another summer with another EuroPython, which means its time again to try to revive PEP 447… I’ve just pushes a minor update to the PEP and would like to get some feedback on this, arguably fairly esoteric, PEP. The PEP proposes to to replace direct access to the class __dict__ in object.__getattribute__ and super.__getattribute__ by calls to a new special method to give the metaclass more control over attribute lookup, especially for access using a super() object. This is needed for classes that cannot store (all) descriptors in the class dict for some reason, see the PEP text for a real-world example of that. Regards, Ronald The PEP text (with an outdated section with benchmarks removed): PEP: 447 Title: Add __getdescriptor__ method to metaclass Version: $Revision$ Last-Modified: $Date$ Author: Ronald Oussoren ronaldousso...@mac.com Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 12-Jun-2013 Post-History: 2-Jul-2013, 15-Jul-2013, 29-Jul-2013, 22-Jul-2015 Abstract Currently ``object.__getattribute__`` and ``super.__getattribute__`` peek in the ``__dict__`` of classes on the MRO for a class when looking for an attribute. This PEP adds an optional ``__getdescriptor__`` method to a metaclass that replaces this behavior and gives more control over attribute lookup, especially when using a `super`_ object. That is, the MRO walking loop in ``_PyType_Lookup`` and ``super.__getattribute__`` gets changed from:: def lookup(mro_list, name): for cls in mro_list: if name in cls.__dict__: return cls.__dict__ return NotFound to:: def lookup(mro_list, name): for cls in mro_list: try: return cls.__getdescriptor__(name) except AttributeError: pass return NotFound The default implemention of ``__getdescriptor__`` looks in the class dictionary:: class type: def __getdescriptor__(cls, name): try: return cls.__dict__[name] except KeyError: raise AttributeError(name) from None Rationale = It is currently not possible to influence how the `super class`_ looks up attributes (that is, ``super.__getattribute__`` unconditionally peeks in the class ``__dict__``), and that can be problematic for dynamic classes that can grow new methods on demand. The ``__getdescriptor__`` method makes it possible to dynamically add attributes even when looking them up using the `super class`_. The new method affects ``object.__getattribute__`` (and `PyObject_GenericGetAttr`_) as well for consistency and to have a single place to implement dynamic attribute resolution for classes. Background -- The current behavior of ``super.__getattribute__`` causes problems for classes that are dynamic proxies for other (non-Python) classes or types, an example of which is `PyObjC`_. PyObjC creates a Python class for every class in the Objective-C runtime, and looks up methods in the Objective-C runtime when they are used. This works fine for normal access, but doesn't work for access with `super`_ objects. Because of this PyObjC currently includes a custom `super`_ that must be used with its classes, as well as completely reimplementing `PyObject_GenericGetAttr`_ for normal attribute access. The API in this PEP makes it possible to remove the custom `super`_ and simplifies the implementation because the custom lookup behavior can be added in a central location. .. note:: `PyObjC`_ cannot precalculate the contents of the class ``__dict__`` because Objective-C classes can grow new methods at runtime. Furthermore Objective-C classes tend to contain a lot of methods while most Python code will only use a small subset of them, this makes precalculating unnecessarily expensive. The superclass attribute lookup hook Both ``super.__getattribute__`` and ``object.__getattribute__`` (or `PyObject_GenericGetAttr`_ and in particular ``_PyType_Lookup`` in C code) walk an object's MRO and currently peek in the class' ``__dict__`` to look up attributes. With this proposal both lookup methods no longer peek in the class ``__dict__`` but call the special method ``__getdescriptor__``, which is a slot defined on the metaclass. The default implementation of that method looks up the name the class ``__dict__``, which means that attribute lookup is unchanged unless a metatype actually defines the new special method. Aside: Attribute resolution algorithm in Python --- The attribute resolution proces as implemented by ``object.__getattribute__`` (or PyObject_GenericGetAttr`` in CPython's implementation) is fairly straightforward, but not entirely so without reading C code. The current CPython implementation of object.__getattribute__ is basicly equivalent to the following (pseudo-) Python code (excluding some
Re: [Python-Dev] Python 3.4.3 on RedHat 6.6 s390x make fails with: make: *** [sharedmods] Error 139
On 7/21/2015 6:20 PM, Vitale, Joseph wrote: Hello, Trying to install Python 3.4.3 on Red Hat 6.6 zLinux(s390x) but “make” fails and core dumps. Not using OpenSSL and did not configure for it. Questions about installing current Python should be directed to python-list. pydev is for developing future releases and versions of Python. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)
On 22 July 2015 at 12:09, Paul Moore p.f.mo...@gmail.com wrote: 5. Assume that the decision was well-considered and made with good reasons. If you don't understand the reasons, and feel you need to, ask for them, but refrain from judgement until you have the reasons. The original mail in this thread (is this a joke? is a particularly bad violation of this rule - does anyone seriously think a core dev commits code as a joke???). My apologies - the original thread was *not* the source of the is this a joke? comment. That appeared somewhere else, and I can't recall exactly where. The original post was well-explained and a sensible question, which pretty much followed all of the rules I covered above (although it was still about something a year old, which might have been nice to note in the post). My apologies to Dima for misrepresenting what he said. Just goes to show, that even when going on about do your research, I failed to do so myself :-( I suppose that emphasises the point that we all make mistakes, so let's try to remember that when discussing rules of conduct... Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?
* Nikolaus Rath nikol...@rath.org [2015-07-21 20:23:15 -0700]: On Jul 21 2015, Nick Coghlan ncogh...@gmail.com wrote: All of this is why the chart that I believe should be worrying people is the topmost one on this page: http://bugs.python.org/issue?@template=stats Both the number of open issues and the number of open issues with patches are steadily trending upwards. That means the bottleneck in the current process *isn't* getting patches written in the first place, it's getting them up to the appropriate standards and applied. Yet the answer to the problem isn't a simple recruit more core developers, as the existing core developers are *also* the bottleneck in the review and mentoring process for *new* core developers. As a random datapoint: Early last year I wanted get involved in CPython development. In the next months I submitted and reviewed maybe 20 - 25 patches in the bug tracker. After seeing all of them languish, I stopped submitting and reviewing and just tried to get someone to look at the issues that I'd worked on. Eventually, I managed to get almost all of them committed (the last one sometime this February, after more than a year). However, it was such an uphill battle just to get someone to look at my contributions that I haven't touched the bugtracker ever since. [...] As another random datapoint: I have some (minor) things which I'd like to contribute to Python - and I never did. Seeing the number of open issues with patches just make me feel like it'd be a waste of time to contribute. It seems very plausible the patches will just be ignored without me putting effort in getting them noticed. I'm fine with revising things until people are happy, i.e. I don't just want to post a patch and disappear - but I don't want to fight to get any kind of response, and it looks to me like I'd have to. :-/ Florian -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ pgpzO6rKynhcM.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)
On 22 July 2015 at 03:18, Stephen J. Turnbull step...@xemacs.org wrote: The only *practical* suggestion from the core has been self- restraint on the part of the crowd I would have said the following has been covered, but maybe not. At the risk of repeating something that's already been said, here are some guidelines for people asking for comments on a commit. 1. Post *once*. Don't post again until there is some feedback from the core dev addressed - the reason threads become self-sustaining is that people respond to each other without any new input from the other side (i.e. the core dev who made the commit/decision). 2. Do your research - read the issue tracker comments before posting. Look at dates, times, and history. The commit that triggered this thread was made over a year ago - we're discussing ancient history here - and the original issue was raised by the lead developer on mock. There's not a lot of explanation in there, so *maybe* asking for more detail is acceptable, but what's wrong with a comment on the issue along the lines of I know this is history, but are there links to any discussion on including the assret mis-spelling that I could read up on?) 3. Prefer comments on the tracker over mailing list discussions. Consider hard why you feel it's necessary to take the discussion to a forum with a wider readership. Honestly assess whether or not you're simply hoping to muster numbers in support of your view. If your arguments are no better than look, lots of people agree with me, then leave it to someone with more compelling arguments (if there are any) to speak up. 4. Seriously consider, if you don't use the functionality in question, why do you feel entitled to an opinion? Bystanders' views are not disallowed, but you should start from the assumption that the opinions of people directly affected by the change have *far* more weight than yours. 5. Assume that the decision was well-considered and made with good reasons. If you don't understand the reasons, and feel you need to, ask for them, but refrain from judgement until you have the reasons. The original mail in this thread (is this a joke? is a particularly bad violation of this rule - does anyone seriously think a core dev commits code as a joke???). Yes, these constitute a very high bar for commenters. So what? The bars being set by commenters on core developers are also very high. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Devguide - Add Communications Quick Start Section
On 21 July 2015 at 18:06, Carol Willing willi...@willingconsulting.com wrote: The Communications Quick Start section would be brief and practical much like the Quick Start section for downloading and testing the source code. Placing the Communications Quick Start section before the existing Quick Start section would emphasize the importance that productive communications has on CPython development. Sounds good. +1 from me. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)
On Wed, Jul 22, 2015 at 7:09 AM, Paul Moore p.f.mo...@gmail.com wrote: does anyone seriously think a core dev commits code as a joke??? Yes, https://hg.python.org/cpython/rev/0530aadff696. :-) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Devguide - Add Communications Quick Start Section
Carol Willing willi...@willingconsulting.com writes: The Communications Quick Start section would be brief and practical much like the Quick Start section for downloading and testing the source code. +1, thanks for the practical contribution! -- \ “Anyone who puts a small gloss on [a] fundamental technology, | `\ calls it proprietary, and then tries to keep others from | _o__) building on it, is a thief.” —Tim O'Reilly, 2000-01-25 | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
