Re: [Python-Dev] decorator module in stdlib?
On Wed, Apr 8, 2009 at 8:10 AM, Jack diederich 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 [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] http://bugs.python.org/issue2240
On Wed, Apr 8, 2009 at 3:55 PM, Jeroen Ruigrok van der Werven < [email protected]> wrote: > -On [20090408 05:24], Tennessee Leeuwenburg ([email protected]) > wrote: > >It seems like the bug relates only to an older version of a 'weird' > >operating system 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 [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] slightly inconsistent set/list pop behaviour
On Wed, Apr 8, 2009 at 2:44 AM, Mark Dickinson wrote: > On Wed, Apr 8, 2009 at 7:13 AM, John Barham 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 [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] slightly inconsistent set/list pop behaviour
Jack diederich wrote: > On Wed, Apr 8, 2009 at 2:44 AM, Mark Dickinson wrote: >> On Wed, Apr 8, 2009 at 7:13 AM, John Barham 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 [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] slightly inconsistent set/list pop behaviour
Andrea Griffini wrote: > On Wed, Apr 8, 2009 at 12:57 PM, Jack diederich > 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 [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] slightly inconsistent set/list pop behaviour
Mark Dickinson gmail.com> writes: > > On Wed, Apr 8, 2009 at 7:13 AM, John Barham 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 [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] slightly inconsistent set/list pop behaviour
On Wed, Apr 8, 2009 at 12:57 PM, Jack diederich 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 [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] 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 [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] 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 [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] slightly inconsistent set/list pop behaviour
2009/4/8 Duncan Booth : > Andrea Griffini wrote: > >> On Wed, Apr 8, 2009 at 12:57 PM, Jack diederich >> 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 [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] slightly inconsistent set/list pop behaviour
Paul Moore wrote: > 2009/4/8 Duncan Booth : >> Andrea Griffini wrote: >> >>> On Wed, Apr 8, 2009 at 12:57 PM, Jack diederich >>> 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 [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] slightly inconsistent set/list pop behaviour
2009/4/8 Steve Holden : > Paul Moore wrote: >> 2009/4/8 Duncan Booth : >>> Andrea Griffini wrote: >>> On Wed, Apr 8, 2009 at 12:57 PM, Jack diederich 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 [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] 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 Date: Wed, Apr 8, 2009 at 9:32 AM Subject: Re: [Jython-dev] Jython on Google AppEngine! To: James Robinson Cc: Jython Developers , Alan Kennedy < [email protected]> On Wed, Apr 8, 2009 at 11:22 AM, James Robinson 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 [email protected] https://lists.sourceforge.net/lists/listinfo/jython-dev -- Jim Baker [email protected] ___ 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] 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 [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] 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 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* Date: Wed, Apr 8, 2009 at 6:37 AM To: Jython Developers , jython users < [email protected]> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/jython-dev -- From: *Tobias Ivarsson* Date: Wed, Apr 8, 2009 at 8:18 AM To: Alan Kennedy Cc: Jython Developers 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 [email protected] https://lists.sourceforge.net/lists/listinfo/jython-dev -- From: *Jim Baker* Date: Wed, Apr 8, 2009 at 8:33 AM To: Alan Kennedy Cc: Jython Developers , jython users < [email protected]> 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 [email protected] -- From: *James Robinson* Date: Wed, Apr 8, 2009 at 8:30 AM To: Tobias Ivarsson Cc: Jython Developers , Alan Kennedy < [email protected]> I have a patch up on your issue tracker already, I'll ping it shortly. It's a very small patch and the SecurityExceptions that are caught and ignored are treated the same as
[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 ([email protected]) <*> 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 [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] decorator module in stdlib?
On Wed, Apr 8, 2009 at 12:17 AM, Michele Simionato wrote: > On Wed, Apr 8, 2009 at 8:10 AM, Jack diederich 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 [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] 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 [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] 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 [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] 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 [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] 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 [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] Evaluated cmake as an autoconf replacement
On Wed, Apr 8, 2009 at 4:18 AM, David Cournapeau 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 [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] 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 [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] 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 | [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
[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 [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] Contributor Agreements for Patches - was [Jython-dev] Jython on Google AppEngine!
On Wed, Apr 8, 2009 at 8:37 PM, "Martin v. Löwis" wrote: --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 [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] Dropping bytes "support" in json
Martin v. Löwis 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 [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] Dropping bytes "support" in json
On Wed, Apr 8, 2009 at 4:10 AM, Antoine Pitrou 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 [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] Evaluated cmake as an autoconf replacement
On Thu, Apr 9, 2009 at 4:45 AM, Alexander Neundorf 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 [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] decorator module in stdlib?
On Wed, Apr 8, 2009 at 7:51 PM, Guido van Rossum 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 [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] Dropping bytes "support" in json
Guido van Rossum 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 "", line 1, in
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
[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] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
