Re: [Python-Dev] decorator module in stdlib?
On Wed, Apr 8, 2009 at 12:09 AM, Michele Simionato michele.simion...@gmail.com wrote: On Tue, Apr 7, 2009 at 11:04 PM, Terry Reedy tjre...@udel.edu wrote: This probably should have gone to the python-ideas list. In any case, I think it needs to start with a clear offer from Michele (directly or relayed by you) to contribute it to the PSF with the usual conditions. I have no problem to contribute the module to the PSF and to maintain it. I would just prefer to have the ability to change the function signature in the core language rather than include in the standard library a clever hack. Flipping Michele's commit bit (if he wants it) is overdue. A quick google doesn't show he refused it in the past, but the same search shows the things things he did do - including the explication of MRO in 2.3 (http://www.python.org/download/releases/2.3/mro/). Plus he's a softie for decorators, as am I. -Jack ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] slightly inconsistent set/list pop behaviour
Tennessee Leeuwenburg wrote: Now, I know that sets aren't ordered, but... foo = set([1,2,3,4,5]) bar = [1,2,3,4,5] foo.pop() will reliably return 1 while bar.pop() will return 5 discuss :) As designed. If you play around a bit it becomes clear that what set.pop() returns is independent of the insertion order: PythonWin 2.5.2 (r252:60911, Mar 27 2008, 17:57:18) [MSC v.1310 32 bit (Intel)] on win32. foo = set([5,4,3,2,1]) # Order reversed from above foo.pop() 1 foo = set([-1,0,1,2,3,4,5]) foo.pop() 0 foo = set([-1,1,2,3,4,5]) foo.pop() 1 As the documentation says (http://docs.python.org/library/stdtypes.html#set.pop) set.pop() is free to return an arbitrary element. list.pop() however always returns the last element of the list, unless of course you specify some other index: http://docs.python.org/library/stdtypes.html#mutable-sequence-types, point 6. John ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] slightly inconsistent set/list pop behaviour
On Wed, Apr 8, 2009 at 7:13 AM, John Barham jbar...@gmail.com wrote: If you play around a bit it becomes clear that what set.pop() returns is independent of the insertion order: It might look like that, but I don't think this is true in general (at least, with the current implementation): foo = set([1, 65537]) foo.pop() 1 foo = set([65537, 1]) foo.pop() 65537 Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
On Wed, Apr 8, 2009 at 8:10 AM, Jack diederich jackd...@gmail.com wrote: Plus he's a softie for decorators, as am I. I must admit that while I still like decorators, I do like them as much as in the past. I also see an overuse of decorators in various libraries for things that could be done more clearly without them ;-( But this is tangential. What I would really like to know is the future of PEP 362, i.e. having a signature object that could be taken from an undecorated function and added to the decorated function. I do not recall people having anything against it, in principle, and there is also an implementation in the sandbox, but after three years nothing happened. I guess this is just not a high priority for the core developers. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] http://bugs.python.org/issue2240
On Wed, Apr 8, 2009 at 3:55 PM, Jeroen Ruigrok van der Werven asmo...@in-nomine.org wrote: -On [20090408 05:24], Tennessee Leeuwenburg (tleeuwenb...@gmail.com) wrote: It seems like the bug relates only to an older version of a 'weird' operating system ducks and could perhaps be left unfixed without causing anyone any problems. Being one of the FreeBSD guys I'll throw peanuts at you. :P In any case, 6.3 is from early 2008 and 6.4 is from November 2008. The 6-STABLE branch is still open and a lot of users are still tracking this. However, the main focus is 7 and with 8 looming on the horizon. And FreeBSD 7 does away with libc_r and uses a whole different model for its threading. Are the tests going ok there? If so, then I shouldn't worry about the 6 branch. :) Thanks for your input. I've done the paper shuffling so someone else can pick up the FreeBSD cleanup job as a new issue... Cheers, -T ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] slightly inconsistent set/list pop behaviour
On Wed, Apr 8, 2009 at 2:44 AM, Mark Dickinson dicki...@gmail.com wrote: On Wed, Apr 8, 2009 at 7:13 AM, John Barham jbar...@gmail.com wrote: If you play around a bit it becomes clear that what set.pop() returns is independent of the insertion order: It might look like that, but I don't think this is true in general (at least, with the current implementation): foo = set([1, 65537]) foo.pop() 1 foo = set([65537, 1]) foo.pop() 65537 You wrote a program to find the two smallest ints that would have a hash collision in the CPython set implementation? I'm impressed. And by impressed I mean frightened. -Jack ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] slightly inconsistent set/list pop behaviour
Jack diederich wrote: On Wed, Apr 8, 2009 at 2:44 AM, Mark Dickinson dicki...@gmail.com wrote: On Wed, Apr 8, 2009 at 7:13 AM, John Barham jbar...@gmail.com wrote: If you play around a bit it becomes clear that what set.pop() returns is independent of the insertion order: It might look like that, but I don't think this is true in general (at least, with the current implementation): foo = set([1, 65537]) foo.pop() 1 foo = set([65537, 1]) foo.pop() 65537 You wrote a program to find the two smallest ints that would have a hash collision in the CPython set implementation? I'm impressed. And by impressed I mean frightened. Given the two numbers in question (1, 2**16+1) I suspect this is the result of analysis rather than algorithm. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Watch PyCon on video now! http://pycon.blip.tv/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] slightly inconsistent set/list pop behaviour
Andrea Griffini griph...@gmail.com wrote: On Wed, Apr 8, 2009 at 12:57 PM, Jack diederich jackd...@gmail.com wrote: You wrote a program to find the two smallest ints that would have a hash collision in the CPython set implementation? I'm impressed. And by impressed I mean frightened. ? print set([0,8]).pop(), set([8,0]).pop() If 'smallest ints' means the sum of the absolute values then these are slightly smaller: print set([-1,6]).pop(), set([6,-1]).pop() 6 -1 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] slightly inconsistent set/list pop behaviour
Mark Dickinson dickinsm at gmail.com writes: On Wed, Apr 8, 2009 at 7:13 AM, John Barham jbarham at gmail.com wrote: If you play around a bit it becomes clear that what set.pop() returns is independent of the insertion order: It might look like that, but I don't think this is true in general (at least, with the current implementation): Not to mention that other implementations (Jython, etc.) will probably exhibit yet different behaviour, and the CPython hash functions are not engraved in stone either. If you want to write portable code, you can't rely on *any* reproduceable ordering for random set member access. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] slightly inconsistent set/list pop behaviour
On Wed, Apr 8, 2009 at 12:57 PM, Jack diederich jackd...@gmail.com wrote: You wrote a program to find the two smallest ints that would have a hash collision in the CPython set implementation? I'm impressed. And by impressed I mean frightened. ? print set([0,8]).pop(), set([8,0]).pop() Andrea ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PyCFunction_* Missing
Hi, Just noticed the new Python 2.6.2 docs now dont have any reference to * PyCFunction_New * PyCFunction_NewEx * PyCFunction_Check * PyCFunction_Call Ofcourse these are still in the source code but Im wondering if this is intentional that these functions should be for internal use only? -- - Campbell ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Dropping bytes support in json
Hello, We're in the process of forward-porting the recent (massive) json updates to 3.1, and we are also thinking of dropping remnants of support of the bytes type in the json library (in 3.1, again). This bytes support almost didn't work at all, but there was a lot of C and Python code for it nevertheless. We're also thinking of dropping the encoding argument in the various APIs, since it is useless. Under the new situation, json would only ever allow str as input, and output str as well. By posting here, I want to know whether anybody would oppose this (knowing, once again, that bytes support is already broken in the current py3k trunk). The bug entry is: http://bugs.python.org/issue4136 Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] slightly inconsistent set/list pop behaviour
2009/4/8 Duncan Booth duncan.bo...@suttoncourtenay.org.uk: Andrea Griffini griph...@gmail.com wrote: On Wed, Apr 8, 2009 at 12:57 PM, Jack diederich jackd...@gmail.com wrote: You wrote a program to find the two smallest ints that would have a hash collision in the CPython set implementation? I'm impressed. And by impressed I mean frightened. ? print set([0,8]).pop(), set([8,0]).pop() If 'smallest ints' means the sum of the absolute values then these are slightly smaller: print set([-1,6]).pop(), set([6,-1]).pop() 6 -1 Can't resist: print set([-2,-1]).pop(), set([-1,-2]).pop() -1 -2 Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] slightly inconsistent set/list pop behaviour
Paul Moore wrote: 2009/4/8 Duncan Booth duncan.bo...@suttoncourtenay.org.uk: Andrea Griffini griph...@gmail.com wrote: On Wed, Apr 8, 2009 at 12:57 PM, Jack diederich jackd...@gmail.com wrote: You wrote a program to find the two smallest ints that would have a hash collision in the CPython set implementation? I'm impressed. And by impressed I mean frightened. ? print set([0,8]).pop(), set([8,0]).pop() If 'smallest ints' means the sum of the absolute values then these are slightly smaller: print set([-1,6]).pop(), set([6,-1]).pop() 6 -1 Can't resist: print set([-2,-1]).pop(), set([-1,-2]).pop() -1 -2 a = 0.001 b = 0.002 print set([a, b]).pop(), set([b, a]).pop() 0.002 0.001 Let's stop here ... regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Watch PyCon on video now! http://pycon.blip.tv/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] slightly inconsistent set/list pop behaviour
2009/4/8 Steve Holden st...@holdenweb.com: Paul Moore wrote: 2009/4/8 Duncan Booth duncan.bo...@suttoncourtenay.org.uk: Andrea Griffini griph...@gmail.com wrote: On Wed, Apr 8, 2009 at 12:57 PM, Jack diederich jackd...@gmail.com wrote: You wrote a program to find the two smallest ints that would have a hash collision in the CPython set implementation? I'm impressed. And by impressed I mean frightened. ? print set([0,8]).pop(), set([8,0]).pop() If 'smallest ints' means the sum of the absolute values then these are slightly smaller: print set([-1,6]).pop(), set([6,-1]).pop() 6 -1 Can't resist: print set([-2,-1]).pop(), set([-1,-2]).pop() -1 -2 a = 0.001 b = 0.002 print set([a, b]).pop(), set([b, a]).pop() 0.002 0.001 Cheat! We were using integers... :-) Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Contributor Agreements for Patches - was [Jython-dev] Jython on Google AppEngine!
A question that arose on this thread, which I'm forwarding for context (and we're quite happy about it too!): - What is the scope of a patch that requires a contributor agreement? This particular patch on #1188 simply adds obvious (in retrospect of course) handling on SecurityException so that it's treated in a similar fashion to IOException (possibly a bit more buried), so it seems like a minor patch. - Do Google employees, working on company time, automatically get treated as contributors with existing contributor agreements on file with the PSF? If so, are there are other companies that automatically get this treatment? - Should we change the workflow for roundup to make this assignment of license clearer (see Tobias's idea in the thread about a click-though agreement). In these matters, Jython, as a project under the Python Software Foundation, intends to follow the same policy as CPython. - Jim -- Forwarded message -- From: Frank Wierzbicki fwierzbi...@gmail.com Date: Wed, Apr 8, 2009 at 9:32 AM Subject: Re: [Jython-dev] Jython on Google AppEngine! To: James Robinson jam...@google.com Cc: Jython Developers jython-...@lists.sourceforge.net, Alan Kennedy jython-...@xhaus.com On Wed, Apr 8, 2009 at 11:22 AM, James Robinson jam...@google.com wrote: I submitted 1188 and I'm a Google employee working on company time. Let me know if anything further is needed, but we have quite a few contributors to the Python project working here. Excellent, and thanks! 1188 was already slated for inclusion in our upcoming RC, but knowing that it is in support of GAE moves it up to a very high priority. -Frank -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Jython-dev mailing list jython-...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jython-dev -- Jim Baker jba...@zyasoft.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping bytes support in json
We're in the process of forward-porting the recent (massive) json updates to 3.1, and we are also thinking of dropping remnants of support of the bytes type in the json library (in 3.1, again). This bytes support almost didn't work at all, but there was a lot of C and Python code for it nevertheless. We're also thinking of dropping the encoding argument in the various APIs, since it is useless. Under the new situation, json would only ever allow str as input, and output str as well. By posting here, I want to know whether anybody would oppose this (knowing, once again, that bytes support is already broken in the current py3k trunk). +1 Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributor Agreements for Patches - was [Jython-dev] Jython on Google AppEngine!
Oops, didn't attach the entire thread, so see below: On Wed, Apr 8, 2009 at 9:50 AM, Jim Baker jba...@zyasoft.com wrote: A question that arose on this thread, which I'm forwarding for context (and we're quite happy about it too!): - What is the scope of a patch that requires a contributor agreement? This particular patch on #1188 simply adds obvious (in retrospect of course) handling on SecurityException so that it's treated in a similar fashion to IOException (possibly a bit more buried), so it seems like a minor patch. - Do Google employees, working on company time, automatically get treated as contributors with existing contributor agreements on file with the PSF? If so, are there are other companies that automatically get this treatment? - Should we change the workflow for roundup to make this assignment of license clearer (see Tobias's idea in the thread about a click-though agreement). In these matters, Jython, as a project under the Python Software Foundation, intends to follow the same policy as CPython. - Jim Forwarded conversation Subject: [Jython-dev] Jython on Google AppEngine! From: *Alan Kennedy* jython-...@xhaus.com Date: Wed, Apr 8, 2009 at 6:37 AM To: Jython Developers jython-...@lists.sourceforge.net, jython users jython-us...@lists.sourceforge.net Hi all, As you may know, Google announced Java for AppEngine yesterday! http://googleappengine.blogspot.com/2009/04/seriously-this-time-new-language-on-app.html And they're also supporting all of the various languages that run on the JVM, including jython. http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine They say about jython - Jython 2.2 works out of the box. - Jython 2.5 requires patches which we'll supply until the changes make it directly into Jython: - jython-r5996-patched-for-appengine.jar is the complete jython binary library, patched for app engine - jython-r5996-appengine.patch is the patch file that contains the source code for the changes They provide the patches they used to make 2.5 work http://google-appengine-java.googlegroups.com/web/jython-r5996-appengine.patch I definitely think this is an important patch to consider for the 2.5RC! It would be nice if Google could say Jython 2.2 works out of the box, and jython 2.5 works out of the box. Alan. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Jython-dev mailing list jython-...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jython-dev -- From: *Tobias Ivarsson* tho...@gmail.com Date: Wed, Apr 8, 2009 at 8:18 AM To: Alan Kennedy jython-...@xhaus.com Cc: Jython Developers jython-...@lists.sourceforge.net Most things in that patch look ok. I'd like to do a more thorough analysis of the implications of each change though. The catching of SecurityException is fine, but I want to look at the places where they drop the exceptions that they caught in their context, and make sure that silently ignoring the exception is a valid approach. The other changes are few but slightly more controversial. Are Google willing to sign a contributors agreement and license this patch to us? otherwise someone who has not looked on it yet (i.e. not me), should probably experiment with Jython on GAE and find out what needs to be patched to get Jython to run there. /Tobias -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Jython-dev mailing list jython-...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jython-dev -- From: *Jim Baker* jba...@zyasoft.com Date: Wed, Apr 8, 2009 at 8:33 AM To: Alan Kennedy jython-...@xhaus.com Cc: Jython Developers jython-...@lists.sourceforge.net, jython users jython-us...@lists.sourceforge.net This is the same patch set requested in http://bugs.jython.org/issue1188: Patch against trunk to handle SecurityExceptions. Now we know the source of the request, and the specific application is very clear: a sandboxed Jython, running under a fairly strict security manager. The bug is a blocker for the release candidate, so this fix will be part of 2.5. We would love to see more work testing the full scope of environments Jython needs to run under, and any resulting bugs. - Jim -- Jim Baker jba...@zyasoft.com -- From: *James Robinson* jam...@google.com Date: Wed, Apr 8, 2009 at 8:30 AM To: Tobias Ivarsson tho...@gmail.com Cc: Jython Developers
[Python-Dev] Update PEP 374 (DVCS)
Someone listed this URL on c.l.py and I thought it would make a good reference addition to PEP 374 (DVCS decision): http://www.catb.org/~esr/writings/version-control/version-control.html -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ ...string iteration isn't about treating strings as sequences of strings, it's about treating strings as sequences of characters. The fact that characters are also strings is the reason we have problems, but characters are strings for other good reasons. --Aahz ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
On Wed, Apr 8, 2009 at 12:17 AM, Michele Simionato michele.simion...@gmail.com wrote: On Wed, Apr 8, 2009 at 8:10 AM, Jack diederich jackd...@gmail.com wrote: Plus he's a softie for decorators, as am I. This worries me a bit. There was a remark (though perhaps meant humorously) in Michele's page about decorators that worried me too: For instance, typical implementations of decorators involve nested functions, and we all know that flat is better than nested. I find the nested-function pattern very clear and easy to grasp, whereas I find using another decorator (a meta-decorator?) to hide this pattern unnecessarily obscuring what's going on. I also happen to disagree in many cases with decorators that attempt to change the signature of the wrapper function to that of the wrapped function. While this may make certain kinds of introspection possible, again it obscures what's going on to a future maintainer of the code, and the cleverness can get in the way of good old-fashioned debugging. I must admit that while I still like decorators, I do like them as much as in the past. I also see an overuse of decorators in various libraries for things that could be done more clearly without them ;-( Right. But this is tangential. (All this BTW is not to say that I don't trust you with commit privileges if you were to be interested in contributing. I just don't think that adding that particular decorator module to the stdlib would be wise. It can be debated though.) What I would really like to know is the future of PEP 362, i.e. having a signature object that could be taken from an undecorated function and added to the decorated function. I do not recall people having anything against it, in principle, and there is also an implementation in the sandbox, but after three years nothing happened. I guess this is just not a high priority for the core developers. That's likely true. To me, introspection is mostly useful for certain situations like debugging or interactively finding help, but I would hesitate to build a large amount of stuff (whether a library, framework or application) on systematic use of introspection. In fact, I rarely use the inspect module and had to type help(inspect) to figure out what you meant by signature. :-) I guess one reason is that in my mind, and in the way I tend to write code, I don't write APIs that require introspection -- for example, I don't like APIs that do different things when given a callable as opposed to something else (common practices in web frameworks notwithstanding), and thinking about it I would like it even less if an API cared about the *actual* signature of a function I pass into it. I like APIs that say, for example, argument 'f' must be a function of two arguments, an int and a string, and then I assume that if I pass it something for 'f' it will try to call that something with an int and a string. If I pass it something else, well, I'll get a type error. But it gives me the freedom to pass something that doesn't even have a signature but happens to be callable in that way regardless (e.g. a bound method of a built-in type). I will probably regret saying this. So be it. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] slightly inconsistent set/list pop behaviour
foo = set([1, 65537]) foo.pop() 1 foo = set([65537, 1]) foo.pop() 65537 You wrote a program to find the two smallest ints that would have a hash collision in the CPython set implementation? I'm impressed. And by impressed I mean frightened. Well, Mark is the guy who deals with floating point numbers for fun. *That* should frighten you :-) Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping bytes support in json
We're in the process of forward-porting the recent (massive) json updates to 3.1, and we are also thinking of dropping remnants of support of the bytes type in the json library (in 3.1, again). This bytes support almost didn't work at all, but there was a lot of C and Python code for it nevertheless. We're also thinking of dropping the encoding argument in the various APIs, since it is useless. Under the new situation, json would only ever allow str as input, and output str as well. By posting here, I want to know whether anybody would oppose this (knowing, once again, that bytes support is already broken in the current py3k trunk). What does Bob Ippolito think about this change? IIUC, he considers simplejson's speed one of its primary advantages, and also attributes it to the fact that he can parse directly out of byte strings, and marshal into them (which is important, as you typically receive them over the wire). Having to run them through a codec slows parsing down. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributor Agreements for Patches - was [Jython-dev] Jython on Google AppEngine!
* What is the scope of a patch that requires a contributor agreement? Unfortunately, that question was never fully answered (or I forgot what the answer was). * Do Google employees, working on company time, automatically get treated as contributors with existing contributor agreements on file with the PSF? Yes, they do. If so, are there are other companies that automatically get this treatment? Not that I know of. * Should we change the workflow for roundup to make this assignment of license clearer (see Tobias's idea in the thread about a click-though agreement). I think we do need something written; a lawyer may be able to tell precisely. I still hope that we can record, in the tracker, which contributors have signed an agreement. In these matters, Jython, as a project under the Python Software Foundation, intends to follow the same policy as CPython. Please keep pushing. From this message alone, I find two questions to the lawyer, and one (possibly two) feature requests for the bug tracker. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
At 10:51 AM 4/8/2009 -0700, Guido van Rossum wrote: I would like it even less if an API cared about the *actual* signature of a function I pass into it. One notable use of callable argument inspection is Bobo, the 12-years-ago predecessor to Zope, which used argument information to determine form or query string parameter names. (Were Bobo being written for the first time today for Python 3, I imagine it would use argument annotations to specify types, instead of requiring them to be in the client-side field names.) Bobo, of course, is just a single case of the general pattern of tools that expose a callable to some other (possibly explicitly-typed) system. E.g., wrapping Python functions for exposure to C, Java, .NET, CORBA, SOAP, etc. Anyway, it's nice for decorators to be transparent to inspection when the decorator doesn't actually modify the calling signature, so that you can then use your decorated functions with tools like the above. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Evaluated cmake as an autoconf replacement
On Wed, Apr 8, 2009 at 4:18 AM, David Cournapeau courn...@gmail.com wrote: ... I guess something similar could be useful for Python, maybe this is what distutils actually do ? distutils does roughly everything that autotools does, and more: - configuration: not often used in extensions, we (numpy) are the exception I would guess - build - installation - tarball generation - bdist_ installers (msi, .exe on windows, .pkg/.mpkg on mac os x, rpm/deb on Linux) I think cmake can do all of the above (cpack supports creating packages). - registration to pypi No idea what this is . Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Evaluated cmake as an autoconf replacement
- registration to pypi Alex No idea what this is . http://pypi.python.org/ It is, in some ways, a CPAN-like system for Python. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
P.J. Eby wrote: Anyway, it's nice for decorators to be transparent to inspection when the decorator doesn't actually modify the calling signature, so that you can then use your decorated functions with tools like the above. If anyone wanted to take PEP 362 up again, we could easily add a __signature__ attribute to functools.update_wrapper. It may be too late to hammer it into shape for 3.1/2.7 though (I don't recall how far the PEP was from being ready for prime time) . Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Deprecating PyOS_ascii_formatd
Assuming that Mark's and my changes in the py3k-short-float-repr branch get checked in shortly, I'd like to deprecate PyOS_ascii_formatd. Its functionality is largely being replaced by PyOS_double_to_string, which we're introducing on our branch. PyOS_ascii_formatd was introduced to fix the issue in PEP 331. PyOS_double_to_string addresses all of the same issues, namely a non-locale aware double-to-string conversion. PyOS_ascii_formatd has an unfortunate interface. It accepts a printf-like format string for a single double parameter. It must parse the format string into the parameters it uses. All uses of it inside Python already know the parameters and must build up a format string using sprintf, only to turn around and have PyOS_ascii_formatd reparse it. In the branch I've replaced all of the internal calls to PyOS_ascii_format with PyOS_double_to_string. My proposal is to deprecate PyOS_ascii_formatd in 3.1 and remove it in 3.2. The 2.7 situation is tricker, because we're not planning on backporting the short-float-repr work back to 2.7. In 2.7 I guess we'll leave PyOS_ascii_formatd around, unfortunately. FWIW, I didn't find any external callers of it using Google code search. And as a reminder, the py3k-short-float-repr changes are on Rietveld at http://codereview.appspot.com/33084/show. So far, no comments. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributor Agreements for Patches - was [Jython-dev] Jython on Google AppEngine!
On Wed, Apr 8, 2009 at 8:37 PM, Martin v. Löwis mar...@v.loewis.dewrote: --8-- * Should we change the workflow for roundup to make this assignment of license clearer (see Tobias's idea in the thread about a click-though agreement). I think we do need something written; a lawyer may be able to tell precisely. The company I work for does open source development. And our lawyers said that our model of having contributors send an e-mail with the text I agree and our CLA as an attachment was perfectly valid, no hand written signature needed. From there the step to a click through for something as simple as a patch isn't too far. But I would not claim that I know any of these things, I'm just hoping that we can have a simple process with no legal gray areas. I still hope that we can record, in the tracker, which contributors have signed an agreement. That would be good. Cheers, Tobias ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping bytes support in json
Martin v. Löwis martin at v.loewis.de writes: What does Bob Ippolito think about this change? IIUC, he considers simplejson's speed one of its primary advantages, and also attributes it to the fact that he can parse directly out of byte strings, and marshal into them (which is important, as you typically receive them over the wire). The only thing I know is that the new version (the one I've tried to merge) is massively faster than the old one - several times faster - and within 20-30% of the speed of the 2.x version (*). Besides, Bob doesn't really seem to care about porting to py3k (he hasn't said anything about it until now, other than that he didn't feel competent to do it). But I'm happy with someone proposing an alternate patch if they want to. As for me, I just wanted to fill the gap and I'm not interested in doing lot of work on this issue. (*) timeit -s import json; l=['abc']*100 json.dumps(l) - trunk: 33.4 usec per loop - py3k + patch: 37.1 usec per loop - vanilla py3k: 314 usec per loop timeit -s import json; s=json.dumps(['abc']*100) json.loads(s) - trunk: 44.8 usec per loop - py3k + patch: 35.4 usec per loop - vanilla py3k: 1.48 msec per loop (!) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping bytes support in json
On Wed, Apr 8, 2009 at 4:10 AM, Antoine Pitrou solip...@pitrou.net wrote: We're in the process of forward-porting the recent (massive) json updates to 3.1, and we are also thinking of dropping remnants of support of the bytes type in the json library (in 3.1, again). This bytes support almost didn't work at all, but there was a lot of C and Python code for it nevertheless. We're also thinking of dropping the encoding argument in the various APIs, since it is useless. Under the new situation, json would only ever allow str as input, and output str as well. By posting here, I want to know whether anybody would oppose this (knowing, once again, that bytes support is already broken in the current py3k trunk). The bug entry is: http://bugs.python.org/issue4136 I'm kind of surprised that a serialization protocol like JSON wouldn't support reading/writing bytes (as the serialized format -- I don't care about having bytes as values, since JavaScript doesn't have something equivalent AFAIK, and hence JSON doesn't allow it IIRC). Marshal and Pickle, for example, *always* treat the serialized format as bytes. And since in most cases it will be sent over a socket, at some point the serialized representation *will* be bytes, I presume. What makes supporting this hard? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Evaluated cmake as an autoconf replacement
On Thu, Apr 9, 2009 at 4:45 AM, Alexander Neundorf alex.neund...@kitware.com wrote: I think cmake can do all of the above (cpack supports creating packages). I am sure it is - it is just a lot of work, specially if you want to stay compatible with distutils-built extensions :) cheers, David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module in stdlib?
On Wed, Apr 8, 2009 at 7:51 PM, Guido van Rossum gu...@python.org wrote: There was a remark (though perhaps meant humorously) in Michele's page about decorators that worried me too: For instance, typical implementations of decorators involve nested functions, and we all know that flat is better than nested. I find the nested-function pattern very clear and easy to grasp, whereas I find using another decorator (a meta-decorator?) to hide this pattern unnecessarily obscuring what's going on. I understand your point and I will freely admit that I have always had mixed feelings about the advantages of a meta decorator with respect to plain simple nested functions. I see pros and contras. If functools.update_wrapper could preserve the signature I would probably use it over the decorator module. I also happen to disagree in many cases with decorators that attempt to change the signature of the wrapper function to that of the wrapped function. While this may make certain kinds of introspection possible, again it obscures what's going on to a future maintainer of the code, and the cleverness can get in the way of good old-fashioned debugging. Then perhaps you misunderstand the goal of the decorator module. The raison d'etre of the module is to PRESERVE the signature: update_wrapper unfortunately *changes* it. When confronted with a library which I do not not know, I often run over it pydoc, or sphinx, or a custom made documentation tool, to extract the signature of functions. For instance, if I see a method get_user(self, username) I have a good hint about what it is supposed to do. But if the library (say a web framework) uses non signature-preserving decorators, my documentation tool says to me that there is function get_user(*args, **kwargs) which frankly is not enough [this is the optimistic case, when the author of the decorator has taken care to preserve the name of the original function]. I *hate* losing information about the true signature of functions, since I also use a lot IPython, Python help, etc. I must admit that while I still like decorators, I do like them as much as in the past. Of course there was a missing NOT in this sentence, but you all understood the intended meaning. (All this BTW is not to say that I don't trust you with commit privileges if you were to be interested in contributing. I just don't think that adding that particular decorator module to the stdlib would be wise. It can be debated though.) Fine. As I have repeated many time that particular module was never meant for inclusion in the standard library. But I feel strongly about the possibility of being able to preserve (not change!) the function signature. To me, introspection is mostly useful for certain situations like debugging or interactively finding help, but I would hesitate to build a large amount of stuff (whether a library, framework or application) on systematic use of introspection. In fact, I rarely use the inspect module and had to type help(inspect) to figure out what you meant by signature. :-) I guess one reason is that in my mind, and in the way I tend to write code, I don't write APIs that require introspection -- for example, I don't like APIs that do different things when given a callable as opposed to something else (common practices in web frameworks notwithstanding), and thinking about it I would like it even less if an API cared about the *actual* signature of a function I pass into it. I like APIs that say, for example, argument 'f' must be a function of two arguments, an int and a string, and then I assume that if I pass it something for 'f' it will try to call that something with an int and a string. If I pass it something else, well, I'll get a type error. But it gives me the freedom to pass something that doesn't even have a signature but happens to be callable in that way regardless (e.g. a bound method of a built-in type). I do not think everybody disagree with your point here. My point still stands, though: objects should not lie about their signature, especially during debugging and when generating documentation from code. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping bytes support in json
Guido van Rossum guido at python.org writes:
I'm kind of surprised that a serialization protocol like JSON wouldn't
support reading/writing bytes (as the serialized format -- I don't
care about having bytes as values, since JavaScript doesn't have
something equivalent AFAIK, and hence JSON doesn't allow it IIRC).
Marshal and Pickle, for example, *always* treat the serialized format
as bytes. And since in most cases it will be sent over a socket, at
some point the serialized representation *will* be bytes, I presume.
What makes supporting this hard?
It's not hard, it just means a lot of duplicated code if the library wants to
support both str and bytes in an optimized way as Martin alluded to. This
duplicated code already exists in the C parts to support the 2.x semantics of
accepting unicode objects as well as str, but not in the Python parts, which
explains why the bytes support is broken in py3k - in 2.x, the same Python code
can be used for str and unicode.
On the other hand, supporting it without going after the last percents of
performance should be fairly trivial (by encoding/decoding before doing the
processing proper), and it would avoid the current duplicated code.
As for reading/writing bytes over the wire, JSON is often used in the same
context as HTML: you are supposed to know the charset and decode/encode the
payload using that charset. However, the RFC specifies a default encoding of
utf-8. (*)
(*) http://www.ietf.org/rfc/rfc4627.txt
The RFC also specifies a discrimination algorithm for non-supersets of ASCII
(“Since the first two characters of a JSON text will always be ASCII
characters [RFC0020], it is possible to determine whether an octet
stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking
at the pattern of nulls in the first four octets.”), but it is not
implemented in the json module:
json.loads('hi')
'hi'
json.loads(u'hi'.encode('utf16'))
Traceback (most recent call last):
File stdin, line 1, in module
File /home/antoine/cpython/__svn__/Lib/json/__init__.py, line 310, in loads
return _default_decoder.decode(s)
File /home/antoine/cpython/__svn__/Lib/json/decoder.py, line 344, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File /home/antoine/cpython/__svn__/Lib/json/decoder.py, line 362, in
raw_decode
raise ValueError(No JSON object could be decoded)
ValueError: No JSON object could be decoded
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping bytes support in json
Besides, Bob doesn't really seem to care about porting to py3k (he hasn't said anything about it until now, other than that he didn't feel competent to do it). That is quite unfortunate, and suggests that perhaps the module shouldn't have been added to Python in the first place. I can understand that you don't want to spend much time on it. How about removing it from 3.1? We could re-add it when long-term support becomes more likely. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
