Re: [Python-Dev] xmlrpc improvements
> I‘d really like to get this stuff in. The performance gains allowing > http1.1 and gzip for xmlrpc are quite significant. I think you really need to get Fredrik Lundh to comment on it. If he can't predict when he'll be able to review the changes, maybe he can accept releasing control of xmlrpclib. Regards, Martin ___ 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] xmlrpc improvements
2009/6/20 "Martin v. Löwis" : >> I‘d really like to get this stuff in. The performance gains allowing >> http1.1 and gzip for xmlrpc are quite significant. > > I think you really need to get Fredrik Lundh to comment on it. If he > can't predict when he'll be able to review the changes, maybe he can > accept releasing control of xmlrpclib. Pointer to the patch? ___ 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] xmlrpc improvements
Fredrik Lundh wrote: >> I think you really need to get Fredrik Lundh to comment on it. If he >> can't predict when he'll be able to review the changes, maybe he can >> accept releasing control of xmlrpclib. > > Pointer to the patch? http://bugs.python.org/issue6267 While I have your attention, please also review http://bugs.python.org/issue6233 Regards, Martin ___ 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] draft pep: backwards compatibility
On 19 Jun, 09:08 pm, [email protected] wrote: 2009/6/19 : On 02:09 pm, [email protected] wrote: 2009/6/19 �: �What about side-effects, or exceptional conditions? �What about interactions with subclasses? (Changing a class in a library from old-style to new-style has serious repercussions, as MRO conflicts can result in applications that subclass it.) I've added a little more about this to the PEP. See what you think. Finally had a chance to take a look. It's a big improvement, certainly: much more specific. Although I think I have a few quibbles with the wording. For one thing, I don't like the use of the word "reasonable". Everybody thinks *their* exception to the rules is reasonable, but nobody else's is. Besides, if the BDFL thinks a change is really reasonable, do you think a PEP is going to stop him? :) For another, I think it's actually a bit too strict, as worded. The side-effects of a function includes the warnings that it emits; any method-call can have side-effects, so you can't change an algorithm *at all*. The only side-effects that I think are important are the ones that get invoked on objects that an application gets to inject somewhere, or inspect later via a public API. The word "releases" also needs to be qualified. Most importantly, minor-version and micro-version releases need to be described distinctly. Finally, the PEP should mention its participation in the universe of compatibility process PEPs. It should describe its relationship to at least some of PEP 3002, 291, 5, 6, 2, 3001, and 384. My point is that triviality is a matter of perspective :). I understand. I think we will just have to provide guidelines for triviality and decide on a case by case basis. A simple litmus test, or some examples, of triviality would be helpful. the pile-on can still happen on python-list, but only the results of the discussion will be announced on the incompatible-announce list. I think that's a fine idea, but the PEP is dealing with policy as our mailing list infrastructure is now. Hmm... well, maybe everybody should just run their tests against Python trunk. The commits list is a reliable notification mechanism for potentially incompatible changes ;-). Perhaps it would be good to mention this specifically in the PEP? For example, "third party projects may request that an incompatible change be reverted, by providing evidence of tests failing on x.y+1 that passed on x.y, where the code in question does not rely on any details not specified as 'public' in the section above"? If more projects did this when there *was* a problem, then it would actually be a lot easier to break the policy with confidence. With an incompatible change, you could know, "we checked it in, and nobody complained". Whereas right now is nobody complains it's more likely that nobody is paying attention. ___ 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] draft pep: backwards compatibility
On Thu, Jun 18, 2009 at 7:17 PM, Benjamin Peterson wrote: [snip] > Backwards Compatibility Rules > = > > This policy applys to all public APIs. These include the C-API, the standard > library, and the core language including syntax and operation as defined by > the > reference manual. > > This is the basic policy for backwards compatibility: > > * The behavior of an API *must* not change between any two consecutive > releases. Is this intended to include performance changes? Clearly no-one will complain if things simply get faster, but I'm thinking about cases where, say, a function runs in half the time but uses double the memory (or vice versa). Collin ___ 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] draft pep: backwards compatibility
[email protected] wrote: On 07:06 pm, [email protected] wrote: Not sure why we need yet another pep on the subject. Just update PEP 5 if needed. I agree. The draft covers the same ground. Two PEPs on the same subject would be redundant where they agree but would create confusion where they do not. To the extent that the new PEP intends to change existing policy by severely curtailing language change, as it appears to, then that *idea* should be directly presented and discussed, perhaps on python-list, before worrying about wording (bikeshed) details. In other words, I think the discussion should have start out "Here is existing policy (PEP 5). I propose to change it like so..." or possibly "Here is existing policy in PEP 5. I believe it has defacto changed as evidenced by ... " In other words, discuss and decide whether the bikeshed should be re-painted before worrying about the exact shade. Right now, the rule to write software that will not break with the next Python release is "read the minds of the python core committers and hope that you do not do anything with the stdlib that they don't like". A bit harsh ;-) Along with this there are several rules you can infer that are probably true most of the time: don't call stuff starting with "_", don't monkey- patch anything, don't use dynamic class replacement on objects from classes other than your own, don't depend on the depth of inheritance hierarchies (for example, no ".__bases__[0].__bases__[0]"), make sure your tests run without producing any DeprecationWarnings, be mindful of potential namespace conflicts when adding attributes to classes that inherit from other libraries. I don't think all these things are written down in one place though. This could be the core of a new PEP Keeeping up with Language Changes. I think that would be a good thing. Terry Jan Reedy ___ 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] io.BufferedReader.peek() Behaviour in python3.1
Lucas P Melo wrote: Am I understanding this correctly: * The blocking version would not do any raw reads. No, the blocking version would keep doing raw reads until the buffer contains enough bytes. -- Greg ___ 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
