Re: [Python-Dev] Preparation for VS2010 - MSDN for Windows build slaves, core devs
If build slave owners could let me know when their machine has VS2010 I'd appreciate it. I got the go-ahead to commit the port but want to wait until the build slaves are ready for it. Please don't wait, but let the build slaves break. This is getting urgent. 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] [Python-checkins] cpython: Issue #14779: Do not use get_config_var('SIZEOF_VOID_P') on OS X 64-/32-bit
-self.sizeof_void_p = get_config_var('SIZEOF_VOID_P') +self.sizeof_void_p = get_config_var('SIZEOF_VOID_P') \ +if sys.platform != 'darwin' else None if not self.sizeof_void_p: -self.sizeof_void_p = 8 if architecture()[0] == '64bit' else 4 +self.sizeof_void_p = 8 if sys.maxsize> 2**32 else 4 Why not unconditionally use sys.maxsize? I'd also hard-code that sys.maxsize ought to be either 2**31-1 or 2**63-1. 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] [Python-checkins] cpython: Issue #14779: Do not use get_config_var('SIZEOF_VOID_P') on OS X 64-/32-bit
"Martin v. L?wis" wrote: [http://bugs.python.org/issue14779] >> -self.sizeof_void_p = get_config_var('SIZEOF_VOID_P') >> +self.sizeof_void_p = get_config_var('SIZEOF_VOID_P') \ >> +if sys.platform != 'darwin' else None >> if not self.sizeof_void_p: >> -self.sizeof_void_p = 8 if architecture()[0] == '64bit' else 4 >> +self.sizeof_void_p = 8 if sys.maxsize> 2**32 else 4 >> > > Why not unconditionally use sys.maxsize? Because the tests need sizeof(void *). In an array with suboffsets void pointers are embedded at the start of the array. The C standard doesn't guarantee sizeof(void *) == sizeof(size_t). In fact, there are machines where sizeof(void *) > sizeof(size_t): http://comments.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/651 http://www-01.ibm.com/support/docview.wss?uid=swg27019425 If you change pyconfig.h to 128 bit pointers while leaving sizeof(size_t) and sizeof(ssize_t) at 8, pyport.h by itself doesn't catch the mismatch. /* The size of `uintptr_t', as computed by sizeof. */ #define SIZEOF_UINTPTR_T 16 /* The size of `void *', as computed by sizeof. */ #define SIZEOF_VOID_P 16 However, now that I tried to compile Python with that pyconfig.h, longobject.c *does* catch it: Objects/longobject.c:943:5: error: #error "PyLong_FromVoidPtr: sizeof(PY_LONG_LONG) < sizeof(void*)" Objects/longobject.c:970:5: error: #error "PyLong_AsVoidPtr: sizeof(PY_LONG_LONG) < sizeof(void*)" If sizeof(void *) == sizeof(size_t) is the general assumption for compiling Python, I think the test should happen prominently in either pyport.h or Python.h. > I'd also hard-code that sys.maxsize ought to be either 2**31-1 or 2**63-1. I would have done exactly that, but the example in the docs that was quoted to me in the issue uses > 2**32: http://docs.python.org/dev/library/platform.html Stefan Krah ___ 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] WSGI paranoia with stdout/stderr
There is fear and uncertainty in this pull request to PyPI - https://bitbucket.org/techtonik/pypi-techtonik/changeset/5396f8c60d49#comment-18915 - which is about that writing to stderr _might_ break things in WSGI applications. As a consequence logging to console will not be accepted in debug mode, which is disappointing, but not as disappointing as the absence of proper explanation. Martin couldn't provide any grounds for his fears, so I am asking fellow Python developers if anybody remember "if writing to stderr can break things in generic WSGI application" and reassure Martin that everything will be ok. -- anatoly 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] WSGI paranoia with stdout/stderr
On Sun, 13 May 2012 14:02:50 +0300 anatoly techtonik wrote: > There is fear and uncertainty in this pull request to PyPI - > https://bitbucket.org/techtonik/pypi-techtonik/changeset/5396f8c60d49#comment-18915 > - which is about that writing to stderr _might_ break things in WSGI > applications. > > As a consequence logging to console will not be accepted in debug > mode, which is disappointing, but not as disappointing as the absence > of proper explanation. Martin couldn't provide any grounds for his > fears, so I am asking fellow Python developers if anybody remember "if > writing to stderr can break things in generic WSGI application" and > reassure Martin that everything will be ok. According to this blog post, writing to stderr is fine (stdout is not): http://blog.dscpl.com.au/2009/04/wsgi-and-printing-to-standard-output.html 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] WSGI paranoia with stdout/stderr
Am 13.05.2012 13:09, schrieb Antoine Pitrou: > On Sun, 13 May 2012 14:02:50 +0300 > anatoly techtonik wrote: >> There is fear and uncertainty in this pull request to PyPI - >> https://bitbucket.org/techtonik/pypi-techtonik/changeset/5396f8c60d49#comment-18915 >> - which is about that writing to stderr _might_ break things in WSGI >> applications. >> >> As a consequence logging to console will not be accepted in debug >> mode, which is disappointing, but not as disappointing as the absence >> of proper explanation. Martin couldn't provide any grounds for his >> fears, so I am asking fellow Python developers if anybody remember "if >> writing to stderr can break things in generic WSGI application" and >> reassure Martin that everything will be ok. > > According to this blog post, writing to stderr is fine (stdout is not): > http://blog.dscpl.com.au/2009/04/wsgi-and-printing-to-standard-output.html Whether yes or no, this topic doesn't belong to python-dev: it's either for python-list or the web-SIG. Georg ___ 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] void* <-> size_t
On 13.05.12 12:48, Stefan Krah wrote: The C standard doesn't guarantee sizeof(void *) == sizeof(size_t). In fact, there are machines where sizeof(void *)> sizeof(size_t): http://comments.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/651 http://www-01.ibm.com/support/docview.wss?uid=swg27019425 I noticed recently that the code is often used unsafe casting void* -> size_t and size_t -> void*. For example: const char *aligned_end = (const char *) ((size_t) end & ~LONG_PTR_MASK); I defer this issue until issues 14624 and 14624 will be resolved (same method is used in the suggested patches), but once it already mentioned, should be replaced size_t to Py_uintptr_t in all such castings? ___ 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] Preparation for VS2010 - MSDN for Windows build slaves, core devs
On Sun, May 13, 2012 at 2:30 AM, wrote: >> If build slave owners could let me know when their machine has VS2010 >> I'd appreciate it. I got the go-ahead to commit the port but want to >> wait until the build slaves are ready for it. > > > Please don't wait, but let the build slaves break. This is getting urgent. Pushed the port in http://hg.python.org/cpython/rev/38d7d944370e ___ 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