+zlib
+
+
+The :mod:`zlib` extension is built using an included copy of the zlib
+sources unless the zlib version found on the system is too old to be
+used for the build::
Unless or if? Building with an included copy *if* the system one is too
old makes sense to me, not the contrary. Am I n
> That said, looking at the PEP, I was wondering whether fields such as
> ob_type, ob_refcnt, ob_size have to be directly accessible, rather than
> through a macro-turned-into-a-function such as Py_REFCNT().
That they are macros still is primarily for performance reasons. For
ob_type, that may be
On 9/7/2010 11:37 AM, R. David Murray wrote:
> On Tue, 07 Sep 2010 18:34:49 +0400, Oleg Broytman wrote:
>> On Tue, Sep 07, 2010 at 02:02:59PM -, exar...@twistedmatrix.com wrote:
>>> On 01:33 pm, p...@phd.pp.ru wrote:
As there is already Python 3.2 alpha, the core of Python has already
>
On Sun, 12 Sep 2010 19:38:33 +0200
"Martin v. Löwis" wrote:
> > On http://bugs.python.org/issue9778 you elaborated on what the PEP would
> > entail in its current state:
> >
> > “No, vice versa. The PEP promises that the ABI won't change until
> > Python 4. For any change that might break the ABI
> On http://bugs.python.org/issue9778 you elaborated on what the PEP would
> entail in its current state:
>
> “No, vice versa. The PEP promises that the ABI won't change until
> Python 4. For any change that might break the ABI, either a
> backwards-compatible solution needs to be found, or the ch
2010/9/12 Georg Brandl :
> Victor changed this from "return NULL" to "goto fail" in r84730, claiming
> that it would fix a reference leak. Is the leak somewhere else then?
Indeed. He missed my earlier fix, though. :)
--
Regards,
Benjamin
___
Python-
> If it's useful on unix like systems, why shouldn't it be useful on
> windows? Multiple versions of python can be installed on windows
> too. And people might also like to share their packages between
> installations.
Multiple versions of Python install into distinct directories, so
extension mod
Victor changed this from "return NULL" to "goto fail" in r84730, claiming
that it would fix a reference leak. Is the leak somewhere else then?
Georg
Am 12.09.2010 18:40, schrieb benjamin.peterson:
> Author: benjamin.peterson
> Date: Sun Sep 12 18:40:53 2010
> New Revision: 84744
>
> Log:
> use
On 9/7/2010 10:15 AM, Michael Foord wrote:
> On 07/09/2010 15:02, exar...@twistedmatrix.com wrote:
>> On 01:33 pm, p...@phd.pp.ru wrote:
>>> Hello. Thank you for the offer!
>>>
>>> On Tue, Sep 07, 2010 at 06:36:10PM +0530, Prashant Kumar wrote:
My name is Prashant Kumar and I wish to contribu
Am 07.09.2010 19:48, schrieb M.-A. Lemburg:
> "Martin v. Löwis" wrote:
>>
>>> This sounds like the issues such a mix can cause are mostly
>>> theoretical and don't really bother much in practice, so
>>> PEP 384 on Windows does have a chance :-)
>>
>> Actually, the CRT issues (FILE* in particular) h
> I only mandated ./configure-based builds to be PEP 3149 conforming. I have no
> objection to expanding the PEP to include Windows builds, but I'm not sure
> it's necessary and it would take a Windows build expert to make and test those
> changes.
>
> Does PEP 3149 have any advantage for Windows
Am 07.09.2010 19:46, schrieb M.-A. Lemburg:
> "Martin v. Löwis" wrote:
>>> -1 on always using wchar_t as well. Python's default is UCS2 and the
>>> stable ABI should not change that.
>>
>> It's not really Python's default. It is what configure.in does by
>> default. Python's default, on Linux, is U
On Sun, 12 Sep 2010 06:12:42 +0200 (CEST)
raymond.hettinger wrote:
>
> -# Each link is stored as a list of length three: [PREV, NEXT, KEY].
> +# The back links are weakref proxies (to prevent circular references).
Are you sure this prevents anything? Since your list is circular,
forward
>> I think that people whose alphabet is for example Cyrillic already use a
>> Latin transliteration in those files, so it’s good.
> At present, such people have no choice ;-).
Right :) So the new policy of real name thanks to UTF-8 + ASCII
transliteration is a superset of the existing conditions
14 matches
Mail list logo