[Python-Dev] Followup - Re: Bad python 2.5 build on OSX 10.8 mountain lion

Way back on 2012-10-05 23:45:11 GMT in article , I wrote: > In article , > Ned Deily wrote: > > In article <20121002073135.ga26...@sleipnir.bytereef.org>, > > Stefan Krah wrote: > > > Ned Deily wrote: > > > > > Forgot the link... > > > > > http://code.google.com/p/googleappengine/issues/deta

Re: [Python-Dev] Matching __all__ to doc: bugfix or enhancement?

On Thu, Mar 14, 2013 at 9:15 PM, Guido van Rossum wrote: > So it's a new feature, albeit a small one. I do see that it shouldn't > be backported, but I don't see any worries about doing it in 3.4. > Adding new functions/classes/constants to modules happens all the > time, and we never give a seco

Re: [Python-Dev] Matching __all__ to doc: bugfix or enhancement?

So it's a new feature, albeit a small one. I do see that it shouldn't be backported, but I don't see any worries about doing it in 3.4. Adding new functions/classes/constants to modules happens all the time, and we never give a second thought to users of import *. :-) On Thu, Mar 14, 2013 at 6:54

Re: [Python-Dev] Matching __all__ to doc: bugfix or enhancement?

On Thu, Mar 14, 2013 at 6:33 PM, Terry Reedy wrote: > The timeit doc describes four public attributes. > The current timeit.__all__ only lists one. > http://bugs.python.org/**issue17414 > proposes to expand __all__ to include all four: > -__all__ = ["Timer"] >

Re: [Python-Dev] Matching __all__ to doc: bugfix or enhancement?

On Thu, Mar 14, 2013 at 9:33 PM, Terry Reedy wrote: > Is the code change an all-version bugfix or a default-only enhancement? > I can see it both ways, but a decision is required to act. This is actually backward-incompatible, so should not be considered a simple bugfix. If determined to be desi

[Python-Dev] Matching __all__ to doc: bugfix or enhancement?

The timeit doc describes four public attributes. The current timeit.__all__ only lists one. http://bugs.python.org/issue17414 proposes to expand __all__ to include all four: -__all__ = ["Timer"] +__all__ = ["Timer", "timeit", "repeat", "default_timer"] The effect of the change is a) help(timit) w

Re: [Python-Dev] About issue 6560

On 3/14/2013 6:48 PM, "Martin v. Löwis" wrote: Am 14.03.13 15:15, schrieb Ani Sinha: I was looking into a mechanism to get the aux fields from recvmsg() in python and I came across this issue. Looks like this feature was added in python 3.3. Is there any reason why this feature was not added for

Re: [Python-Dev] Slides from today's parallel/async Python talk

On Thu, Mar 14, 2013 at 03:56:33PM -0700, "Martin v. Löwis" wrote: > Am 14.03.13 11:23, schrieb Trent Nelson: > > Porting the Py_PXCTX part is trivial compared to the work that is > > going to be required to get this stuff working on POSIX where none > > of the sublime Windows concur

Re: [Python-Dev] Slides from today's parallel/async Python talk

Am 14.03.13 12:59, schrieb Stefan Ring: I think you should be able to just take the address of a static __thread variable to achieve the same thing in a more portable way. That assumes that the compiler supports __thread variables, which isn't that portable in the first place. Regards, Martin

Re: [Python-Dev] Slides from today's parallel/async Python talk

On Thu, Mar 14, 2013 at 03:50:27PM -0700, "Martin v. Löwis" wrote: > Am 14.03.13 12:59, schrieb Stefan Ring: > > I think you should be able to just take the address of a static > > __thread variable to achieve the same thing in a more portable way. > > That assumes that the compiler supports __thr

Re: [Python-Dev] About issue 6560

Am 14.03.13 15:15, schrieb Ani Sinha: I was looking into a mechanism to get the aux fields from recvmsg() in python and I came across this issue. Looks like this feature was added in python 3.3. Is there any reason why this feature was not added for python 2.7? Most certainly: Python 2.7 (and t

Re: [Python-Dev] Slides from today's parallel/async Python talk

Am 14.03.13 11:23, schrieb Trent Nelson: ARM CPUs don't have segment registers because they have a simpler addressing model. The register CP15 came up after a couple of Google searches. Noted, thanks! Yeah that's my general sentiment too. I'm definitely curious to see if other

Re: [Python-Dev] Slides from today's parallel/async Python talk

On Thu, Mar 14, 2013 at 12:59:57PM -0700, Stefan Ring wrote: > > Yup, in fact, if I hadn't come up with the __read[gf]sword() trick, > > my only other option would have been TLS (or the GetCurrentThreadId > > /pthread_self() approach in the presentation). TLS is fantastic, > > and

[Python-Dev] About issue 6560

Hi : I was looking into a mechanism to get the aux fields from recvmsg() in python and I came across this issue. Looks like this feature was added in python 3.3. Is there any reason why this feature was not added for python 2.7? I am now trying to backport the patch to python 2.7. any insight int

Re: [Python-Dev] Slides from today's parallel/async Python talk

On Thu, Mar 14, 2013 at 02:30:14PM -0700, Trent Nelson wrote: > Then it dawned on me to just add the snapshot/rollback stuff to > normal Context objects. In retrospect, it's silly I didn't think of > this in the first place -- the biggest advantage of the Context > abstraction is t

Re: [Python-Dev] Slides from today's parallel/async Python talk

Cross-referenced to relevant bits of code where appropriate. (And just a quick reminder regarding the code quality disclaimer: I've been hacking away on this stuff relentlessly for a few months; the aim has been to make continual forward progress without getting bogged down in

Re: [Python-Dev] Slides from today's parallel/async Python talk

> Yup, in fact, if I hadn't come up with the __read[gf]sword() trick, > my only other option would have been TLS (or the GetCurrentThreadId > /pthread_self() approach in the presentation). TLS is fantastic, > and it's definitely an intrinsic part of the solution (the "Y" part >

Re: [Python-Dev] Slides from today's parallel/async Python talk

On Wed, Mar 13, 2013 at 07:05:41PM -0700, Trent Nelson wrote: > Just posted the slides for those that didn't have the benefit of > attending the language summit today: > > > https://speakerdeck.com/trent/parallelizing-the-python-interpreter-an-alternate-approach-to-async Some

Re: [Python-Dev] Slides from today's parallel/async Python talk

On Thu, Mar 14, 2013 at 05:21:09AM -0700, Christian Heimes wrote: > Am 14.03.2013 03:05, schrieb Trent Nelson: > > Just posted the slides for those that didn't have the benefit of > > attending the language summit today: > > > > > > https://speakerdeck.com/trent/parallelizing-the-

Re: [Python-Dev] VC++ 2008 Express Edition now locked away?

Am 07.03.13 09:53, schrieb Steve Dower: To use the SDK compiler, you need to do a few manual steps first. After starting a command window, you need to run a batch file to configure your environment. Choose the appropriate option from C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\vcv

Re: [Python-Dev] Slides from today's parallel/async Python talk

By the way on the arm (and any platform that can do cross-compiling) I've created a Makefile based build of the python 2.7.x: https://bitbucket.org/cavallo71/android Please don't be fooled by the Android name, it really can take any crosscompiler (provided it follows the gcc synatx). It wa

Re: [Python-Dev] Slides from today's parallel/async Python talk

Le Thu, 14 Mar 2013 13:21:09 +0100, Christian Heimes a écrit : > > IMHO you should target x86, x86_64, ARMv6 and ARMv7. ARMv7 is going to > be more important than x86 in the future. We are going to see more > ARM based servers. Well we can't really see less of them, since there are hardly any ;

Re: [Python-Dev] Slides from today's parallel/async Python talk

Am 14.03.2013 03:05, schrieb Trent Nelson: > Just posted the slides for those that didn't have the benefit of > attending the language summit today: > > > https://speakerdeck.com/trent/parallelizing-the-python-interpreter-an-alternate-approach-to-async Wow, neat! Your idea with P