Re: [Python-Dev] Packaging and binary distributions for Python 3.3
On Sat, Oct 15, 2011 at 4:42 AM, Paul Moore wrote: > I wish I felt more comfortable with MSI as a format (as opposed to an > opaque clickable installer). I'd be interested to know what others > think. Compilation can be a problem on Linux systems as well, so a platform neutral format is a better idea. Just have a mechanism that allows pysetup to create a bdist_msi from a bdist_simple. Similar, bdist_rpm and bdist_deb plugins could be taught to interpret bdist_simple. However, you do get into architecture problems (x86 vs x86_64 vs ARM) if you go that route. 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
Re: [Python-Dev] Packaging and binary distributions for Python 3.3
On 15 October 2011 09:04, Nick Coghlan wrote: > On Sat, Oct 15, 2011 at 4:42 AM, Paul Moore wrote: >> I wish I felt more comfortable with MSI as a format (as opposed to an >> opaque clickable installer). I'd be interested to know what others >> think. > > Compilation can be a problem on Linux systems as well, so a platform > neutral format is a better idea. Just have a mechanism that allows > pysetup to create a bdist_msi from a bdist_simple. Similar, bdist_rpm > and bdist_deb plugins could be taught to interpret bdist_simple. > > However, you do get into architecture problems (x86 vs x86_64 vs ARM) > if you go that route. Architecture problems are an issue for any binary format, surely? It's the content (the binaries themselves) that are architecture dependent, not the format itself. 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] Identifier API
PyObject *tmp; Py_identifier(update); As I understand it, the macro expands to both the ID variable declaration and the init-at-first-call code, right? No. The variable will only get static initialization with the char*. The initialization on first call (of the PyObject*) happens in the helper functions, such as PyObject_GetAttrId. I'm not sure how often users will need more than one identifier in a function That's actually fairly common. Also note that existing code needs to be changed in order to take advantage of this. It might be possible to optimise PyObject_CallMethod() internally by making the lookup either reuse a number of cached Python strings, or by supporting a lookup of char* values in a dict *somehow*. However, this appears to be substantially more involved than just moving a smaller burden on the users. I think this would have to hash the string in any case, since keying by char* pointer value cannot work (there might be a different string at the same memory the next time). So even if this could side-step many of the steps, you'd keep at least one iteration over the characters; if this is hashing, you actually need two iterations (the second one to determine whether it's the right string). The Py_IDENTIFIER API can do the lookup in constant time for all but the first call. 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 (2.7): Issue #13156: revert changeset f6feed6ec3f9, which was only relevant for native
-- Issue #10517: After fork(), reinitialize the TLS used by the PyGILState_* - APIs, to avoid a crash with the pthread implementation in RHEL 5. Patch - by Charles-François Natali. You should restore this NEWS entry and add a new one to say that the patch has been reverted. This may be a done deal, but: no. If a patch is reverted, the NEWS entry that got in with it gets out again on reversal. The NEWS file is for users of the release; there is no point telling them that a change was made first, and than got undone. 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 (2.7): Issue #13156: revert changeset f6feed6ec3f9, which was only relevant for native
On 10/15/2011 7:47 AM, "Martin v. Löwis" wrote: -- Issue #10517: After fork(), reinitialize the TLS used by the PyGILState_* - APIs, to avoid a crash with the pthread implementation in RHEL 5. Patch - by Charles-François Natali. You should restore this NEWS entry and add a new one to say that the patch has been reverted. This may be a done deal, but: no. If a patch is reverted, the NEWS entry that got in with it gets out again on reversal. The NEWS file is for users of the release; there is no point telling them that a change was made first, and than got undone. I was going to say the same thing, but ... If a change is released in x.y.z and reverted for release x.y.(z+k), then I think both notices should be present in their respective sections. I checked the date on the original patch and it was before 3.2.1, so perhaps it *was* released. -- Terry Jan Reedy ___ 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] check for PyUnicode_READY look backwards
On 10/7/2011 7:13 PM, Terry Reedy wrote: > On 10/7/2011 10:06 AM, Nick Coghlan wrote: >> FWIW, I don't mind whether it's "< 0" or "== -1", so long as there's a >> comparison there to kick my brain out of Python boolean logic mode. > > Is there any speed difference (on common x86/64 processors and > compilers)? I would expect that '< 0' should be optimized to just check > the sign bit and 'if n < 0' to 'load n; jump-non-negative'. > There are several different ways to express those operators depending on the context. If "n" is worth moving into a register, then "<0" will get to use a "test" and it's fewer instruction bytes than a "cmp", but otherwise, it is no better. So, there is a very special case where "<0" is better, but I think you'd be hard-pressed to measure it against the noise. -- Scott Dial sc...@scottdial.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
