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 mar...@v.loewis.de 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 techto...@gmail.com 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 techto...@gmail.com 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, mar...@v.loewis.de 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
