From christian at python.org  Sun Dec  1 02:53:32 2013
From: christian at python.org (Christian Heimes)
Date: Sun, 01 Dec 2013 02:53:32 +0100
Subject: [Python-Dev] Verification of SSL cert and hostname made easy
In-Reply-To: <20131130235117.622994e5@fsol>
References: <l7daq6$r5c$1@ger.gmane.org> <20131130235117.622994e5@fsol>
Message-ID: <529A969C.90908@python.org>

Am 30.11.2013 23:51, schrieb Antoine Pitrou:
> Small nit: what happens if the server_hostname is None (i.e. wasn't
> passed to context.wrap_socket())?

The code will raise an exception. My patch already implements a more
verbose ValueError that explains the cause of the problem. It's flaw in
code, that calls context.wrap_socket. Erroneous code will no longer pass
silently.

The patch also ensures a valid combination of verify_mode and
check_hostname:

>>> context = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
>>> context.check_hostname = True
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: check_hostname needs a SSL context with either CERT_OPTIONAL
or CERT_REQUIRED
>>> context.verify_mode = ssl.CERT_REQUIRED
>>> context.check_hostname = True
>>> context.verify_mode = ssl.CERT_NONE
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Cannot set verify_mode to CERT_NONE when check_hostname is
enabled.


It's only a limitation of the Python API, getpeercert() returns {} for
an unverified cert. OpenSSL can still returns the cert, though.

Christian

From solipsis at pitrou.net  Sun Dec  1 11:37:01 2013
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 1 Dec 2013 11:37:01 +0100
Subject: [Python-Dev] Verification of SSL cert and hostname made easy
In-Reply-To: <529A969C.90908@python.org>
References: <l7daq6$r5c$1@ger.gmane.org> <20131130235117.622994e5@fsol>
 <529A969C.90908@python.org>
Message-ID: <20131201113701.18f1aa65@fsol>

On Sun, 01 Dec 2013 02:53:32 +0100
Christian Heimes <christian at python.org> wrote:
> Am 30.11.2013 23:51, schrieb Antoine Pitrou:
> > Small nit: what happens if the server_hostname is None (i.e. wasn't
> > passed to context.wrap_socket())?
> 
> The code will raise an exception. My patch already implements a more
> verbose ValueError that explains the cause of the problem. It's flaw in
> code, that calls context.wrap_socket. Erroneous code will no longer pass
> silently.
> 
> The patch also ensures a valid combination of verify_mode and
> check_hostname:
> 
> >>> context = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
> >>> context.check_hostname = True
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ValueError: check_hostname needs a SSL context with either CERT_OPTIONAL
> or CERT_REQUIRED
> >>> context.verify_mode = ssl.CERT_REQUIRED
> >>> context.check_hostname = True
> >>> context.verify_mode = ssl.CERT_NONE
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ValueError: Cannot set verify_mode to CERT_NONE when check_hostname is
> enabled.

So I have to set attributes in a given order? I find this silly.

Regards

Antoine.

From ncoghlan at gmail.com  Sun Dec  1 12:33:06 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 1 Dec 2013 21:33:06 +1000
Subject: [Python-Dev] Verification of SSL cert and hostname made easy
In-Reply-To: <20131201113701.18f1aa65@fsol>
References: <l7daq6$r5c$1@ger.gmane.org> <20131130235117.622994e5@fsol>
 <529A969C.90908@python.org> <20131201113701.18f1aa65@fsol>
Message-ID: <CADiSq7dAXBvDAdrPzXN35_8-CUGHxc9TEcC0JzhbbTi08M8M2g@mail.gmail.com>

On 1 December 2013 20:37, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 01 Dec 2013 02:53:32 +0100
> Christian Heimes <christian at python.org> wrote:
>> Am 30.11.2013 23:51, schrieb Antoine Pitrou:
>> > Small nit: what happens if the server_hostname is None (i.e. wasn't
>> > passed to context.wrap_socket())?
>>
>> The code will raise an exception. My patch already implements a more
>> verbose ValueError that explains the cause of the problem. It's flaw in
>> code, that calls context.wrap_socket. Erroneous code will no longer pass
>> silently.
>>
>> The patch also ensures a valid combination of verify_mode and
>> check_hostname:
>>
>> >>> context = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
>> >>> context.check_hostname = True
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>> ValueError: check_hostname needs a SSL context with either CERT_OPTIONAL
>> or CERT_REQUIRED
>> >>> context.verify_mode = ssl.CERT_REQUIRED
>> >>> context.check_hostname = True
>> >>> context.verify_mode = ssl.CERT_NONE
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>> ValueError: Cannot set verify_mode to CERT_NONE when check_hostname is
>> enabled.
>
> So I have to set attributes in a given order? I find this silly.

Perhaps a cleaner option would be to make check_hostname read only,
and add a secure-by-default method that allows all verification
related settings to be adjusted at once:

    def set_verify_mode(mode=ssl.CERT_REQUIRED, check_hostname=True):
        ...

That way the consistency check would be directly on the method
arguments, rather than involving the current context state. Any future
settings that required a verified cert could then use a similar model.

If we don't do that, then I think Christian's approach is a reasonable
compromise given the late stage of the release cycle - it ensures the
context can't get into the inconsistent verify_mode=CERT_NONE and
check_hostname=True state, and leaves our options completely open for
3.5:

- add a "configure all security related settings at once"
set_verify_mode method as suggested above
- allow the context to get into an inconsistent state, check it in
wrap_socket (bad due to point of exception != point of error)
- have setting check_hostname potentially affect verify_mode and
vice-versa (bad due to being implicit magic)

We wouldn't be able to make check_hostname read-only the way we would
if we added the configuration method now, but that doesn't bother me
that much as long as the setting consistency invariant is enforced.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From solipsis at pitrou.net  Sun Dec  1 12:40:10 2013
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 1 Dec 2013 12:40:10 +0100
Subject: [Python-Dev] Verification of SSL cert and hostname made easy
In-Reply-To: <CADiSq7dAXBvDAdrPzXN35_8-CUGHxc9TEcC0JzhbbTi08M8M2g@mail.gmail.com>
References: <l7daq6$r5c$1@ger.gmane.org> <20131130235117.622994e5@fsol>
 <529A969C.90908@python.org> <20131201113701.18f1aa65@fsol>
 <CADiSq7dAXBvDAdrPzXN35_8-CUGHxc9TEcC0JzhbbTi08M8M2g@mail.gmail.com>
Message-ID: <20131201124010.41bb781d@fsol>

On Sun, 1 Dec 2013 21:33:06 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> If we don't do that, then I think Christian's approach is a reasonable
> compromise given the late stage of the release cycle - it ensures the
> context can't get into the inconsistent verify_mode=CERT_NONE and
> check_hostname=True state, and leaves our options completely open for
> 3.5:

I would prefer the check to be made when the the socket is created,
i.e. the wrap_socket() call.

Regards

Antoine.

From ncoghlan at gmail.com  Sun Dec  1 12:54:59 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 1 Dec 2013 21:54:59 +1000
Subject: [Python-Dev] Verification of SSL cert and hostname made easy
In-Reply-To: <20131201124010.41bb781d@fsol>
References: <l7daq6$r5c$1@ger.gmane.org> <20131130235117.622994e5@fsol>
 <529A969C.90908@python.org> <20131201113701.18f1aa65@fsol>
 <CADiSq7dAXBvDAdrPzXN35_8-CUGHxc9TEcC0JzhbbTi08M8M2g@mail.gmail.com>
 <20131201124010.41bb781d@fsol>
Message-ID: <CADiSq7e87088f9SmoVCOpJYXmqW9CUNC-OPsVyg_R02=VPNm9w@mail.gmail.com>

On 1 December 2013 21:40, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 1 Dec 2013 21:33:06 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> If we don't do that, then I think Christian's approach is a reasonable
>> compromise given the late stage of the release cycle - it ensures the
>> context can't get into the inconsistent verify_mode=CERT_NONE and
>> check_hostname=True state, and leaves our options completely open for
>> 3.5:
>
> I would prefer the check to be made when the the socket is created,
> i.e. the wrap_socket() call.

That was my initial reaction, but then I realised it creates a
situation where the exception is raised at a point that differs from
the source of the error (the bug is in the way the context was
configured, but the exception won't be thrown until you actually try
to wrap a socket). So I now agree with Christian that it's better to
prevent the creation of the internally inconsistent SSL context in the
first place, rather than delaying the detection of the inconsistency
until the context is actually used.

I think a read-only attribute and a combined setter method is a better
way to achieve that (since it avoids the quirky "order of setting
attributes matters" behaviour), but I'm also OK with  read/write
properties that internally enforce of the state invariant.

If we decide the invariant enforcement in 3.4 is too strict, we can
change our minds and relax things in 3.5. By contrast, if we allow the
invariant to be broken in 3.4, we're locked in by backwards
compatibility concerns and can't change our minds in the future.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From christian at python.org  Sun Dec  1 17:55:07 2013
From: christian at python.org (Christian Heimes)
Date: Sun, 01 Dec 2013 17:55:07 +0100
Subject: [Python-Dev] Verification of SSL cert and hostname made easy
In-Reply-To: <CADiSq7dAXBvDAdrPzXN35_8-CUGHxc9TEcC0JzhbbTi08M8M2g@mail.gmail.com>
References: <l7daq6$r5c$1@ger.gmane.org> <20131130235117.622994e5@fsol>
 <529A969C.90908@python.org> <20131201113701.18f1aa65@fsol>
 <CADiSq7dAXBvDAdrPzXN35_8-CUGHxc9TEcC0JzhbbTi08M8M2g@mail.gmail.com>
Message-ID: <l7fpl1$lrv$1@ger.gmane.org>

Am 01.12.2013 12:33, schrieb Nick Coghlan:
> Perhaps a cleaner option would be to make check_hostname read only,
> and add a secure-by-default method that allows all verification
> related settings to be adjusted at once:
> 
>     def set_verify_mode(mode=ssl.CERT_REQUIRED, check_hostname=True):
>         ...
> 
> That way the consistency check would be directly on the method
> arguments, rather than involving the current context state. Any future
> settings that required a verified cert could then use a similar model.

I don't like to add yet another API element to SSLContext. I'd rather
extend SSLContext.__init__ to take two additional parameters:

class SSLContext(_SSLContext):
    def __init__(self, protocol, verify_mode=ssl.CERT_NONE,
check_hostname=False):
        self.protocol = protocol
        self.verify_mode = verify_mode
        self.check_hostname = check_hostname


I also like to point out (again) that the requirement is only a
limitation of our API. OpenSSL is able to acquire and return the peer's
certificate with any mode. In the past somebody decided to map 'no
certificate' to None and 'no verification' to empty dict.


> If we don't do that, then I think Christian's approach is a reasonable
> compromise given the late stage of the release cycle - it ensures the
> context can't get into the inconsistent verify_mode=CERT_NONE and
> check_hostname=True state, and leaves our options completely open for
> 3.5:

You are right, I'm trying to aim for the simplest and smallest solution
possible. I'm well aware that the order of API calls is a limitation and
that it feels a bit awkward, too. In my opinion there is no way this API
can be screwed up. :) Any limitation can be lifted for 3.5 but we can't
make it more restrict in future versions.

And there is ssl.create_default_context(), too. It creates a context
with all security-related bits flipped on.

Christian



From christian at python.org  Sun Dec  1 18:03:28 2013
From: christian at python.org (Christian Heimes)
Date: Sun, 01 Dec 2013 18:03:28 +0100
Subject: [Python-Dev] Verification of SSL cert and hostname made easy
In-Reply-To: <CAP7+vJLB1KK48hZnr9z2sVk14EQp_Q2js57H63Oofhktx-2V4g@mail.gmail.com>
References: <l7daq6$r5c$1@ger.gmane.org>
 <CADiSq7dwQP6qkRKHyJXEBE7aHixO7b7CNEF_E6RLAKHBZ_CV8Q@mail.gmail.com>
 <CAP7+vJLB1KK48hZnr9z2sVk14EQp_Q2js57H63Oofhktx-2V4g@mail.gmail.com>
Message-ID: <529B6BE0.6000702@python.org>

Am 30.11.2013 23:16, schrieb Guido van Rossum:
> Sounds good.
> 
> Is another change for asyncio needed?

Yes, but just a small one. The match_hostname() call in
selector_events is no longer required in 3.4.

Christian

From ronaldoussoren at mac.com  Sun Dec  1 18:03:47 2013
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 01 Dec 2013 18:03:47 +0100
Subject: [Python-Dev] Verification of SSL cert and hostname made easy
In-Reply-To: <l7daq6$r5c$1@ger.gmane.org>
References: <l7daq6$r5c$1@ger.gmane.org>
Message-ID: <D2992685-D258-4031-84D5-FB54AA9801C9@mac.com>



> On 30 nov. 2013, at 19:29, Christian Heimes <christian at python.org> wrote:
> 
> With CERT_REQUIRED OpenSSL verifies that the peer's certificate is
> directly or indirectly signed by a trusted root certification authority.
> With Python 3.4 the ssl module is able to use/load the system's trusted
> root certs on all major systems (Linux, Mac, BSD, Windows). On Linux and
> BSD it requires a properly configured system openssl to locate the root
> certs. This usually works out of the box. On Mac Apple's openssl build
> is able to use the keychain API of OSX. I have added code for Windows'
> system store.

Note that only Apple's build of OpenSSL integrates with keychain, other builds don't. The patch for keychain integration is on Apple's open source site but that isn't very helpful because that code uses a private API to do most of the work.   

This almost certainly means that users of fink, macports and the like cannot use the system keystore. 

It is probably possible to use the Keychain API to verify certificates, I haven't seriously looked into that yet and there is a risk of using higher level APIs: those tend to not like calling fork without calling execv soon after and that could break existing scripts. 

Ronald

From jon+python-dev at unequivocal.co.uk  Mon Dec  2 01:37:55 2013
From: jon+python-dev at unequivocal.co.uk (Jon Ribbens)
Date: Mon, 2 Dec 2013 00:37:55 +0000
Subject: [Python-Dev] SSL sockets and settimeout
Message-ID: <20131202003755.GQ26180@snowy.squish.net>

Am I correct in thinking that Python's newfangled socket.settimeout()
feature does not play well with SSL wrapped sockets? Would there be
any interest in making it so that it did?

From ncoghlan at gmail.com  Mon Dec  2 13:18:10 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 2 Dec 2013 22:18:10 +1000
Subject: [Python-Dev] [Python-checkins] cpython (3.3): Issue #19728: Fix
 sys.getfilesystemencoding() documentation
In-Reply-To: <3dY3hr6BG1z7LrQ@mail.python.org>
References: <3dY3hr6BG1z7LrQ@mail.python.org>
Message-ID: <CADiSq7eNV_VAdrU90PWz_vtSsxd6o0+ugja-bzqj1Hh-Cs12EQ@mail.gmail.com>

On 2 Dec 2013 21:18, "victor.stinner" <python-checkins at python.org> wrote:
>
> http://hg.python.org/cpython/rev/b231e0c3fd26
> changeset:   87692:b231e0c3fd26
> branch:      3.3
> parent:      87690:7d3297f127ae
> user:        Victor Stinner <victor.stinner at gmail.com>
> date:        Mon Dec 02 12:16:46 2013 +0100
> summary:
>   Issue #19728: Fix sys.getfilesystemencoding() documentation

This doesn't appear to be the right issue number (ironically, this number
refers to the PEP 453 Windows installer one I was trying to reference when
I got a commit message wrong the other day and ended up referencing an
asyncio bug instead).

Cheers,
Nick.

>
> files:
>   Doc/library/sys.rst |  5 ++---
>   1 files changed, 2 insertions(+), 3 deletions(-)
>
>
> diff --git a/Doc/library/sys.rst b/Doc/library/sys.rst
> --- a/Doc/library/sys.rst
> +++ b/Doc/library/sys.rst
> @@ -409,7 +409,7 @@
>     * On Mac OS X, the encoding is ``'utf-8'``.
>
>     * On Unix, the encoding is the user's preference according to the
result of
> -     nl_langinfo(CODESET), or ``'utf-8'`` if ``nl_langinfo(CODESET)``
failed.
> +     nl_langinfo(CODESET).
>
>     * On Windows NT+, file names are Unicode natively, so no conversion is
>       performed. :func:`getfilesystemencoding` still returns ``'mbcs'``,
as
> @@ -420,8 +420,7 @@
>     * On Windows 9x, the encoding is ``'mbcs'``.
>
>     .. versionchanged:: 3.2
> -      On Unix, use ``'utf-8'`` instead of ``None`` if
``nl_langinfo(CODESET)``
> -      failed. :func:`getfilesystemencoding` result cannot be ``None``.
> +      :func:`getfilesystemencoding` result cannot be ``None`` anymore.
>
>
>  .. function:: getrefcount(object)
>
> --
> Repository URL: http://hg.python.org/cpython
>
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> https://mail.python.org/mailman/listinfo/python-checkins
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131202/a75dc2c6/attachment.html>

From victor.stinner at gmail.com  Mon Dec  2 13:25:00 2013
From: victor.stinner at gmail.com (Victor Stinner)
Date: Mon, 2 Dec 2013 13:25:00 +0100
Subject: [Python-Dev] [Python-checkins] cpython (3.3): Issue #19728: Fix
 sys.getfilesystemencoding() documentation
In-Reply-To: <CADiSq7eNV_VAdrU90PWz_vtSsxd6o0+ugja-bzqj1Hh-Cs12EQ@mail.gmail.com>
References: <3dY3hr6BG1z7LrQ@mail.python.org>
 <CADiSq7eNV_VAdrU90PWz_vtSsxd6o0+ugja-bzqj1Hh-Cs12EQ@mail.gmail.com>
Message-ID: <CAMpsgwYmKRsa4RbbaA_RJYi0at3T1s3cG3Y1Cv4h3OSaNDT_tw@mail.gmail.com>

Oops, I happens to me sometimes when I open too many tabs in Firefox.

The correct issue number is #19847: "Setting the default filesystem-encoding".

Victor

2013/12/2 Nick Coghlan <ncoghlan at gmail.com>:
> On 2 Dec 2013 21:18, "victor.stinner" <python-checkins at python.org> wrote:
>>
>> http://hg.python.org/cpython/rev/b231e0c3fd26
>> changeset:   87692:b231e0c3fd26
>> branch:      3.3
>> parent:      87690:7d3297f127ae
>> user:        Victor Stinner <victor.stinner at gmail.com>
>> date:        Mon Dec 02 12:16:46 2013 +0100
>> summary:
>>   Issue #19728: Fix sys.getfilesystemencoding() documentation
>
> This doesn't appear to be the right issue number (ironically, this number
> refers to the PEP 453 Windows installer one I was trying to reference when I
> got a commit message wrong the other day and ended up referencing an asyncio
> bug instead).
>
> Cheers,
> Nick.

From steve at holdenweb.com  Mon Dec  2 20:01:21 2013
From: steve at holdenweb.com (Steve Holden)
Date: Mon, 2 Dec 2013 19:01:21 +0000 (UTC)
Subject: [Python-Dev] PEP 0404 and VS 2010
References: <528D20FA.8040902@stackless.com>
Message-ID: <loom.20131202T195955-647@post.gmane.org>

Christian Tismer <tismer <at> stackless.com> writes:

> 
> Howdy friends,
> 
> according to pep 404, there will never be an official Python 2.8.
> The migration path is from 2.7 to 3.x.
> 
[...]
> And if not, what do you suggest then?

Stackless Python 2.799

> It will be submitted by end of November, thanks for your quick responses!
> 
Oops, too quick!

> all the best -- Chris
> 

And to you.

Steve


From reubengarrett at gmail.com  Tue Dec  3 16:24:40 2013
From: reubengarrett at gmail.com (Reuben Garrett)
Date: Tue, 3 Dec 2013 09:24:40 -0600
Subject: [Python-Dev] test_bind_port and test_find_unused_port fail due to
 missing SO_REUSEPORT when building Python 3.3.2-r2 (from portage) on
 3.7.10-gentoo-r1 kernel
Message-ID: <CAA-SZJEmwNzn3u6OtV9P3hQNoe6zXWKC0J=A_9TQ4OV634V8xQ@mail.gmail.com>

Greetings, learned Python devs!

Apologies in advance if my message is misdirected. I'm building Python
3.3.2-r2 from Gentoo's Portage tree [1] and encountered two failed tests
which probably should not have been attempted on my OS (Gentoo 3.7.10):
test_bind_port and test_find_unused_port both use the SO_REUSEPORT socket
option which, to the best of my knowledge is only available since kernel
version 3.9. I was able to build by skipping the tests ? but I believe the
tests are there for a reason, and it would be best if a test that is known
to fail should be skipped (or replaced with a fallback that is likely to
succeed). Issue # 16594 [3] may be related (not sure).

Is it possible to detect the kernel version and skip (or modify) these
tests if SO_REUSEPORT is not available? If I'm missing something obvious
(or should be reporting this elsewhere), please educate me so I can better
respect your attention next time around :]


+=== excerpt of portage build log:
======================================================================
ERROR: test_bind_port (test.test_support.TestSupport)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/test_support.py",
line 87, in test_bind_port
    support.bind_port(s)
  File
"/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/support.py",
line 548, in bind_port
    if sock.getsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT) == 1:
OSError: [Errno 92] Protocol not available

======================================================================
ERROR: test_find_unused_port (test.test_support.TestSupport)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/test_support.py",
line 80, in test_find_unused_port
    port = support.find_unused_port()
  File
"/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/support.py",
line 522, in find_unused_port
    port = bind_port(tempsock)
  File
"/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/support.py",
line 548, in bind_port
    if sock.getsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT) == 1:
OSError: [Errno 92] Protocol not available
===+

[1]: https://packages.gentoo.org/package/dev-lang/python
[2]: https://lwn.net/Articles/542629/
[3]: http://bugs.python.org/issue16594

-- 
Best regards,
Reuben Garrett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131203/3880f2d5/attachment.html>

From guido at python.org  Tue Dec  3 16:44:00 2013
From: guido at python.org (Guido van Rossum)
Date: Tue, 3 Dec 2013 07:44:00 -0800
Subject: [Python-Dev] test_bind_port and test_find_unused_port fail due
 to missing SO_REUSEPORT when building Python 3.3.2-r2 (from portage) on
 3.7.10-gentoo-r1 kernel
In-Reply-To: <CAA-SZJEmwNzn3u6OtV9P3hQNoe6zXWKC0J=A_9TQ4OV634V8xQ@mail.gmail.com>
References: <CAA-SZJEmwNzn3u6OtV9P3hQNoe6zXWKC0J=A_9TQ4OV634V8xQ@mail.gmail.com>
Message-ID: <CAP7+vJ+4EMQ0Rwxd6pDYkK7b4L9X+8iaA58Czo6S9NYcvxtQCw@mail.gmail.com>

Hi Reuben,

Thanks for reporting this. I've had a similar report recently in the Tulip
tracker (http://code.google.com/p/tulip/issues/detail?id=89). But the
problem seems with the use of SO_REUSEPORT in the test.support package's
bind_port() helper.

This really belongs in the Python issue tracker (bugs.python.org) -- can
you submit a bug there? My hunch is that, because this seems to be a
relatively new feature, we should just catch and ignore the exception from
that specific call.

--Guido


On Tue, Dec 3, 2013 at 7:24 AM, Reuben Garrett <reubengarrett at gmail.com>wrote:

> Greetings, learned Python devs!
>
> Apologies in advance if my message is misdirected. I'm building Python
> 3.3.2-r2 from Gentoo's Portage tree [1] and encountered two failed tests
> which probably should not have been attempted on my OS (Gentoo 3.7.10):
> test_bind_port and test_find_unused_port both use the SO_REUSEPORT socket
> option which, to the best of my knowledge is only available since kernel
> version 3.9. I was able to build by skipping the tests ? but I believe the
> tests are there for a reason, and it would be best if a test that is known
> to fail should be skipped (or replaced with a fallback that is likely to
> succeed). Issue # 16594 [3] may be related (not sure).
>
> Is it possible to detect the kernel version and skip (or modify) these
> tests if SO_REUSEPORT is not available? If I'm missing something obvious
> (or should be reporting this elsewhere), please educate me so I can better
> respect your attention next time around :]
>
>
> +=== excerpt of portage build log:
> ======================================================================
> ERROR: test_bind_port (test.test_support.TestSupport)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File
> "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/test_support.py",
> line 87, in test_bind_port
>     support.bind_port(s)
>   File
> "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/support.py",
> line 548, in bind_port
>     if sock.getsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT) == 1:
> OSError: [Errno 92] Protocol not available
>
> ======================================================================
> ERROR: test_find_unused_port (test.test_support.TestSupport)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File
> "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/test_support.py",
> line 80, in test_find_unused_port
>     port = support.find_unused_port()
>   File
> "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/support.py",
> line 522, in find_unused_port
>     port = bind_port(tempsock)
>   File
> "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/support.py",
> line 548, in bind_port
>     if sock.getsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT) == 1:
> OSError: [Errno 92] Protocol not available
> ===+
>
> [1]: https://packages.gentoo.org/package/dev-lang/python
> [2]: https://lwn.net/Articles/542629/
> [3]: http://bugs.python.org/issue16594
>
> --
> Best regards,
> Reuben Garrett
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131203/4180bad3/attachment.html>

From sky.kok at speaklikeaking.com  Tue Dec  3 17:16:11 2013
From: sky.kok at speaklikeaking.com (Vajrasky Kok)
Date: Wed, 4 Dec 2013 00:16:11 +0800
Subject: [Python-Dev] Running the unit test as root/administrator
Message-ID: <CAB+fVUWYgD=yM3UXn7Gctwn2ZNpAgmtAOK8nELWV=wt-L6GEMg@mail.gmail.com>

Greetings, comrades!

Having handled these two issues personally:

http://bugs.python.org/issue19877
- test related with symlink fails on Windows Vista with administrator
account (in Windows NT 6, only account in administrator group can
create symlink)
http://bugs.python.org/issue18678
- bug in spwd module, which can be used only by root

I believe there is a virtue of running the unit test as
root/administrator to catch these errors automatically. Currently
there is no unit test for spwd module.

What do you say, comrades?

--Vajrasky

From guido at python.org  Tue Dec  3 17:25:38 2013
From: guido at python.org (Guido van Rossum)
Date: Tue, 3 Dec 2013 08:25:38 -0800
Subject: [Python-Dev] Running the unit test as root/administrator
In-Reply-To: <CAB+fVUWYgD=yM3UXn7Gctwn2ZNpAgmtAOK8nELWV=wt-L6GEMg@mail.gmail.com>
References: <CAB+fVUWYgD=yM3UXn7Gctwn2ZNpAgmtAOK8nELWV=wt-L6GEMg@mail.gmail.com>
Message-ID: <CAP7+vJ+y8R5O1-8JWXrKj8NCyy2TO-4B577mGua4xa46v3gW0Q@mail.gmail.com>

I would be rather worried about some accidental Trojen running that way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131203/0e544094/attachment.html>

From cs at zip.com.au  Wed Dec  4 01:45:36 2013
From: cs at zip.com.au (Cameron Simpson)
Date: Wed, 4 Dec 2013 11:45:36 +1100
Subject: [Python-Dev] Running the unit test as root/administrator
In-Reply-To: <CAP7+vJ+y8R5O1-8JWXrKj8NCyy2TO-4B577mGua4xa46v3gW0Q@mail.gmail.com>
References: <CAP7+vJ+y8R5O1-8JWXrKj8NCyy2TO-4B577mGua4xa46v3gW0Q@mail.gmail.com>
Message-ID: <20131204004536.GA98992@cskk.homeip.net>

On 03Dec2013 08:25, Guido van Rossum <guido at python.org> wrote:
> I would be rather worried about some accidental Trojen running that way.

Or even just a badly framed clean-up-temp-files step.
-- 
Cameron Simpson <cs at zip.com.au>

manual, n.:
A unit of documentation. There are always three or more on a given item.
One is on the shelf; someone has the others.
The information you need is in the others.               - Ray Simard

From rymg19 at gmail.com  Wed Dec  4 03:14:18 2013
From: rymg19 at gmail.com (Ryan Gonzalez)
Date: Tue, 3 Dec 2013 20:14:18 -0600
Subject: [Python-Dev] Running the unit test as root/administrator
In-Reply-To: <CAP7+vJ+y8R5O1-8JWXrKj8NCyy2TO-4B577mGua4xa46v3gW0Q@mail.gmail.com>
References: <CAB+fVUWYgD=yM3UXn7Gctwn2ZNpAgmtAOK8nELWV=wt-L6GEMg@mail.gmail.com>
 <CAP7+vJ+y8R5O1-8JWXrKj8NCyy2TO-4B577mGua4xa46v3gW0Q@mail.gmail.com>
Message-ID: <CAO41-mPhcZLPoFHnJq1H1N3PQLGKduxwAJSm1Rd=D2rotFy4qA@mail.gmail.com>

Just don't run it on Windows...


On Tue, Dec 3, 2013 at 10:25 AM, Guido van Rossum <guido at python.org> wrote:

> I would be rather worried about some accidental Trojen running that way.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
>


-- 
Ryan
When your hammer is C++, everything begins to look like a thumb.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131203/56d44135/attachment.html>

From fil at pobox.com  Wed Dec  4 13:17:11 2013
From: fil at pobox.com (Fil Mackay)
Date: Wed, 4 Dec 2013 23:17:11 +1100
Subject: [Python-Dev] 128 bit integer support
Message-ID: <CAKgz=nBx+oh5dnEkgccU=-Zq-r9WY+3nwhifHhorpbj_VBVABQ@mail.gmail.com>

I have been doing some research on getting "int128_t" supported in Python,
and have hit a snag:

I've found that libffi does support this type, but sadly ctypes and cffi do
not. Adding to ctypes does not seem to be trivial, since the description of
an integer type is limited to a single character ("q" in the case of long
long). "q" is considered to be a length of 8, whereas what I really want is
the integer type "ll" which is correctly considered length of 16.

These musings are on OSX.

Can anyone give me some pointers as to why this has not been added to date,
and the best line of attack?

Regards, Fil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131204/a8e5dc31/attachment.html>

From solipsis at pitrou.net  Wed Dec  4 15:15:42 2013
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 4 Dec 2013 15:15:42 +0100
Subject: [Python-Dev] 128 bit integer support
References: <CAKgz=nBx+oh5dnEkgccU=-Zq-r9WY+3nwhifHhorpbj_VBVABQ@mail.gmail.com>
Message-ID: <20131204151542.6e97dd09@fsol>


Hi Fil,

On Wed, 4 Dec 2013 23:17:11 +1100
Fil Mackay <fil at pobox.com> wrote:
> 
> I've found that libffi does support this type, but sadly ctypes and cffi do
> not. Adding to ctypes does not seem to be trivial, since the description of
> an integer type is limited to a single character ("q" in the case of long
> long). "q" is considered to be a length of 8, whereas what I really want is
> the integer type "ll" which is correctly considered length of 16.

Aren't you talking about the struct module? In ctypes, it seems it
would be sufficient to add a "c_int128" type (and/or "c_uint128").

> These musings are on OSX.
> 
> Can anyone give me some pointers as to why this has not been added to date,
> and the best line of attack?

Probably because noone needed it until now?

We have a comprehensive guide if you want to contribute a patch:
http://docs.python.org/devguide/

The first step would be to open an enhancement request on the
issue tracker, the discussion will then move on there:
http://bugs.python.org/

(if you want to enhance both the ctypes and struct modules, please open
a separate issue for each)

Regards

Antoine.



From brett at python.org  Wed Dec  4 15:38:44 2013
From: brett at python.org (Brett Cannon)
Date: Wed, 4 Dec 2013 09:38:44 -0500
Subject: [Python-Dev] Python 3 is five years old
Message-ID: <CAP1=2W4cxP0YCxPho7qgm85cvb+w=MpBTPP5B3-K1QTUDtf2eA@mail.gmail.com>

On 2008-12-03, Python 3.0.0 was released by Barry. I was actually on IRC
the night when it happened, with Guido leaving his office across the hall
from mine. We gave each other a high-five and then we both went home. Not
exactly a party, but I know I at least breathed a sigh of relief that
Python 3 was finally real.

On this anniversary I just wanted to thank everyone who contributed to
making Python 3 happen. Thanks to the core devs who worked hard to make
Python better for everyone, even in the face of people yelling at us that
we were crazy, killing Python, etc. Thanks to those in the community who
stuck by the dev team and had faith we knew what we were doing and have
continued to help everyone move forward and off of Python 2 to realize how
much more pleasant Python 3 is to work with.

At this point I'm willing to say I'm happy with how Python 3 has turned out
and how the community has supported it. Python 3.3 was a great release and
I think Python 3.4 will be as well. I see no reason to think that the
language and community's forward momentum will not continue, leading to a
day where Python 2 only exists for people stuck on RHEL. =)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131204/34e2ba15/attachment.html>

From brian at python.org  Thu Dec  5 00:07:32 2013
From: brian at python.org (Brian Curtin)
Date: Wed, 4 Dec 2013 17:07:32 -0600
Subject: [Python-Dev] Running the unit test as root/administrator
In-Reply-To: <CAO41-mPhcZLPoFHnJq1H1N3PQLGKduxwAJSm1Rd=D2rotFy4qA@mail.gmail.com>
References: <CAB+fVUWYgD=yM3UXn7Gctwn2ZNpAgmtAOK8nELWV=wt-L6GEMg@mail.gmail.com>
 <CAP7+vJ+y8R5O1-8JWXrKj8NCyy2TO-4B577mGua4xa46v3gW0Q@mail.gmail.com>
 <CAO41-mPhcZLPoFHnJq1H1N3PQLGKduxwAJSm1Rd=D2rotFy4qA@mail.gmail.com>
Message-ID: <CAD+XWwpU+Mkox87DPtfR-C9mZ_r6TK-MQBbX39we-MB5bJWNJw@mail.gmail.com>

On Tue, Dec 3, 2013 at 8:14 PM, Ryan Gonzalez <rymg19 at gmail.com> wrote:

> Just don't run it on Windows...
>

Not helpful.

I'm in meetings/training/traveling all week, but I'll get another Windows
build slave up within the next few days. I used to have a spare desktop box
that ran a build slave as admin so it would exercise the os.symlink code,
but I moved, then the box died, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131204/ad060080/attachment.html>

From ncoghlan at gmail.com  Thu Dec  5 00:40:16 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 5 Dec 2013 09:40:16 +1000
Subject: [Python-Dev] Python 3 is five years old
In-Reply-To: <CAP1=2W4cxP0YCxPho7qgm85cvb+w=MpBTPP5B3-K1QTUDtf2eA@mail.gmail.com>
References: <CAP1=2W4cxP0YCxPho7qgm85cvb+w=MpBTPP5B3-K1QTUDtf2eA@mail.gmail.com>
Message-ID: <CADiSq7dUvKb3HRJOgCiY5xWBzBTmA-E3XhPppECPrsG=XYPetg@mail.gmail.com>

On 5 Dec 2013 00:41, "Brett Cannon" <brett at python.org> wrote:
>
> On 2008-12-03, Python 3.0.0 was released by Barry. I was actually on IRC
the night when it happened, with Guido leaving his office across the hall
from mine. We gave each other a high-five and then we both went home. Not
exactly a party, but I know I at least breathed a sigh of relief that
Python 3 was finally real.
>
> On this anniversary I just wanted to thank everyone who contributed to
making Python 3 happen. Thanks to the core devs who worked hard to make
Python better for everyone, even in the face of people yelling at us that
we were crazy, killing Python, etc. Thanks to those in the community who
stuck by the dev team and had faith we knew what we were doing and have
continued to help everyone move forward and off of Python 2 to realize how
much more pleasant Python 3 is to work with.
>
> At this point I'm willing to say I'm happy with how Python 3 has turned
out and how the community has supported it. Python 3.3 was a great release
and I think Python 3.4 will be as well. I see no reason to think that the
language and community's forward momentum will not continue, leading to a
day where Python 2 only exists for people stuck on RHEL. =)

Red Hat Software Collections (which includes a Red Hat supported Python 3.3
release) hit general availability in September, so even RHEL users have a
fully supported migration option these days.

It's still going to be a while before the RHEL system Python gets upgraded,
but Fedora at least has a plan for that now :)

Cheers,
Nick.

>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131205/3512dd12/attachment.html>

From sky.kok at speaklikeaking.com  Thu Dec  5 02:04:33 2013
From: sky.kok at speaklikeaking.com (Vajrasky Kok)
Date: Thu, 5 Dec 2013 09:04:33 +0800
Subject: [Python-Dev] Running the unit test as root/administrator
In-Reply-To: <CAD+XWwpU+Mkox87DPtfR-C9mZ_r6TK-MQBbX39we-MB5bJWNJw@mail.gmail.com>
References: <CAB+fVUWYgD=yM3UXn7Gctwn2ZNpAgmtAOK8nELWV=wt-L6GEMg@mail.gmail.com>
 <CAP7+vJ+y8R5O1-8JWXrKj8NCyy2TO-4B577mGua4xa46v3gW0Q@mail.gmail.com>
 <CAO41-mPhcZLPoFHnJq1H1N3PQLGKduxwAJSm1Rd=D2rotFy4qA@mail.gmail.com>
 <CAD+XWwpU+Mkox87DPtfR-C9mZ_r6TK-MQBbX39we-MB5bJWNJw@mail.gmail.com>
Message-ID: <CAB+fVUUB7_Akzm8s1yCuU97mVHPiYz91NnsBH3_H6Vjk+47tqQ@mail.gmail.com>

On Thu, Dec 5, 2013 at 7:07 AM, Brian Curtin <brian at python.org> wrote:
>
> Not helpful.
>
> I'm in meetings/training/traveling all week, but I'll get another Windows
> build slave up within the next few days. I used to have a spare desktop box
> that ran a build slave as admin so it would exercise the os.symlink code,
> but I moved, then the box died, etc.
>
>

Cool. What about Linux/Unix/BSD with root account? If we have
something similar, I may plan to write unit test for spwd module.

--Vajrasky

From meadori at gmail.com  Thu Dec  5 13:56:18 2013
From: meadori at gmail.com (Meador Inge)
Date: Thu, 5 Dec 2013 06:56:18 -0600
Subject: [Python-Dev] 128 bit integer support
In-Reply-To: <20131204151542.6e97dd09@fsol>
References: <CAKgz=nBx+oh5dnEkgccU=-Zq-r9WY+3nwhifHhorpbj_VBVABQ@mail.gmail.com>
 <20131204151542.6e97dd09@fsol>
Message-ID: <CAK1QoorLnyiTvgVwA_WuTTuO0pW56MjrhhwqxQpj33va5nF7NA@mail.gmail.com>

On Wed, Dec 4, 2013 at 8:15 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

Aren't you talking about the struct module? In ctypes, it seems it
> would be sufficient to add a "c_int128" type (and/or "c_uint128").


Even in ctypes these codes are used internally for the field descriptors.
For ctypes "c_int128" seems reasonable to me.  We already have support for "
for 8-bit, 16-bit, 32-bit, and 64-bit fixed sized integer types with
comparable names.  The struct module has the notion of a "standard size"
where the size is fixed, but we default to native.

-- Meador
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131205/84623fd6/attachment.html>

From martin at v.loewis.de  Thu Dec  5 16:06:09 2013
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 05 Dec 2013 16:06:09 +0100
Subject: [Python-Dev] Running the unit test as root/administrator
In-Reply-To: <CAB+fVUUB7_Akzm8s1yCuU97mVHPiYz91NnsBH3_H6Vjk+47tqQ@mail.gmail.com>
References: <CAB+fVUWYgD=yM3UXn7Gctwn2ZNpAgmtAOK8nELWV=wt-L6GEMg@mail.gmail.com>
 <CAP7+vJ+y8R5O1-8JWXrKj8NCyy2TO-4B577mGua4xa46v3gW0Q@mail.gmail.com>
 <CAO41-mPhcZLPoFHnJq1H1N3PQLGKduxwAJSm1Rd=D2rotFy4qA@mail.gmail.com>
 <CAD+XWwpU+Mkox87DPtfR-C9mZ_r6TK-MQBbX39we-MB5bJWNJw@mail.gmail.com>
 <CAB+fVUUB7_Akzm8s1yCuU97mVHPiYz91NnsBH3_H6Vjk+47tqQ@mail.gmail.com>
Message-ID: <52A09661.2080801@v.loewis.de>

Am 05.12.13 02:04, schrieb Vajrasky Kok:
> Cool. What about Linux/Unix/BSD with root account? If we have
> something similar, I may plan to write unit test for spwd module.

Can you please phrase your question more explicit? What is it that
you want to be done before writing unit tests for the spwd module?

Anybody could run the test suite, and somebody might run it as root -
so you must be asking for something else.

Regards,
Martin



From martin at v.loewis.de  Thu Dec  5 16:29:03 2013
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 05 Dec 2013 16:29:03 +0100
Subject: [Python-Dev] Running the unit test as root/administrator
In-Reply-To: <CAB+fVUUQOE1+Pj4c0=K5XFMQmU2w66wxdZRniXHq6SVZ-0iRBw@mail.gmail.com>
References: <CAB+fVUWYgD=yM3UXn7Gctwn2ZNpAgmtAOK8nELWV=wt-L6GEMg@mail.gmail.com>	<CAP7+vJ+y8R5O1-8JWXrKj8NCyy2TO-4B577mGua4xa46v3gW0Q@mail.gmail.com>	<CAO41-mPhcZLPoFHnJq1H1N3PQLGKduxwAJSm1Rd=D2rotFy4qA@mail.gmail.com>	<CAD+XWwpU+Mkox87DPtfR-C9mZ_r6TK-MQBbX39we-MB5bJWNJw@mail.gmail.com>	<CAB+fVUUB7_Akzm8s1yCuU97mVHPiYz91NnsBH3_H6Vjk+47tqQ@mail.gmail.com>	<52A09661.2080801@v.loewis.de>
 <CAB+fVUUQOE1+Pj4c0=K5XFMQmU2w66wxdZRniXHq6SVZ-0iRBw@mail.gmail.com>
Message-ID: <52A09BBF.20203@v.loewis.de>

Am 05.12.13 16:21, schrieb Vajrasky Kok:
> On Thu, Dec 5, 2013 at 11:06 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>
>> Can you please phrase your question more explicit? What is it that
>> you want to be done before writing unit tests for the spwd module?
> 
> I am asking buildbot of Linux/Unix/BSD with root account. Do we have it now?

Ah. I don't think we have one. If somebody would want to donate one, I
suggest to run it in a VM, to reduce the (valid) security concerns that
Guido has voiced. If a snapshot of the VM is made, it would be easy to
restore in case a commit performs serious damage.

Regards,
Martin

From rosuav at gmail.com  Thu Dec  5 16:31:38 2013
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 6 Dec 2013 02:31:38 +1100
Subject: [Python-Dev] Running the unit test as root/administrator
In-Reply-To: <52A09BBF.20203@v.loewis.de>
References: <CAB+fVUWYgD=yM3UXn7Gctwn2ZNpAgmtAOK8nELWV=wt-L6GEMg@mail.gmail.com>
 <CAP7+vJ+y8R5O1-8JWXrKj8NCyy2TO-4B577mGua4xa46v3gW0Q@mail.gmail.com>
 <CAO41-mPhcZLPoFHnJq1H1N3PQLGKduxwAJSm1Rd=D2rotFy4qA@mail.gmail.com>
 <CAD+XWwpU+Mkox87DPtfR-C9mZ_r6TK-MQBbX39we-MB5bJWNJw@mail.gmail.com>
 <CAB+fVUUB7_Akzm8s1yCuU97mVHPiYz91NnsBH3_H6Vjk+47tqQ@mail.gmail.com>
 <52A09661.2080801@v.loewis.de>
 <CAB+fVUUQOE1+Pj4c0=K5XFMQmU2w66wxdZRniXHq6SVZ-0iRBw@mail.gmail.com>
 <52A09BBF.20203@v.loewis.de>
Message-ID: <CAPTjJmoBvuVM5hi5ddwAjPP7F0Rye9hdm2humz0eByQP5agUng@mail.gmail.com>

On Fri, Dec 6, 2013 at 2:29 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Am 05.12.13 16:21, schrieb Vajrasky Kok:
>> On Thu, Dec 5, 2013 at 11:06 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>>
>>> Can you please phrase your question more explicit? What is it that
>>> you want to be done before writing unit tests for the spwd module?
>>
>> I am asking buildbot of Linux/Unix/BSD with root account. Do we have it now?
>
> Ah. I don't think we have one. If somebody would want to donate one, I
> suggest to run it in a VM, to reduce the (valid) security concerns that
> Guido has voiced. If a snapshot of the VM is made, it would be easy to
> restore in case a commit performs serious damage.

Are we worried about malicious or accidental damage, here?

I might be able to offer a buildbot VM, though I don't know what the
requirements are.

ChrisA

From sky.kok at speaklikeaking.com  Thu Dec  5 16:21:57 2013
From: sky.kok at speaklikeaking.com (Vajrasky Kok)
Date: Thu, 5 Dec 2013 23:21:57 +0800
Subject: [Python-Dev] Running the unit test as root/administrator
In-Reply-To: <52A09661.2080801@v.loewis.de>
References: <CAB+fVUWYgD=yM3UXn7Gctwn2ZNpAgmtAOK8nELWV=wt-L6GEMg@mail.gmail.com>
 <CAP7+vJ+y8R5O1-8JWXrKj8NCyy2TO-4B577mGua4xa46v3gW0Q@mail.gmail.com>
 <CAO41-mPhcZLPoFHnJq1H1N3PQLGKduxwAJSm1Rd=D2rotFy4qA@mail.gmail.com>
 <CAD+XWwpU+Mkox87DPtfR-C9mZ_r6TK-MQBbX39we-MB5bJWNJw@mail.gmail.com>
 <CAB+fVUUB7_Akzm8s1yCuU97mVHPiYz91NnsBH3_H6Vjk+47tqQ@mail.gmail.com>
 <52A09661.2080801@v.loewis.de>
Message-ID: <CAB+fVUUQOE1+Pj4c0=K5XFMQmU2w66wxdZRniXHq6SVZ-0iRBw@mail.gmail.com>

On Thu, Dec 5, 2013 at 11:06 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
> Can you please phrase your question more explicit? What is it that
> you want to be done before writing unit tests for the spwd module?

I am asking buildbot of Linux/Unix/BSD with root account. Do we have it now?

>
> Anybody could run the test suite, and somebody might run it as root -
> so you must be asking for something else.
>

Of course, I can write unit test for spwd module right now and mark it
only to be run with root account and skipped with regular user
account. But I would argue that it would be hard to find people
running test suite with root account. That's why buildbot is helping
much in this case.

--Vajrasky

From martin at v.loewis.de  Thu Dec  5 16:45:43 2013
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 05 Dec 2013 16:45:43 +0100
Subject: [Python-Dev] Running the unit test as root/administrator
In-Reply-To: <CAPTjJmoBvuVM5hi5ddwAjPP7F0Rye9hdm2humz0eByQP5agUng@mail.gmail.com>
References: <CAB+fVUWYgD=yM3UXn7Gctwn2ZNpAgmtAOK8nELWV=wt-L6GEMg@mail.gmail.com>
 <CAP7+vJ+y8R5O1-8JWXrKj8NCyy2TO-4B577mGua4xa46v3gW0Q@mail.gmail.com>
 <CAO41-mPhcZLPoFHnJq1H1N3PQLGKduxwAJSm1Rd=D2rotFy4qA@mail.gmail.com>
 <CAD+XWwpU+Mkox87DPtfR-C9mZ_r6TK-MQBbX39we-MB5bJWNJw@mail.gmail.com>
 <CAB+fVUUB7_Akzm8s1yCuU97mVHPiYz91NnsBH3_H6Vjk+47tqQ@mail.gmail.com>
 <52A09661.2080801@v.loewis.de>
 <CAB+fVUUQOE1+Pj4c0=K5XFMQmU2w66wxdZRniXHq6SVZ-0iRBw@mail.gmail.com>
 <52A09BBF.20203@v.loewis.de>
 <CAPTjJmoBvuVM5hi5ddwAjPP7F0Rye9hdm2humz0eByQP5agUng@mail.gmail.com>
Message-ID: <52A09FA7.2050304@v.loewis.de>

Am 05.12.13 16:31, schrieb Chris Angelico:
>> Ah. I don't think we have one. If somebody would want to donate one, I
>> suggest to run it in a VM, to reduce the (valid) security concerns that
>> Guido has voiced. If a snapshot of the VM is made, it would be easy to
>> restore in case a commit performs serious damage.
> 
> Are we worried about malicious or accidental damage, here?

Accidental damage is a serious risk, IMO. Malicious damage is a risk
for the paranoid: it might be that an SSH key gets stolen, and is then
used to commit a trojan. Of course, that would affect all build slaves
(but less so if they run in a restricted account), and we would disable
the key as soon as we notice, but some damage might have happened.

> I might be able to offer a buildbot VM, though I don't know what the
> requirements are.

The machine should be up "most of the time", including internet
connectivity. A fixed IP address is no requirement (although I'm
unsure how resilient the slaves are when the IP changes). The
admin (i.e. you) needs to set up the box initially, and then care
for it in case of problems; a response time of a few days for
most of the year would be appreciated (although we can also deal
with operators that leave for longer periods of time - we just
disable the slave then, and reenable it when the admin brings
it back up). The commitment should be for a "long" period, i.e.
a few years.

Regards,
Martin



From cyberdupo56 at gmail.com  Thu Dec  5 19:20:22 2013
From: cyberdupo56 at gmail.com (Allen Li)
Date: Thu, 5 Dec 2013 13:20:22 -0500
Subject: [Python-Dev] One-line abstractmethod function?
Message-ID: <20131205182022.GA27767@avalon.amherst.edu>

Hello Python devs,

As a regular Python user, I find the abc module useful for making
Python's duck typing more explicit.  In particular, I ofen use it
like a Java interface or C header, to provide methods to implement for a
given "duck type".

90% of the time, it ends up looking something like this:

class Foo(metaclass=abc.ABCMeta):

    @abc.abstractmethod
    def f1(self):
        raise NotImplementedError

    @staticmethod
    @abc.abstractmethod
    def f2(arg1):
        raise NotImplementedError

    ...

What if there was a function, say make_abstract_method (better name
pending), so that the above could be written like:

class Foo(metaclass=abc.ABCMeta):

    f1 = abc.make_abstract_method('f1', ['self'])
    f2 = staticmethod(abc.make_abstract_method('f2', ['arg1']))
    ...

I think that it would make ABC definitions a lot more compact for many
use cases, but I welcome any criticisms against this idea.

Allen Li

From guido at python.org  Thu Dec  5 19:24:11 2013
From: guido at python.org (Guido van Rossum)
Date: Thu, 5 Dec 2013 10:24:11 -0800
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <20131205182022.GA27767@avalon.amherst.edu>
References: <20131205182022.GA27767@avalon.amherst.edu>
Message-ID: <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>

How would you get the docstrings in? It seems cramming that much on a
single line doesn't help readability (even though I agree there is a
fair amount of boilerplace).

On Thu, Dec 5, 2013 at 10:20 AM, Allen Li <cyberdupo56 at gmail.com> wrote:
> Hello Python devs,
>
> As a regular Python user, I find the abc module useful for making
> Python's duck typing more explicit.  In particular, I ofen use it
> like a Java interface or C header, to provide methods to implement for a
> given "duck type".
>
> 90% of the time, it ends up looking something like this:
>
> class Foo(metaclass=abc.ABCMeta):
>
>     @abc.abstractmethod
>     def f1(self):
>         raise NotImplementedError
>
>     @staticmethod
>     @abc.abstractmethod
>     def f2(arg1):
>         raise NotImplementedError
>
>     ...
>
> What if there was a function, say make_abstract_method (better name
> pending), so that the above could be written like:
>
> class Foo(metaclass=abc.ABCMeta):
>
>     f1 = abc.make_abstract_method('f1', ['self'])
>     f2 = staticmethod(abc.make_abstract_method('f2', ['arg1']))
>     ...
>
> I think that it would make ABC definitions a lot more compact for many
> use cases, but I welcome any criticisms against this idea.
>
> Allen Li
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org



-- 
--Guido van Rossum (python.org/~guido)

From alexander.belopolsky at gmail.com  Thu Dec  5 19:56:25 2013
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Thu, 5 Dec 2013 13:56:25 -0500
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
References: <20131205182022.GA27767@avalon.amherst.edu>
 <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
Message-ID: <CAP7h-xaHjdXdBMyjKKu5f3CV0N+8uSAYNtJNGpoKjyQTnz+v2w@mail.gmail.com>

On Thu, Dec 5, 2013 at 1:24 PM, Guido van Rossum <guido at python.org> wrote:

> How would you get the docstrings in? It seems cramming that much on a
> single line doesn't help readability (even though I agree there is a
> fair amount of boilerplace).
>

One way to reduce the amount of boilerplate code is to make abstractmethod
to supply raise NotImplementedError body when none is given.  Then you can
write

class Foo:
    @abc.abstractmethod
    def do_bar(self):
         """perform bar"""


instead of

class Foo:
    @abc.abstractmethod
    def do_bar(self):
         """perform bar"""
         raise NotImplementedError

The docstring will be required when skipping the body which is probably a
good thing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131205/eee07a55/attachment.html>

From ethan at stoneleaf.us  Thu Dec  5 20:22:36 2013
From: ethan at stoneleaf.us (Ethan Furman)
Date: Thu, 05 Dec 2013 11:22:36 -0800
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <CAP7h-xaHjdXdBMyjKKu5f3CV0N+8uSAYNtJNGpoKjyQTnz+v2w@mail.gmail.com>
References: <20131205182022.GA27767@avalon.amherst.edu>
 <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
 <CAP7h-xaHjdXdBMyjKKu5f3CV0N+8uSAYNtJNGpoKjyQTnz+v2w@mail.gmail.com>
Message-ID: <52A0D27C.1030400@stoneleaf.us>

On 12/05/2013 10:56 AM, Alexander Belopolsky wrote:
> On Thu, Dec 5, 2013 at 1:24 PM, Guido van Rossum wrote:
>>
>> How would you get the docstrings in? [...]
>
> One way to reduce the amount of boilerplate code is to make abstractmethod
> to supply raise NotImplementedError body when none is given.  Then you can
>  write
>
> class Foo:
>      @abc.abstractmethod
>      def do_bar(self):
>           """perform bar"""
>
> The docstring will be required when skipping the body which is probably a good thing.

How will abstractmethod know its function has no body?

--
~Ethan~

From brett at python.org  Thu Dec  5 21:06:00 2013
From: brett at python.org (Brett Cannon)
Date: Thu, 5 Dec 2013 15:06:00 -0500
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <52A0D27C.1030400@stoneleaf.us>
References: <20131205182022.GA27767@avalon.amherst.edu>
 <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
 <CAP7h-xaHjdXdBMyjKKu5f3CV0N+8uSAYNtJNGpoKjyQTnz+v2w@mail.gmail.com>
 <52A0D27C.1030400@stoneleaf.us>
Message-ID: <CAP1=2W402=CZsj5bnWAJp9fpf8FJ3FMfHSaGY4sJ31FUOkXL1g@mail.gmail.com>

On Thu, Dec 5, 2013 at 2:22 PM, Ethan Furman <ethan at stoneleaf.us> wrote:

> On 12/05/2013 10:56 AM, Alexander Belopolsky wrote:
>
>> On Thu, Dec 5, 2013 at 1:24 PM, Guido van Rossum wrote:
>>
>>>
>>> How would you get the docstrings in? [...]
>>>
>>
>> One way to reduce the amount of boilerplate code is to make abstractmethod
>> to supply raise NotImplementedError body when none is given.  Then you can
>>  write
>>
>> class Foo:
>>      @abc.abstractmethod
>>      def do_bar(self):
>>           """perform bar"""
>>
>> The docstring will be required when skipping the body which is probably a
>> good thing.
>>
>
> How will abstractmethod know its function has no body?
>

Technically you could inspect the code object of the method. to figure out
if the body is empty.

But I would be very leery of this being a default behaviour. Raising
NotImplementedError is not necessarily what the default result should be
for a method. If you are building a class that supports multiple
inheritance you will be calling super().do_bar() almost blindly which, if
you are not careful, will raise NotImplementedError and that might not be
appropriate. Maybe returning None is more reasonable, maybe raising
TypeError. But support a default blindly like this can promote bad
practices.

You can see all of changes I had to make for importlib.abc in Python 3.4 to
have API-matching default exceptions and return values instead of blindly
raising NotImplementedError as a lesson learned:
http://docs.python.org/3.4/library/importlib.html#module-importlib.abc.
Hunt down Thomas Wouters at PyCon if you want to hear the same arguments he
gave me as to why blindly raise NotImplementedError is bad.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131205/65880438/attachment-0001.html>

From python at mrabarnett.plus.com  Thu Dec  5 21:39:05 2013
From: python at mrabarnett.plus.com (MRAB)
Date: Thu, 05 Dec 2013 20:39:05 +0000
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <52A0D27C.1030400@stoneleaf.us>
References: <20131205182022.GA27767@avalon.amherst.edu>
 <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
 <CAP7h-xaHjdXdBMyjKKu5f3CV0N+8uSAYNtJNGpoKjyQTnz+v2w@mail.gmail.com>
 <52A0D27C.1030400@stoneleaf.us>
Message-ID: <52A0E469.7090904@mrabarnett.plus.com>

On 05/12/2013 19:22, Ethan Furman wrote:
> On 12/05/2013 10:56 AM, Alexander Belopolsky wrote:
>> On Thu, Dec 5, 2013 at 1:24 PM, Guido van Rossum wrote:
>>>
>>> How would you get the docstrings in? [...]
>>
>> One way to reduce the amount of boilerplate code is to make abstractmethod
>> to supply raise NotImplementedError body when none is given.  Then you can
>>  write
>>
>> class Foo:
>>      @abc.abstractmethod
>>      def do_bar(self):
>>           """perform bar"""
>>
>> The docstring will be required when skipping the body which is probably a good thing.
>
> How will abstractmethod know its function has no body?
>
An abstract method won't have a body (I'm not counting the docstring).

If it _does_ have a body, then it's _not_ an abstract method!


From cyberdupo56 at gmail.com  Thu Dec  5 22:12:28 2013
From: cyberdupo56 at gmail.com (Allen Li)
Date: Thu, 5 Dec 2013 16:12:28 -0500
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <52A0E469.7090904@mrabarnett.plus.com>
 <CAP1=2W402=CZsj5bnWAJp9fpf8FJ3FMfHSaGY4sJ31FUOkXL1g@mail.gmail.com>
 <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
Message-ID: <20131205211228.GB27767@avalon.amherst.edu>

On Thu, Dec 05, 2013 at 10:24:11AM -0800, Guido van Rossum wrote:
> How would you get the docstrings in? It seems cramming that much on a
> single line doesn't help readability (even though I agree there is a
> fair amount of boilerplace).

I was basing my initial suggestion somewhat on collections.namedtuple,
which doesn't support docstring either.  One option would be to simply
not allow for docstrings, requiring the boilerplate method, the other
would be to add a parameter for the docstring:

make_abstractmethod(name, arglist, docstring='')

On Thu, Dec 5, 2013 at 2:22 PM, Ethan Furman <ethan at stoneleaf.us> wrote:

> On 12/05/2013 10:56 AM, Alexander Belopolsky wrote:
>
>> On Thu, Dec 5, 2013 at 1:24 PM, Guido van Rossum wrote:
>>
>>>
>>> How would you get the docstrings in? [...]
>>>
>>
>> One way to reduce the amount of boilerplate code is to make abstractmethod
>> to supply raise NotImplementedError body when none is given.  Then you can
>>  write
>>
>> class Foo:
>>      @abc.abstractmethod
>>      def do_bar(self):
>>           """perform bar"""
>>
>> The docstring will be required when skipping the body which is probably a
>> good thing.
>>
>
> How will abstractmethod know its function has no body?

I don't think this is a good idea at all, very magical behavior.  It is
not intuitive or explicit that an abstractmethod-decorated empty
function raises NotImplementedError.

On Thu, Dec 05, 2013 at 03:06:00PM -0500, Brett Cannon wrote:
> But I would be very leery of this being a default behaviour. Raising
> NotImplementedError is not necessarily what the default result should be
> for a method. If you are building a class that supports multiple
> inheritance you will be calling super().do_bar() almost blindly which, if
> you are not careful, will raise NotImplementedError and that might not be
> appropriate. Maybe returning None is more reasonable, maybe raising
> TypeError. But support a default blindly like this can promote bad
> practices.

I'm not sure what's considered best practice with super() at the moment.
super() is dangerous if you don't know what you are doing in
multi-inheritance design, so I'd consider calling super() blindly is the
problem here, not raising NotImplementedError.  I do think raising
NotImplementedError is reasonable default behavior for an
abstractmethod.  The only two alternatives are doing nothing/pass/return
None or having actual code in the method.

The former is only useful to silently ignore blind super() calling, the
latter you would define and decorate the method normally.

On Thu, Dec 05, 2013 at 08:39:05PM +0000, MRAB wrote:
> An abstract method won't have a body (I'm not counting the docstring).
> 
> If it _does_ have a body, then it's _not_ an abstract method!

It could have a body, though I would agree it's not commonly used that
way.  Maybe something like the following (though it's a poor example):

class Printer(metaclass=abc.ABCMeta):

    @abc.abstractmethod
    def print(self):
        print("Print done.")

class Foo(Printer):

    def print(self):
        print('foo')
        super().print()

From alexander.belopolsky at gmail.com  Thu Dec  5 22:19:26 2013
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Thu, 5 Dec 2013 16:19:26 -0500
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <CAP1=2W402=CZsj5bnWAJp9fpf8FJ3FMfHSaGY4sJ31FUOkXL1g@mail.gmail.com>
References: <20131205182022.GA27767@avalon.amherst.edu>
 <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
 <CAP7h-xaHjdXdBMyjKKu5f3CV0N+8uSAYNtJNGpoKjyQTnz+v2w@mail.gmail.com>
 <52A0D27C.1030400@stoneleaf.us>
 <CAP1=2W402=CZsj5bnWAJp9fpf8FJ3FMfHSaGY4sJ31FUOkXL1g@mail.gmail.com>
Message-ID: <CAP7h-xaKUCjOUakFFKW=kMU37oC-LsQangZJjKJWaMmWu10PLg@mail.gmail.com>

On Thu, Dec 5, 2013 at 3:06 PM, Brett Cannon <brett at python.org> wrote:

> How will abstractmethod know its function has no body?
>>
>
> Technically you could inspect the code object of the method. to figure out
> if the body is empty.
>

One way if to check f.__code__.co_lnotab - it will be empty when f has no
body.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131205/6628ee65/attachment.html>

From ethan at stoneleaf.us  Thu Dec  5 21:43:10 2013
From: ethan at stoneleaf.us (Ethan Furman)
Date: Thu, 05 Dec 2013 12:43:10 -0800
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <52A0E469.7090904@mrabarnett.plus.com>
References: <20131205182022.GA27767@avalon.amherst.edu>
 <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
 <CAP7h-xaHjdXdBMyjKKu5f3CV0N+8uSAYNtJNGpoKjyQTnz+v2w@mail.gmail.com>
 <52A0D27C.1030400@stoneleaf.us> <52A0E469.7090904@mrabarnett.plus.com>
Message-ID: <52A0E55E.703@stoneleaf.us>

On 12/05/2013 12:39 PM, MRAB wrote:
> On 05/12/2013 19:22, Ethan Furman wrote:
>> On 12/05/2013 10:56 AM, Alexander Belopolsky wrote:
>>> On Thu, Dec 5, 2013 at 1:24 PM, Guido van Rossum wrote:
>>>>
>>>> How would you get the docstrings in? [...]
>>>
>>> One way to reduce the amount of boilerplate code is to make abstractmethod
>>> to supply raise NotImplementedError body when none is given.  Then you can
>>>  write
>>>
>>> class Foo:
>>>      @abc.abstractmethod
>>>      def do_bar(self):
>>>           """perform bar"""
>>>
>>> The docstring will be required when skipping the body which is probably a good thing.
>>
>> How will abstractmethod know its function has no body?
>>
> An abstract method won't have a body (I'm not counting the docstring).
>
> If it _does_ have a body, then it's _not_ an abstract method!

To quote the docs [1]:

> Note
>
> Unlike Java abstract methods, these abstract methods may have an implementation.
>  This implementation can be called via the super() mechanism from the class that
>  overrides it. This could be useful as an end-point for a super-call in a framework
>  that uses cooperative multiple-inheritance.

--
~Ethan~

[1] http://docs.python.org/dev/library/abc.html

From reubengarrett at gmail.com  Thu Dec  5 22:05:34 2013
From: reubengarrett at gmail.com (Reuben Garrett)
Date: Thu, 5 Dec 2013 15:05:34 -0600
Subject: [Python-Dev] test_bind_port and test_find_unused_port fail due
 to missing SO_REUSEPORT when building Python 3.3.2-r2 (from portage) on
 3.7.10-gentoo-r1 kernel
In-Reply-To: <CAP7+vJ+4EMQ0Rwxd6pDYkK7b4L9X+8iaA58Czo6S9NYcvxtQCw@mail.gmail.com>
References: <CAA-SZJEmwNzn3u6OtV9P3hQNoe6zXWKC0J=A_9TQ4OV634V8xQ@mail.gmail.com>
 <CAP7+vJ+4EMQ0Rwxd6pDYkK7b4L9X+8iaA58Czo6S9NYcvxtQCw@mail.gmail.com>
Message-ID: <CAA-SZJGB54hBAoiRDHYknCJng6Ct_-ufXFsu80PEDZ33V9QSwQ@mail.gmail.com>

On Tue, Dec 3, 2013 at 9:44 AM, Guido van Rossum <guido at python.org> wrote:
> Thanks for reporting this.

With pleasure! I'm just glad to have reported a valid bug for once in my
life :b

> This really belongs in the Python issue tracker (bugs.python.org) -- can
you submit a bug there?

I've opened issue # 19901 [1] as requested.

> My hunch is that, because this seems to be a relatively new feature, we
should just catch and ignore the exception from that specific call.

I agree, although I sort of phrased it poorly in the bug.

Thank you again for your support (and sorry for the delayed response).
Python is cool :]

[1]: http://bugs.python.org/issue19901
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131205/1da17d8b/attachment.html>

From guido at python.org  Thu Dec  5 22:33:00 2013
From: guido at python.org (Guido van Rossum)
Date: Thu, 5 Dec 2013 13:33:00 -0800
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <20131205211228.GB27767@avalon.amherst.edu>
References: <52A0E469.7090904@mrabarnett.plus.com>
 <CAP1=2W402=CZsj5bnWAJp9fpf8FJ3FMfHSaGY4sJ31FUOkXL1g@mail.gmail.com>
 <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
 <20131205211228.GB27767@avalon.amherst.edu>
Message-ID: <CAP7+vJJQOjtFfSutYuhMdb+-KdSZ43+aXaK=WW3W=NjRTAS9HQ@mail.gmail.com>

On Thu, Dec 5, 2013 at 1:12 PM, Allen Li <cyberdupo56 at gmail.com> wrote:
> On Thu, Dec 05, 2013 at 10:24:11AM -0800, Guido van Rossum wrote:
>> How would you get the docstrings in? It seems cramming that much on a
>> single line doesn't help readability (even though I agree there is a
>> fair amount of boilerplace).
>
> I was basing my initial suggestion somewhat on collections.namedtuple,
> which doesn't support docstring either.

Not yet. :-) (http://bugs.python.org/issue16669)

> One option would be to simply
> not allow for docstrings, requiring the boilerplate method, the other
> would be to add a parameter for the docstring:
>
> make_abstractmethod(name, arglist, docstring='')
>
> On Thu, Dec 5, 2013 at 2:22 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
>
>> On 12/05/2013 10:56 AM, Alexander Belopolsky wrote:
>>
>>> On Thu, Dec 5, 2013 at 1:24 PM, Guido van Rossum wrote:
>>>
>>>>
>>>> How would you get the docstrings in? [...]
>>>>
>>>
>>> One way to reduce the amount of boilerplate code is to make abstractmethod
>>> to supply raise NotImplementedError body when none is given.  Then you can
>>>  write
>>>
>>> class Foo:
>>>      @abc.abstractmethod
>>>      def do_bar(self):
>>>           """perform bar"""
>>>
>>> The docstring will be required when skipping the body which is probably a
>>> good thing.
>>>
>>
>> How will abstractmethod know its function has no body?
>
> I don't think this is a good idea at all, very magical behavior.  It is
> not intuitive or explicit that an abstractmethod-decorated empty
> function raises NotImplementedError.

Agreed.

> On Thu, Dec 05, 2013 at 03:06:00PM -0500, Brett Cannon wrote:
>> But I would be very leery of this being a default behaviour. Raising
>> NotImplementedError is not necessarily what the default result should be
>> for a method. If you are building a class that supports multiple
>> inheritance you will be calling super().do_bar() almost blindly which, if
>> you are not careful, will raise NotImplementedError and that might not be
>> appropriate. Maybe returning None is more reasonable, maybe raising
>> TypeError. But support a default blindly like this can promote bad
>> practices.
>
> I'm not sure what's considered best practice with super() at the moment.
> super() is dangerous if you don't know what you are doing in
> multi-inheritance design, so I'd consider calling super() blindly is the
> problem here, not raising NotImplementedError.

Actually I think the combination of not knowing what you're doing and
mulitple inheritance is the problem.

> I do think raising
> NotImplementedError is reasonable default behavior for an
> abstractmethod.

When not using multiple inheritance, yes.

> The only two alternatives are doing nothing/pass/return
> None or having actual code in the method.
>
> The former is only useful to silently ignore blind super() calling, the
> latter you would define and decorate the method normally.

Actually if you want to support multiple inheritance of your ABC, your
abstract methods *must* be no-ops (or have some kind of default
behavior that can always be done last).

> On Thu, Dec 05, 2013 at 08:39:05PM +0000, MRAB wrote:
>> An abstract method won't have a body (I'm not counting the docstring).
>>
>> If it _does_ have a body, then it's _not_ an abstract method!
>
> It could have a body, though I would agree it's not commonly used that
> way.  Maybe something like the following (though it's a poor example):
>
> class Printer(metaclass=abc.ABCMeta):
>
>     @abc.abstractmethod
>     def print(self):
>         print("Print done.")
>
> class Foo(Printer):
>
>     def print(self):
>         print('foo')
>         super().print()

That's exactly right.

-- 
--Guido van Rossum (python.org/~guido)

From ethan at stoneleaf.us  Thu Dec  5 22:28:03 2013
From: ethan at stoneleaf.us (Ethan Furman)
Date: Thu, 05 Dec 2013 13:28:03 -0800
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <20131205182022.GA27767@avalon.amherst.edu>
References: <20131205182022.GA27767@avalon.amherst.edu>
Message-ID: <52A0EFE3.7090208@stoneleaf.us>

On 12/05/2013 10:20 AM, Allen Li wrote:
>
> 90% of the time, it ends up looking something like this:
>
> class Foo(metaclass=abc.ABCMeta):
>
>      @abc.abstractmethod
>      def f1(self):
>          raise NotImplementedError
>
>      @staticmethod
>      @abc.abstractmethod
>      def f2(arg1):
>          raise NotImplementedError

I think we're getting sidetracked by the `raise NotImplementedError` -- why do you have that line in there?  If I 
understand the ABCs correctly a class that does *not* have concrete methods to replace the abstract methods will raise 
an exception at class creation time, so why do you need the `raise NotImplementedError`?  It would only ever happen on a 
super() type of call.

Having said all that, I would hope that any abstract class I had to implement would have good doc strings, and the 
multi-line format is much easier to read.

-1 on the one-liner.

--
~Ethan~

From fil at pobox.com  Fri Dec  6 02:31:07 2013
From: fil at pobox.com (Fil Mackay)
Date: Fri, 6 Dec 2013 12:31:07 +1100
Subject: [Python-Dev] Python-Dev Digest, Vol 125, Issue 5
In-Reply-To: <mailman.75.1386241205.9540.python-dev@python.org>
References: <mailman.75.1386241205.9540.python-dev@python.org>
Message-ID: <CAKgz=nBYGMXTiXHXxR6t3kHk90DxOoSnu-fqYdLgxdUej429gg@mail.gmail.com>

Hi Antoine,

> I've found that libffi does support this type, but sadly ctypes and cffi
> do
> > not. Adding to ctypes does not seem to be trivial, since the description
> of
> > an integer type is limited to a single character ("q" in the case of long
> > long). "q" is considered to be a length of 8, whereas what I really want
> is
> > the integer type "ll" which is correctly considered length of 16.
>
> Aren't you talking about the struct module? In ctypes, it seems it
> would be sufficient to add a "c_int128" type (and/or "c_uint128").
>

Adding a c_int128 type seems somewhat non trivial though. The
specific-sized c_intX types are assigned to the named equivalents (c_long
etc.). Getting a named type that equates to 128-bit (on OSX at least
anyway) is the problem.

The :

class c_something(_SimpleCData):
    _type_ = "?"
_check_size(c_something)

The type "q" seems to relate to "long long" ("q"uad word?) - but that has a
size of 8 for me. I don't know: what "something" should be, and what "?"
should be.

I am guessing stay away from the "long long long" schenanigans and just
define c_int128 directly:

class c_int128(_SimpleCData):
    _type_ = "?"

.. but there still seems to lack a _type_ that will relate to a 128-bit
integer..

OK, it seems that adding a new "?" that relates to 128-bit requires the
change to struct module. This seems to be in lib-dynload and is written in
C not python?

> Can anyone give me some pointers as to why this has not been added to
> date,
> > and the best line of attack?
>
> Probably because noone needed it until now?
>
> We have a comprehensive guide if you want to contribute a patch:
> http://docs.python.org/devguide/
>
> The first step would be to open an enhancement request on the
> issue tracker, the discussion will then move on there:
> http://bugs.python.org/


> (if you want to enhance both the ctypes and struct modules, please open
> a separate issue for each)
>

OK, thanks. I had been put off by the "bugs" title since this is an
enhancement.. will do.

Regards, Fil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131206/319be03f/attachment.html>

From tim.peters at gmail.com  Fri Dec  6 02:52:28 2013
From: tim.peters at gmail.com (Tim Peters)
Date: Thu, 5 Dec 2013 19:52:28 -0600
Subject: [Python-Dev] Python 3 is five years old
In-Reply-To: <CAP1=2W4cxP0YCxPho7qgm85cvb+w=MpBTPP5B3-K1QTUDtf2eA@mail.gmail.com>
References: <CAP1=2W4cxP0YCxPho7qgm85cvb+w=MpBTPP5B3-K1QTUDtf2eA@mail.gmail.com>
Message-ID: <CAExdVNm047S=Rq52TnF0g-z_reYf0rWp9ubvt+raCRjBcv84zQ@mail.gmail.com>

[Brett]
> On 2008-12-03, Python 3.0.0 was released by Barry.

Dang - nobody ever tells me anything.  Congratulations!  It's about
time 3.0.0 was released ;-)

> ...
> Thanks to those in the community who stuck by the dev team and had faith
> we knew what we were doing and have continued to help everyone move
> forward and off of Python 2 to realize how much more pleasant Python 3
> is to work with.

I'm doing all my own coding in 3 now - I like it.  I just wish someone
had told me in 2008 ;-)

From cyberdupo56 at gmail.com  Fri Dec  6 03:08:12 2013
From: cyberdupo56 at gmail.com (Allen Li)
Date: Thu, 5 Dec 2013 21:08:12 -0500
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <20131206020629.GA15017@avalon.amherst.edu>
References: <52A0E469.7090904@mrabarnett.plus.com>
 <CAP1=2W402=CZsj5bnWAJp9fpf8FJ3FMfHSaGY4sJ31FUOkXL1g@mail.gmail.com>
 <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
 <20131205211228.GB27767@avalon.amherst.edu>
 <CAP7+vJJQOjtFfSutYuhMdb+-KdSZ43+aXaK=WW3W=NjRTAS9HQ@mail.gmail.com>
 <20131206020629.GA15017@avalon.amherst.edu>
Message-ID: <20131206020812.GB15017@avalon.amherst.edu>

On Thu, Dec 05, 2013 at 01:33:00PM -0800, Guido van Rossum wrote:
> > The only two alternatives are doing nothing/pass/return
> > None or having actual code in the method.
> >
> > The former is only useful to silently ignore blind super() calling, the
> > latter you would define and decorate the method normally.
> 
> Actually if you want to support multiple inheritance of your ABC, your
> abstract methods *must* be no-ops (or have some kind of default
> behavior that can always be done last).

I must respectfully disagree with this.  If your ABCs aren't meant to be
in the MRO, then you should be @registering them as virtual classes and
not inheriting them.

The trick with Python multiple inheritance and super() (from personal
experience) is to not think of it as multiple inheritance (a tree with
cycles), but as building the MRO (linear, the same as single
inheritance).

From stephen at xemacs.org  Fri Dec  6 03:21:48 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 06 Dec 2013 11:21:48 +0900
Subject: [Python-Dev] Python 3 is five years old
In-Reply-To: <CAExdVNm047S=Rq52TnF0g-z_reYf0rWp9ubvt+raCRjBcv84zQ@mail.gmail.com>
References: <CAP1=2W4cxP0YCxPho7qgm85cvb+w=MpBTPP5B3-K1QTUDtf2eA@mail.gmail.com>
 <CAExdVNm047S=Rq52TnF0g-z_reYf0rWp9ubvt+raCRjBcv84zQ@mail.gmail.com>
Message-ID: <8761r24t37.fsf@uwakimon.sk.tsukuba.ac.jp>

Tim Peters writes:

 > I'm doing all my own coding in 3 now - I like it.  I just wish someone
 > had told me in 2008 ;-)

I think it's a testament to the basic strength of the language that
you haven't noticed that *nothing has changed* in Python 2 for several
years. ;-)


From ethan at stoneleaf.us  Fri Dec  6 03:31:16 2013
From: ethan at stoneleaf.us (Ethan Furman)
Date: Thu, 05 Dec 2013 18:31:16 -0800
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <20131206020812.GB15017@avalon.amherst.edu>
References: <52A0E469.7090904@mrabarnett.plus.com>
 <CAP1=2W402=CZsj5bnWAJp9fpf8FJ3FMfHSaGY4sJ31FUOkXL1g@mail.gmail.com>
 <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
 <20131205211228.GB27767@avalon.amherst.edu>
 <CAP7+vJJQOjtFfSutYuhMdb+-KdSZ43+aXaK=WW3W=NjRTAS9HQ@mail.gmail.com>
 <20131206020629.GA15017@avalon.amherst.edu>
 <20131206020812.GB15017@avalon.amherst.edu>
Message-ID: <52A136F4.2090609@stoneleaf.us>

On 12/05/2013 06:08 PM, Allen Li wrote:
> On Thu, Dec 05, 2013 at 01:33:00PM -0800, Guido van Rossum wrote:
>>
>> Actually if you want to support multiple inheritance of your ABC, your
>> abstract methods *must* be no-ops (or have some kind of default
>> behavior that can always be done last).

Done last or first really depends on what the default behavior is, doesn't it?  Using __new__ as an example, the chain 
of calls for that has the most ancestorish (yeah, I just made that word up ;) method doing the work first, with each 
less-ancestorish method building on to that as the call chain unwinds.


> I must respectfully disagree with this.  If your ABCs aren't meant to be
> in the MRO, then you should be @registering them as virtual classes and
> not inheriting them.

Why would you think they are not meant to be in the MRO?  When dealing with multiple-inheritance, there must be a base 
class that does not try to call super() (object does not work for this) -- what better class to use than the base 
abstract class?

>
> The trick with Python multiple inheritance and super() (from personal
> experience) is to not think of it as multiple inheritance (a tree with
> cycles), but as building the MRO (linear, the same as single
> inheritance).

--
~Ethan~

From guido at python.org  Fri Dec  6 03:57:21 2013
From: guido at python.org (Guido van Rossum)
Date: Thu, 5 Dec 2013 18:57:21 -0800
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <20131206020812.GB15017@avalon.amherst.edu>
References: <52A0E469.7090904@mrabarnett.plus.com>
 <CAP1=2W402=CZsj5bnWAJp9fpf8FJ3FMfHSaGY4sJ31FUOkXL1g@mail.gmail.com>
 <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
 <20131205211228.GB27767@avalon.amherst.edu>
 <CAP7+vJJQOjtFfSutYuhMdb+-KdSZ43+aXaK=WW3W=NjRTAS9HQ@mail.gmail.com>
 <20131206020629.GA15017@avalon.amherst.edu>
 <20131206020812.GB15017@avalon.amherst.edu>
Message-ID: <CAP7+vJKOPYokF02YgU-7G-fXizJzF4xZMuG5kLtWCAAF96OBsQ@mail.gmail.com>

On Thu, Dec 5, 2013 at 6:08 PM, Allen Li <cyberdupo56 at gmail.com> wrote:
> On Thu, Dec 05, 2013 at 01:33:00PM -0800, Guido van Rossum wrote:
>> > The only two alternatives are doing nothing/pass/return
>> > None or having actual code in the method.
>> >
>> > The former is only useful to silently ignore blind super() calling, the
>> > latter you would define and decorate the method normally.
>>
>> Actually if you want to support multiple inheritance of your ABC, your
>> abstract methods *must* be no-ops (or have some kind of default
>> behavior that can always be done last).
>
> I must respectfully disagree with this.  If your ABCs aren't meant to be
> in the MRO, then you should be @registering them as virtual classes and
> not inheriting them.

Registering is meant to be a method of last resort; it is implemented
for cases where an ABC is introduced after implementations already
exist (IOW, formalizing duck typing). When the ABC *is* actually used
as a base class, when the standard M.I. patterns are used, the
abstract methods must be no-ops, because they will be called (last).

> The trick with Python multiple inheritance and super() (from personal
> experience) is to not think of it as multiple inheritance (a tree with
> cycles), but as building the MRO (linear, the same as single
> inheritance).

I'm not sure I understand -- or maybe I disagree. "A tree with cycles"
seems a really poor way to describe what is usually referred to as a
"diamond inheritance diagram". The right patterns require that you
design your class to be unaware of the exact MRO. But we're getting
off-topic. You should probably read one of the standard tutorials on
the topic to refresh your use of the terminology.

-- 
--Guido van Rossum (python.org/~guido)

From guido at python.org  Fri Dec  6 04:07:09 2013
From: guido at python.org (Guido van Rossum)
Date: Thu, 5 Dec 2013 19:07:09 -0800
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <52A136F4.2090609@stoneleaf.us>
References: <52A0E469.7090904@mrabarnett.plus.com>
 <CAP1=2W402=CZsj5bnWAJp9fpf8FJ3FMfHSaGY4sJ31FUOkXL1g@mail.gmail.com>
 <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
 <20131205211228.GB27767@avalon.amherst.edu>
 <CAP7+vJJQOjtFfSutYuhMdb+-KdSZ43+aXaK=WW3W=NjRTAS9HQ@mail.gmail.com>
 <20131206020629.GA15017@avalon.amherst.edu>
 <20131206020812.GB15017@avalon.amherst.edu>
 <52A136F4.2090609@stoneleaf.us>
Message-ID: <CAP7+vJK4dgXWsw6=UnmbzDYXxvxoDc8zjAcT10EUKJuFB9VWaQ@mail.gmail.com>

On Thu, Dec 5, 2013 at 6:31 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
>> On Thu, Dec 05, 2013 at 01:33:00PM -0800, Guido van Rossum wrote:
>>> Actually if you want to support multiple inheritance of your ABC, your
>>> abstract methods *must* be no-ops (or have some kind of default
>>> behavior that can always be done last).

> Done last or first really depends on what the default behavior is, doesn't
> it?  Using __new__ as an example, the chain of calls for that has the most
> ancestorish (yeah, I just made that word up ;) method doing the work first,
> with each less-ancestorish method building on to that as the call chain
> unwinds.

If you count which call *starts* first, the base class is always
called later than the subclass (even if it finishes earlier :-).

-- 
--Guido van Rossum (python.org/~guido)

From apieum at gmail.com  Fri Dec  6 07:28:57 2013
From: apieum at gmail.com (Gregory Salvan)
Date: Fri, 6 Dec 2013 07:28:57 +0100
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <CAP7+vJK4dgXWsw6=UnmbzDYXxvxoDc8zjAcT10EUKJuFB9VWaQ@mail.gmail.com>
References: <52A0E469.7090904@mrabarnett.plus.com>
 <CAP1=2W402=CZsj5bnWAJp9fpf8FJ3FMfHSaGY4sJ31FUOkXL1g@mail.gmail.com>
 <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
 <20131205211228.GB27767@avalon.amherst.edu>
 <CAP7+vJJQOjtFfSutYuhMdb+-KdSZ43+aXaK=WW3W=NjRTAS9HQ@mail.gmail.com>
 <20131206020629.GA15017@avalon.amherst.edu>
 <20131206020812.GB15017@avalon.amherst.edu>
 <52A136F4.2090609@stoneleaf.us>
 <CAP7+vJK4dgXWsw6=UnmbzDYXxvxoDc8zjAcT10EUKJuFB9VWaQ@mail.gmail.com>
Message-ID: <CAAZsQLBfK+_WgZ-SBqQkA6mfg_CLS2BueGtG3oUkx=OxC1c0Mg@mail.gmail.com>

Hi,
maybe a syntax like that can correspond:

class MyObject(metaclass=ObjectSpec):
    ''' MyObject doc'''
    'attr1 contains something'
    attr1 = None
    'attr2 contains something'
    attr2 = str
    'method1 do something'
    method1 = NotImplementedMethod('self', 'arg1', kwarg1=str)


Metaclass "ObjectSpec" would extend ABCMeta to search class source code for
comments before members assignement,
and replace NotImplementedMethod objects by a corresponding method wich
signature can simply be given by arguments or by ArgSpec, FullArgSpec,
Signature...
with factories like these of "Signature" (from_function, from_builtins...).



2013/12/6 Guido van Rossum <guido at python.org>

> On Thu, Dec 5, 2013 at 6:31 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
> >> On Thu, Dec 05, 2013 at 01:33:00PM -0800, Guido van Rossum wrote:
> >>> Actually if you want to support multiple inheritance of your ABC, your
> >>> abstract methods *must* be no-ops (or have some kind of default
> >>> behavior that can always be done last).
>
> > Done last or first really depends on what the default behavior is,
> doesn't
> > it?  Using __new__ as an example, the chain of calls for that has the
> most
> > ancestorish (yeah, I just made that word up ;) method doing the work
> first,
> > with each less-ancestorish method building on to that as the call chain
> > unwinds.
>
> If you count which call *starts* first, the base class is always
> called later than the subclass (even if it finishes earlier :-).
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/apieum%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131206/d6477540/attachment.html>

From steve at pearwood.info  Fri Dec  6 11:46:21 2013
From: steve at pearwood.info (Steven D'Aprano)
Date: Fri, 6 Dec 2013 21:46:21 +1100
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <CAAZsQLBfK+_WgZ-SBqQkA6mfg_CLS2BueGtG3oUkx=OxC1c0Mg@mail.gmail.com>
References: <52A0E469.7090904@mrabarnett.plus.com>
 <CAP1=2W402=CZsj5bnWAJp9fpf8FJ3FMfHSaGY4sJ31FUOkXL1g@mail.gmail.com>
 <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
 <20131205211228.GB27767@avalon.amherst.edu>
 <CAP7+vJJQOjtFfSutYuhMdb+-KdSZ43+aXaK=WW3W=NjRTAS9HQ@mail.gmail.com>
 <20131206020629.GA15017@avalon.amherst.edu>
 <20131206020812.GB15017@avalon.amherst.edu> <52A136F4.2090609@stoneleaf.us>
 <CAP7+vJK4dgXWsw6=UnmbzDYXxvxoDc8zjAcT10EUKJuFB9VWaQ@mail.gmail.com>
 <CAAZsQLBfK+_WgZ-SBqQkA6mfg_CLS2BueGtG3oUkx=OxC1c0Mg@mail.gmail.com>
Message-ID: <20131206104621.GN2085@ando>

On Fri, Dec 06, 2013 at 07:28:57AM +0100, Gregory Salvan wrote:
> Hi,
> maybe a syntax like that can correspond:
> 
> class MyObject(metaclass=ObjectSpec):
>     ''' MyObject doc'''
>     'attr1 contains something'
>     attr1 = None
>     'attr2 contains something'
>     attr2 = str
>     'method1 do something'
>     method1 = NotImplementedMethod('self', 'arg1', kwarg1=str)

I really don't like the idea of extending the docstring syntax to 
arbitrary objects. Docstrings are just the right amount of magic to be 
useful, without being so much as to be confusing. If you extend them to 
arbitrary objects, that crosses the line. I really don't like the look 
of the above, I'd rather see:


class MyObject(metaclass=ObjectSpec):
    ''' MyObject doc

    attr1 contains something
    attr2 contains something

    '''
    attr1 = None
    attr2 = str

    @NotImplementedMethod
    def method1(self, arg1, kwarg1=str):
       '''method1 do something'''


One-liners are over-rated, especially since there isn't that much that 
you can fit in 80 or even 100 chars on a single line. Toy examples, 
like "method1 do something", sure. But real methods that do real things? 
Not so often.

Besides, this suggestion changes the semantics of code, and therefore 
would need to go through a "from __future__ import docstring_everywhere" 
phase. Currently, bare strings can be used for multiline comments, as 
the compiler discards them at compile-time:


fe()
fi()
fo()
fum()
"""At this point, we can smell the blood of any Englishmen in the 
vicinity."""
bread = grind_bones(englishman)


Another issue is that many objects (particularly built-ins) cannot take 
additional attributes. So where are you going to attach the docstrings? 
What are you going to do with singletons like None?

"Amount of spam."""
spam = None

"Amount of eggs."""
eggs = None

print(spam.__doc__)
=> 'Amount of eggs.'



> Metaclass "ObjectSpec" would extend ABCMeta to search class source code for
> comments before members assignement,

What do you expect to happen when the source code is not available?

The behaviour of code should not depend on whether it is pre-compiled or 
not.



-- 
Steven

From guido at python.org  Fri Dec  6 17:00:16 2013
From: guido at python.org (Guido van Rossum)
Date: Fri, 6 Dec 2013 08:00:16 -0800
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <20131206104621.GN2085@ando>
References: <52A0E469.7090904@mrabarnett.plus.com>
 <CAP1=2W402=CZsj5bnWAJp9fpf8FJ3FMfHSaGY4sJ31FUOkXL1g@mail.gmail.com>
 <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
 <20131205211228.GB27767@avalon.amherst.edu>
 <CAP7+vJJQOjtFfSutYuhMdb+-KdSZ43+aXaK=WW3W=NjRTAS9HQ@mail.gmail.com>
 <20131206020629.GA15017@avalon.amherst.edu>
 <20131206020812.GB15017@avalon.amherst.edu>
 <52A136F4.2090609@stoneleaf.us>
 <CAP7+vJK4dgXWsw6=UnmbzDYXxvxoDc8zjAcT10EUKJuFB9VWaQ@mail.gmail.com>
 <CAAZsQLBfK+_WgZ-SBqQkA6mfg_CLS2BueGtG3oUkx=OxC1c0Mg@mail.gmail.com>
 <20131206104621.GN2085@ando>
Message-ID: <CAP7+vJLOwjJGo82fipLCq0h3ZAhnZy3a=iBiJWkarbLZuvmeHg@mail.gmail.com>

We might adopt the conventions promoted by the Sphinx autodoc extension:
http://sphinx-doc.org/ext/autodoc.html#directive-autofunction

Example:

class Foo:
    """Docstring for class Foo."""

    #: Doc comment for class attribute Foo.bar.
    #: It can have multiple lines.
    bar = 1

    flox = 1.5   #: Doc comment for Foo.flox. One line only.

    baz = 2
    """Docstring for class attribute Foo.baz."""

    def __init__(self):
        #: Doc comment for instance attribute qux.
        self.qux = 3

        self.spam = 4
        """Docstring for instance attribute spam."""


-- 
--Guido van Rossum (python.org/~guido)

From status at bugs.python.org  Fri Dec  6 18:07:34 2013
From: status at bugs.python.org (Python tracker)
Date: Fri,  6 Dec 2013 18:07:34 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20131206170734.BF4C756A34@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2013-11-29 - 2013-12-06)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    4323 ( +6)
  closed 27359 (+70)
  total  31682 (+76)

Open issues with patches: 1982 


Issues opened (56)
==================

#10717: Multiprocessing module cannot call instance methods across pro
http://bugs.python.org/issue10717  reopened by alexandre.vassalotti

#16549: regression: -m json.tool module is broken
http://bugs.python.org/issue16549  reopened by Arfrever

#19835: Add a MemoryError singleton to fix an unlimited loop when the 
http://bugs.python.org/issue19835  opened by haypo

#19837: Wire protocol encoding for the JSON module
http://bugs.python.org/issue19837  opened by ncoghlan

#19838: test.test_pathlib.PosixPathTest.test_touch_common fails on Fre
http://bugs.python.org/issue19838  opened by Claudiu.Popa

#19840: The is no way to tell shutil.move to ignore metadata
http://bugs.python.org/issue19840  opened by zodalahtathi

#19841: ConfigParser PEP issues
http://bugs.python.org/issue19841  opened by Ivailo.Monev

#19843: Wait for multiple sub-processes to terminate
http://bugs.python.org/issue19843  opened by giampaolo.rodola

#19846: print() and write() are relying on sys.getfilesystemencoding()
http://bugs.python.org/issue19846  opened by Sworddragon

#19847: Setting the default filesystem-encoding
http://bugs.python.org/issue19847  opened by Sworddragon

#19851: imp.reload problem with submodule
http://bugs.python.org/issue19851  opened by ronaldoussoren

#19855: uuid._find_mac fails if an executable not in /sbin or /usr/sbi
http://bugs.python.org/issue19855  opened by serhiy.storchaka

#19856: Possible bug in shutil.move() on Windows
http://bugs.python.org/issue19856  opened by serhiy.storchaka

#19857: test_imaplib doesn't always reap SocketServer thread
http://bugs.python.org/issue19857  opened by neologix

#19858: Make pickletools.optimize aware of the MEMOIZE opcode.
http://bugs.python.org/issue19858  opened by alexandre.vassalotti

#19861: Update What's New for Python 3.4
http://bugs.python.org/issue19861  opened by serhiy.storchaka

#19862: Unclear xpath caching for custom  namespaces
http://bugs.python.org/issue19862  opened by valeriy.nov

#19863: Missing function attributes in 2.7 docs.
http://bugs.python.org/issue19863  opened by mark.dickinson

#19864: multiprocessing Proxy docs need locking semantics explained
http://bugs.python.org/issue19864  opened by maxpolk

#19865: create_unicode_buffer() fails on non-BMP strings on Windows
http://bugs.python.org/issue19865  opened by gergely.erdelyi

#19866: tests aifc, sunau and wave failures on a fresh Win64 installat
http://bugs.python.org/issue19866  opened by francismb

#19867: pickletools.OpcodeInfo.code is a string
http://bugs.python.org/issue19867  opened by pitrou

#19869: BaseCookie does not complain if a non RFC compliant cookie hea
http://bugs.python.org/issue19869  opened by florianpilz

#19870: Backport Cookie fix to 2.7 (httponly / secure flag)
http://bugs.python.org/issue19870  opened by florianpilz

#19871: json module won't parse a float that starts with a decimal poi
http://bugs.python.org/issue19871  opened by picomancer

#19873: There is a duplicate function in Lib/test/test_pathlib.py
http://bugs.python.org/issue19873  opened by vajrasky

#19875: test_getsockaddrarg occasional failure
http://bugs.python.org/issue19875  opened by pitrou

#19876: selectors (and asyncio?): document behaviour on closed files/s
http://bugs.python.org/issue19876  opened by haypo

#19878: bz2.BZ2File.__init__() cannot be called twice with non-existen
http://bugs.python.org/issue19878  opened by Level

#19879: imageop: bug in error handler
http://bugs.python.org/issue19879  opened by Level

#19880: unittest: on failure, TestCase.run() keeps a reference to the 
http://bugs.python.org/issue19880  opened by haypo

#19883: Integer overflow in zipimport.c
http://bugs.python.org/issue19883  opened by christian.heimes

#19884: Importing readline produces erroneous output
http://bugs.python.org/issue19884  opened by bkabrda

#19885: lzma segfault when __init__ with non-existent file after execu
http://bugs.python.org/issue19885  opened by vajrasky

#19886: Better estimated memory requirements for bigmem tests
http://bugs.python.org/issue19886  opened by serhiy.storchaka

#19887: Path.resolve() ENAMETOOLONG on pathologic symlinks
http://bugs.python.org/issue19887  opened by serhiy.storchaka

#19888: Three argument type() super call sets __name__ but not __qualn
http://bugs.python.org/issue19888  opened by zkrynicki

#19890: Typo in multiprocessing docs
http://bugs.python.org/issue19890  opened by Antony.Lee

#19891: Exiting Python REPL prompt with user without home directory th
http://bugs.python.org/issue19891  opened by vajrasky

#19893: Python cApi memory problem. Py_Initialize memory leak
http://bugs.python.org/issue19893  opened by rstarostecki

#19894: zipfile ignores deflate level settings in zipinfo object
http://bugs.python.org/issue19894  opened by rmilne

#19895: Cryptic error when subclassing multiprocessing classes
http://bugs.python.org/issue19895  opened by Antony.Lee

#19896: Exposing "q" and "Q" to multiprocessing.sharedctypes
http://bugs.python.org/issue19896  opened by Antony.Lee

#19897: Use python as executable instead of python3 in Python 2 docs
http://bugs.python.org/issue19897  opened by berker.peksag

#19898: No tests for dequereviter_new
http://bugs.python.org/issue19898  opened by christian.heimes

#19899: No test for thread.interrupt_main()
http://bugs.python.org/issue19899  opened by christian.heimes

#19900: improve pickle intro
http://bugs.python.org/issue19900  opened by pitrou

#19901: tests fail due to unsupported SO_REUSEPORT when building Pytho
http://bugs.python.org/issue19901  opened by RubyTuesdayDONO

#19902: logging docs don't document integer constants
http://bugs.python.org/issue19902  opened by follower

#19903: Idle: Use inspect.signature for calltips
http://bugs.python.org/issue19903  opened by terry.reedy

#19904: Add 128-bit integer support to struct
http://bugs.python.org/issue19904  opened by fil

#19905: Add 128-bit integer support to ctypes
http://bugs.python.org/issue19905  opened by fil

#19906: Typo in urllib documentation
http://bugs.python.org/issue19906  opened by Claudiu.Popa

#19907: gettext - Non ascii chars in header
http://bugs.python.org/issue19907  opened by Michael.M??ller

#19909: Best practice docs for new SSL features
http://bugs.python.org/issue19909  opened by christian.heimes

#19910: Document that compile() source may be bytes
http://bugs.python.org/issue19910  opened by gvanrossum



Most recent 15 issues with no replies (15)
==========================================

#19910: Document that compile() source may be bytes
http://bugs.python.org/issue19910

#19909: Best practice docs for new SSL features
http://bugs.python.org/issue19909

#19907: gettext - Non ascii chars in header
http://bugs.python.org/issue19907

#19906: Typo in urllib documentation
http://bugs.python.org/issue19906

#19905: Add 128-bit integer support to ctypes
http://bugs.python.org/issue19905

#19903: Idle: Use inspect.signature for calltips
http://bugs.python.org/issue19903

#19902: logging docs don't document integer constants
http://bugs.python.org/issue19902

#19899: No test for thread.interrupt_main()
http://bugs.python.org/issue19899

#19898: No tests for dequereviter_new
http://bugs.python.org/issue19898

#19897: Use python as executable instead of python3 in Python 2 docs
http://bugs.python.org/issue19897

#19896: Exposing "q" and "Q" to multiprocessing.sharedctypes
http://bugs.python.org/issue19896

#19895: Cryptic error when subclassing multiprocessing classes
http://bugs.python.org/issue19895

#19894: zipfile ignores deflate level settings in zipinfo object
http://bugs.python.org/issue19894

#19890: Typo in multiprocessing docs
http://bugs.python.org/issue19890

#19867: pickletools.OpcodeInfo.code is a string
http://bugs.python.org/issue19867



Most recent 15 issues waiting for review (15)
=============================================

#19906: Typo in urllib documentation
http://bugs.python.org/issue19906

#19900: improve pickle intro
http://bugs.python.org/issue19900

#19897: Use python as executable instead of python3 in Python 2 docs
http://bugs.python.org/issue19897

#19896: Exposing "q" and "Q" to multiprocessing.sharedctypes
http://bugs.python.org/issue19896

#19894: zipfile ignores deflate level settings in zipinfo object
http://bugs.python.org/issue19894

#19887: Path.resolve() ENAMETOOLONG on pathologic symlinks
http://bugs.python.org/issue19887

#19886: Better estimated memory requirements for bigmem tests
http://bugs.python.org/issue19886

#19883: Integer overflow in zipimport.c
http://bugs.python.org/issue19883

#19880: unittest: on failure, TestCase.run() keeps a reference to the 
http://bugs.python.org/issue19880

#19878: bz2.BZ2File.__init__() cannot be called twice with non-existen
http://bugs.python.org/issue19878

#19876: selectors (and asyncio?): document behaviour on closed files/s
http://bugs.python.org/issue19876

#19863: Missing function attributes in 2.7 docs.
http://bugs.python.org/issue19863

#19855: uuid._find_mac fails if an executable not in /sbin or /usr/sbi
http://bugs.python.org/issue19855

#19843: Wait for multiple sub-processes to terminate
http://bugs.python.org/issue19843

#19841: ConfigParser PEP issues
http://bugs.python.org/issue19841



Top 10 most discussed issues (10)
=================================

#18885: handle EINTR in the stdlib
http://bugs.python.org/issue18885  17 msgs

#19876: selectors (and asyncio?): document behaviour on closed files/s
http://bugs.python.org/issue19876  14 msgs

#19837: Wire protocol encoding for the JSON module
http://bugs.python.org/issue19837  13 msgs

#7105: weak dict iterators are fragile because of unpredictable GC ru
http://bugs.python.org/issue7105  12 msgs

#19888: Three argument type() super call sets __name__ but not __qualn
http://bugs.python.org/issue19888  10 msgs

#19717: resolve() fails when the path doesn't exist
http://bugs.python.org/issue19717   7 msgs

#19834: Unpickling exceptions pickled by Python 2
http://bugs.python.org/issue19834   7 msgs

#19847: Setting the default filesystem-encoding
http://bugs.python.org/issue19847   7 msgs

#19871: json module won't parse a float that starts with a decimal poi
http://bugs.python.org/issue19871   7 msgs

#19891: Exiting Python REPL prompt with user without home directory th
http://bugs.python.org/issue19891   7 msgs



Issues closed (68)
==================

#2295: cPickle corner case - docs or bug?
http://bugs.python.org/issue2295  closed by alexandre.vassalotti

#2799: Remove _PyUnicode_AsString(), rework _PyUnicode_AsStringAndSiz
http://bugs.python.org/issue2799  closed by alexandre.vassalotti

#3657: pickle can pickle the wrong function
http://bugs.python.org/issue3657  closed by alexandre.vassalotti

#3693: Obscure array.array error message
http://bugs.python.org/issue3693  closed by alexandre.vassalotti

#6477: Pickling of NoneType raises PicklingError
http://bugs.python.org/issue6477  closed by alexandre.vassalotti

#9269: Cannot pickle self-referencing sets
http://bugs.python.org/issue9269  closed by alexandre.vassalotti

#9276: pickle should support methods
http://bugs.python.org/issue9276  closed by alexandre.vassalotti

#9709: test_distutils warning: initfunc exported twice on Windows
http://bugs.python.org/issue9709  closed by skrah

#11349: _pickle should implement the module finalisation protocol
http://bugs.python.org/issue11349  closed by alexandre.vassalotti

#11480: Cannot copy a class with a metaclass other than type
http://bugs.python.org/issue11480  closed by alexandre.vassalotti

#11854: __or__ et al instantiate subclass of set without calling __ini
http://bugs.python.org/issue11854  closed by mark.dickinson

#13520: Patch to make pickle aware of __qualname__
http://bugs.python.org/issue13520  closed by alexandre.vassalotti

#15667: PEP 3121, 384 refactoring applied to pickle module
http://bugs.python.org/issue15667  closed by alexandre.vassalotti

#15798: subprocess.Popen() fails if 0, 1 or 2 descriptor is closed
http://bugs.python.org/issue15798  closed by gregory.p.smith

#16231: pickle persistent_id return value
http://bugs.python.org/issue16231  closed by alexandre.vassalotti

#17897: Optimize unpickle prefetching
http://bugs.python.org/issue17897  closed by serhiy.storchaka

#18015: python 2.7.5 fails to unpickle namedtuple pickled by 2.7.3 or 
http://bugs.python.org/issue18015  closed by alexandre.vassalotti

#18073: pickle.Unpickler may read too many bytes, causing hangs with b
http://bugs.python.org/issue18073  closed by alexandre.vassalotti

#18699: What is Future.running() for in PEP 3148 / concurrent.futures.
http://bugs.python.org/issue18699  closed by gvanrossum

#18840: Tutorial recommends pickle module without any warning of insec
http://bugs.python.org/issue18840  closed by pitrou

#18843: Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at P
http://bugs.python.org/issue18843  closed by neologix

#18994: Inside fcntl module, we does not check the return code of all_
http://bugs.python.org/issue18994  closed by neologix

#19088: TypeError with pickle in embedded python3.3 when starting mult
http://bugs.python.org/issue19088  closed by alexandre.vassalotti

#19138: doctest.IGNORE_EXCEPTION_DETAIL doesn't match when no detail e
http://bugs.python.org/issue19138  closed by tim.peters

#19296: Compiler warning when compiling dbm module
http://bugs.python.org/issue19296  closed by christian.heimes

#19454: devguide: Document what a "platform support" is
http://bugs.python.org/issue19454  closed by gvanrossum

#19509: No SSL match_hostname() in ftp, imap, nntp, pop, smtp modules
http://bugs.python.org/issue19509  closed by christian.heimes

#19595: Silently skipped test in test_winsound
http://bugs.python.org/issue19595  closed by zach.ware

#19665: test_logging fails with SMTPHandler timeout
http://bugs.python.org/issue19665  closed by python-dev

#19707: Check if unittest.mock needs updating for PEP 451
http://bugs.python.org/issue19707  closed by brett.cannon

#19726: BaseProtocol is not an ABC
http://bugs.python.org/issue19726  closed by gvanrossum

#19741: tracemalloc: tracemalloc_log_alloc() doesn't check _Py_HASHTAB
http://bugs.python.org/issue19741  closed by python-dev

#19754: pickletools.optimize doesn't reframe correctly
http://bugs.python.org/issue19754  closed by alexandre.vassalotti

#19757: _tracemalloc.c: compiler warning with gil_state
http://bugs.python.org/issue19757  closed by python-dev

#19780: Pickle 4 frame headers optimization
http://bugs.python.org/issue19780  closed by pitrou

#19781: No SSL match_hostname() in ftplib
http://bugs.python.org/issue19781  closed by christian.heimes

#19782: No SSL match_hostname() in imaplib
http://bugs.python.org/issue19782  closed by christian.heimes

#19783: No SSL match_hostname() in nntplib
http://bugs.python.org/issue19783  closed by christian.heimes

#19784: No SSL match_hostname() in poplib
http://bugs.python.org/issue19784  closed by christian.heimes

#19785: No SSL match_hostname() in smtplib
http://bugs.python.org/issue19785  closed by christian.heimes

#19789: Improve wording of how to "undo" a call to logging.disable(lvl
http://bugs.python.org/issue19789  closed by python-dev

#19800: Write more detailed framing tests
http://bugs.python.org/issue19800  closed by pitrou

#19814: Document prefix matching behavior of argparse, particularly fo
http://bugs.python.org/issue19814  closed by eli.bendersky

#19827: Optimize socket.settimeout() and socket.setblocking(): avoid s
http://bugs.python.org/issue19827  closed by python-dev

#19831: tracemalloc: stop the module later at Python shutdown
http://bugs.python.org/issue19831  closed by python-dev

#19833: asyncio: patches to document EventLoop and add more examples
http://bugs.python.org/issue19833  closed by haypo

#19836: selectors: improve examples section
http://bugs.python.org/issue19836  closed by gvanrossum

#19839: bz2: regression wrt supporting files with trailing garbage aft
http://bugs.python.org/issue19839  closed by python-dev

#19842: selectors: refactor BaseSelector implementation
http://bugs.python.org/issue19842  closed by gvanrossum

#19844: os.path.split fails on windows path
http://bugs.python.org/issue19844  closed by christian.heimes

#19845: Compiling Python on Windows docs
http://bugs.python.org/issue19845  closed by zach.ware

#19848: Misleading error on creating already existed symlink
http://bugs.python.org/issue19848  closed by serhiy.storchaka

#19849: selectors behaviour on EINTR undocumented
http://bugs.python.org/issue19849  closed by neologix

#19850: asyncio: limit EINTR occurrences with SA_RESTART
http://bugs.python.org/issue19850  closed by neologix

#19852: Misplaced private API method in pathlib.py
http://bugs.python.org/issue19852  closed by pitrou

#19853: Add support for Bitrig to 2.7
http://bugs.python.org/issue19853  closed by brett.cannon

#19854: Add support for Bitrig to 3.4
http://bugs.python.org/issue19854  closed by brett.cannon

#19859: functools.lru_cache keeps objects alive forever
http://bugs.python.org/issue19859  closed by rhettinger

#19860: asyncio: Add context manager to BaseEventLoop?
http://bugs.python.org/issue19860  closed by gvanrossum

#19868: Importing humanhash and uuid causes a segmentation fault crash
http://bugs.python.org/issue19868  closed by ned.deily

#19872: Remove unused imports in pathlib
http://bugs.python.org/issue19872  closed by pitrou

#19874: test_logging failures on Snow Leopard
http://bugs.python.org/issue19874  closed by vinay.sajip

#19877: test_resolve_dot of test_pathlib.py fails on Windows Vista
http://bugs.python.org/issue19877  closed by pitrou

#19881: Fix bigmem pickle tests
http://bugs.python.org/issue19881  closed by alexandre.vassalotti

#19882: Closing a socket when makefile() is used
http://bugs.python.org/issue19882  closed by pitrou

#19889: Revision information missing in Python 2.6.9
http://bugs.python.org/issue19889  closed by barry

#19892: register.send_metadata fails with EOFError: EOF when reading a
http://bugs.python.org/issue19892  closed by neaj

#19908: pathlib.PureWindowsPath doesn't join relative paths correctly 
http://bugs.python.org/issue19908  closed by serhiy.storchaka

From tjreedy at udel.edu  Sat Dec  7 00:44:59 2013
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 06 Dec 2013 18:44:59 -0500
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <20131206104621.GN2085@ando>
References: <52A0E469.7090904@mrabarnett.plus.com>
 <CAP1=2W402=CZsj5bnWAJp9fpf8FJ3FMfHSaGY4sJ31FUOkXL1g@mail.gmail.com>
 <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
 <20131205211228.GB27767@avalon.amherst.edu>
 <CAP7+vJJQOjtFfSutYuhMdb+-KdSZ43+aXaK=WW3W=NjRTAS9HQ@mail.gmail.com>
 <20131206020629.GA15017@avalon.amherst.edu>
 <20131206020812.GB15017@avalon.amherst.edu> <52A136F4.2090609@stoneleaf.us>
 <CAP7+vJK4dgXWsw6=UnmbzDYXxvxoDc8zjAcT10EUKJuFB9VWaQ@mail.gmail.com>
 <CAAZsQLBfK+_WgZ-SBqQkA6mfg_CLS2BueGtG3oUkx=OxC1c0Mg@mail.gmail.com>
 <20131206104621.GN2085@ando>
Message-ID: <l7tnhj$v2u$1@ger.gmane.org>

On 12/6/2013 5:46 AM, Steven D'Aprano wrote:
> On Fri, Dec 06, 2013 at 07:28:57AM +0100, Gregory Salvan wrote:

>> class MyObject(metaclass=ObjectSpec):
>>      ''' MyObject doc'''
>>      'attr1 contains something'
>>      attr1 = None
>>      'attr2 contains something'
>>      attr2 = str
>>      'method1 do something'
>>      method1 = NotImplementedMethod('self', 'arg1', kwarg1=str)
>
> I really don't like the idea of extending the docstring syntax to
> arbitrary objects.
 > ...
> Another issue is that many objects (particularly built-ins) cannot take
> additional attributes. So where are you going to attach the docstrings?

For data attributes, which are usually mutable, it should be attached to 
the attribute *concept*, which is represented by the name, rather than 
the current but usually changeable value. Values are usually already 
documented either by a value representation or a docstring. This could 
be done with a string subclass that is used as needed.

For methods, the value is nearly always constant. When multiple methods 
share the same function, they usually also share the same name, and 
represent the same concept.

A half-way measure would be to extend help() (pydoc, I guess) to 
recognize the same attribute comment conventions as Sphinx autodoc when 
source is available, as it usually is. If we do this, I think the 
conventions should be 'blessed' in an info pep. Docstrings are seldom 
needed for runtime execution, which is why we have an option to remove them.

-- 
Terry Jan Reedy


From stephen at xemacs.org  Sat Dec  7 02:05:07 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 07 Dec 2013 10:05:07 +0900
Subject: [Python-Dev] Attribute docstrings [was: One-line abstractmethod
	function?]
In-Reply-To: <l7tnhj$v2u$1@ger.gmane.org>
References: <52A0E469.7090904@mrabarnett.plus.com>
 <CAP1=2W402=CZsj5bnWAJp9fpf8FJ3FMfHSaGY4sJ31FUOkXL1g@mail.gmail.com>
 <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
 <20131205211228.GB27767@avalon.amherst.edu>
 <CAP7+vJJQOjtFfSutYuhMdb+-KdSZ43+aXaK=WW3W=NjRTAS9HQ@mail.gmail.com>
 <20131206020629.GA15017@avalon.amherst.edu>
 <20131206020812.GB15017@avalon.amherst.edu>
 <52A136F4.2090609@stoneleaf.us>
 <CAP7+vJK4dgXWsw6=UnmbzDYXxvxoDc8zjAcT10EUKJuFB9VWaQ@mail.gmail.com>
 <CAAZsQLBfK+_WgZ-SBqQkA6mfg_CLS2BueGtG3oUkx=OxC1c0Mg@mail.gmail.com>
 <20131206104621.GN2085@ando> <l7tnhj$v2u$1@ger.gmane.org>
Message-ID: <87vbz131z0.fsf@uwakimon.sk.tsukuba.ac.jp>

Reply-To set to python-ideas at python.org.

Terry Reedy writes:

 > For data attributes, which are usually mutable, it should be attached to 
 > the attribute *concept*, which is represented by the name, rather than 
 > the current but usually changeable value. Values are usually already 
 > documented either by a value representation or a docstring. This could 
 > be done with a string subclass that is used as needed.
 > 
 > For methods, the value is nearly always constant. When multiple methods 
 > share the same function, they usually also share the same name, and 
 > represent the same concept.

Aside: Properties are which?  Data, or method?  It's also not clear to
me that "def first (self): return self.values[0]" is unlikely to be
used for completely different purposes than getting the head of a
list.  I conclude the considerations above are mostly red herrings.

The important thing, I suppose, is that the names of attributes
defined in a class are not mutable.  This means that their docstrings
can be kept in a completely separate dict (or other string -> string
mapping), which could even be stored in a separate file.  (Emacs Lisp
uses this to good effect.  The DOC file for XEmacs is 1.6MB; for GNU
Emacs it's 2.4MB.)  Of course it has its problems, but they're pretty
minor.



From rosuav at gmail.com  Sat Dec  7 14:35:52 2013
From: rosuav at gmail.com (Chris Angelico)
Date: Sun, 8 Dec 2013 00:35:52 +1100
Subject: [Python-Dev] Buildbot running Debian amd64 as root
Message-ID: <CAPTjJmpB7foyaQZMuOWPaxoLb96keTJsKta9qdiyK5hi-y+DqA@mail.gmail.com>

In another thread it was suggested that a new buildbot running as root
would be of value. I've spun up a virtual machine running Debian
Wheezy amd64, have installed buildbot from the repository (version
0.8.6p1), and am ready to have it join the farm. How do I go about
doing this?

I've followed the instructions in
https://wiki.python.org/moin/BuildBot as far as creating the slave.
There's a user named buildbot but I'll be running the buildslave
command as root - that would do it, right? Which means I just need to
set up a name and password.

The VM has 1GB RAM and is permitted up to two cores of my i5 CPU, and
has 120GB disk space available. It's running behind NAT, which should
be safe against accidental problems, but not malicious compromise.
I'll look into firewalling it off to keep things safeish but mainly
I'm trusting that Python core devs aren't going to be attacking my
network :)

ChrisA

From seotaewong40 at yahoo.co.kr  Sun Dec  8 04:03:40 2013
From: seotaewong40 at yahoo.co.kr (TaeWong)
Date: Sun, 8 Dec 2013 11:03:40 +0800 (SGT)
Subject: [Python-Dev] Add Gentoo packagers of external modules to Misc/ACKS
Message-ID: <1386471820.89814.YahooMailNeo@web193101.mail.sg3.yahoo.com>

Please add the Gentoo packagers of external modules to Misc/ACKS:

Rob Cakebread
Corentin Chary
Ian Delaney
Sebastien Fabbro
Mike Gilbert
Carsten Lohrke
Jan Matejka
Rafael Martins
Patrick McLean
Tiziano M?ller
Dirkjan Ochtman
Bryan ?stergaard
Krzysztof Pawlik
Ali Polatel
Thomas Raschbacher
Jesus Rivero
Lisa M. Seelye
Fernando Serboncini
Jason Shoemaker
Lukasz Strzygowski
Michael Tindal
Alastair Tse
Amadeusz ?o?nowski
Marien Zwart


From guido at python.org  Sun Dec  8 05:03:16 2013
From: guido at python.org (Guido van Rossum)
Date: Sat, 7 Dec 2013 20:03:16 -0800
Subject: [Python-Dev] Add Gentoo packagers of external modules to
	Misc/ACKS
In-Reply-To: <1386471820.89814.YahooMailNeo@web193101.mail.sg3.yahoo.com>
References: <1386471820.89814.YahooMailNeo@web193101.mail.sg3.yahoo.com>
Message-ID: <CAP7+vJJ=FJmoP1kvme3t6Cb5t4mTt2UP+_YkcVaEJa_VY3_SMg@mail.gmail.com>

Spam.
On Dec 7, 2013 7:26 PM, "TaeWong" <seotaewong40 at yahoo.co.kr> wrote:

> Please add the Gentoo packagers of external modules to Misc/ACKS:
>
> Rob Cakebread
> Corentin Chary
> Ian Delaney
> Sebastien Fabbro
> Mike Gilbert
> Carsten Lohrke
> Jan Matejka
> Rafael Martins
> Patrick McLean
> Tiziano M?ller
> Dirkjan Ochtman
> Bryan ?stergaard
> Krzysztof Pawlik
> Ali Polatel
> Thomas Raschbacher
> Jesus Rivero
> Lisa M. Seelye
> Fernando Serboncini
> Jason Shoemaker
> Lukasz Strzygowski
> Michael Tindal
> Alastair Tse
> Amadeusz ?o?nowski
> Marien Zwart
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131207/87da9eec/attachment.html>

From seotaewong40 at yahoo.co.kr  Sun Dec  8 06:02:14 2013
From: seotaewong40 at yahoo.co.kr (TaeWong)
Date: Sun, 8 Dec 2013 13:02:14 +0800 (SGT)
Subject: [Python-Dev] =?euc-kr?q?=B4=E4=C0=E5=3A_Add_Gentoo_packagers_of_e?=
 =?euc-kr?q?xternal_modules_to_Misc/ACKS?=
In-Reply-To: <1386471820.89814.YahooMailNeo@web193101.mail.sg3.yahoo.com>
References: <1386471820.89814.YahooMailNeo@web193101.mail.sg3.yahoo.com>
Message-ID: <1386478934.30515.YahooMailNeo@web193106.mail.sg3.yahoo.com>

Is this a spam post?

This suggestion needs to be accepted.

As you can know, Marien Zwart is a Gentoo developer.


From dirkjan at ochtman.nl  Sun Dec  8 11:07:10 2013
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Sun, 8 Dec 2013 11:07:10 +0100
Subject: [Python-Dev] Add Gentoo packagers of external modules to
	Misc/ACKS
In-Reply-To: <1386471820.89814.YahooMailNeo@web193101.mail.sg3.yahoo.com>
References: <1386471820.89814.YahooMailNeo@web193101.mail.sg3.yahoo.com>
Message-ID: <CAKmKYaAeiteTFd3SG4KUqVTfi-Y3YkoUZw0ZnqAM0xZzGDEWLg@mail.gmail.com>

Tae Wong,

Please don't speak on behalf the Gentoo Python team.

Everyone else, sorry for this, they are definitely not actually
connected to our Gentoo team.

Cheers,

Dirkjan

From rdmurray at bitdance.com  Sun Dec  8 11:29:49 2013
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 08 Dec 2013 05:29:49 -0500
Subject: [Python-Dev] Add Gentoo packagers of external modules to
	Misc/ACKS
In-Reply-To: <CAKmKYaAeiteTFd3SG4KUqVTfi-Y3YkoUZw0ZnqAM0xZzGDEWLg@mail.gmail.com>
References: <1386471820.89814.YahooMailNeo@web193101.mail.sg3.yahoo.com>
 <CAKmKYaAeiteTFd3SG4KUqVTfi-Y3YkoUZw0ZnqAM0xZzGDEWLg@mail.gmail.com>
Message-ID: <20131208102950.6A2D7250C34@webabinitio.net>

As far as we have been able to determine, Tae Wong is in fact a bot
(note the 'seo' in the email address...a tip of the hand, as far as
I can see).  We have removed all access permissions (including email)
from the related account on the bug tracker already.  IMO this address
should be blocked from posting to all python lists.

--David

On Sun, 08 Dec 2013 11:07:10 +0100, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> Tae Wong,
> 
> Please don't speak on behalf the Gentoo Python team.
> 
> Everyone else, sorry for this, they are definitely not actually
> connected to our Gentoo team.
> 
> Cheers,
> 
> Dirkjan
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com

From stephen at xemacs.org  Sun Dec  8 16:26:51 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 09 Dec 2013 00:26:51 +0900
Subject: [Python-Dev] Add Gentoo packagers of external modules
	to	Misc/ACKS
In-Reply-To: <20131208102950.6A2D7250C34@webabinitio.net>
References: <1386471820.89814.YahooMailNeo@web193101.mail.sg3.yahoo.com>
 <CAKmKYaAeiteTFd3SG4KUqVTfi-Y3YkoUZw0ZnqAM0xZzGDEWLg@mail.gmail.com>
 <20131208102950.6A2D7250C34@webabinitio.net>
Message-ID: <87mwkb2wjo.fsf@uwakimon.sk.tsukuba.ac.jp>

R. David Murray writes:
 > As far as we have been able to determine, Tae Wong is in fact a bot
 > (note the 'seo' in the email address...a tip of the hand,

It's not a good idea to guess about foreign words, including names.
"seo" is a common romanized spelling for a Korean syllable (or perhaps
part of one).  That doesn't mean Tae Wong isn't a 'bot, of course, but
it's a leap to suppose SEO stands for "search engine optimization".


From dmi.baranov at gmail.com  Sun Dec  8 19:11:33 2013
From: dmi.baranov at gmail.com (Dmitriy Baranov)
Date: Sun, 8 Dec 2013 21:11:33 +0300
Subject: [Python-Dev] Add Gentoo packagers of external modules to
	Misc/ACKS
In-Reply-To: <20131208102950.6A2D7250C34@webabinitio.net>
References: <1386471820.89814.YahooMailNeo@web193101.mail.sg3.yahoo.com>
 <CAKmKYaAeiteTFd3SG4KUqVTfi-Y3YkoUZw0ZnqAM0xZzGDEWLg@mail.gmail.com>
 <20131208102950.6A2D7250C34@webabinitio.net>
Message-ID: <CAF0v8012NP=o32SX-dGn=8hGRYDHuVF63wVdJqK_NSr45VVjWg@mail.gmail.com>

2013/12/8 R. David Murray <rdmurray at bitdance.com>:
> As far as we have been able to determine, Tae Wong is in fact a bot
> (note the 'seo' in the email address...a tip of the hand, as far as
> I can see).  We have removed all access permissions (including email)
> from the related account on the bug tracker already.  IMO this address
> should be blocked from posting to all python lists.

Tae Wong bot used a seotaewong40 at gmail.com address before, that new. I
think rule about "taewong" in address will be enough.

>
> --David
>
> On Sun, 08 Dec 2013 11:07:10 +0100, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
>> Tae Wong,
>>
>> Please don't speak on behalf the Gentoo Python team.
>>
>> Everyone else, sorry for this, they are definitely not actually
>> connected to our Gentoo team.
>>
>> Cheers,
>>
>> Dirkjan
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/dmi.baranov%40gmail.com

From mail at timgolden.me.uk  Sun Dec  8 19:23:19 2013
From: mail at timgolden.me.uk (Tim Golden)
Date: Sun, 08 Dec 2013 18:23:19 +0000
Subject: [Python-Dev] Add Gentoo packagers of external modules to
	Misc/ACKS
In-Reply-To: <CAF0v8012NP=o32SX-dGn=8hGRYDHuVF63wVdJqK_NSr45VVjWg@mail.gmail.com>
References: <1386471820.89814.YahooMailNeo@web193101.mail.sg3.yahoo.com>
 <CAKmKYaAeiteTFd3SG4KUqVTfi-Y3YkoUZw0ZnqAM0xZzGDEWLg@mail.gmail.com>
 <20131208102950.6A2D7250C34@webabinitio.net>
 <CAF0v8012NP=o32SX-dGn=8hGRYDHuVF63wVdJqK_NSr45VVjWg@mail.gmail.com>
Message-ID: <52A4B917.1070004@timgolden.me.uk>

On 08/12/2013 18:11, Dmitriy Baranov wrote:
> 2013/12/8 R. David Murray <rdmurray at bitdance.com>:
>> As far as we have been able to determine, Tae Wong is in fact a bot
>> (note the 'seo' in the email address...a tip of the hand, as far as
>> I can see).  We have removed all access permissions (including email)
>> from the related account on the bug tracker already.  IMO this address
>> should be blocked from posting to all python lists.

He doesn't appear to have a subscription to python-list. (And I don't 
remember seeing any of these posts there, in any case).

TJG


From victor.stinner at gmail.com  Sun Dec  8 21:43:40 2013
From: victor.stinner at gmail.com (Victor Stinner)
Date: Sun, 8 Dec 2013 21:43:40 +0100
Subject: [Python-Dev] Add Gentoo packagers of external modules to
	Misc/ACKS
In-Reply-To: <1386471820.89814.YahooMailNeo@web193101.mail.sg3.yahoo.com>
References: <1386471820.89814.YahooMailNeo@web193101.mail.sg3.yahoo.com>
Message-ID: <CAMpsgwYDzmr4iZhjN6df6iF0fSst0u6sT5gr-YFaAafzMi1Bjw@mail.gmail.com>

Hi,

Packagers provide an important help and I would like to thank all
packagers! For CPython, we don't have the habit of listing
"third-party" contributors, but only direct contributors. For example,
Django helped a lot for the popularity of the Python language, but we
don't list them in Misc/ACKS.

So thank you all packagers!

By the way, it would be nice to limit patches on Python packages. Do
you know how to do that?

Victor

2013/12/8 TaeWong <seotaewong40 at yahoo.co.kr>:
> Please add the Gentoo packagers of external modules to Misc/ACKS:
>
> Rob Cakebread
> Corentin Chary
> Ian Delaney
> Sebastien Fabbro
> Mike Gilbert
> Carsten Lohrke
> Jan Matejka
> Rafael Martins
> Patrick McLean
> Tiziano M?ller
> Dirkjan Ochtman
> Bryan ?stergaard
> Krzysztof Pawlik
> Ali Polatel
> Thomas Raschbacher
> Jesus Rivero
> Lisa M. Seelye
> Fernando Serboncini
> Jason Shoemaker
> Lukasz Strzygowski
> Michael Tindal
> Alastair Tse
> Amadeusz ?o?nowski
> Marien Zwart
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com

From victor.stinner at gmail.com  Mon Dec  9 02:56:26 2013
From: victor.stinner at gmail.com (Victor Stinner)
Date: Mon, 9 Dec 2013 02:56:26 +0100
Subject: [Python-Dev] tracemalloc: add an optional memory limit
Message-ID: <CAMpsgwZi9N9nEsjxLvocpJStLcnE6R=64D=iZ5pO3t36Sn+iWg@mail.gmail.com>

Hi,

The PEP 454 (tracemalloc module) has been implemented in Python 3.4
beta 1. Previously, I also wrote a pyfailmalloc project to test how
Python behaves on memory allocation failures. I found various bugs
using this tool.

I propose to add an optional memory limit feature to the
tracemallocmodule. It would allow to set an arbitrary limit (ex: 100
MB) to check how your application behaves on systems with a few free
memory (ex: embedded devices).

What do you think of this enhancement? Would it fit Python 3.4
timeline? It's a new feature, but for a module which was introduced in
Python 3.4. I wanted to propose directly the feature in the PEP, but
Python was not ready for that (Python failed to handle correctly
memory allocation failures).

On Linux, it's possible to limit globally the "address space" of a
process, but this value is not convinient. For example, the address
space includes shared memory and read-only memory mappings of files,
whereas this memory should not reduce the memory available for other
applications. tracemalloc only counts memory directly allocated by
Python and so private memory which reduces directly the memory
available for other applications.

Technically, it's interesting to implement this feature in
tracemalloc. No new code should be added to count how many bytes were
allocated by Python, tracemalloc must already do that (indirectly).
It's simple to modify tracemalloc to make malloc() fails if an
allocation would make the counter greater than the limit.

I wrote a patch in the following issue to add an optional memory_limit
parameter to tracemalloc.start():
http://bugs.python.org/issue19817

The patch is short:

 Doc/library/tracemalloc.rst  |    6 +++-
 Lib/test/test_tracemalloc.py |   11 +++++++-
 Modules/_tracemalloc.c       |   56 ++++++++++++++++++++++++++++++++++++-------
 3 files changed, 63 insertions(+), 10 deletions(-)

--

I tried to fix all bugs in Python to handle correctly memory
allocation failures. When the memory limit is very low (less than 1024
bytes), there are still some corner cases where Python may crash.
These corner cases can be fixed. For example, I proposed a patch to
make PyErr_NoMemory() more reliable (which is probably the most
critical bug of remaining bugs):
http://bugs.python.org/issue19835

I fixed a reference leak in the unittest module (#19880) to reduce the
risk of PyErr_NoMemory() crash when I use the Python test suite to
test the memory limit feature (see issue #19817). I'm not sure that
PyErr_NoMemory() bug affects real applications.

Victor

From storchaka at gmail.com  Mon Dec  9 10:07:38 2013
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 11:07:38 +0200
Subject: [Python-Dev] tracemalloc: add an optional memory limit
In-Reply-To: <CAMpsgwZi9N9nEsjxLvocpJStLcnE6R=64D=iZ5pO3t36Sn+iWg@mail.gmail.com>
References: <CAMpsgwZi9N9nEsjxLvocpJStLcnE6R=64D=iZ5pO3t36Sn+iWg@mail.gmail.com>
Message-ID: <l8417t$u6i$1@ger.gmane.org>

09.12.13 03:56, Victor Stinner ???????(??):
> On Linux, it's possible to limit globally the "address space" of a
> process, but this value is not convinient. For example, the address
> space includes shared memory and read-only memory mappings of files,
> whereas this memory should not reduce the memory available for other
> applications. tracemalloc only counts memory directly allocated by
> Python and so private memory which reduces directly the memory
> available for other applications.

But tracemalloc doesn't count memory allocated besides Python allocators 
(e.g. memory for executable, static variables and stack, memory 
allocated by extensions and C lib, unallocated but not returned to OS 
dynamical memory). When you want investigate how your program works on 
low memory, e.g. 500 MB, ulimit -v 500000 is much closer to real life 
than tracemalloc.

Limiting memory in tracemalloc can be used only for testing obscure 
corner cases in Python interpreter itself. It will be very rarely used 
since all bugs will be fixed first time (and thank you for your current 
work). So there is more sense implemented it as auxiliary utility than 
as feature of the stdlib module.



From victor.stinner at gmail.com  Mon Dec  9 10:28:17 2013
From: victor.stinner at gmail.com (Victor Stinner)
Date: Mon, 9 Dec 2013 10:28:17 +0100
Subject: [Python-Dev] tracemalloc: add an optional memory limit
In-Reply-To: <l8417t$u6i$1@ger.gmane.org>
References: <CAMpsgwZi9N9nEsjxLvocpJStLcnE6R=64D=iZ5pO3t36Sn+iWg@mail.gmail.com>
 <l8417t$u6i$1@ger.gmane.org>
Message-ID: <CAMpsgwag2EvExb66NvWXqzD-Xbwv3-trd9eQGdjW2XbxwC4gnQ@mail.gmail.com>

Hi,

2013/12/9 Serhiy Storchaka <storchaka at gmail.com>:
> But tracemalloc doesn't count memory allocated besides Python allocators
> (e.g. memory for executable, static variables and stack, memory allocated by
> extensions and C lib, unallocated but not returned to OS dynamical memory).
> When you want investigate how your program works on low memory, e.g. 500 MB,
> ulimit -v 500000 is much closer to real life than tracemalloc.

Well, both limits are useful, but also (completly?) different.

"memory for executable, static variables and stack," : these values
are fixed, so they don't matter at all. Substract them from the RSS
when you choose the memory limit for tracemalloc.

"memory allocated by extensions" : I started to modify some Python
extensions (ex: zlib, bzip2, lzma) to reuse Python memory allocation,
so the memory is also traced by tracemalloc. Memory allocated by other
extensions is not traced.

"and C lib," : correct, this memory is not traced by tracemalloc and
so not counted in the memory limit.

"unallocated but not returned to OS dynamical memory" : it's really
hard to estimate and understand the fragmentation of the heap memory
:-( But this may only concern short peak, and the free memory can be
reused later. If the peak is still lower than the limit, the
fragmentation does not matter

> Limiting memory in tracemalloc can be used only for testing obscure corner
> cases in Python interpreter itself.

In my previous job in embedded device, we hard an *hard* limit for
memory. Python had its own dedicated memory: an hardcoded 30 MB chunk
of memory, reserved for Python. Only memory directly allocated by
Python was stored in this 30 MB chunk. Other allocations ("memory
allocated by extensions, C lib" in your list) was allocated in the
system memory. And I was only concerned of memory directly allocated
by Python.

So being able to run the application on a PC and set a "Python" memory
limit of 30 MB makes sense in such use case.

> It will be very rarely used since all
> bugs will be fixed first time (and thank you for your current work). So
> there is more sense implemented it as auxiliary utility than as feature of
> the stdlib module.

The memory limit is used to test if the application doesn't leak
memory nor allocate more than the limit. Said differently, it's a
convinient tool to simulate an embeded device :-)

Victor

From seotaewong40 at yahoo.co.kr  Mon Dec  9 08:41:45 2013
From: seotaewong40 at yahoo.co.kr (TaeWong)
Date: Mon, 9 Dec 2013 15:41:45 +0800 (SGT)
Subject: [Python-Dev] =?euc-kr?q?=B4=E4=C0=E5=3A__Add_Gentoo_packagers_of_?=
 =?euc-kr?q?external_modules_to_Misc/ACKS?=
In-Reply-To: <CAMpsgwYDzmr4iZhjN6df6iF0fSst0u6sT5gr-YFaAafzMi1Bjw@mail.gmail.com>
References: <1386471820.89814.YahooMailNeo@web193101.mail.sg3.yahoo.com>
 <CAMpsgwYDzmr4iZhjN6df6iF0fSst0u6sT5gr-YFaAafzMi1Bjw@mail.gmail.com>
Message-ID: <1386574905.6788.YahooMailNeo@web193104.mail.sg3.yahoo.com>

Please add access permissions on the Python bug tracker for the seotaewong40 account.

For what it's worth, you need to add Marien Zwart to Misc/ACKS (apparently he has contributed to the GNU Emacs mode for Python).


From seotaewong40 at yahoo.co.kr  Mon Dec  9 09:00:18 2013
From: seotaewong40 at yahoo.co.kr (TaeWong)
Date: Mon, 9 Dec 2013 16:00:18 +0800 (SGT)
Subject: [Python-Dev] Sort error in Misc/ACKS
Message-ID: <1386576018.49920.YahooMailNeo@web193106.mail.sg3.yahoo.com>

There is a sorting error:


The name Jonas Wagner comes before Zachary Ware and Barry Warsaw.

Please correct sorting error so that his name appears between Sjoerd de Vries and Niki W. Waibel.


From solipsis at pitrou.net  Mon Dec  9 14:37:26 2013
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 9 Dec 2013 14:37:26 +0100
Subject: [Python-Dev] tracemalloc: add an optional memory limit
References: <CAMpsgwZi9N9nEsjxLvocpJStLcnE6R=64D=iZ5pO3t36Sn+iWg@mail.gmail.com>
 <l8417t$u6i$1@ger.gmane.org>
 <CAMpsgwag2EvExb66NvWXqzD-Xbwv3-trd9eQGdjW2XbxwC4gnQ@mail.gmail.com>
Message-ID: <20131209143726.715357cb@fsol>

On Mon, 9 Dec 2013 10:28:17 +0100
Victor Stinner <victor.stinner at gmail.com> wrote:
> Hi,
> 
> 2013/12/9 Serhiy Storchaka <storchaka at gmail.com>:
> > But tracemalloc doesn't count memory allocated besides Python allocators
> > (e.g. memory for executable, static variables and stack, memory allocated by
> > extensions and C lib, unallocated but not returned to OS dynamical memory).
> > When you want investigate how your program works on low memory, e.g. 500 MB,
> > ulimit -v 500000 is much closer to real life than tracemalloc.
> 
> Well, both limits are useful, but also (completly?) different.
> 
> "memory for executable, static variables and stack," : these values
> are fixed, so they don't matter at all. Substract them from the RSS
> when you choose the memory limit for tracemalloc.

Stack consumption is O(number of threads).

> "unallocated but not returned to OS dynamical memory" : it's really
> hard to estimate and understand the fragmentation of the heap memory
> :-( But this may only concern short peak, and the free memory can be
> reused later. If the peak is still lower than the limit, the
> fragmentation does not matter

I don't understand the statement: "if the peak is still lower than the
limit, the fragmentation does not matter". Serhiy's point is precisely
that the peak's computation doesn't account for OS-level fragmentation.

That said, I agree the feature can be useful. Unlike ulimit, it's a
best-effort thing, but it also works at a much more useful level than
"size of the virtual address space".

Regards

Antoine.



From barry at python.org  Mon Dec  9 15:57:00 2013
From: barry at python.org (Barry Warsaw)
Date: Mon, 9 Dec 2013 09:57:00 -0500
Subject: [Python-Dev] Sort error in Misc/ACKS
In-Reply-To: <1386576018.49920.YahooMailNeo@web193106.mail.sg3.yahoo.com>
References: <1386576018.49920.YahooMailNeo@web193106.mail.sg3.yahoo.com>
Message-ID: <20131209095700.325e847a@anarchist.wooz.org>

On Dec 09, 2013, at 04:00 PM, TaeWong wrote:

>The name Jonas Wagner comes before Zachary Ware and Barry Warsaw.

Maybe it's time to give up on trying to sort by last name, and just sort by
first character?

No, this is not a bold attempt to jump higher up in the list.
-AAAAAABarry

From zachary.ware+pydev at gmail.com  Mon Dec  9 16:19:14 2013
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Mon, 9 Dec 2013 09:19:14 -0600
Subject: [Python-Dev] Sort error in Misc/ACKS
In-Reply-To: <20131209095700.325e847a@anarchist.wooz.org>
References: <1386576018.49920.YahooMailNeo@web193106.mail.sg3.yahoo.com>
 <20131209095700.325e847a@anarchist.wooz.org>
Message-ID: <CAKJDb-NT3aD3cPjg3xKpHA7X8DpPHUCUJbsJej66g-+-7x+5oQ@mail.gmail.com>

On Mon, Dec 9, 2013 at 8:57 AM, Barry Warsaw <barry at python.org> wrote:
> On Dec 09, 2013, at 04:00 PM, TaeWong wrote:
>
>>The name Jonas Wagner comes before Zachary Ware and Barry Warsaw.
>
> Maybe it's time to give up on trying to sort by last name, and just sort by
> first character?
>
> No, this is not a bold attempt to jump higher up in the list.
> -AAAAAABarry

Hey, I'm far enough down the list already...

More seriously, we do specify "rough alphabetical order[ing]"; there's
no need to point out this kind of thing.

(Although it might be worth it to change that to "no particular order"
so that adding someone is as simple as `echo "Some Human" >>
Misc/ACKS`.  We could always run random.shuffle() on the current list
so new additions don't look out of place ;)

-- 
Zach

From gokoproject at gmail.com  Mon Dec  9 16:22:18 2013
From: gokoproject at gmail.com (John Wong)
Date: Mon, 9 Dec 2013 10:22:18 -0500
Subject: [Python-Dev] Add Gentoo packagers of external modules to
	Misc/ACKS
In-Reply-To: <20131208102950.6A2D7250C34@webabinitio.net>
References: <1386471820.89814.YahooMailNeo@web193101.mail.sg3.yahoo.com>
 <CAKmKYaAeiteTFd3SG4KUqVTfi-Y3YkoUZw0ZnqAM0xZzGDEWLg@mail.gmail.com>
 <20131208102950.6A2D7250C34@webabinitio.net>
Message-ID: <CACCLA559bcXAaajeO3qEZkGbUNHCYyQfa=zyH9eGVrVPW79uPg@mail.gmail.com>

Looks like a human to me instead, or some kind of smart AI. look he just
responded again.


On Sun, Dec 8, 2013 at 5:29 AM, R. David Murray <rdmurray at bitdance.com>wrote:

> As far as we have been able to determine, Tae Wong is in fact a bot
> (note the 'seo' in the email address...a tip of the hand, as far as
> I can see).  We have removed all access permissions (including email)
> from the related account on the bug tracker already.  IMO this address
> should be blocked from posting to all python lists.
>
> --David
>
> On Sun, 08 Dec 2013 11:07:10 +0100, Dirkjan Ochtman <dirkjan at ochtman.nl>
> wrote:
> > Tae Wong,
> >
> > Please don't speak on behalf the Gentoo Python team.
> >
> > Everyone else, sorry for this, they are definitely not actually
> > connected to our Gentoo team.
> >
> > Cheers,
> >
> > Dirkjan
> > _______________________________________________
> > Python-Dev mailing list
> > Python-Dev at python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/gokoproject%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131209/4659b4ae/attachment.html>

From guido at python.org  Mon Dec  9 16:43:19 2013
From: guido at python.org (Guido van Rossum)
Date: Mon, 9 Dec 2013 07:43:19 -0800
Subject: [Python-Dev] Add Gentoo packagers of external modules to
	Misc/ACKS
In-Reply-To: <CACCLA559bcXAaajeO3qEZkGbUNHCYyQfa=zyH9eGVrVPW79uPg@mail.gmail.com>
References: <1386471820.89814.YahooMailNeo@web193101.mail.sg3.yahoo.com>
 <CAKmKYaAeiteTFd3SG4KUqVTfi-Y3YkoUZw0ZnqAM0xZzGDEWLg@mail.gmail.com>
 <20131208102950.6A2D7250C34@webabinitio.net>
 <CACCLA559bcXAaajeO3qEZkGbUNHCYyQfa=zyH9eGVrVPW79uPg@mail.gmail.com>
Message-ID: <CAP7+vJKU+EWG9+hye3hddRT78XNF5OvnqUX69HkuMp=g=_akfg@mail.gmail.com>

Please look up his name in the archives. We've gone through this
before. He sends posts like this to many lists and there is never any
value to it (but it's hard to prove since usually 1-2 of the people in
his list really did contribute or are at least known to the target
audience). His motivations are unclear unless it is just to attract
links to his email profile. Please ban and ignore.

On Mon, Dec 9, 2013 at 7:22 AM, John Wong <gokoproject at gmail.com> wrote:
> Looks like a human to me instead, or some kind of smart AI. look he just
> responded again.
>
>
> On Sun, Dec 8, 2013 at 5:29 AM, R. David Murray <rdmurray at bitdance.com>
> wrote:
>>
>> As far as we have been able to determine, Tae Wong is in fact a bot
>> (note the 'seo' in the email address...a tip of the hand, as far as
>> I can see).  We have removed all access permissions (including email)
>> from the related account on the bug tracker already.  IMO this address
>> should be blocked from posting to all python lists.
>>
>> --David
>>
>> On Sun, 08 Dec 2013 11:07:10 +0100, Dirkjan Ochtman <dirkjan at ochtman.nl>
>> wrote:
>> > Tae Wong,
>> >
>> > Please don't speak on behalf the Gentoo Python team.
>> >
>> > Everyone else, sorry for this, they are definitely not actually
>> > connected to our Gentoo team.
>> >
>> > Cheers,
>> >
>> > Dirkjan
>> > _______________________________________________
>> > Python-Dev mailing list
>> > Python-Dev at python.org
>> > https://mail.python.org/mailman/listinfo/python-dev
>> > Unsubscribe:
>> > https://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/gokoproject%40gmail.com
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)

From rdmurray at bitdance.com  Mon Dec  9 16:59:29 2013
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 09 Dec 2013 10:59:29 -0500
Subject: [Python-Dev] Add Gentoo packagers of external modules to
	Misc/ACKS
In-Reply-To: <CACCLA559bcXAaajeO3qEZkGbUNHCYyQfa=zyH9eGVrVPW79uPg@mail.gmail.com>
References: <1386471820.89814.YahooMailNeo@web193101.mail.sg3.yahoo.com>
 <CAKmKYaAeiteTFd3SG4KUqVTfi-Y3YkoUZw0ZnqAM0xZzGDEWLg@mail.gmail.com>
 <20131208102950.6A2D7250C34@webabinitio.net>
 <CACCLA559bcXAaajeO3qEZkGbUNHCYyQfa=zyH9eGVrVPW79uPg@mail.gmail.com>
Message-ID: <20131209155929.DEF012504A3@webabinitio.net>

On Mon, 09 Dec 2013 10:22:18 -0500, John Wong <gokoproject at gmail.com> wrote:
> Looks like a human to me instead, or some kind of smart AI. look he just
> responded again.

Could be.  He's never responded to a direct question on the bug tracker,
though, just posts a new comment with some loose connection to the first
comment, as happened here.

So human or not, his "contributions" on the bug tracker did not have any
utility.  He's also never talked about anything other than the ACKS file,
and given the absence of response to questions on the existing issue,
we viewed the opening of new issues as spam, and therefore disabled
the account.  Someone from another project reported similar problems
on that project, and a google search did not turn up any *meaningful*
contributions anywhere that I could find.

If he'll engage us in a real conversation, this could of course be
changed :)

--David

From dmalcolm at redhat.com  Mon Dec  9 17:57:05 2013
From: dmalcolm at redhat.com (David Malcolm)
Date: Mon, 09 Dec 2013 11:57:05 -0500
Subject: [Python-Dev] Add Gentoo packagers of external modules to
 Misc/ACKS
In-Reply-To: <20131208102950.6A2D7250C34@webabinitio.net>
References: <1386471820.89814.YahooMailNeo@web193101.mail.sg3.yahoo.com>
 <CAKmKYaAeiteTFd3SG4KUqVTfi-Y3YkoUZw0ZnqAM0xZzGDEWLg@mail.gmail.com>
 <20131208102950.6A2D7250C34@webabinitio.net>
Message-ID: <1386608225.12091.96.camel@surprise>

On Sun, 2013-12-08 at 05:29 -0500, R. David Murray wrote:
> As far as we have been able to determine, Tae Wong is in fact a bot
> (note the 'seo' in the email address...a tip of the hand, as far as
> I can see).  We have removed all access permissions (including email)
> from the related account on the bug tracker already.  IMO this address
> should be blocked from posting to all python lists.

FWIW the address has also been posting to the gcc lists "helpfully"
asking for spam posts to be removed (with *links* to the posts), plus
some (apparently) random-harvested paragraphs of text from various other
mailing lists, presumably to try to get past filters.

See e.g. the URL obtained by running:
 echo uggc://tpp.tah.bet/zy/tpp/2013-12/zft00097.ugzy | rot13


Hope this is constructive
Dave


From skip at pobox.com  Mon Dec  9 19:13:16 2013
From: skip at pobox.com (Skip Montanaro)
Date: Mon, 9 Dec 2013 12:13:16 -0600
Subject: [Python-Dev] Sort error in Misc/ACKS
In-Reply-To: <CAKJDb-NT3aD3cPjg3xKpHA7X8DpPHUCUJbsJej66g-+-7x+5oQ@mail.gmail.com>
References: <1386576018.49920.YahooMailNeo@web193106.mail.sg3.yahoo.com>
 <20131209095700.325e847a@anarchist.wooz.org>
 <CAKJDb-NT3aD3cPjg3xKpHA7X8DpPHUCUJbsJej66g-+-7x+5oQ@mail.gmail.com>
Message-ID: <CANc-5Uz-kwhm76ejf+bWyErMgb=dFe+OWigNQ80A7L=0T3t=Hw@mail.gmail.com>

> We could always run random.shuffle() on the current list
> so new additions don't look out of place ;)

Wouldn't that bloat the repository with diffs and make merges more difficult?

<wink>

Skip

From thatiparthysreenivas at gmail.com  Mon Dec  9 19:37:26 2013
From: thatiparthysreenivas at gmail.com (Sreenivas Reddy T)
Date: Tue, 10 Dec 2013 00:07:26 +0530
Subject: [Python-Dev] Sort error in Misc/ACKS
In-Reply-To: <CANc-5Uz-kwhm76ejf+bWyErMgb=dFe+OWigNQ80A7L=0T3t=Hw@mail.gmail.com>
References: <1386576018.49920.YahooMailNeo@web193106.mail.sg3.yahoo.com>
 <20131209095700.325e847a@anarchist.wooz.org>
 <CAKJDb-NT3aD3cPjg3xKpHA7X8DpPHUCUJbsJej66g-+-7x+5oQ@mail.gmail.com>
 <CANc-5Uz-kwhm76ejf+bWyErMgb=dFe+OWigNQ80A7L=0T3t=Hw@mail.gmail.com>
Message-ID: <CAEaN0UaaT+i3=F-rNCE7no94Z3rMb5h6YL4QSff6Kz+xmc-CAA@mail.gmail.com>

Am i the one who feels we do not add any value by doing this?

Best Regards,
Srinivas Reddy Thatiparthy
9703888668.

"Anyone who has never made a mistake has never tried anything new !!! "
--Albert Einstein


On Mon, Dec 9, 2013 at 11:43 PM, Skip Montanaro <skip at pobox.com> wrote:

> > We could always run random.shuffle() on the current list
> > so new additions don't look out of place ;)
>
> Wouldn't that bloat the repository with diffs and make merges more
> difficult?
>
> <wink>
>
> Skip
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/thatiparthysreenivas%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131210/5d93dd96/attachment.html>

From guido at python.org  Mon Dec  9 19:40:55 2013
From: guido at python.org (Guido van Rossum)
Date: Mon, 9 Dec 2013 10:40:55 -0800
Subject: [Python-Dev] Sort error in Misc/ACKS
In-Reply-To: <CAEaN0UaaT+i3=F-rNCE7no94Z3rMb5h6YL4QSff6Kz+xmc-CAA@mail.gmail.com>
References: <1386576018.49920.YahooMailNeo@web193106.mail.sg3.yahoo.com>
 <20131209095700.325e847a@anarchist.wooz.org>
 <CAKJDb-NT3aD3cPjg3xKpHA7X8DpPHUCUJbsJej66g-+-7x+5oQ@mail.gmail.com>
 <CANc-5Uz-kwhm76ejf+bWyErMgb=dFe+OWigNQ80A7L=0T3t=Hw@mail.gmail.com>
 <CAEaN0UaaT+i3=F-rNCE7no94Z3rMb5h6YL4QSff6Kz+xmc-CAA@mail.gmail.com>
Message-ID: <CAP7+vJKgkRDRWRGQcdh8nXXW3yTd5TUfBnJHRegNxdNqk1q_kQ@mail.gmail.com>

The troll is successful already. Read the other thread. :-(

On Mon, Dec 9, 2013 at 10:37 AM, Sreenivas Reddy T
<thatiparthysreenivas at gmail.com> wrote:
> Am i the one who feels we do not add any value by doing this?
>
> Best Regards,
> Srinivas Reddy Thatiparthy
> 9703888668.
>
> "Anyone who has never made a mistake has never tried anything new !!! "
> --Albert Einstein
>
>
> On Mon, Dec 9, 2013 at 11:43 PM, Skip Montanaro <skip at pobox.com> wrote:
>>
>> > We could always run random.shuffle() on the current list
>> > so new additions don't look out of place ;)
>>
>> Wouldn't that bloat the repository with diffs and make merges more
>> difficult?
>>
>> <wink>
>>
>> Skip
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/thatiparthysreenivas%40gmail.com
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)

From cyberdupo56 at gmail.com  Mon Dec  9 20:52:53 2013
From: cyberdupo56 at gmail.com (Allen Li)
Date: Mon, 9 Dec 2013 14:52:53 -0500
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <l7tnhj$v2u$1@ger.gmane.org>
References: <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
 <20131205211228.GB27767@avalon.amherst.edu>
 <CAP7+vJJQOjtFfSutYuhMdb+-KdSZ43+aXaK=WW3W=NjRTAS9HQ@mail.gmail.com>
 <20131206020629.GA15017@avalon.amherst.edu>
 <20131206020812.GB15017@avalon.amherst.edu>
 <52A136F4.2090609@stoneleaf.us>
 <CAP7+vJK4dgXWsw6=UnmbzDYXxvxoDc8zjAcT10EUKJuFB9VWaQ@mail.gmail.com>
 <CAAZsQLBfK+_WgZ-SBqQkA6mfg_CLS2BueGtG3oUkx=OxC1c0Mg@mail.gmail.com>
 <20131206104621.GN2085@ando> <l7tnhj$v2u$1@ger.gmane.org>
Message-ID: <20131209195253.GB31166@avalon.amherst.edu>

I just wanted to sum up this thread of discussion.

Proposal:
A function in abc to provide a default abstract method
implementation.

foo = make_abstractmethod('foo', ['self'])

is the same as

@abc.abstractmethod
def foo(self):
    pass

Details:
Default behavior, if implemented, should probably be empty/pass/return
None.  How to handle docstrings?  Either attribute docstring (a separate
discussion) or a parameter in the function call.

Pros:
Save a lot of lines defining interface-like ABCs, especially in small
scripts without docstrings (bad practice, but I do it often =))

Cons:
Do we need it?

From ethan at stoneleaf.us  Mon Dec  9 21:30:30 2013
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 09 Dec 2013 12:30:30 -0800
Subject: [Python-Dev] One-line abstractmethod function?
In-Reply-To: <20131209195253.GB31166@avalon.amherst.edu>
References: <CAP7+vJLkSSMLNqo=5Bqo0Erf3=D-XzP3bemCLF4e669+aXiyWw@mail.gmail.com>
 <20131205211228.GB27767@avalon.amherst.edu>
 <CAP7+vJJQOjtFfSutYuhMdb+-KdSZ43+aXaK=WW3W=NjRTAS9HQ@mail.gmail.com>
 <20131206020629.GA15017@avalon.amherst.edu>
 <20131206020812.GB15017@avalon.amherst.edu> <52A136F4.2090609@stoneleaf.us>
 <CAP7+vJK4dgXWsw6=UnmbzDYXxvxoDc8zjAcT10EUKJuFB9VWaQ@mail.gmail.com>
 <CAAZsQLBfK+_WgZ-SBqQkA6mfg_CLS2BueGtG3oUkx=OxC1c0Mg@mail.gmail.com>
 <20131206104621.GN2085@ando> <l7tnhj$v2u$1@ger.gmane.org>
 <20131209195253.GB31166@avalon.amherst.edu>
Message-ID: <52A62866.30202@stoneleaf.us>

On 12/09/2013 11:52 AM, Allen Li wrote:
>
> Pros:
> Save a lot of lines defining interface-like ABCs, especially in small
> scripts without docstrings (bad practice, but I do it often =))

If the only pro is encouraging bad practice, it's not going to happen. ;)


> Cons:
> Do we need it?

In my opinion, no.

--
~Ethan~


From stefan at bytereef.org  Wed Dec 11 22:55:35 2013
From: stefan at bytereef.org (Stefan Krah)
Date: Wed, 11 Dec 2013 22:55:35 +0100
Subject: [Python-Dev] [buildbot] Increase number of stored builds
Message-ID: <20131211215535.GA10056@sleipnir.bytereef.org>

Hello,

is it possible to increase the number of stored builds?  Sometimes I want
to see a build that might be a week or even 6 months old.

Examples:

  1) Recently I was wondering if the HPUX CFLAGS changed at some point.

  2) The HPUX build has the following error:

       "*** WARNING: renaming "_curses" since importing it failed: dynamic module does not define init function (PyInit__curses)"

     I need to see if http://hg.python.org/cpython/rev/97fb852c5c26 is responsible.



Stefan Krah



From solipsis at pitrou.net  Wed Dec 11 23:24:47 2013
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 11 Dec 2013 23:24:47 +0100
Subject: [Python-Dev] cpython (3.3): Issue #17576: Deprecation warning
 emitted now when __int__() or __index__()
References: <3dfp8M5ZFMz7Lmp@mail.python.org>
Message-ID: <20131211232447.5fa02d4a@fsol>

On Wed, 11 Dec 2013 20:28:19 +0100 (CET)
serhiy.storchaka <python-checkins at python.org> wrote:
> http://hg.python.org/cpython/rev/618cca51a27e
> changeset:   87899:618cca51a27e
> branch:      3.3
> parent:      87896:46186736e91c
> user:        Serhiy Storchaka <storchaka at gmail.com>
> date:        Wed Dec 11 21:07:54 2013 +0200
> summary:
>   Issue #17576: Deprecation warning emitted now when __int__() or __index__()
> return not int instance.  Introduced _PyLong_FromNbInt() and refactored
> PyLong_As*() functions.

Is it ok to add deprecation warnings in bugfix versions?

Regards

Antoine.



From ncoghlan at gmail.com  Thu Dec 12 00:46:05 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 12 Dec 2013 09:46:05 +1000
Subject: [Python-Dev] cpython (3.3): Issue #17576: Deprecation warning
 emitted now when __int__() or __index__()
In-Reply-To: <20131211232447.5fa02d4a@fsol>
References: <3dfp8M5ZFMz7Lmp@mail.python.org>
	<20131211232447.5fa02d4a@fsol>
Message-ID: <CADiSq7f5jgSBKWqV=Sw3hp76Rx2ZYiRB-H0udXmQ4yZQLeH-=w@mail.gmail.com>

On 12 Dec 2013 08:26, "Antoine Pitrou" <solipsis at pitrou.net> wrote:
>
> On Wed, 11 Dec 2013 20:28:19 +0100 (CET)
> serhiy.storchaka <python-checkins at python.org> wrote:
> > http://hg.python.org/cpython/rev/618cca51a27e
> > changeset:   87899:618cca51a27e
> > branch:      3.3
> > parent:      87896:46186736e91c
> > user:        Serhiy Storchaka <storchaka at gmail.com>
> > date:        Wed Dec 11 21:07:54 2013 +0200
> > summary:
> >   Issue #17576: Deprecation warning emitted now when __int__() or
__index__()
> > return not int instance.  Introduced _PyLong_FromNbInt() and refactored
> > PyLong_As*() functions.
>
> Is it ok to add deprecation warnings in bugfix versions?

Oh, I missed that this was landed on multiple branches. In general, we try
to avoid doing that, but the ultimate decision rests with the release
manager (although in this case, I would suggest only making the change for
3.4).

>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131212/cfcddc9a/attachment.html>

From storchaka at gmail.com  Thu Dec 12 09:54:05 2013
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Thu, 12 Dec 2013 10:54:05 +0200
Subject: [Python-Dev] cpython (3.3): Issue #17576: Deprecation warning
 emitted now when __int__() or __index__()
In-Reply-To: <20131211232447.5fa02d4a@fsol>
References: <3dfp8M5ZFMz7Lmp@mail.python.org> <20131211232447.5fa02d4a@fsol>
Message-ID: <l8btj5$vne$1@ger.gmane.org>

12.12.13 00:24, Antoine Pitrou ???????(??):
> On Wed, 11 Dec 2013 20:28:19 +0100 (CET)
> serhiy.storchaka <python-checkins at python.org> wrote:
>> http://hg.python.org/cpython/rev/618cca51a27e
>> changeset:   87899:618cca51a27e
>> branch:      3.3
>> parent:      87896:46186736e91c
>> user:        Serhiy Storchaka <storchaka at gmail.com>
>> date:        Wed Dec 11 21:07:54 2013 +0200
>> summary:
>>    Issue #17576: Deprecation warning emitted now when __int__() or __index__()
>> return not int instance.  Introduced _PyLong_FromNbInt() and refactored
>> PyLong_As*() functions.
>
> Is it ok to add deprecation warnings in bugfix versions?

Some clarifications. This is a precursor of a bugfix. I split a patch on 
two parts for simplicity. First part doesn't change behavior besides 
introducing warnings. Second part is simple and will change behavior (I 
still doubt how many behavior it should change).


From rdmurray at bitdance.com  Thu Dec 12 16:22:40 2013
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 12 Dec 2013 10:22:40 -0500
Subject: [Python-Dev] cpython (3.3): Issue #17576: Deprecation warning
	emitted now when __int__() or __index__()
In-Reply-To: <l8btj5$vne$1@ger.gmane.org>
References: <3dfp8M5ZFMz7Lmp@mail.python.org> <20131211232447.5fa02d4a@fsol>
 <l8btj5$vne$1@ger.gmane.org>
Message-ID: <20131212152240.95242250934@webabinitio.net>

On Thu, 12 Dec 2013 10:54:05 +0200, Serhiy Storchaka <storchaka at gmail.com> wrote:
> 12.12.13 00:24, Antoine Pitrou ??????????????(????):
> > On Wed, 11 Dec 2013 20:28:19 +0100 (CET)
> > serhiy.storchaka <python-checkins at python.org> wrote:
> >> http://hg.python.org/cpython/rev/618cca51a27e
> >> changeset:   87899:618cca51a27e
> >> branch:      3.3
> >> parent:      87896:46186736e91c
> >> user:        Serhiy Storchaka <storchaka at gmail.com>
> >> date:        Wed Dec 11 21:07:54 2013 +0200
> >> summary:
> >>    Issue #17576: Deprecation warning emitted now when __int__() or __index__()
> >> return not int instance.  Introduced _PyLong_FromNbInt() and refactored
> >> PyLong_As*() functions.
> >
> > Is it ok to add deprecation warnings in bugfix versions?
> 
> Some clarifications. This is a precursor of a bugfix. I split a patch on 
> two parts for simplicity. First part doesn't change behavior besides 
> introducing warnings. Second part is simple and will change behavior (I 
> still doubt how many behavior it should change).

That doesn't address the question of why the deprecation is added
to a bug-fix release.  Normal policy is deprecate in the current
feature release and make the change in the next feature release.

Is there a reason why the normal deprecation process should not be
followed in this case?  It being a not-likely-to-be-encountered
in-the-real-world bug could be one such reason, if the release
managers agree.

--David

From princemody19 at gmail.com  Fri Dec 13 12:43:37 2013
From: princemody19 at gmail.com (Kingmody)
Date: Fri, 13 Dec 2013 14:43:37 +0300
Subject: [Python-Dev] Committing PEP 3155
Message-ID: <1CB5649B-93C6-4DAC-A226-F40A4CA1421D@gmail.com>



???? ???? ??? iPad ????? ???
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131213/6b8050cf/attachment.html>

From princemody19 at gmail.com  Fri Dec 13 12:43:34 2013
From: princemody19 at gmail.com (Kingmody)
Date: Fri, 13 Dec 2013 14:43:34 +0300
Subject: [Python-Dev] Committing PEP 3155
Message-ID: <80638E48-E680-4543-9156-0698A77CF9C0@gmail.com>



???? ???? ??? iPad ????? ???
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131213/63b52f1e/attachment.html>

From princemody19 at gmail.com  Fri Dec 13 12:43:30 2013
From: princemody19 at gmail.com (Kingmody)
Date: Fri, 13 Dec 2013 14:43:30 +0300
Subject: [Python-Dev] Committing PEP 3155
Message-ID: <EAB0456F-3ED1-4ACA-BACC-F10F6AF00C81@gmail.com>



???? ???? ??? iPad ????? ???
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131213/a0a8166c/attachment.html>

From brett at yvrsfo.ca  Fri Dec 13 18:04:29 2013
From: brett at yvrsfo.ca (Brett Cannon)
Date: Fri, 13 Dec 2013 12:04:29 -0500
Subject: [Python-Dev] How do we feel about using pragmas and __attribute__
	in C code?
Message-ID: <CAP1=2W66gD2WHTeQ0579dnPwetu=jGvCu43nxuSxwxurmxqEXg@mail.gmail.com>

http://bugs.python.org/issue12837 deals with the single compiler warning
left on OS X: a tautalogical compare in socketmodule.c that is valid under
POSIX. I have a solution that uses pragmas to turn off tautological compare
warnings for the single 'if' statement that triggers it. But there are very
few places in Python's code base which use pragmas and I have never seen a
discussion if we are okay with their overall use.

So is there any reason to not use pragmas sparsely in the code?

Tying into this and using compiler-specific things in C code, what about
__attribute__? http://bugs.python.org/issue19298 proposes an idea that
Daniel Stutzbach originally came up with where we could use __atribute__
(behind a nicer macro) to help detect refleaks on PyObject* stack
variables. Would __attribute__ usage be okay in that situation?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131213/4ea88ede/attachment.html>

From status at bugs.python.org  Fri Dec 13 18:07:44 2013
From: status at bugs.python.org (Python tracker)
Date: Fri, 13 Dec 2013 18:07:44 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20131213170744.CC640568C2@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2013-12-06 - 2013-12-13)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    4322 ( -1)
  closed 27428 (+69)
  total  31750 (+68)

Open issues with patches: 1979 


Issues opened (48)
==================

#16669: Docstrings for namedtuple
http://bugs.python.org/issue16669  reopened by serhiy.storchaka

#19911: ntpath.splitdrive() fails when UNC part contains \u0130
http://bugs.python.org/issue19911  opened by serhiy.storchaka

#19912: ntpath.splitunc() is broken and not tested
http://bugs.python.org/issue19912  opened by serhiy.storchaka

#19913: TR/Crypt.XPACK.Gen-4 in easy_install.exe
http://bugs.python.org/issue19913  opened by christian.heimes

#19914: help([object]) returns "Not enough memory." on standard Python
http://bugs.python.org/issue19914  opened by hct

#19915: int.bit_at(n) - Accessing a single bit in O(1)
http://bugs.python.org/issue19915  opened by anon

#19917: [httplib] logging information for request is not pretty printe
http://bugs.python.org/issue19917  opened by mcepl

#19918: PureWindowsPath.relative_to() is not case insensitive
http://bugs.python.org/issue19918  opened by serhiy.storchaka

#19919: SSL: test_connect_ex_error fails with EWOULDBLOCK
http://bugs.python.org/issue19919  opened by christian.heimes

#19920: TarFile.list() fails on some files
http://bugs.python.org/issue19920  opened by serhiy.storchaka

#19921: Path.mkdir(0, True) always fails
http://bugs.python.org/issue19921  opened by serhiy.storchaka

#19923: OSError: [Errno 512] Unknown error 512 in test_multiprocessing
http://bugs.python.org/issue19923  opened by pitrou

#19925: Add unit test for spwd module
http://bugs.python.org/issue19925  opened by vajrasky

#19927: Path-based loaders lack a meaningful __eq__() implementation.
http://bugs.python.org/issue19927  opened by eric.snow

#19930: os.makedirs('dir1/dir2', 0) always fails
http://bugs.python.org/issue19930  opened by serhiy.storchaka

#19931: namedtuple docstrings are verbose for no added benefit
http://bugs.python.org/issue19931  opened by nedbat

#19933: Round default argument for "ndigits"
http://bugs.python.org/issue19933  opened by JBernardo

#19934: collections.Counter.most_common does not document `None` as ac
http://bugs.python.org/issue19934  opened by mgilson

#19936: Executable permissions of Python source files
http://bugs.python.org/issue19936  opened by serhiy.storchaka

#19938: Re-enable test_bug_1333982 on 3.x
http://bugs.python.org/issue19938  opened by zach.ware

#19939: Deprecate portions or all of pkgutil module.
http://bugs.python.org/issue19939  opened by eric.snow

#19940: ssl.cert_time_to_seconds() returns wrong results if local time
http://bugs.python.org/issue19940  opened by akira

#19941: python -m imports non-ASCII .py file without encoding declarat
http://bugs.python.org/issue19941  opened by jwilk

#19942: UTF-8 encoding not enforced
http://bugs.python.org/issue19942  opened by jwilk

#19944: Make importlib.find_spec load packages as needed
http://bugs.python.org/issue19944  opened by ncoghlan

#19948: POSIX semantics of PATH search in execvpe is not respected
http://bugs.python.org/issue19948  opened by glondu

#19949: Explicitly skip or mask skipped/disabled tests in test_xpickle
http://bugs.python.org/issue19949  opened by zach.ware

#19950: Document that unittest.TestCase.__init__ is called once per te
http://bugs.python.org/issue19950  opened by Claudiu.Popa

#19953: __iadd__() doc not strictly correct
http://bugs.python.org/issue19953  opened by ferno

#19954: test_tk floating point exception on my gentoo box running tk 8
http://bugs.python.org/issue19954  opened by r.david.murray

#19955: When adding .PY and .PYW to PATHEXT, it replaced string instea
http://bugs.python.org/issue19955  opened by nickhil.rokkam

#19956: inspect.getsource(obj.foo) fails when foo is an injected metho
http://bugs.python.org/issue19956  opened by mtahmed

#19959: argparse.FileType does not expand tilde "~"
http://bugs.python.org/issue19959  opened by garthy

#19960: MacOSX: Building 2.7 without the xcode command line  tools ins
http://bugs.python.org/issue19960  opened by ronaldoussoren

#19961: MacOSX: Tkinter build failure when building without command-li
http://bugs.python.org/issue19961  opened by ronaldoussoren

#19962: Create a 'python.bat' script to invoke interpreter from source
http://bugs.python.org/issue19962  opened by zach.ware

#19963: Update docs for importlib.import_module()
http://bugs.python.org/issue19963  opened by brett.cannon

#19965: Non-atomic generation of Include/Python-ast.h and Python/Pytho
http://bugs.python.org/issue19965  opened by Arfrever

#19966: Wrong mtimes of files in 3.3.3 tarballs
http://bugs.python.org/issue19966  opened by Arfrever

#19967: asyncio: remove _TracebackLogger
http://bugs.python.org/issue19967  opened by haypo

#19968: Using DESTDIR breaks sys.path
http://bugs.python.org/issue19968  opened by mishikal

#19970: Typo of `immediatly` and `agin` words
http://bugs.python.org/issue19970  opened by vajrasky

#19972: Leak in pickle (?)
http://bugs.python.org/issue19972  opened by skrah

#19974: tarfile doesn't overwrite symlink by directory
http://bugs.python.org/issue19974  opened by antonymayi

#19975: Remove unused imports from webbrowser
http://bugs.python.org/issue19975  opened by Claudiu.Popa

#19976: Argument Clinic: generate second arg for METH_NOARGS
http://bugs.python.org/issue19976  opened by skrah

#19977: Use "surrogateescape" error handler for sys.stdin and sys.stdo
http://bugs.python.org/issue19977  opened by haypo

#19978: Update multiprocessing.spawn to use runpy.run_path
http://bugs.python.org/issue19978  opened by brett.cannon



Most recent 15 issues with no replies (15)
==========================================

#19978: Update multiprocessing.spawn to use runpy.run_path
http://bugs.python.org/issue19978

#19975: Remove unused imports from webbrowser
http://bugs.python.org/issue19975

#19974: tarfile doesn't overwrite symlink by directory
http://bugs.python.org/issue19974

#19970: Typo of `immediatly` and `agin` words
http://bugs.python.org/issue19970

#19966: Wrong mtimes of files in 3.3.3 tarballs
http://bugs.python.org/issue19966

#19963: Update docs for importlib.import_module()
http://bugs.python.org/issue19963

#19962: Create a 'python.bat' script to invoke interpreter from source
http://bugs.python.org/issue19962

#19961: MacOSX: Tkinter build failure when building without command-li
http://bugs.python.org/issue19961

#19960: MacOSX: Building 2.7 without the xcode command line  tools ins
http://bugs.python.org/issue19960

#19955: When adding .PY and .PYW to PATHEXT, it replaced string instea
http://bugs.python.org/issue19955

#19953: __iadd__() doc not strictly correct
http://bugs.python.org/issue19953

#19949: Explicitly skip or mask skipped/disabled tests in test_xpickle
http://bugs.python.org/issue19949

#19938: Re-enable test_bug_1333982 on 3.x
http://bugs.python.org/issue19938

#19936: Executable permissions of Python source files
http://bugs.python.org/issue19936

#19931: namedtuple docstrings are verbose for no added benefit
http://bugs.python.org/issue19931



Most recent 15 issues waiting for review (15)
=============================================

#19977: Use "surrogateescape" error handler for sys.stdin and sys.stdo
http://bugs.python.org/issue19977

#19975: Remove unused imports from webbrowser
http://bugs.python.org/issue19975

#19972: Leak in pickle (?)
http://bugs.python.org/issue19972

#19970: Typo of `immediatly` and `agin` words
http://bugs.python.org/issue19970

#19967: asyncio: remove _TracebackLogger
http://bugs.python.org/issue19967

#19965: Non-atomic generation of Include/Python-ast.h and Python/Pytho
http://bugs.python.org/issue19965

#19962: Create a 'python.bat' script to invoke interpreter from source
http://bugs.python.org/issue19962

#19960: MacOSX: Building 2.7 without the xcode command line  tools ins
http://bugs.python.org/issue19960

#19959: argparse.FileType does not expand tilde "~"
http://bugs.python.org/issue19959

#19950: Document that unittest.TestCase.__init__ is called once per te
http://bugs.python.org/issue19950

#19949: Explicitly skip or mask skipped/disabled tests in test_xpickle
http://bugs.python.org/issue19949

#19944: Make importlib.find_spec load packages as needed
http://bugs.python.org/issue19944

#19938: Re-enable test_bug_1333982 on 3.x
http://bugs.python.org/issue19938

#19936: Executable permissions of Python source files
http://bugs.python.org/issue19936

#19934: collections.Counter.most_common does not document `None` as ac
http://bugs.python.org/issue19934



Top 10 most discussed issues (10)
=================================

#19915: int.bit_at(n) - Accessing a single bit in O(1)
http://bugs.python.org/issue19915  27 msgs

#19933: Round default argument for "ndigits"
http://bugs.python.org/issue19933  14 msgs

#17576: PyNumber_Index() is not int-subclass friendly (or operator.ind
http://bugs.python.org/issue17576  13 msgs

#19904: Add 128-bit integer support to struct
http://bugs.python.org/issue19904  13 msgs

#18983: Specify time unit for timeit CLI
http://bugs.python.org/issue18983  12 msgs

#18576: Rename and document test.script_helper as test.support.script_
http://bugs.python.org/issue18576  10 msgs

#19921: Path.mkdir(0, True) always fails
http://bugs.python.org/issue19921  10 msgs

#19944: Make importlib.find_spec load packages as needed
http://bugs.python.org/issue19944  10 msgs

#19965: Non-atomic generation of Include/Python-ast.h and Python/Pytho
http://bugs.python.org/issue19965   9 msgs

#19976: Argument Clinic: generate second arg for METH_NOARGS
http://bugs.python.org/issue19976   9 msgs



Issues closed (64)
==================

#6784: byte/unicode pickle incompatibilities between python2 and pyth
http://bugs.python.org/issue6784  closed by alexandre.vassalotti

#9645: PEP 383: os.pathconf() does not accept surrogateescape argumen
http://bugs.python.org/issue9645  closed by serhiy.storchaka

#14432: Bug in generator if the generator in created in a temporary C 
http://bugs.python.org/issue14432  closed by haypo

#15032: Provide a select.select implemented using select.poll
http://bugs.python.org/issue15032  closed by gregory.p.smith

#15475: Correct __sizeof__ support for itertools
http://bugs.python.org/issue15475  closed by serhiy.storchaka

#17200: telnetlib.read_until() timeout uses the wrong units
http://bugs.python.org/issue17200  closed by gregory.p.smith

#17429: platform.linux_distribution() should decode files from UTF-8, 
http://bugs.python.org/issue17429  closed by haypo

#17786: Crash in test_ctypes.test_callbacks() on AMD64 NetBSD 5.1.2 [S
http://bugs.python.org/issue17786  closed by haypo

#18270: IDLE on OS X fails with Attribute Error if no initial shell an
http://bugs.python.org/issue18270  closed by ned.deily

#18430: gzip, bz2, lzma: peek advances file position of existing file 
http://bugs.python.org/issue18430  closed by python-dev

#18746: test_threading.test_finalize_with_trace() fails on FreeBSD bui
http://bugs.python.org/issue18746  closed by haypo

#19063: Python 3.3.3  encodes emails containing non-ascii data as 7bit
http://bugs.python.org/issue19063  closed by r.david.murray

#19099: struct.pack fails first time with unicode fmt
http://bugs.python.org/issue19099  closed by serhiy.storchaka

#19230: Reimplement the keyword module in C
http://bugs.python.org/issue19230  closed by haypo

#19343: Expose FreeBSD-specific APIs in resource module
http://bugs.python.org/issue19343  closed by christian.heimes

#19437: More failures found by pyfailmalloc
http://bugs.python.org/issue19437  closed by haypo

#19481: IDLE hangs while printing instance of Unicode subclass
http://bugs.python.org/issue19481  closed by serhiy.storchaka

#19506: subprocess.communicate() should use a memoryview
http://bugs.python.org/issue19506  closed by gregory.p.smith

#19535: Test failures with -OO
http://bugs.python.org/issue19535  closed by serhiy.storchaka

#19566: ERROR: test_close (test.test_asyncio.test_unix_events.FastChil
http://bugs.python.org/issue19566  closed by haypo

#19572: Report more silently skipped tests as skipped
http://bugs.python.org/issue19572  closed by zach.ware

#19576: "Non-Python created threads" documentation doesn't mention PyE
http://bugs.python.org/issue19576  closed by python-dev

#19635: asyncio should not depend on concurrent.futures, it is not alw
http://bugs.python.org/issue19635  closed by haypo

#19636: Fix usage of MAX_PATH in posixmodule.c
http://bugs.python.org/issue19636  closed by haypo

#19661: AIX: Python: RuntimeError "invalid slot offset when importing 
http://bugs.python.org/issue19661  closed by dellair.jie

#19690: test_logging test_race failed with PermissionError
http://bugs.python.org/issue19690  closed by vinay.sajip

#19712: Make sure there are exec_module tests for _LoaderBasics subcla
http://bugs.python.org/issue19712  closed by brett.cannon

#19750: test_asyncio.test_unix_events constructor failures on AIX
http://bugs.python.org/issue19750  closed by haypo

#19758: Warnings in tests
http://bugs.python.org/issue19758  closed by serhiy.storchaka

#19787: Fix PyThread_set_key_value() strange behaviour
http://bugs.python.org/issue19787  closed by python-dev

#19828: test_site fails with -S flag
http://bugs.python.org/issue19828  closed by zach.ware

#19830: test_poplib emits resource warning
http://bugs.python.org/issue19830  closed by haypo

#19843: Wait for multiple sub-processes to terminate
http://bugs.python.org/issue19843  closed by gregory.p.smith

#19846: Python 3 raises Unicode errors with the C locale
http://bugs.python.org/issue19846  closed by haypo

#19851: reload problem with submodule
http://bugs.python.org/issue19851  closed by eric.snow

#19857: test_imaplib doesn't always reap SocketServer thread
http://bugs.python.org/issue19857  closed by neologix

#19862: Unclear xpath caching for custom  namespaces
http://bugs.python.org/issue19862  closed by eric.araujo

#19876: selectors (and asyncio?): document behaviour on closed files/s
http://bugs.python.org/issue19876  closed by gvanrossum

#19880: unittest: on failure, TestCase.run() keeps a reference to the 
http://bugs.python.org/issue19880  closed by python-dev

#19893: Python cApi memory problem. Py_Initialize memory leak
http://bugs.python.org/issue19893  closed by rstarostecki

#19900: improve pickle intro
http://bugs.python.org/issue19900  closed by pitrou

#19901: tests fail due to unsupported SO_REUSEPORT when building Pytho
http://bugs.python.org/issue19901  closed by gregory.p.smith

#19910: Document that compile() source may be bytes
http://bugs.python.org/issue19910  closed by python-dev

#19916: urllib2 fails on https,SSL broken.
http://bugs.python.org/issue19916  closed by r.david.murray

#19922: mbstate_t requires _INCLUDE__STDC_A1_SOURCE
http://bugs.python.org/issue19922  closed by christian.heimes

#19924: test_venv fails with --without-threads
http://bugs.python.org/issue19924  closed by ncoghlan

#19926: Refactor unit test in abstract numbers test
http://bugs.python.org/issue19926  closed by zach.ware

#19928: Implement cell repr test
http://bugs.python.org/issue19928  closed by serhiy.storchaka

#19929: subprocess: increase read buffer size
http://bugs.python.org/issue19929  closed by gregory.p.smith

#19932: Missing spaces in import.h?
http://bugs.python.org/issue19932  closed by brett.cannon

#19935: IPv6 urlparse error on python 2.6
http://bugs.python.org/issue19935  closed by christian.heimes

#19937: IDLE can't be launched
http://bugs.python.org/issue19937  closed by ned.deily

#19943: typo: unkown ??? unknown
http://bugs.python.org/issue19943  closed by ezio.melotti

#19945: os.path.split starting with two slashes
http://bugs.python.org/issue19945  closed by Toilal

#19946: Have multiprocessing raise ImportError when spawning a process
http://bugs.python.org/issue19946  closed by brett.cannon

#19947: Inspect module broken
http://bugs.python.org/issue19947  closed by zach.ware

#19951: parse_qsl fails on empty query argument without =
http://bugs.python.org/issue19951  closed by r.david.murray

#19952: asyncio: test_wait_for_handle failure
http://bugs.python.org/issue19952  closed by haypo

#19957: Minor refactor of Lib/email/encoders.py
http://bugs.python.org/issue19957  closed by r.david.murray

#19958: Assignment success despite TypeError exception
http://bugs.python.org/issue19958  closed by ezio.melotti

#19964: '?' is always non-greedy
http://bugs.python.org/issue19964  closed by tim.peters

#19969: PyBytes_FromFormatV("%c") and PyString_FromFormatV("%c") don't
http://bugs.python.org/issue19969  closed by haypo

#19971: Remove Tulip words from asyncio documentation/code
http://bugs.python.org/issue19971  closed by haypo

#19973: Deprecate pyio
http://bugs.python.org/issue19973  closed by larry

From stefan-usenet at bytereef.org  Fri Dec 13 18:27:08 2013
From: stefan-usenet at bytereef.org (Stefan Krah)
Date: Fri, 13 Dec 2013 18:27:08 +0100
Subject: [Python-Dev] How do we feel about using pragmas and
 __attribute__ in C code?
In-Reply-To: <CAP1=2W66gD2WHTeQ0579dnPwetu=jGvCu43nxuSxwxurmxqEXg@mail.gmail.com>
References: <CAP1=2W66gD2WHTeQ0579dnPwetu=jGvCu43nxuSxwxurmxqEXg@mail.gmail.com>
Message-ID: <20131213172708.GA11053@sleipnir.bytereef.org>

Brett Cannon <brett at yvrsfo.ca> wrote:
> So is there any reason to not use pragmas sparsely in the code?

I'm +1 on using pragmas for suppressing selected warnings.


> Tying into this and using compiler-specific things in C code, what about
> __attribute__? http://bugs.python.org/issue19298 proposes an idea that Daniel
> Stutzbach originally came up with where we could use __atribute__ (behind a
> nicer macro) to help detect refleaks on PyObject* stack variables. Would
> __attribute__ usage be okay in that situation?

I would have to see an example function, mostly to get an idea of how
readable the code is.


Stefan Krah



From christian at python.org  Fri Dec 13 18:43:20 2013
From: christian at python.org (Christian Heimes)
Date: Fri, 13 Dec 2013 18:43:20 +0100
Subject: [Python-Dev] How do we feel about using pragmas and
	__attribute__ in C code?
In-Reply-To: <CAP1=2W66gD2WHTeQ0579dnPwetu=jGvCu43nxuSxwxurmxqEXg@mail.gmail.com>
References: <CAP1=2W66gD2WHTeQ0579dnPwetu=jGvCu43nxuSxwxurmxqEXg@mail.gmail.com>
Message-ID: <52AB4738.70603@python.org>

Am 13.12.2013 18:04, schrieb Brett Cannon:
> http://bugs.python.org/issue12837 deals with the single compiler warning
> left on OS X: a tautalogical compare in socketmodule.c that is valid
> under POSIX. I have a solution that uses pragmas to turn off
> tautological compare warnings for the single 'if' statement that
> triggers it. But there are very few places in Python's code base which
> use pragmas and I have never seen a discussion if we are okay with their
> overall use.

+1

We should aim for zero compiler warnings. You may have to wrap the
pragma in a #ifdef __clang__ block to silence warnings:

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/830/steps/compile/logs/warnings%20%2822%29

> Tying into this and using compiler-specific things in C code, what about
> __attribute__? http://bugs.python.org/issue19298 proposes an idea that
> Daniel Stutzbach originally came up with where we could use __atribute__
> (behind a nicer macro) to help detect refleaks on PyObject* stack
> variables. Would __attribute__ usage be okay in that situation?

+1, too.

Christian


From alexander.belopolsky at gmail.com  Fri Dec 13 18:56:14 2013
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 13 Dec 2013 12:56:14 -0500
Subject: [Python-Dev] (#19562) Asserts in Python stdlib code
	(datetime.py)
In-Reply-To: <CAExdVNnvs1-haqU_4d6a0-h8N5Pzo7k+rJK5hDZbdCy8dMpjzQ@mail.gmail.com>
References: <l66j2p$13n$1@ger.gmane.org>
 <CAExdVNnvs1-haqU_4d6a0-h8N5Pzo7k+rJK5hDZbdCy8dMpjzQ@mail.gmail.com>
Message-ID: <CAP7h-xa2me5C-5Lw24ZVaqsEQ1GyBqcYyBvDwXt4FP9_dyaD=A@mail.gmail.com>

On Fri, Nov 15, 2013 at 9:10 PM, Tim Peters <tim.peters at gmail.com> wrote:

> > _DI4Y   = _days_before_year(5)
> > # A 4-year cycle has an extra leap day over what we'd get from pasting
> > # together 4 single years.
> > assert _DI4Y == 4 * 365 + 1
> >
> > To me, the constant should be directly set to its known value.
> > _DI4Y = 4*365 + 1.
> > The function should then be tested in test_datetime.
> >   self.assertEqual(dt._days_before_year(5), dt._DI4Y)
>
> I think making that change would be pointless code churn.  Harmful,
> even.  As the guy who happened to have written that code ;-), I think
> it's valuable to have the _code_ (not off buried in some monstrously
> tedious test file) explain what the comments there do explain, and
> verify with the assert.  If anyone needs to muck with the
> implementation of datetime, it's crucial they understand what DI4Y
> _means_, and that it's identical to _days_before_year(5).  Its actual
> value (4*365 + 1) isn't really interesting.  Defining _DI4Y _as_
> _days_before_year(5) captures its _meaning_.
>


Interestingly, the corresponding C code is closer to what Terry suggested:

/* Number of days in 4, 100, and 400 year cycles.  That these have
 * the correct values is asserted in the module init function.
 */
#define DI4Y    1461    /* days_before_year(5); days in 4 years */
#define DI100Y  36524   /* days_before_year(101); days in 100 years */
#define DI400Y  146097  /* days_before_year(401); days in 400 years  */
...  skipping to the init function ...
    /* A 4-year cycle has an extra leap day over what we'd get from
     * pasting together 4 single years.
     */
    assert(DI4Y == 4 * 365 + 1);
    assert(DI4Y == days_before_year(4+1));

This is probably explainable by the limitations of the C language, but I
would find

_DI4Y = 4 * 365 + 1
assert _DI4Y == _days_before_year(5)

to be more natural than the way it is currently written.


>
> Ain't broke - don't fix.


Agree.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131213/d847441d/attachment.html>

From sky.kok at speaklikeaking.com  Sat Dec 14 05:56:06 2013
From: sky.kok at speaklikeaking.com (Vajrasky Kok)
Date: Sat, 14 Dec 2013 12:56:06 +0800
Subject: [Python-Dev] How long the wrong type of argument should we limit
 (or not) in the error message (C-api)?
Message-ID: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>

Greetings,

When fixing/adding error message for wrong type of argument in C code,
I am always confused, how long the wrong type is the ideal?

The type of error message that I am talking about:

"Blabla() argument 1 must be integer not wrong_type".

We have inconsistency in CPython code, for example:

Python/sysmodule.c
===============
        PyErr_Format(PyExc_TypeError,
                        "can't intern %.400s", s->ob_type->tp_name);

Modules/_json.c
============
        PyErr_Format(PyExc_TypeError,
                     "first argument must be a string, not %.80s",
                     Py_TYPE(pystr)->tp_name);


Objects/typeobject.c
===============
        PyErr_Format(PyExc_TypeError,
                     "can only assign string to %s.__name__, not '%s'",
                     type->tp_name, Py_TYPE(value)->tp_name);

So is it %.400s or %.80s or %s? I vote for %s.

Other thing is which one is more preferable? Py_TYPE(value)->tp_name
or value->ob_type->tp_name? I vote for Py_TYPE(value)->tp_name.

Or this is just a matter of taste?

Thank you.

Vajrasky Kok

From dwightdhutto at gmail.com  Sat Dec 14 06:21:35 2013
From: dwightdhutto at gmail.com (David Hutto)
Date: Sat, 14 Dec 2013 00:21:35 -0500
Subject: [Python-Dev] How long the wrong type of argument should we
 limit (or not) in the error message (C-api)?
In-Reply-To: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
References: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
Message-ID: <CA+vVgJWVJ6h0bNZgF1JxgXu_KfNgXS_uvn5=BVtHrGAGODCVHA@mail.gmail.com>

Being that python is, to me, a prototyping language, then every possible
outcome should be presented to the end user.

A full variety of explanations should be presented to the programmer.



On Fri, Dec 13, 2013 at 11:56 PM, Vajrasky Kok
<sky.kok at speaklikeaking.com>wrote:

> Greetings,
>
> When fixing/adding error message for wrong type of argument in C code,
> I am always confused, how long the wrong type is the ideal?
>
> The type of error message that I am talking about:
>
> "Blabla() argument 1 must be integer not wrong_type".
>
> We have inconsistency in CPython code, for example:
>
> Python/sysmodule.c
> ===============
>         PyErr_Format(PyExc_TypeError,
>                         "can't intern %.400s", s->ob_type->tp_name);
>
> Modules/_json.c
> ============
>         PyErr_Format(PyExc_TypeError,
>                      "first argument must be a string, not %.80s",
>                      Py_TYPE(pystr)->tp_name);
>
>
> Objects/typeobject.c
> ===============
>         PyErr_Format(PyExc_TypeError,
>                      "can only assign string to %s.__name__, not '%s'",
>                      type->tp_name, Py_TYPE(value)->tp_name);
>
> So is it %.400s or %.80s or %s? I vote for %s.
>
> Other thing is which one is more preferable? Py_TYPE(value)->tp_name
> or value->ob_type->tp_name? I vote for Py_TYPE(value)->tp_name.
>
> Or this is just a matter of taste?
>
> Thank you.
>
> Vajrasky Kok
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/dwightdhutto%40gmail.com
>



-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com <http://www.hitwebdevelopment.com>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131214/6fff348a/attachment.html>

From jurko.gospodnetic at pke.hr  Sat Dec 14 15:14:10 2013
From: jurko.gospodnetic at pke.hr (=?windows-1250?Q?Jurko_Gospodneti=E6?=)
Date: Sat, 14 Dec 2013 15:14:10 +0100
Subject: [Python-Dev] Default SIGINT handling dangerous?
Message-ID: <l8hp36$pkh$1@ger.gmane.org>

   Hi all.

   Is there any way to disable the default asynchronous exception 
raising SIGINT signal handling? Or a plan to add support for this? My 
searches on the net found several bug reports and discussions regarding 
this, but nothing seems final... :-(

   I believe the current Python default SIGINT handling by raising an 
asynchronous KeyboardInterrupt exception is dangerous, and can directly 
cause Python interpreter crashes even if no user code is involved, or 
any sort of other 'undefined behaviour' if it is.

   On Windows at least (using Python 3.3.3 at the moment, but seen with 
earlier versions as well), I occasionally get 'python.exe has stopped 
working' dialogs when Ctrl-C is pressed (most often if pressed during 
Python's initialization - loading site.py or earlier).

   The problem with asynchronous exceptions is, of course, that they can 
occur at _any_ time, even at the start of a finally: block, effectively 
causing cleanup code to be skipped even though the programmer intended 
it to be called even in case of exceptions.

   My scripts replace the default SIGINT/SIGBREAK signal handlers as 
soon as possible, and everything works great after that, but things get 
ugly if Ctrl-C is pressed before the script gets a chance to do this. I 
could even live with an 'exit with an ugly traceback', but having the 
process hang or fail so that Windows reports it as non-responding or 
reports it as 'stopped working' and offers to send failure information 
to Microsoft? That just leaves a bad taste in my mouth. :-(

   Also, Python documentation should not helpfully state or infer in 
several places that user can handle KeyboardInterrupt exceptions to 
implement Ctrl-C handling. Even if you do manage to catch it, you must 
never ever ignore it and must terminate your application since it might 
have already been left in an inconsistent state internally (e.g. some 
important finally clause got skipped, even one located deep in the 
Python standard library internals). Doing anything else can only be 
considered a partially working hack. Another problem is that that 
multiple SIGINT signals might occur in a sequence and any such 
KeyboardInterrupt handling can itself be interrupted in the same way as 
the original code. You can say that this is 'unlikely', or even add 
additional code to make this even more unlikely, but it still smells 
bad. :-(

   Hope this helps.

   Best regards,
     Jurko Gospodneti?


   Below, I've included a few script outputs (tracebacks included) from 
instances where Python interpreter crashed due to pressing Ctrl-C soon 
after an empty Python script has been run.

In the first of these instances I got the Microsoft's error reporting 
dialog. In all the later instances I checked the Python process's debug 
output and every time it included the message: 'Microsoft Visual Studio 
C Runtime Library has detected a fatal error in python.exe.'.

Using:
   - OS: Windows 7 SP1 x64
   - Python 3.3.3 (64-it)
   - default site.py

--------------
Occurrence #1:
--------------
> D:\Workplace>run.py
> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> Traceback (most recent call last):
>   File "<frozen importlib._bootstrap>", line 755, in _open_registry
> FileNotFoundError: [WinError 2] The system cannot find the file specified
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "C:\Program Files\Python\Python333\lib\encodings\__init__.py", line 98, in search_function
>     level=0)
>   File "<frozen importlib._bootstrap>", line 1565, in _find_and_load
>   File "<frozen importlib._bootstrap>", line 1523, in_find_and_load_unlocked
>   File "<frozen importlib._bootstrap>", line 1477, in _find_module
>   File "<frozen importlib._bootstrap>", line 777, in find_module
>   File "<frozen importlib._bootstrap>", line 768, in _search_registry
>   File "<frozen importlib._bootstrap>", line 755, in _open_registry
> KeyboardInterrupt


--------------
Occurrence #2:
--------------
> D:\Workplace>run.py
> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> Traceback (most recent call last):
>   File "C:\Program Files\Python\Python333\lib\codecs.py", line 165, in __init__
>     def __init__(self, errors='strict'):
> KeyboardInterrupt


--------------
Occurrence #3:
--------------
> D:\Workplace>run.py
> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> Traceback (most recent call last):
>   File "<frozen importlib._bootstrap>", line 1565, in _find_and_load
>   File "<frozen importlib._bootstrap>", line 1523, in _find_and_load_unlocked
>   File "<frozen importlib._bootstrap>", line 1477, in _find_module
>   File "<frozen importlib._bootstrap>", line 1309, in find_module
>   File "<frozen importlib._bootstrap>", line 1288, in _get_loader
>   File "<frozen importlib._bootstrap>", line 1387, in find_loader
>   File "<frozen importlib._bootstrap>", line 110, in _path_isfile
>   File "<frozen importlib._bootstrap>", line 101, in _path_is_mode_type
> KeyboardInterrupt


--------------
Occurrence #4:
--------------
> D:\Workplace>run.py
> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> Traceback (most recent call last):
>   File "C:\Program Files\Python\Python333\lib\io.py", line 52, in <module>
>     import abc
>   File "<frozen importlib._bootstrap>", line 1565, in _find_and_load
>   File "<frozen importlib._bootstrap>", line 1533, in _find_and_load_unlocked
>   File "<frozen importlib._bootstrap>", line 486, in _verbose_message
> KeyboardInterrupt


--------------
Occurrence #5:
--------------
> D:\Workplace>run.py
> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> Traceback (most recent call last):
>   File "C:\Program Files\Python\Python333\lib\io.py", line 52, in <module>
>     import abc
>   File "C:\Program Files\Python\Python333\lib\abc.py", line 6, in <module>
>     from _weakrefset import WeakSet
>   File "<frozen importlib._bootstrap>", line 1559, in _find_and_load
> KeyboardInterrupt


--------------
Occurrence #6:
--------------
> D:\Workplace>run.py
> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> Traceback (most recent call last):
>   File "C:\Program Files\Python\Python333\lib\encodings\__init__.py", line 69, in search_function
>     def search_function(encoding):
> KeyboardInterrupt


--------------
Occurrence #7:
--------------
> D:\Workplace>run.py
> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> Traceback (most recent call last):
>   File "C:\Program Files\Python\Python333\lib\io.py", line 52, in <module>
>     import abc
>   File "C:\Program Files\Python\Python333\lib\abc.py", line 6, in <module>
>     from _weakrefset import WeakSet
>   File "<frozen importlib._bootstrap>", line 1565, in _find_and_load
>   File "<frozen importlib._bootstrap>", line 1532, in _find_and_load_unlocked
>   File "<frozen importlib._bootstrap>", line 584, in _check_name_wrapper
>   File "<frozen importlib._bootstrap>", line 1022, in load_module
>   File "<frozen importlib._bootstrap>", line 1003, in load_module
> KeyboardInterrupt


--------------
Occurrence #8:
--------------
> D:\Workplace>run.py
> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> Traceback (most recent call last):
>   File "C:\Program Files\Python\Python333\lib\encodings\__init__.py", line 98, in search_function
>     level=0)
>   File "<frozen importlib._bootstrap>", line 1565, in _find_and_load
>   File "<frozen importlib._bootstrap>", line 1532, in _find_and_load_unlocked
>   File "<frozen importlib._bootstrap>", line 584, in _check_name_wrapper
>   File "<frozen importlib._bootstrap>", line 1022, in load_module
>   File "<frozen importlib._bootstrap>", line 1003, in load_module
>   File "<frozen importlib._bootstrap>", line 560, in module_for_loader_wrapper
>   File "<frozen importlib._bootstrap>", line 857, in _load_module
>   File "<frozen importlib._bootstrap>", line 439, in cache_from_source
> KeyboardInterrupt


--------------
Occurrence #9:
--------------
> D:\Workplace>run.py
> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> Traceback (most recent call last):
>   File "C:\Program Files\Python\Python333\lib\encodings\__init__.py", line 98, in search_function
>     level=0)
>   File "C:\Program Files\Python\Python333\lib\encodings\cp852.py", line 175, in <module>
>     0x00ff: 0x00a0,     #  NO-BREAK SPACE
> KeyboardInterrupt


From rdmurray at bitdance.com  Sat Dec 14 17:14:34 2013
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 14 Dec 2013 11:14:34 -0500
Subject: [Python-Dev] Default SIGINT handling dangerous?
In-Reply-To: <l8hp36$pkh$1@ger.gmane.org>
References: <l8hp36$pkh$1@ger.gmane.org>
Message-ID: <20131214161435.2018E250848@webabinitio.net>

On Sat, 14 Dec 2013 15:14:10 +0100, "Jurko Gospodneti" <jurko.gospodnetic at pke.hr> wrote:
>    My scripts replace the default SIGINT/SIGBREAK signal handlers as 
> soon as possible, and everything works great after that, but things get 
> ugly if Ctrl-C is pressed before the script gets a chance to do this. I 
> could even live with an 'exit with an ugly traceback', but having the 
> process hang or fail so that Windows reports it as non-responding or 
> reports it as 'stopped working' and offers to send failure information 
> to Microsoft? That just leaves a bad taste in my mouth. :-(

This sounds like a more troubling variation on the issue raised in
issue 14288 (http://bugs.python.org/issue14228).  The solution proposed 
there would appear to be something that would help you, so you might
want to chime in on that issue.

(I'll be curious to see the responses to the other points you raise.)

--David

From guido at python.org  Sat Dec 14 17:31:26 2013
From: guido at python.org (Guido van Rossum)
Date: Sat, 14 Dec 2013 08:31:26 -0800
Subject: [Python-Dev] Default SIGINT handling dangerous?
In-Reply-To: <l8hp36$pkh$1@ger.gmane.org>
References: <l8hp36$pkh$1@ger.gmane.org>
Message-ID: <CAP7+vJ+oL=dnKDvx+geBprsnZ+3XAwQUO5SYmJAw6QS3NWWG+g@mail.gmail.com>

Your subject should probably have mentioned Windows. SIGINT handling
on UNIX is well-behaved. Yes, you can interrupt a finally clause, but
this by itself doesn't threaten the integrity of the interpreter and
the standard data types.

On Windows, "signal" handling is some feeble emulation done by the C
library wrappers and all bets are, as you've discovered, off. My own
experience is the opposite of yours -- I often end up with
uninterruptable runaway code that can only be stopped by ctrl-BRK,
which takes e.g. Powershell with it. :-(

That said, I'd be fine with a command-line flag to skip the default
SIGINT handler setup.

-- 
--Guido van Rossum (python.org/~guido)

From greg.ewing at canterbury.ac.nz  Sat Dec 14 22:07:20 2013
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 15 Dec 2013 10:07:20 +1300
Subject: [Python-Dev] How long the wrong type of argument should we
 limit (or not) in the error message (C-api)?
In-Reply-To: <CA+vVgJWVJ6h0bNZgF1JxgXu_KfNgXS_uvn5=BVtHrGAGODCVHA@mail.gmail.com>
References: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
 <CA+vVgJWVJ6h0bNZgF1JxgXu_KfNgXS_uvn5=BVtHrGAGODCVHA@mail.gmail.com>
Message-ID: <52ACC888.4020805@canterbury.ac.nz>

David Hutto wrote:
> Being that python is, to me, a prototyping language, then every possible 
> outcome should be presented to the end user.

So we should produce a quantum superposition of
error messages? :-)

(Sorry, I've been watching Susskind's lectures on
QM and I've got quantum on the brain at the moment.)

-- 
Greg

From jurko.gospodnetic at pke.hr  Sun Dec 15 00:09:21 2013
From: jurko.gospodnetic at pke.hr (=?UTF-8?B?SnVya28gR29zcG9kbmV0acSH?=)
Date: Sun, 15 Dec 2013 00:09:21 +0100
Subject: [Python-Dev] Default SIGINT handling dangerous?
In-Reply-To: <20131214161435.2018E250848@webabinitio.net>
References: <l8hp36$pkh$1@ger.gmane.org>
 <20131214161435.2018E250848@webabinitio.net>
Message-ID: <l8ioel$j22$1@ger.gmane.org>

   Hi.

On 14.12.2013. 17:14, R. David Murray wrote:
> On Sat, 14 Dec 2013 15:14:10 +0100, "Jurko Gospodneti" <jurko.gospodnetic at pke.hr> wrote:
>>     My scripts replace the default SIGINT/SIGBREAK signal handlers as
>> soon as possible, and everything works great after that, but things get
>> ugly if Ctrl-C is pressed before the script gets a chance to do this. I
>> could even live with an 'exit with an ugly traceback', but having the
> process hang or fail so that Windows reports it as non-responding or
>> reports it as 'stopped working' and offers to send failure information
>> to Microsoft? That just leaves a bad taste in my mouth. :-(
>
> This sounds like a more troubling variation on the issue raised in
> issue 14288 (http://bugs.python.org/issue14228).  The solution proposed
> there would appear to be something that would help you, so you might
> want to chime in on that issue.

   Thanks for the tip. I've seen the bug report you mention before, but 
thought to first inquire about the issue on the mailing list. I'll chime 
in what I know to the bug report.

   Final solution proposed there is to add a command-line option to 
delay enabling current default Python SIGINT handling until after the 
site.py package has been loaded.

   That would most likely avoid the startup crashes I mentioned in the 
original post.

   On Unix it would make Ctrl-C silently terminate the process if it 
occurs before default Python signal handling is enabled. I do not know 
what effect this would have on Windows - possibly the signal would 
simply be ignored & lost.

   It would also still leave a slight window between when Python sets up 
its default SIGINT handling and when user code has a chance to set up 
its own.

   My first instinct is to not do that and instead add an option to 
block SIGINT handling and allow user code to enable its own or default 
Python handling as it wishes and then unblock SIGINT handling. Note that 
by 'blocking' a signal I do not mean losing/ignoring it but delaying its 
handling until signal handling is unblocked.

   Best regards,
     Jurko Gospodneti?



From ncoghlan at gmail.com  Sun Dec 15 00:10:08 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 15 Dec 2013 09:10:08 +1000
Subject: [Python-Dev] How long the wrong type of argument should we
 limit (or not) in the error message (C-api)?
In-Reply-To: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
References: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
Message-ID: <CADiSq7fEBjOtB9iZzdbnngWXnDJW4OJrgq0W74wG879o2CDELA@mail.gmail.com>

On 14 December 2013 14:56, Vajrasky Kok <sky.kok at speaklikeaking.com> wrote:
> Greetings,
>
> When fixing/adding error message for wrong type of argument in C code,
> I am always confused, how long the wrong type is the ideal?
>
> The type of error message that I am talking about:
>
> "Blabla() argument 1 must be integer not wrong_type".
>
> We have inconsistency in CPython code, for example:
>
> Python/sysmodule.c
> ===============
>         PyErr_Format(PyExc_TypeError,
>                         "can't intern %.400s", s->ob_type->tp_name);
>
> Modules/_json.c
> ============
>         PyErr_Format(PyExc_TypeError,
>                      "first argument must be a string, not %.80s",
>                      Py_TYPE(pystr)->tp_name);
>
>
> Objects/typeobject.c
> ===============
>         PyErr_Format(PyExc_TypeError,
>                      "can only assign string to %s.__name__, not '%s'",
>                      type->tp_name, Py_TYPE(value)->tp_name);
>
> So is it %.400s or %.80s or %s? I vote for %s.
>
> Other thing is which one is more preferable? Py_TYPE(value)->tp_name
> or value->ob_type->tp_name? I vote for Py_TYPE(value)->tp_name.
>
> Or this is just a matter of taste?

The idiom has shifted over time, but the preference more recently is
definitely for length limiting user provided identifiers (which are
generally type names) to limit the maximum length of error messages
(to add another variant to the mix, PEP 7 has "%.100s" in an example
about breaking long lines that happens to include reporting
TypeError).

The question should probably be addressed directly in PEP 7, and I'd
be inclined to just bless the "%.400s" variant for future code.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From solipsis at pitrou.net  Sun Dec 15 00:16:54 2013
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 15 Dec 2013 00:16:54 +0100
Subject: [Python-Dev] How long the wrong type of argument should we
 limit (or not) in the error message (C-api)?
References: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
 <CADiSq7fEBjOtB9iZzdbnngWXnDJW4OJrgq0W74wG879o2CDELA@mail.gmail.com>
Message-ID: <20131215001654.089a9c35@fsol>

On Sun, 15 Dec 2013 09:10:08 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> The question should probably be addressed directly in PEP 7, and I'd
> be inclined to just bless the "%.400s" variant for future code.

Shouldn't we have a special "%T" shortcut instead of trying to
harmonize all the occurrences of `"%.400s", Py_TYPE(self)->tp_name` ?

Sprinkling the same magic number / convention everywhere doesn't sound
very future-proof, nor convenient.

Regards

Antoine.



From solipsis at pitrou.net  Sun Dec 15 00:19:05 2013
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 15 Dec 2013 00:19:05 +0100
Subject: [Python-Dev] Default SIGINT handling dangerous?
References: <l8hp36$pkh$1@ger.gmane.org>
Message-ID: <20131215001905.2941b93f@fsol>

On Sat, 14 Dec 2013 15:14:10 +0100
Jurko Gospodneti? <jurko.gospodnetic at pke.hr> wrote:
> 
>    I believe the current Python default SIGINT handling by raising an 
> asynchronous KeyboardInterrupt exception is dangerous, and can directly 
> cause Python interpreter crashes even if no user code is involved, or 
> any sort of other 'undefined behaviour' if it is.

It would be nice if you could get an actual C traceback, and open an
issue on the bug tracker. Python isn't supposed to crash willy-nilly
when Ctrl+C is pressed.

(also, which Python version is this?)

Regards

Antoine.



From victor.stinner at gmail.com  Sun Dec 15 00:52:44 2013
From: victor.stinner at gmail.com (Victor Stinner)
Date: Sun, 15 Dec 2013 00:52:44 +0100
Subject: [Python-Dev] How long the wrong type of argument should we
 limit (or not) in the error message (C-api)?
In-Reply-To: <20131215001654.089a9c35@fsol>
References: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
 <CADiSq7fEBjOtB9iZzdbnngWXnDJW4OJrgq0W74wG879o2CDELA@mail.gmail.com>
 <20131215001654.089a9c35@fsol>
Message-ID: <CAMpsgwbS6ggmjD5K-wndyK0Jrev9K3mxJSSF+gf5is=tdyNiOQ@mail.gmail.com>

2013/12/15 Antoine Pitrou <solipsis at pitrou.net>:
> Shouldn't we have a special "%T" shortcut instead of trying to
> harmonize all the occurrences of `"%.400s", Py_TYPE(self)->tp_name` ?

Oh, I like this proposition! The following pattern is very common in Python:

"... %.400s ...", Py_TYPE(self)->tp_name

Victor

From ncoghlan at gmail.com  Sun Dec 15 02:25:10 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 15 Dec 2013 11:25:10 +1000
Subject: [Python-Dev] How long the wrong type of argument should we
 limit (or not) in the error message (C-api)?
In-Reply-To: <CAMpsgwbS6ggmjD5K-wndyK0Jrev9K3mxJSSF+gf5is=tdyNiOQ@mail.gmail.com>
References: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
 <CADiSq7fEBjOtB9iZzdbnngWXnDJW4OJrgq0W74wG879o2CDELA@mail.gmail.com>
 <20131215001654.089a9c35@fsol>
 <CAMpsgwbS6ggmjD5K-wndyK0Jrev9K3mxJSSF+gf5is=tdyNiOQ@mail.gmail.com>
Message-ID: <CADiSq7e5ZHp3MyQgStzCPwzC6RK0V4iStU5yHhUaOGx1J4opgw@mail.gmail.com>

On 15 December 2013 09:52, Victor Stinner <victor.stinner at gmail.com> wrote:
> 2013/12/15 Antoine Pitrou <solipsis at pitrou.net>:
>> Shouldn't we have a special "%T" shortcut instead of trying to
>> harmonize all the occurrences of `"%.400s", Py_TYPE(self)->tp_name` ?
>
> Oh, I like this proposition! The following pattern is very common in Python:
>
> "... %.400s ...", Py_TYPE(self)->tp_name

Oh, yes, a %T shortcut for "length limited type name of the supplied
object" would be brilliant. We need this frequently for C level error
messages, and I almost always have to look at an existing example to
remember the exact incantation :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From jurko.gospodnetic at pke.hr  Sun Dec 15 03:33:38 2013
From: jurko.gospodnetic at pke.hr (=?UTF-8?B?SnVya28gR29zcG9kbmV0acSH?=)
Date: Sun, 15 Dec 2013 03:33:38 +0100
Subject: [Python-Dev] Default SIGINT handling dangerous?
In-Reply-To: <20131215001905.2941b93f@fsol>
References: <l8hp36$pkh$1@ger.gmane.org> <20131215001905.2941b93f@fsol>
Message-ID: <52AD1502.30601@pke.hr>

   Hi.

On 15.12.2013. 0:19, Antoine Pitrou wrote:
> It would be nice if you could get an actual C traceback
 > and open an issue on the bug tracker.

   Done. C traceback and related information collected and attached to a 
new Python issue report available at:
   http://bugs.python.org/issue19983


> Python isn't supposed to crash willy-nilly when Ctrl+C is
> pressed.

  :-D


> (also, which Python version is this?)

   - Python 3.3.3 (64-bit) downloaded from:
       http://www.python.org/download/releases/3.3.3
   - OS: Windows 7 SP1 x64
   - default site.py


   Hope this helps.

   Best regards,
     Jurko Gospodneti?



From steve at pearwood.info  Sun Dec 15 04:51:29 2013
From: steve at pearwood.info (Steven D'Aprano)
Date: Sun, 15 Dec 2013 14:51:29 +1100
Subject: [Python-Dev] How long the wrong type of argument should we
	limit (or not) in the error message (C-api)?
In-Reply-To: <CADiSq7e5ZHp3MyQgStzCPwzC6RK0V4iStU5yHhUaOGx1J4opgw@mail.gmail.com>
References: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
 <CADiSq7fEBjOtB9iZzdbnngWXnDJW4OJrgq0W74wG879o2CDELA@mail.gmail.com>
 <20131215001654.089a9c35@fsol>
 <CAMpsgwbS6ggmjD5K-wndyK0Jrev9K3mxJSSF+gf5is=tdyNiOQ@mail.gmail.com>
 <CADiSq7e5ZHp3MyQgStzCPwzC6RK0V4iStU5yHhUaOGx1J4opgw@mail.gmail.com>
Message-ID: <20131215035128.GV29356@ando>

On Sun, Dec 15, 2013 at 11:25:10AM +1000, Nick Coghlan wrote:

> Oh, yes, a %T shortcut for "length limited type name of the supplied
> object" would be brilliant. We need this frequently for C level error
> messages, and I almost always have to look at an existing example to
> remember the exact incantation :)

What are the chances that could be made available from pure Python too? 
Having to extract the name of the type is a very common need for error 
messages, and I never know whether I ought to write type(obj).__name__ 
or obj.__class__.__name__. A %T and/or {:T} format code could be the One 
Obvious Way to include the type name in strings:

    raise TypeError("Expected int but got '{:T}'".format(obj))

looks nicer to me than either of:

    raise TypeError("Expected int but got '{}'".format(type(obj).__name__))
    raise TypeError("Expected int but got '{}'".format(obj.__class__.__name__))


-- 
Steven

From dwightdhutto at gmail.com  Sun Dec 15 05:09:59 2013
From: dwightdhutto at gmail.com (David Hutto)
Date: Sat, 14 Dec 2013 23:09:59 -0500
Subject: [Python-Dev] How long the wrong type of argument should we
 limit (or not) in the error message (C-api)?
In-Reply-To: <52ACC888.4020805@canterbury.ac.nz>
References: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
 <CA+vVgJWVJ6h0bNZgF1JxgXu_KfNgXS_uvn5=BVtHrGAGODCVHA@mail.gmail.com>
 <52ACC888.4020805@canterbury.ac.nz>
Message-ID: <CA+vVgJUPozbMXHGQY0Y9zryv6fqWzz5ptUquW-A7D_6HEePd9A@mail.gmail.com>

Susskinds...Me too, but the refinement of the error messages is the point.
We should be looking at the full assessment of the error, which the
prototyping of python should present.

I've seen others reply that python wouldn't be around, or that theree are
other forms I've seen before that will take the forefront.

The point should be to align the prototyping of python with the updates in
technology taking place.

It should be like it usually is, line for lineerror assessments, even
followed by further info to inform the prototyper that is looking to
translate to a lower level language.


On Sat, Dec 14, 2013 at 4:07 PM, Greg Ewing <greg.ewing at canterbury.ac.nz>wrote:

> David Hutto wrote:
>
>> Being that python is, to me, a prototyping language, then every possible
>> outcome should be presented to the end user.
>>
>
> So we should produce a quantum superposition of
> error messages? :-)
>
> (Sorry, I've been watching Susskind's lectures on
> QM and I've got quantum on the brain at the moment.)
>
> --
> Greg
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> dwightdhutto%40gmail.com
>



-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com <http://www.hitwebdevelopment.com>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131214/b7ec097e/attachment.html>

From dwightdhutto at gmail.com  Sun Dec 15 05:18:45 2013
From: dwightdhutto at gmail.com (David Hutto)
Date: Sat, 14 Dec 2013 23:18:45 -0500
Subject: [Python-Dev] How long the wrong type of argument should we
 limit (or not) in the error message (C-api)?
In-Reply-To: <CA+vVgJUPozbMXHGQY0Y9zryv6fqWzz5ptUquW-A7D_6HEePd9A@mail.gmail.com>
References: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
 <CA+vVgJWVJ6h0bNZgF1JxgXu_KfNgXS_uvn5=BVtHrGAGODCVHA@mail.gmail.com>
 <52ACC888.4020805@canterbury.ac.nz>
 <CA+vVgJUPozbMXHGQY0Y9zryv6fqWzz5ptUquW-A7D_6HEePd9A@mail.gmail.com>
Message-ID: <CA+vVgJWNKdu7L6dyx5==D-+raupNqf5hCrKeXRovPnmO3qZcFw@mail.gmail.com>

We all strive to be python programmers, and some of the responses are that
it might not be around in the future.

Now we all probably speak conversational in other langs, but I'm thinking
of keeping around a great prototyping language.


So the topic becomes how too integrate it with the not just the expected,
but the unexpected technologies....Despite the topic is error messages, it
should apply to all possibilities that could be derived from a prototyping
language like python.


On Sat, Dec 14, 2013 at 11:09 PM, David Hutto <dwightdhutto at gmail.com>wrote:

> Susskinds...Me too, but the refinement of the error messages is the point.
> We should be looking at the full assessment of the error, which the
> prototyping of python should present.
>
> I've seen others reply that python wouldn't be around, or that theree are
> other forms I've seen before that will take the forefront.
>
> The point should be to align the prototyping of python with the updates in
> technology taking place.
>
> It should be like it usually is, line for lineerror assessments, even
> followed by further info to inform the prototyper that is looking to
> translate to a lower level language.
>
>
> On Sat, Dec 14, 2013 at 4:07 PM, Greg Ewing <greg.ewing at canterbury.ac.nz>wrote:
>
>> David Hutto wrote:
>>
>>> Being that python is, to me, a prototyping language, then every possible
>>> outcome should be presented to the end user.
>>>
>>
>> So we should produce a quantum superposition of
>> error messages? :-)
>>
>> (Sorry, I've been watching Susskind's lectures on
>> QM and I've got quantum on the brain at the moment.)
>>
>> --
>> Greg
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
>> dwightdhutto%40gmail.com
>>
>
>
>
> --
> Best Regards,
> David Hutto
> *CEO:* *http://www.hitwebdevelopment.com
> <http://www.hitwebdevelopment.com>*
>



-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com <http://www.hitwebdevelopment.com>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131214/cc7b0da1/attachment.html>

From sky.kok at speaklikeaking.com  Sun Dec 15 06:30:44 2013
From: sky.kok at speaklikeaking.com (Vajrasky Kok)
Date: Sun, 15 Dec 2013 13:30:44 +0800
Subject: [Python-Dev] How long the wrong type of argument should we
 limit (or not) in the error message (C-api)?
In-Reply-To: <CAMpsgwbS6ggmjD5K-wndyK0Jrev9K3mxJSSF+gf5is=tdyNiOQ@mail.gmail.com>
References: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
 <CADiSq7fEBjOtB9iZzdbnngWXnDJW4OJrgq0W74wG879o2CDELA@mail.gmail.com>
 <20131215001654.089a9c35@fsol>
 <CAMpsgwbS6ggmjD5K-wndyK0Jrev9K3mxJSSF+gf5is=tdyNiOQ@mail.gmail.com>
Message-ID: <CAB+fVUVZrW+yfrEAK1O1xZAK1wd_4xYYcTVhS96Pi3BWNLNQwA@mail.gmail.com>

On Sun, Dec 15, 2013 at 7:52 AM, Victor Stinner
<victor.stinner at gmail.com> wrote:
>
> Oh, I like this proposition! The following pattern is very common in Python:
>
> "... %.400s ...", Py_TYPE(self)->tp_name
>

Okay, I have created ticket (and preliminary patch) for this
enhancement: http://bugs.python.org/issue19984

Vajrasky Kok

From ethan at stoneleaf.us  Sun Dec 15 17:33:30 2013
From: ethan at stoneleaf.us (Ethan Furman)
Date: Sun, 15 Dec 2013 08:33:30 -0800
Subject: [Python-Dev] How long the wrong type of argument should we
 limit (or not) in the error message (C-api)?
In-Reply-To: <20131215035128.GV29356@ando>
References: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
 <CADiSq7fEBjOtB9iZzdbnngWXnDJW4OJrgq0W74wG879o2CDELA@mail.gmail.com>
 <20131215001654.089a9c35@fsol>
 <CAMpsgwbS6ggmjD5K-wndyK0Jrev9K3mxJSSF+gf5is=tdyNiOQ@mail.gmail.com>
 <CADiSq7e5ZHp3MyQgStzCPwzC6RK0V4iStU5yHhUaOGx1J4opgw@mail.gmail.com>
 <20131215035128.GV29356@ando>
Message-ID: <52ADD9DA.9030706@stoneleaf.us>

On 12/14/2013 07:51 PM, Steven D'Aprano wrote:
> On Sun, Dec 15, 2013 at 11:25:10AM +1000, Nick Coghlan wrote:
>
>> Oh, yes, a %T shortcut for "length limited type name of the supplied
>> object" would be brilliant. We need this frequently for C level error
>> messages, and I almost always have to look at an existing example to
>> remember the exact incantation :)
>
> What are the chances that could be made available from pure Python too?
> Having to extract the name of the type is a very common need for error
> messages, and I never know whether I ought to write type(obj).__name__
> or obj.__class__.__name__. A %T and/or {:T} format code could be the One
> Obvious Way to include the type name in strings

+1

--
~Ethan~

From ncoghlan at gmail.com  Sun Dec 15 22:30:56 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 16 Dec 2013 07:30:56 +1000
Subject: [Python-Dev] How long the wrong type of argument should we
 limit (or not) in the error message (C-api)?
In-Reply-To: <52ADD9DA.9030706@stoneleaf.us>
References: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
 <CADiSq7fEBjOtB9iZzdbnngWXnDJW4OJrgq0W74wG879o2CDELA@mail.gmail.com>
 <20131215001654.089a9c35@fsol>
 <CAMpsgwbS6ggmjD5K-wndyK0Jrev9K3mxJSSF+gf5is=tdyNiOQ@mail.gmail.com>
 <CADiSq7e5ZHp3MyQgStzCPwzC6RK0V4iStU5yHhUaOGx1J4opgw@mail.gmail.com>
 <20131215035128.GV29356@ando> <52ADD9DA.9030706@stoneleaf.us>
Message-ID: <CADiSq7d8ub+FfMice-rp3CEWCQDAVym2BpPQUjds=0kPM1k7Hw@mail.gmail.com>

On 16 Dec 2013 02:58, "Ethan Furman" <ethan at stoneleaf.us> wrote:
>
> On 12/14/2013 07:51 PM, Steven D'Aprano wrote:
>>
>> On Sun, Dec 15, 2013 at 11:25:10AM +1000, Nick Coghlan wrote:
>>
>>> Oh, yes, a %T shortcut for "length limited type name of the supplied
>>> object" would be brilliant. We need this frequently for C level error
>>> messages, and I almost always have to look at an existing example to
>>> remember the exact incantation :)
>>
>>
>> What are the chances that could be made available from pure Python too?
>> Having to extract the name of the type is a very common need for error
>> messages, and I never know whether I ought to write type(obj).__name__
>> or obj.__class__.__name__. A %T and/or {:T} format code could be the One
>> Obvious Way to include the type name in strings
>
>
> +1

It's less obviously correct for Python code, though. In C, we're almost
always running off slots, so type(obj).__name__ has a very high chance of
being what we want, and is also preferred for speed reasons (since it's
just a couple of pointer dereferences).

At the Python level, whether to display obj.__name__ (working with a class
directly), type(obj).__name__ (working with the concrete type, ignoring any
proxying) or obj.__class__.__name__ (which takes proxying into account)
really depends on exactly what you're doing, and the speed differences
between them aren't so stark.

Cheers,
Nick.

>
> --
> ~Ethan~
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131216/e411210c/attachment.html>

From steve at pearwood.info  Mon Dec 16 02:23:10 2013
From: steve at pearwood.info (Steven D'Aprano)
Date: Mon, 16 Dec 2013 12:23:10 +1100
Subject: [Python-Dev] How long the wrong type of argument should we
	limit (or not) in the error message (C-api)?
In-Reply-To: <CADiSq7d8ub+FfMice-rp3CEWCQDAVym2BpPQUjds=0kPM1k7Hw@mail.gmail.com>
References: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
 <CADiSq7fEBjOtB9iZzdbnngWXnDJW4OJrgq0W74wG879o2CDELA@mail.gmail.com>
 <20131215001654.089a9c35@fsol>
 <CAMpsgwbS6ggmjD5K-wndyK0Jrev9K3mxJSSF+gf5is=tdyNiOQ@mail.gmail.com>
 <CADiSq7e5ZHp3MyQgStzCPwzC6RK0V4iStU5yHhUaOGx1J4opgw@mail.gmail.com>
 <20131215035128.GV29356@ando> <52ADD9DA.9030706@stoneleaf.us>
 <CADiSq7d8ub+FfMice-rp3CEWCQDAVym2BpPQUjds=0kPM1k7Hw@mail.gmail.com>
Message-ID: <20131216012307.GA29356@ando>

On Mon, Dec 16, 2013 at 07:30:56AM +1000, Nick Coghlan wrote:
> On 16 Dec 2013 02:58, "Ethan Furman" <ethan at stoneleaf.us> wrote:
> >
> > On 12/14/2013 07:51 PM, Steven D'Aprano wrote:
> >>
> >> On Sun, Dec 15, 2013 at 11:25:10AM +1000, Nick Coghlan wrote:
> >>
> >>> Oh, yes, a %T shortcut for "length limited type name of the supplied
> >>> object" would be brilliant. We need this frequently for C level error
> >>> messages, and I almost always have to look at an existing example to
> >>> remember the exact incantation :)
> >>
> >>
> >> What are the chances that could be made available from pure Python too?
> >> Having to extract the name of the type is a very common need for error
> >> messages, and I never know whether I ought to write type(obj).__name__
> >> or obj.__class__.__name__. A %T and/or {:T} format code could be the One
> >> Obvious Way to include the type name in strings
> >
> >
> > +1
> 
> It's less obviously correct for Python code, though. In C, we're almost
> always running off slots, so type(obj).__name__ has a very high chance of
> being what we want, and is also preferred for speed reasons (since it's
> just a couple of pointer dereferences).
> 
> At the Python level, whether to display obj.__name__ (working with a class
> directly), type(obj).__name__ (working with the concrete type, ignoring any
> proxying) or obj.__class__.__name__ (which takes proxying into account)
> really depends on exactly what you're doing, and the speed differences
> between them aren't so stark.

That's a good point, but I think most coders would have a very fuzzy 
idea of the difference between type(obj).__name__ and 
obj.__class__.__name__, and when to use one versus the other. I know I 
don't have a clue, and nearly always end up just arbitrarily picking 
one. It would be a good thing if the 95% of the time that I don't need 
to think about it, I don't need to think about it and just use {:T} 
formatting code. The other 5% of the time I can always extract the name 
manually, as before.

Likewise, I think that most of the time it is useful to distinguish 
between instances and classes, metaclasses not withstanding. If obj 
is itself a class, we should see its name directly, and not the name of 
its class (which will generally be "type"). In other words, what I 
usually want to write is:

    raise TypeError("some error regarding type '%s'" % 
         obj.__name__ if isinstance(obj, type) else type(obj).__name__
         )

(modulo difference between type(obj) and obj.__class__, as above), but 
what I end up doing is take the lazy way out and unconditionally use 
type(obj).__name__.

But this is getting further away from the %T formatting code at the C 
level, so perhaps it needs to go to Python Ideas first?



-- 
Steven

From stephen at xemacs.org  Mon Dec 16 07:37:12 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 16 Dec 2013 15:37:12 +0900
Subject: [Python-Dev] How long the wrong type of argument should
	we	limit (or not) in the error message (C-api)?
In-Reply-To: <20131216012307.GA29356@ando>
References: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
 <CADiSq7fEBjOtB9iZzdbnngWXnDJW4OJrgq0W74wG879o2CDELA@mail.gmail.com>
 <20131215001654.089a9c35@fsol>
 <CAMpsgwbS6ggmjD5K-wndyK0Jrev9K3mxJSSF+gf5is=tdyNiOQ@mail.gmail.com>
 <CADiSq7e5ZHp3MyQgStzCPwzC6RK0V4iStU5yHhUaOGx1J4opgw@mail.gmail.com>
 <20131215035128.GV29356@ando> <52ADD9DA.9030706@stoneleaf.us>
 <CADiSq7d8ub+FfMice-rp3CEWCQDAVym2BpPQUjds=0kPM1k7Hw@mail.gmail.com>
 <20131216012307.GA29356@ando>
Message-ID: <87ob4hz4h3.fsf@uwakimon.sk.tsukuba.ac.jp>

Steven D'Aprano writes:

 > That's a good point, but I think most coders would have a very fuzzy 
 > idea of the difference between type(obj).__name__ and 
 > obj.__class__.__name__, and when to use one versus the other.

 > Likewise, I think that most of the time it is useful to distinguish 
 > between instances and classes, metaclasses not withstanding.

To me trying to handle all of those distinctions in a single format
code sounds like way confusing magic (and probably will fail to DWIM
way too often).


From walter at livinglogic.de  Mon Dec 16 16:29:09 2013
From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=)
Date: Mon, 16 Dec 2013 16:29:09 +0100
Subject: [Python-Dev] How long the wrong type of argument should we
 limit (or not) in the error message (C-api)?
In-Reply-To: <52ADD9DA.9030706@stoneleaf.us>
References: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
 <CADiSq7fEBjOtB9iZzdbnngWXnDJW4OJrgq0W74wG879o2CDELA@mail.gmail.com>
 <20131215001654.089a9c35@fsol>
 <CAMpsgwbS6ggmjD5K-wndyK0Jrev9K3mxJSSF+gf5is=tdyNiOQ@mail.gmail.com>
 <CADiSq7e5ZHp3MyQgStzCPwzC6RK0V4iStU5yHhUaOGx1J4opgw@mail.gmail.com>
 <20131215035128.GV29356@ando> <52ADD9DA.9030706@stoneleaf.us>
Message-ID: <52AF1C45.4080208@livinglogic.de>

On 15.12.13 17:33, Ethan Furman wrote:
> On 12/14/2013 07:51 PM, Steven D'Aprano wrote:
>> On Sun, Dec 15, 2013 at 11:25:10AM +1000, Nick Coghlan wrote:
>>
>>> Oh, yes, a %T shortcut for "length limited type name of the supplied
>>> object" would be brilliant. We need this frequently for C level error
>>> messages, and I almost always have to look at an existing example to
>>> remember the exact incantation :)
>>
>> What are the chances that could be made available from pure Python too?
>> Having to extract the name of the type is a very common need for error
>> messages, and I never know whether I ought to write type(obj).__name__
>> or obj.__class__.__name__. A %T and/or {:T} format code could be the One
>> Obvious Way to include the type name in strings
>
> +1

I'd vote for including the module name in the string and using 
__qualname__ instead of __name__, i.e. make "{:T}".format(obj) 
equivalent to 
"{0.__class__.__module__}.{0.__class__.qualname__}".format(obj).

Servus,
    Walter


From eric at trueblade.com  Mon Dec 16 17:21:26 2013
From: eric at trueblade.com (Eric V. Smith)
Date: Mon, 16 Dec 2013 11:21:26 -0500
Subject: [Python-Dev] How long the wrong type of argument should we
 limit (or not) in the error message (C-api)?
In-Reply-To: <52AF1C45.4080208@livinglogic.de>
References: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
 <CADiSq7fEBjOtB9iZzdbnngWXnDJW4OJrgq0W74wG879o2CDELA@mail.gmail.com>
 <20131215001654.089a9c35@fsol>
 <CAMpsgwbS6ggmjD5K-wndyK0Jrev9K3mxJSSF+gf5is=tdyNiOQ@mail.gmail.com>
 <CADiSq7e5ZHp3MyQgStzCPwzC6RK0V4iStU5yHhUaOGx1J4opgw@mail.gmail.com>
 <20131215035128.GV29356@ando> <52ADD9DA.9030706@stoneleaf.us>
 <52AF1C45.4080208@livinglogic.de>
Message-ID: <52AF2886.5090501@trueblade.com>

On 12/16/2013 10:29 AM, Walter D?rwald wrote:
> I'd vote for including the module name in the string and using
> __qualname__ instead of __name__, i.e. make "{:T}".format(obj)
> equivalent to
> "{0.__class__.__module__}.{0.__class__.qualname__}".format(obj).

That's not possible in general. The format specifier interpretation is
done by each type. So, you could add this to str.__format__ and
int.__format__, but you can't add it to an arbitrary type's __format__.
For example, types not in the stdlib would never know about it.

There's no logic for calling through to object.__format__ for unknown
specifiers. Look at datetime, for example. It uses strftime, so "T"
currently just prints a literal "T".

And for object.__format__, we recently made it an error to specify any
format string. This is to prevent you from calling
format(an_object, ".30")
and "knowning" that it's interpreted by str.__format__ (because that's
the default conversion for object.__format__). If in the future
an_object's class added its own __format__, this code would break (or at
least do the wrong thing).

But I really do like the idea! Maybe there's a way to just make
obj.__class__ recognize "T", so you could at least do:
format(obj.__class__, "T")
or equivalently:
"{:T}".format(obj.__class__)

I realize that having to use .__class__ defeats some of the beauty of
this scheme.

Eric.



From ncoghlan at gmail.com  Mon Dec 16 21:49:38 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 17 Dec 2013 06:49:38 +1000
Subject: [Python-Dev] How long the wrong type of argument should we
 limit (or not) in the error message (C-api)?
In-Reply-To: <52AF2886.5090501@trueblade.com>
References: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
 <CADiSq7fEBjOtB9iZzdbnngWXnDJW4OJrgq0W74wG879o2CDELA@mail.gmail.com>
 <20131215001654.089a9c35@fsol>
 <CAMpsgwbS6ggmjD5K-wndyK0Jrev9K3mxJSSF+gf5is=tdyNiOQ@mail.gmail.com>
 <CADiSq7e5ZHp3MyQgStzCPwzC6RK0V4iStU5yHhUaOGx1J4opgw@mail.gmail.com>
 <20131215035128.GV29356@ando> <52ADD9DA.9030706@stoneleaf.us>
 <52AF1C45.4080208@livinglogic.de> <52AF2886.5090501@trueblade.com>
Message-ID: <CADiSq7ecveZ+jgg_+nJN+UPUrYKtEedgJyZXFZCeYDdOHOeExw@mail.gmail.com>

On 17 Dec 2013 02:23, "Eric V. Smith" <eric at trueblade.com> wrote:
>
> On 12/16/2013 10:29 AM, Walter D?rwald wrote:
> > I'd vote for including the module name in the string and using
> > __qualname__ instead of __name__, i.e. make "{:T}".format(obj)
> > equivalent to
> > "{0.__class__.__module__}.{0.__class__.qualname__}".format(obj).
>
> That's not possible in general. The format specifier interpretation is
> done by each type. So, you could add this to str.__format__ and
> int.__format__, but you can't add it to an arbitrary type's __format__.
> For example, types not in the stdlib would never know about it.

That just suggests it would need to be a type coercion code, like !a, !r,
and !s. However, that observation also suggests that starting with a
"classname" or "typename" builtin would be more appropriate than jumping
directly to a formatting code.

We've definitely drifted well into python-ideas territory at this point,
though :)

Cheers,
Nick.

>
> There's no logic for calling through to object.__format__ for unknown
> specifiers. Look at datetime, for example. It uses strftime, so "T"
> currently just prints a literal "T".
>
> And for object.__format__, we recently made it an error to specify any
> format string. This is to prevent you from calling
> format(an_object, ".30")
> and "knowning" that it's interpreted by str.__format__ (because that's
> the default conversion for object.__format__). If in the future
> an_object's class added its own __format__, this code would break (or at
> least do the wrong thing).
>
> But I really do like the idea! Maybe there's a way to just make
> obj.__class__ recognize "T", so you could at least do:
> format(obj.__class__, "T")
> or equivalently:
> "{:T}".format(obj.__class__)
>
> I realize that having to use .__class__ defeats some of the beauty of
> this scheme.
>
> Eric.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131217/a0bc2320/attachment.html>

From stefan at bytereef.org  Tue Dec 17 17:43:08 2013
From: stefan at bytereef.org (Stefan Krah)
Date: Tue, 17 Dec 2013 17:43:08 +0100
Subject: [Python-Dev] cffi in stdlib
In-Reply-To: <CAK5idxQA+9zbBGhG0Thxzg9aBEko9UBtFTGK9_uJJ1vkyrGXwg@mail.gmail.com>
References: <CAK5idxQA+9zbBGhG0Thxzg9aBEko9UBtFTGK9_uJJ1vkyrGXwg@mail.gmail.com>
Message-ID: <20131217164308.GA24264@sleipnir.bytereef.org>

Maciej Fijalkowski <fijall at gmail.com> wrote:
> I would like to discuss on the language summit a potential inclusion
> of cffi[1] into stdlib. This is a project Armin Rigo has been working
> for a while, with some input from other developers.

I've tried cffi (admittedly only in a toy script) and find it very nice
to use.

Here's a comparison (pi benchmark) between wrapping libmpdec using a
C-extension (_decimal), cffi and ctypes:


+-------------------------------+----------+----------+---------+
|                               | _decimal |  ctypes  |   cffi  |
+===============================+==========+==========+=========+
| cpython-tip (with-system-ffi) |   0.19s  |   5.40s  |  5.14s  |
+-------------------------------+----------+----------+---------+
| cpython-2.7 (with-system-ffi) |    n/a   |   4.46s  |  5.18s  |
+-------------------------------+----------+----------+---------+
|      Ubuntu-cpython-2.7       |    n/a   |   3.63s  |    -    |
+-------------------------------+----------+----------+---------+
|      pypy-2.2.1-linux64       |    n/a   |  125.9s  |  0.94s  |
+-------------------------------+----------+----------+---------+
|     pypy3-2.1-beta1-linux64   |    n/a   |  264.9s  |  2.93s  |
+-------------------------------+----------+----------+---------+


I guess the key points are that C-extensions are hard to beat and that
cffi performance on pypy-2 is outstanding. Additionally it's worth noting
that Ubuntu does something in their Python build that we should do, too.


+1 for cffi in the stdlib.



Stefan Krah




From brett at python.org  Tue Dec 17 18:21:24 2013
From: brett at python.org (Brett Cannon)
Date: Tue, 17 Dec 2013 12:21:24 -0500
Subject: [Python-Dev] cffi in stdlib
In-Reply-To: <20131217164308.GA24264@sleipnir.bytereef.org>
References: <CAK5idxQA+9zbBGhG0Thxzg9aBEko9UBtFTGK9_uJJ1vkyrGXwg@mail.gmail.com>
 <20131217164308.GA24264@sleipnir.bytereef.org>
Message-ID: <CAP1=2W6qcdRsSyBqC5rgf1DicqCFTykpB+kXkvUzX0R8vXzjOA@mail.gmail.com>

Maybe someone from PyPy should bring this up as an official topic at the
language summit to figure out the blockers (again). Or it can join regex on
the list of "module discussed for addition at the language summit but never
quite pushed to commitment". =)


On Tue, Dec 17, 2013 at 11:43 AM, Stefan Krah <stefan at bytereef.org> wrote:

> Maciej Fijalkowski <fijall at gmail.com> wrote:
> > I would like to discuss on the language summit a potential inclusion
> > of cffi[1] into stdlib. This is a project Armin Rigo has been working
> > for a while, with some input from other developers.
>
> I've tried cffi (admittedly only in a toy script) and find it very nice
> to use.
>
> Here's a comparison (pi benchmark) between wrapping libmpdec using a
> C-extension (_decimal), cffi and ctypes:
>
>
> +-------------------------------+----------+----------+---------+
> |                               | _decimal |  ctypes  |   cffi  |
> +===============================+==========+==========+=========+
> | cpython-tip (with-system-ffi) |   0.19s  |   5.40s  |  5.14s  |
> +-------------------------------+----------+----------+---------+
> | cpython-2.7 (with-system-ffi) |    n/a   |   4.46s  |  5.18s  |
> +-------------------------------+----------+----------+---------+
> |      Ubuntu-cpython-2.7       |    n/a   |   3.63s  |    -    |
> +-------------------------------+----------+----------+---------+
> |      pypy-2.2.1-linux64       |    n/a   |  125.9s  |  0.94s  |
> +-------------------------------+----------+----------+---------+
> |     pypy3-2.1-beta1-linux64   |    n/a   |  264.9s  |  2.93s  |
> +-------------------------------+----------+----------+---------+
>
>
> I guess the key points are that C-extensions are hard to beat and that
> cffi performance on pypy-2 is outstanding. Additionally it's worth noting
> that Ubuntu does something in their Python build that we should do, too.
>
>
> +1 for cffi in the stdlib.
>
>
>
> Stefan Krah
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131217/1eadc373/attachment.html>

From tseaver at palladion.com  Tue Dec 17 19:18:25 2013
From: tseaver at palladion.com (Tres Seaver)
Date: Tue, 17 Dec 2013 13:18:25 -0500
Subject: [Python-Dev] Backward-incompatible change to random.randrange in
	2.7.6
Message-ID: <l8q4h5$ujb$1@ger.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

http://hg.python.org/cpython/rev/b1e94e332ec8


Do we really want to change an undocumented-but-effectively-public API in
a late-in-the-release-cycle third dot release?  It caused, ZODB's tests
to fail, for instance.

While the docstring said, "Don't use the 'int', 'default', and 'maxwidth'
arguments", their names were not intrinsically private.  In particular,
passing in the 'int' argument was a strategy for generating compatible
long values when straddling Python 2.x / Python 3.x.




Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKwlXAACgkQ+gerLs4ltQ60DQCgzlO8mHMXQ0vsHNpS9GKwjpmD
G6oAoMIjtrKkGTlFj0b9Tfdj5BCu1rYS
=GxuS
-----END PGP SIGNATURE-----


From guido at python.org  Tue Dec 17 19:40:35 2013
From: guido at python.org (Guido van Rossum)
Date: Tue, 17 Dec 2013 10:40:35 -0800
Subject: [Python-Dev] Backward-incompatible change to random.randrange
	in 2.7.6
In-Reply-To: <l8q4h5$ujb$1@ger.gmane.org>
References: <l8q4h5$ujb$1@ger.gmane.org>
Message-ID: <CAP7+vJ++20SYMmYR6EYc2LuBoNZJsAzEkrgKmjxZVJxU40PdYg@mail.gmail.com>

This really seems a case of ZODB depending on internals where it
really, really should have known better. Calling this "a de-facto
public interface" seems way too far a stretch of the intention. And
please don't fix it by version-testing and using a different argument
name...

On Tue, Dec 17, 2013 at 10:18 AM, Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> http://hg.python.org/cpython/rev/b1e94e332ec8
>
>
> Do we really want to change an undocumented-but-effectively-public API in
> a late-in-the-release-cycle third dot release?  It caused, ZODB's tests
> to fail, for instance.
>
> While the docstring said, "Don't use the 'int', 'default', and 'maxwidth'
> arguments", their names were not intrinsically private.  In particular,
> passing in the 'int' argument was a strategy for generating compatible
> long values when straddling Python 2.x / Python 3.x.
>
>
>
>
> Tres.
> - --
> ===================================================================
> Tres Seaver          +1 540-429-0999          tseaver at palladion.com
> Palladion Software   "Excellence by Design"    http://palladion.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlKwlXAACgkQ+gerLs4ltQ60DQCgzlO8mHMXQ0vsHNpS9GKwjpmD
> G6oAoMIjtrKkGTlFj0b9Tfdj5BCu1rYS
> =GxuS
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org



-- 
--Guido van Rossum (python.org/~guido)

From barry at python.org  Tue Dec 17 19:55:46 2013
From: barry at python.org (Barry Warsaw)
Date: Tue, 17 Dec 2013 13:55:46 -0500
Subject: [Python-Dev] Backward-incompatible change to random.randrange
 in 2.7.6
In-Reply-To: <l8q4h5$ujb$1@ger.gmane.org>
References: <l8q4h5$ujb$1@ger.gmane.org>
Message-ID: <20131217135546.7435a2eb@anarchist.wooz.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Dec 17, 2013, at 01:18 PM, Tres Seaver wrote:

>http://hg.python.org/cpython/rev/b1e94e332ec8
>
>Do we really want to change an undocumented-but-effectively-public API in
>a late-in-the-release-cycle third dot release?  It caused, ZODB's tests
>to fail, for instance.
>
>While the docstring said, "Don't use the 'int', 'default', and 'maxwidth'
>arguments", their names were not intrinsically private.  In particular,
>passing in the 'int' argument was a strategy for generating compatible
>long values when straddling Python 2.x / Python 3.x.

Being quite sensitive to complaints about API breaks in patch releases, it
does seem like a bad idea to change these in a backward incompatible way.

It's true the docstring warns against it, and that the module does not
document those arguments, but they're still there and changing them breaks
existing code.  That should be enough to revert and rewrite the change.

I don't think the API *has* to change in a backward incompatible way either.
The methods could be given **kws with a bit of hackery to figure out whether
the old API was being used (keys: int, default, maxwidth) or the new API was
being used (keys: _int and _maxwidth).  Yeah it's ugly, but we serve our users
better by doing it that way.

Cheers,
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)

iQIcBAEBCAAGBQJSsJ4yAAoJEBJutWOnSwa/7EsP/1P3VaaeWdLnWkQKa06e4TpY
oXHG3YUMAQ4AjrBFTc5KL1GQtSkg1m6pQKZf937XYhi9d4xfwbaSBqCBWYPkNdrx
DR2Ix0Y/HwVPQvlqgfLWPS6TaZIrA2ssCVoOgWL2kmX+5KugIUy3O521OOre14jo
jCQZTOL2sloT+/TlX1PSImYRrJnK9yklW0CW13OVnj5BsvjzQPtsL0z1ueSrebqu
awTRCI7O8gpBcw7vcXnB6ZAfuA4urLQ+AnBXF1p5Rsxs3tGW9HS7L+QYWBM7sktV
Hmb5ZIdH+4+gkCws2LSowt+06M3WEyLkGhwOH1gNU3WTgywcJ4L9sh7WwLZN5eCe
Wz37LQ1fVFjpJhX2zOtI6djqL5r+6xpBxtuig0ezNJbAc1mhhvkPkTjMyvXqQzwX
HJQ7OMthiHqVnNJRZQZs4tSeCPgRDkDSNe/RWSyh6gYr6Gn6wwDcbW20RrbbbU4y
eKyY2VHQ0MKD283HVb3nfgelN96OgqWbpG/uk6mRPwPU1oIUyDDuhyyzNabggTSV
n97lPsHvOJyPehKdu+QKxpFULlX6KEmTCLJsUIWsjMCVIUnHjobkpOqW20KveLr+
cPcSHDGIPKv4qnFJuihYWBz9NPbUT2xebaP02bL7Wu5UVDFxQ3t0P/wuhLoNjRzU
vkUJ8m7CnRDFGuGPy6NQ
=lw3q
-----END PGP SIGNATURE-----

From tseaver at palladion.com  Tue Dec 17 20:02:12 2013
From: tseaver at palladion.com (Tres Seaver)
Date: Tue, 17 Dec 2013 14:02:12 -0500
Subject: [Python-Dev] Backward-incompatible change to random.randrange
	in 2.7.6
In-Reply-To: <CAP7+vJ++20SYMmYR6EYc2LuBoNZJsAzEkrgKmjxZVJxU40PdYg@mail.gmail.com>
References: <l8q4h5$ujb$1@ger.gmane.org>
 <CAP7+vJ++20SYMmYR6EYc2LuBoNZJsAzEkrgKmjxZVJxU40PdYg@mail.gmail.com>
Message-ID: <l8q739$ubb$1@ger.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/17/2013 01:40 PM, Guido van Rossum wrote:
> This really seems a case of ZODB depending on internals where it 
> really, really should have known better. Calling this "a de-facto 
> public interface" seems way too far a stretch of the intention. And 
> please don't fix it by version-testing and using a different argument 
> name...

The usage is *ancient*:  Jeremy checked it in 2001-10-05:


https://github.com/zopefoundation/ZODB/commit/fd1653580ca67bdc281fb8c54662c97dd3cf1aaa

The comment about "do not pass the 'int' or 'default' arguments" goes
back to at least the 'whrandom.py' module in 1.5.2. ;)



Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKwn7QACgkQ+gerLs4ltQ4WzACeOMXqg5Jg8ck3vK3cCDuTgKSS
8GwAn0yR8ukdQTh5Wo0jGDHq/AIgu+Yg
=fTUf
-----END PGP SIGNATURE-----


From tim.peters at gmail.com  Tue Dec 17 20:10:49 2013
From: tim.peters at gmail.com (Tim Peters)
Date: Tue, 17 Dec 2013 13:10:49 -0600
Subject: [Python-Dev] Backward-incompatible change to random.randrange
	in 2.7.6
In-Reply-To: <20131217135546.7435a2eb@anarchist.wooz.org>
References: <l8q4h5$ujb$1@ger.gmane.org>
 <20131217135546.7435a2eb@anarchist.wooz.org>
Message-ID: <CAExdVN=yeEOewL9LemsBNbR9G2uKSR5AZ23WffehCp9k_keG=w@mail.gmail.com>

[Barry]
> ...
> I don't think the API *has* to change in a backward incompatible way either.
> The methods could be given **kws with a bit of hackery to figure out whether
> the old API was being used (keys: int, default, maxwidth) or the new API was
> being used (keys: _int and _maxwidth).  Yeah it's ugly, but we serve our users
> better by doing it that way.

-1.  The speed of randrange() is crucial for many applications;
indeed, that's the only reason it abused default arguments to begin
with (i.e., to make `int` et alia fast local lookups).  Digging
through a dict to guess which API was invoked would ruin that.

And the ZODB tests in question deserve whatever they get ;-)

From fijall at gmail.com  Tue Dec 17 21:20:03 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 17 Dec 2013 22:20:03 +0200
Subject: [Python-Dev] cffi in stdlib
In-Reply-To: <CAP1=2W6qcdRsSyBqC5rgf1DicqCFTykpB+kXkvUzX0R8vXzjOA@mail.gmail.com>
References: <CAK5idxQA+9zbBGhG0Thxzg9aBEko9UBtFTGK9_uJJ1vkyrGXwg@mail.gmail.com>
 <20131217164308.GA24264@sleipnir.bytereef.org>
 <CAP1=2W6qcdRsSyBqC5rgf1DicqCFTykpB+kXkvUzX0R8vXzjOA@mail.gmail.com>
Message-ID: <CAK5idxSxu_4EsNOu=8jCmGje_wQsxRynpLJyr9qR7c2+VkpXgw@mail.gmail.com>

On Tue, Dec 17, 2013 at 7:21 PM, Brett Cannon <brett at python.org> wrote:
> Maybe someone from PyPy should bring this up as an official topic at the
> language summit to figure out the blockers (again). Or it can join regex on
> the list of "module discussed for addition at the language summit but never
> quite pushed to commitment". =)

we're still working on resolving discussed issues before officially
proposing it for inclusion.

>
>
> On Tue, Dec 17, 2013 at 11:43 AM, Stefan Krah <stefan at bytereef.org> wrote:
>>
>> Maciej Fijalkowski <fijall at gmail.com> wrote:
>> > I would like to discuss on the language summit a potential inclusion
>> > of cffi[1] into stdlib. This is a project Armin Rigo has been working
>> > for a while, with some input from other developers.
>>
>> I've tried cffi (admittedly only in a toy script) and find it very nice
>> to use.
>>
>> Here's a comparison (pi benchmark) between wrapping libmpdec using a
>> C-extension (_decimal), cffi and ctypes:
>>
>>
>> +-------------------------------+----------+----------+---------+
>> |                               | _decimal |  ctypes  |   cffi  |
>> +===============================+==========+==========+=========+
>> | cpython-tip (with-system-ffi) |   0.19s  |   5.40s  |  5.14s  |
>> +-------------------------------+----------+----------+---------+
>> | cpython-2.7 (with-system-ffi) |    n/a   |   4.46s  |  5.18s  |
>> +-------------------------------+----------+----------+---------+
>> |      Ubuntu-cpython-2.7       |    n/a   |   3.63s  |    -    |
>> +-------------------------------+----------+----------+---------+
>> |      pypy-2.2.1-linux64       |    n/a   |  125.9s  |  0.94s  |
>> +-------------------------------+----------+----------+---------+
>> |     pypy3-2.1-beta1-linux64   |    n/a   |  264.9s  |  2.93s  |
>> +-------------------------------+----------+----------+---------+
>>
>>
>> I guess the key points are that C-extensions are hard to beat and that
>> cffi performance on pypy-2 is outstanding. Additionally it's worth noting
>> that Ubuntu does something in their Python build that we should do, too.
>>
>>
>> +1 for cffi in the stdlib.
>>
>>
>>
>> Stefan Krah
>>
>>
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
>

From ncoghlan at gmail.com  Tue Dec 17 22:37:56 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 18 Dec 2013 07:37:56 +1000
Subject: [Python-Dev] cffi in stdlib
In-Reply-To: <CAK5idxSxu_4EsNOu=8jCmGje_wQsxRynpLJyr9qR7c2+VkpXgw@mail.gmail.com>
References: <CAK5idxQA+9zbBGhG0Thxzg9aBEko9UBtFTGK9_uJJ1vkyrGXwg@mail.gmail.com>
 <20131217164308.GA24264@sleipnir.bytereef.org>
 <CAP1=2W6qcdRsSyBqC5rgf1DicqCFTykpB+kXkvUzX0R8vXzjOA@mail.gmail.com>
 <CAK5idxSxu_4EsNOu=8jCmGje_wQsxRynpLJyr9qR7c2+VkpXgw@mail.gmail.com>
Message-ID: <CADiSq7eOXtdkxJTmT91jXz53nZ7UYuTn18uqAtAXCUB9aTBm1A@mail.gmail.com>

On 18 Dec 2013 06:21, "Maciej Fijalkowski" <fijall at gmail.com> wrote:
>
> On Tue, Dec 17, 2013 at 7:21 PM, Brett Cannon <brett at python.org> wrote:
> > Maybe someone from PyPy should bring this up as an official topic at the
> > language summit to figure out the blockers (again). Or it can join
regex on
> > the list of "module discussed for addition at the language summit but
never
> > quite pushed to commitment". =)
>
> we're still working on resolving discussed issues before officially
> proposing it for inclusion.

Note that there's also now a link chain from the CPython extension creation
docs to cffi (and Cython) - the cross version Python Packaging User Guide
now has a section on binary extensions that covers several of the
alternatives to writing them by hand, while the stdlib extension writing
guide has a note at the beginning pointing to that resource.

Cheers,
Nick.

>
> >
> >
> > On Tue, Dec 17, 2013 at 11:43 AM, Stefan Krah <stefan at bytereef.org>
wrote:
> >>
> >> Maciej Fijalkowski <fijall at gmail.com> wrote:
> >> > I would like to discuss on the language summit a potential inclusion
> >> > of cffi[1] into stdlib. This is a project Armin Rigo has been working
> >> > for a while, with some input from other developers.
> >>
> >> I've tried cffi (admittedly only in a toy script) and find it very nice
> >> to use.
> >>
> >> Here's a comparison (pi benchmark) between wrapping libmpdec using a
> >> C-extension (_decimal), cffi and ctypes:
> >>
> >>
> >> +-------------------------------+----------+----------+---------+
> >> |                               | _decimal |  ctypes  |   cffi  |
> >> +===============================+==========+==========+=========+
> >> | cpython-tip (with-system-ffi) |   0.19s  |   5.40s  |  5.14s  |
> >> +-------------------------------+----------+----------+---------+
> >> | cpython-2.7 (with-system-ffi) |    n/a   |   4.46s  |  5.18s  |
> >> +-------------------------------+----------+----------+---------+
> >> |      Ubuntu-cpython-2.7       |    n/a   |   3.63s  |    -    |
> >> +-------------------------------+----------+----------+---------+
> >> |      pypy-2.2.1-linux64       |    n/a   |  125.9s  |  0.94s  |
> >> +-------------------------------+----------+----------+---------+
> >> |     pypy3-2.1-beta1-linux64   |    n/a   |  264.9s  |  2.93s  |
> >> +-------------------------------+----------+----------+---------+
> >>
> >>
> >> I guess the key points are that C-extensions are hard to beat and that
> >> cffi performance on pypy-2 is outstanding. Additionally it's worth
noting
> >> that Ubuntu does something in their Python build that we should do,
too.
> >>
> >>
> >> +1 for cffi in the stdlib.
> >>
> >>
> >>
> >> Stefan Krah
> >>
> >>
> >>
> >> _______________________________________________
> >> Python-Dev mailing list
> >> Python-Dev at python.org
> >> https://mail.python.org/mailman/listinfo/python-dev
> >> Unsubscribe:
> >> https://mail.python.org/mailman/options/python-dev/brett%40python.org
> >
> >
> >
> > _______________________________________________
> > Python-Dev mailing list
> > Python-Dev at python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> > https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
> >
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131218/8f6e24bc/attachment-0001.html>

From solipsis at pitrou.net  Wed Dec 18 00:20:24 2013
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 18 Dec 2013 00:20:24 +0100
Subject: [Python-Dev] Backward-incompatible change to random.randrange
	in 2.7.6
References: <l8q4h5$ujb$1@ger.gmane.org>
Message-ID: <20131218002024.6dff72b6@fsol>

On Tue, 17 Dec 2013 13:18:25 -0500
Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> http://hg.python.org/cpython/rev/b1e94e332ec8
> 
> 
> Do we really want to change an undocumented-but-effectively-public API in
> a late-in-the-release-cycle third dot release?  It caused, ZODB's tests
> to fail, for instance.

Given the change doesn't seem to bring any visible change for users
(either performance or robustness), I think it would be safe to revert
it *in 2.7*.

Of course Zope's practice is still rather bad here... 

Regards

Antoine.



From benjamin at python.org  Wed Dec 18 00:54:40 2013
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 17 Dec 2013 18:54:40 -0500
Subject: [Python-Dev] Backward-incompatible change to random.randrange
	in 2.7.6
In-Reply-To: <20131218002024.6dff72b6@fsol>
References: <l8q4h5$ujb$1@ger.gmane.org>
	<20131218002024.6dff72b6@fsol>
Message-ID: <CAPZV6o-VWfn_sNAKQCqKfxYGsb0vgYDkuP80ZL9E6A2zDrHkiA@mail.gmail.com>

2013/12/17 Antoine Pitrou <solipsis at pitrou.net>:
> On Tue, 17 Dec 2013 13:18:25 -0500
> Tres Seaver <tseaver at palladion.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> http://hg.python.org/cpython/rev/b1e94e332ec8
>>
>>
>> Do we really want to change an undocumented-but-effectively-public API in
>> a late-in-the-release-cycle third dot release?  It caused, ZODB's tests
>> to fail, for instance.
>
> Given the change doesn't seem to bring any visible change for users
> (either performance or robustness), I think it would be safe to revert
> it *in 2.7*.

I agree with Antoine. It's better not to break even morally-broken
programs like the zope tests in 2.7.x if it doesn't win anything.


-- 
Regards,
Benjamin

From daniel at pocock.com.au  Wed Dec 18 00:07:17 2013
From: daniel at pocock.com.au (Daniel Pocock)
Date: Wed, 18 Dec 2013 00:07:17 +0100
Subject: [Python-Dev] thread issues when embedding Python
Message-ID: <52B0D925.2060008@pocock.com.au>



I've successfully embedded Python for a single thread

I tried to extend the implementation for multiple threads (a worker
thread scenario) and I'm encountering either deadlocks or seg faults
depending upon how I got about it.

There seems to be some inconsistency between what is covered in the docs
here:

http://docs.python.org/2/c-api/init.html#non-python-created-threads

and the experiences of other users trying the same thing, e.g.

http://bugs.python.org/issue19576
http://wiki.blender.org/index.php/Dev:2.4/Source/Python/API/Threads

Can anybody comment on the situation, in particular,

Is the non-python-created-threads documentation accurate for v2.7?

If a main thread does things like importing a module and obtaining a
reference to a Python method, can those things be used by other C++
threads or do they have to repeat those lookups?

Is there any logic that needs to be executed once only as each thread is
started? (the doc suggests just PyGILState_Ensure/PyGILState_Release
each time a thread accesses Python methods - is there anything else?)

Given the bug 19576, what is the most portable way to code this to work
reliably on unfixed Python versions?  (e.g. should users always
explicitly call PyEval_InitThreads() in their main thread or worker
threads or both?)




Here is my actual source code:

https://svn.resiprocate.org/viewsvn/resiprocate/main/repro/plugins/pyroute/

  (see example.py for a trivial example of what it does)

The problem that I encounter:

- the init stuff runs fine in PyRoutePlugin.cxx,
    it calls Py_Initialize, PyEval_InitThreads, PyImport_ImportModule
      and looks up the "provide_route" method in the module
    it creates a PyRouteWorker object,
      giving it a reference to "provide_route"
    it creates a thread pool to run the worker

- the PyRouteWorker::process() method is invoked in one of those threads

- it crashes when trying to call the "provide_route" method
    PyRouteWorker.cxx:
      routes = mAction.apply(args);


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff30b8700 (LWP 23965)]
0x00007ffff3d6ad06 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
(gdb) bt
#0  0x00007ffff3d6ad06 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#1  0x00007ffff3d6b647 in PyEval_CallObjectWithKeywords ()
   from /usr/lib/libpython2.7.so.1.0
#2  0x00007ffff414885a in apply (args=..., this=<optimized out>)
    at /usr/include/python2.7/CXX/Python2/Objects.hxx:3215
#3  repro::PyRouteWorker::process (this=0x6f00a0, msg=<optimized out>)
    at PyRouteWorker.cxx:98
#4  0x00007ffff7b879e1 in repro::WorkerThread::thread (this=0x68e110)
    at WorkerThread.cxx:36
#5  0x00007ffff70b7a2f in threadIfThreadWrapper (threadParm=<optimized out>)
    at ThreadIf.cxx:51
#6  0x00007ffff65ffb50 in start_thread (arg=<optimized out>)
    at pthread_create.c:304
#7  0x00007ffff5999a7d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#8  0x0000000000000000 in ?? ()

From daniel at pocock.com.au  Wed Dec 18 00:19:23 2013
From: daniel at pocock.com.au (Daniel Pocock)
Date: Wed, 18 Dec 2013 00:19:23 +0100
Subject: [Python-Dev] thread issues when embedding Python
Message-ID: <52B0DBFB.8040500@pocock.com.au>



I've successfully embedded Python for a single thread

I tried to extend the implementation for multiple threads (a worker
thread scenario) and I'm encountering either deadlocks or seg faults
depending upon how I got about it.

There seems to be some inconsistency between what is covered in the docs
here:

http://docs.python.org/2/c-api/init.html#non-python-created-threads

and the experiences of other users trying the same thing, e.g.

http://bugs.python.org/issue19576
http://wiki.blender.org/index.php/Dev:2.4/Source/Python/API/Threads

Can anybody comment on the situation, in particular,

Is the non-python-created-threads documentation accurate for v2.7?

If a main thread does things like importing a module and obtaining a
reference to a Python method, can those things be used by other C++
threads or do they have to repeat those lookups?

Is there any logic that needs to be executed once only as each thread is
started? (the doc suggests just PyGILState_Ensure/PyGILState_Release
each time a thread accesses Python methods - is there anything else?)

Given the bug 19576, what is the most portable way to code this to work
reliably on unfixed Python versions?  (e.g. should users always
explicitly call PyEval_InitThreads() in their main thread or worker
threads or both?)




Here is my actual source code:

https://svn.resiprocate.org/viewsvn/resiprocate/main/repro/plugins/pyroute/

  (see example.py for a trivial example of what it does)

The problem that I encounter:

- the init stuff runs fine in PyRoutePlugin.cxx,
    it calls Py_Initialize, PyEval_InitThreads, PyImport_ImportModule
      and looks up the "provide_route" method in the module
    it creates a PyRouteWorker object,
      giving it a reference to "provide_route"
    it creates a thread pool to run the worker

- the PyRouteWorker::process() method is invoked in one of those threads

- it crashes when trying to call the "provide_route" method
    PyRouteWorker.cxx:
      routes = mAction.apply(args);


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff30b8700 (LWP 23965)]
0x00007ffff3d6ad06 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
(gdb) bt
#0  0x00007ffff3d6ad06 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#1  0x00007ffff3d6b647 in PyEval_CallObjectWithKeywords ()
   from /usr/lib/libpython2.7.so.1.0
#2  0x00007ffff414885a in apply (args=..., this=<optimized out>)
    at /usr/include/python2.7/CXX/Python2/Objects.hxx:3215
#3  repro::PyRouteWorker::process (this=0x6f00a0, msg=<optimized out>)
    at PyRouteWorker.cxx:98
#4  0x00007ffff7b879e1 in repro::WorkerThread::thread (this=0x68e110)
    at WorkerThread.cxx:36
#5  0x00007ffff70b7a2f in threadIfThreadWrapper (threadParm=<optimized out>)
    at ThreadIf.cxx:51
#6  0x00007ffff65ffb50 in start_thread (arg=<optimized out>)
    at pthread_create.c:304
#7  0x00007ffff5999a7d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#8  0x0000000000000000 in ?? ()

From donald at stufft.io  Wed Dec 18 01:17:39 2013
From: donald at stufft.io (Donald Stufft)
Date: Tue, 17 Dec 2013 18:17:39 -0600
Subject: [Python-Dev] Backward-incompatible change to random.randrange
	in 2.7.6
In-Reply-To: <CAPZV6o-VWfn_sNAKQCqKfxYGsb0vgYDkuP80ZL9E6A2zDrHkiA@mail.gmail.com>
References: <l8q4h5$ujb$1@ger.gmane.org> <20131218002024.6dff72b6@fsol>
 <CAPZV6o-VWfn_sNAKQCqKfxYGsb0vgYDkuP80ZL9E6A2zDrHkiA@mail.gmail.com>
Message-ID: <BC54CBDC-276B-4FD0-AF07-0329FD588DCD@stufft.io>

Isn't changing it in 2.7.6 which is already released and then reverting in 2.7.7 worse? Either way 2.7.6 will have this change and be in the wild and broken for people who depend on it

> On Dec 17, 2013, at 5:54 PM, Benjamin Peterson <benjamin at python.org> wrote:
> 
> 2013/12/17 Antoine Pitrou <solipsis at pitrou.net>:
>> On Tue, 17 Dec 2013 13:18:25 -0500
>> Tres Seaver <tseaver at palladion.com> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>> 
>>> http://hg.python.org/cpython/rev/b1e94e332ec8
>>> 
>>> 
>>> Do we really want to change an undocumented-but-effectively-public API in
>>> a late-in-the-release-cycle third dot release?  It caused, ZODB's tests
>>> to fail, for instance.
>> 
>> Given the change doesn't seem to bring any visible change for users
>> (either performance or robustness), I think it would be safe to revert
>> it *in 2.7*.
> 
> I agree with Antoine. It's better not to break even morally-broken
> programs like the zope tests in 2.7.x if it doesn't win anything.
> 
> 
> -- 
> Regards,
> Benjamin
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io

From benjamin at python.org  Wed Dec 18 03:40:16 2013
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 17 Dec 2013 21:40:16 -0500
Subject: [Python-Dev] Backward-incompatible change to random.randrange
	in 2.7.6
In-Reply-To: <BC54CBDC-276B-4FD0-AF07-0329FD588DCD@stufft.io>
References: <l8q4h5$ujb$1@ger.gmane.org> <20131218002024.6dff72b6@fsol>
 <CAPZV6o-VWfn_sNAKQCqKfxYGsb0vgYDkuP80ZL9E6A2zDrHkiA@mail.gmail.com>
 <BC54CBDC-276B-4FD0-AF07-0329FD588DCD@stufft.io>
Message-ID: <CAPZV6o_LEcEAArHbyNNb=LEfEY+=X_DUsAgVfoGufQfVUOVXMg@mail.gmail.com>

Mostly yes, but at least you could tell people to upgrade straight to
2.7.7 and skip 2.7.6.

2013/12/17 Donald Stufft <donald at stufft.io>:
> Isn't changing it in 2.7.6 which is already released and then reverting in 2.7.7 worse? Either way 2.7.6 will have this change and be in the wild and broken for people who depend on it
>
>> On Dec 17, 2013, at 5:54 PM, Benjamin Peterson <benjamin at python.org> wrote:
>>
>> 2013/12/17 Antoine Pitrou <solipsis at pitrou.net>:
>>> On Tue, 17 Dec 2013 13:18:25 -0500
>>> Tres Seaver <tseaver at palladion.com> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> http://hg.python.org/cpython/rev/b1e94e332ec8
>>>>
>>>>
>>>> Do we really want to change an undocumented-but-effectively-public API in
>>>> a late-in-the-release-cycle third dot release?  It caused, ZODB's tests
>>>> to fail, for instance.
>>>
>>> Given the change doesn't seem to bring any visible change for users
>>> (either performance or robustness), I think it would be safe to revert
>>> it *in 2.7*.
>>
>> I agree with Antoine. It's better not to break even morally-broken
>> programs like the zope tests in 2.7.x if it doesn't win anything.
>>
>>
>> --
>> Regards,
>> Benjamin
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io



-- 
Regards,
Benjamin

From storchaka at gmail.com  Wed Dec 18 10:43:23 2013
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Wed, 18 Dec 2013 11:43:23 +0200
Subject: [Python-Dev] Backward-incompatible change to random.randrange
	in 2.7.6
In-Reply-To: <CAPZV6o_LEcEAArHbyNNb=LEfEY+=X_DUsAgVfoGufQfVUOVXMg@mail.gmail.com>
References: <l8q4h5$ujb$1@ger.gmane.org> <20131218002024.6dff72b6@fsol>
 <CAPZV6o-VWfn_sNAKQCqKfxYGsb0vgYDkuP80ZL9E6A2zDrHkiA@mail.gmail.com>
 <BC54CBDC-276B-4FD0-AF07-0329FD588DCD@stufft.io>
 <CAPZV6o_LEcEAArHbyNNb=LEfEY+=X_DUsAgVfoGufQfVUOVXMg@mail.gmail.com>
Message-ID: <l8rqng$psg$1@ger.gmane.org>

18.12.13 04:40, Benjamin Peterson ???????(??):
> Mostly yes, but at least you could tell people to upgrade straight to
> 2.7.7 and skip 2.7.6.

It'll make the people to postpone the upgrade to 2.7.6 (which fixes many 
security bugs) until 2.7.7 release,  instead of correcting their 
morally-broken programs.



From rosuav at gmail.com  Wed Dec 18 11:17:15 2013
From: rosuav at gmail.com (Chris Angelico)
Date: Wed, 18 Dec 2013 21:17:15 +1100
Subject: [Python-Dev] Backward-incompatible change to random.randrange
	in 2.7.6
In-Reply-To: <l8rqng$psg$1@ger.gmane.org>
References: <l8q4h5$ujb$1@ger.gmane.org> <20131218002024.6dff72b6@fsol>
 <CAPZV6o-VWfn_sNAKQCqKfxYGsb0vgYDkuP80ZL9E6A2zDrHkiA@mail.gmail.com>
 <BC54CBDC-276B-4FD0-AF07-0329FD588DCD@stufft.io>
 <CAPZV6o_LEcEAArHbyNNb=LEfEY+=X_DUsAgVfoGufQfVUOVXMg@mail.gmail.com>
 <l8rqng$psg$1@ger.gmane.org>
Message-ID: <CAPTjJmo=KDzWhS=k8gX0yRxOo2CWM+0rxMw_jpMG9rBHXTNydg@mail.gmail.com>

On Wed, Dec 18, 2013 at 8:43 PM, Serhiy Storchaka <storchaka at gmail.com> wrote:
> 18.12.13 04:40, Benjamin Peterson ???????(??):
>
>> Mostly yes, but at least you could tell people to upgrade straight to
>> 2.7.7 and skip 2.7.6.
>
>
> It'll make the people to postpone the upgrade to 2.7.6 (which fixes many
> security bugs) until 2.7.7 release,  instead of correcting their
> morally-broken programs.

If this is considered enough breakage to be a problem, would it be
possible to issue a 2.7.6.1 or 2.7.6+fixed release that's identical to
2.7.6 but with this change reverted? It'd be a minor mess, but then
people would still get those security fixes, and it means not breaking
stuff in a point release.

ChrisA

From ncoghlan at gmail.com  Wed Dec 18 11:51:56 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 18 Dec 2013 20:51:56 +1000
Subject: [Python-Dev] Backward-incompatible change to random.randrange
	in 2.7.6
In-Reply-To: <CAPTjJmo=KDzWhS=k8gX0yRxOo2CWM+0rxMw_jpMG9rBHXTNydg@mail.gmail.com>
References: <l8q4h5$ujb$1@ger.gmane.org> <20131218002024.6dff72b6@fsol>
 <CAPZV6o-VWfn_sNAKQCqKfxYGsb0vgYDkuP80ZL9E6A2zDrHkiA@mail.gmail.com>
 <BC54CBDC-276B-4FD0-AF07-0329FD588DCD@stufft.io>
 <CAPZV6o_LEcEAArHbyNNb=LEfEY+=X_DUsAgVfoGufQfVUOVXMg@mail.gmail.com>
 <l8rqng$psg$1@ger.gmane.org>
 <CAPTjJmo=KDzWhS=k8gX0yRxOo2CWM+0rxMw_jpMG9rBHXTNydg@mail.gmail.com>
Message-ID: <CADiSq7fey-gJiyRyh3EtS2b75xqd5EH7=36jU3c0JBrE89L_Pg@mail.gmail.com>

On 18 December 2013 20:17, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, Dec 18, 2013 at 8:43 PM, Serhiy Storchaka <storchaka at gmail.com> wrote:
>> 18.12.13 04:40, Benjamin Peterson ???????(??):
>>
>>> Mostly yes, but at least you could tell people to upgrade straight to
>>> 2.7.7 and skip 2.7.6.
>>
>>
>> It'll make the people to postpone the upgrade to 2.7.6 (which fixes many
>> security bugs) until 2.7.7 release,  instead of correcting their
>> morally-broken programs.
>
> If this is considered enough breakage to be a problem, would it be
> possible to issue a 2.7.6.1 or 2.7.6+fixed release that's identical to
> 2.7.6 but with this change reverted? It'd be a minor mess, but then
> people would still get those security fixes, and it means not breaking
> stuff in a point release.

If we revert it, it means we do 2.7.7 ASAP so that *everyone* can just
skip straight to 2.7.7.

That kind of user visible change shouldn't have been made in a point
release, regardless of what the docs said. It just isn't worth the
risk of breaking the code of people that are relying on what's
possible rather than what the docs say.

Cheers,
Nick.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From daniel at pocock.com.au  Wed Dec 18 11:26:09 2013
From: daniel at pocock.com.au (Daniel Pocock)
Date: Wed, 18 Dec 2013 11:26:09 +0100
Subject: [Python-Dev] thread issues when embedding Python
In-Reply-To: <52B0DBFB.8040500@pocock.com.au>
References: <52B0DBFB.8040500@pocock.com.au>
Message-ID: <52B17841.9040208@pocock.com.au>


Another link that fills in some gaps and finally helped me make this work:

http://www.codevate.com/blog/7-concurrency-with-embedded-python-in-a-multi-threaded-c-application

In particular, I found that PyGILState_Ensure/PyGILState_Release as
described in the Python docs is not sufficient - as described in that
blog link, I had to

a) obtain PyInterpreterState from the first thread where Py_Initialize()
was called

b) when each worker thread starts, call
PyThreadState_New(mInterpreterState)  and save the result in a thread
local mPyThreadState

c) use the mPyThreadState with PyEval_RestoreThread and
PyEval_SaveThread before and after calling Python methods

Is this a bug in PyGILState_Ensure or is it a deficiency in the
documentation?

I also found one bug in my own code, although that was not related to
the problem just described with PyGILState_Ensure and I had to fix both
problems to make it work.  Specifically, the PyWorkerThread constructor
was taking an object argument when it should have taken a reference
argument and this was creating an invalid Py::Callable member in my worker.

On 18/12/13 00:19, Daniel Pocock wrote:
>
> I've successfully embedded Python for a single thread
>
> I tried to extend the implementation for multiple threads (a worker
> thread scenario) and I'm encountering either deadlocks or seg faults
> depending upon how I got about it.
>
> There seems to be some inconsistency between what is covered in the docs
> here:
>
> http://docs.python.org/2/c-api/init.html#non-python-created-threads
>
> and the experiences of other users trying the same thing, e.g.
>
> http://bugs.python.org/issue19576
> http://wiki.blender.org/index.php/Dev:2.4/Source/Python/API/Threads
>
> Can anybody comment on the situation, in particular,
>
> Is the non-python-created-threads documentation accurate for v2.7?
>
> If a main thread does things like importing a module and obtaining a
> reference to a Python method, can those things be used by other C++
> threads or do they have to repeat those lookups?
>
> Is there any logic that needs to be executed once only as each thread is
> started? (the doc suggests just PyGILState_Ensure/PyGILState_Release
> each time a thread accesses Python methods - is there anything else?)
>
> Given the bug 19576, what is the most portable way to code this to work
> reliably on unfixed Python versions?  (e.g. should users always
> explicitly call PyEval_InitThreads() in their main thread or worker
> threads or both?)
>
>
>
>
> Here is my actual source code:
>
> https://svn.resiprocate.org/viewsvn/resiprocate/main/repro/plugins/pyroute/
>
>   (see example.py for a trivial example of what it does)
>
> The problem that I encounter:
>
> - the init stuff runs fine in PyRoutePlugin.cxx,
>     it calls Py_Initialize, PyEval_InitThreads, PyImport_ImportModule
>       and looks up the "provide_route" method in the module
>     it creates a PyRouteWorker object,
>       giving it a reference to "provide_route"
>     it creates a thread pool to run the worker
>
> - the PyRouteWorker::process() method is invoked in one of those threads
>
> - it crashes when trying to call the "provide_route" method
>     PyRouteWorker.cxx:
>       routes = mAction.apply(args);
>
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7ffff30b8700 (LWP 23965)]
> 0x00007ffff3d6ad06 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
> (gdb) bt
> #0  0x00007ffff3d6ad06 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
> #1  0x00007ffff3d6b647 in PyEval_CallObjectWithKeywords ()
>    from /usr/lib/libpython2.7.so.1.0
> #2  0x00007ffff414885a in apply (args=..., this=<optimized out>)
>     at /usr/include/python2.7/CXX/Python2/Objects.hxx:3215
> #3  repro::PyRouteWorker::process (this=0x6f00a0, msg=<optimized out>)
>     at PyRouteWorker.cxx:98
> #4  0x00007ffff7b879e1 in repro::WorkerThread::thread (this=0x68e110)
>     at WorkerThread.cxx:36
> #5  0x00007ffff70b7a2f in threadIfThreadWrapper (threadParm=<optimized out>)
>     at ThreadIf.cxx:51
> #6  0x00007ffff65ffb50 in start_thread (arg=<optimized out>)
>     at pthread_create.c:304
> #7  0x00007ffff5999a7d in clone ()
>     at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
> #8  0x0000000000000000 in ?? ()
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/daniel%40pocock.com.au


From rosuav at gmail.com  Wed Dec 18 16:02:23 2013
From: rosuav at gmail.com (Chris Angelico)
Date: Thu, 19 Dec 2013 02:02:23 +1100
Subject: [Python-Dev] thread issues when embedding Python
In-Reply-To: <52B17841.9040208@pocock.com.au>
References: <52B0DBFB.8040500@pocock.com.au> <52B17841.9040208@pocock.com.au>
Message-ID: <CAPTjJmr8T5kZxD1V+jEtQEb=bxm3S3A38eiMz0hVKhhuS6EiEw@mail.gmail.com>

On Wed, Dec 18, 2013 at 9:26 PM, Daniel Pocock <daniel at pocock.com.au> wrote:
> b) when each worker thread starts, call
> PyThreadState_New(mInterpreterState)  and save the result in a thread
> local mPyThreadState
>
> c) use the mPyThreadState with PyEval_RestoreThread and
> PyEval_SaveThread before and after calling Python methods
>
> Is this a bug in PyGILState_Ensure or is it a deficiency in the
> documentation?

It doesn't surprise me that you would need to do step b - I do seem to
recall the need to call that for each new thread. Not so sure about c.
Once you fixed the unrelated bug, do you still need that step? (Been a
while since I last embedded Python though, and I might well be wrong.)

ChrisA

From daniel at pocock.com.au  Wed Dec 18 16:12:39 2013
From: daniel at pocock.com.au (Daniel Pocock)
Date: Wed, 18 Dec 2013 16:12:39 +0100
Subject: [Python-Dev] thread issues when embedding Python
In-Reply-To: <CAPTjJmr8T5kZxD1V+jEtQEb=bxm3S3A38eiMz0hVKhhuS6EiEw@mail.gmail.com>
References: <52B0DBFB.8040500@pocock.com.au> <52B17841.9040208@pocock.com.au>
 <CAPTjJmr8T5kZxD1V+jEtQEb=bxm3S3A38eiMz0hVKhhuS6EiEw@mail.gmail.com>
Message-ID: <52B1BB67.5000203@pocock.com.au>

On 18/12/13 16:02, Chris Angelico wrote:
> On Wed, Dec 18, 2013 at 9:26 PM, Daniel Pocock <daniel at pocock.com.au> wrote:
>> b) when each worker thread starts, call
>> PyThreadState_New(mInterpreterState)  and save the result in a thread
>> local mPyThreadState
>>
>> c) use the mPyThreadState with PyEval_RestoreThread and
>> PyEval_SaveThread before and after calling Python methods
>>
>> Is this a bug in PyGILState_Ensure or is it a deficiency in the
>> documentation?
> It doesn't surprise me that you would need to do step b - I do seem to
> recall the need to call that for each new thread. Not so sure about c.
> Once you fixed the unrelated bug, do you still need that step? (Been a
> while since I last embedded Python though, and I might well be wrong.)

Yes, I definitely needed to use this PyThreadState_New call even after
my unrelated bug fix

Should it be added to the documentation?

I created a C++ wrapper around this logic, it is here:

https://github.com/resiprocate/resiprocate/blob/master/repro/plugins/pyroute/PyThreadSupport.hxx

and the use case is something like:

      // in constructor:

    PyExternalUser* mPyUser = new PyExternalUser(mInterpreterState);


and each time Python calls are made, just do:

{

        PyExternalUser::Use use(*mPyUser);
        // now call Python code
}

When the PyExternalUser::Use instance is created it does PyEval_RestoreThread()

When the PyExternalUser::Use instance goes out of scope it is destroyed and PyEval_SaveThread() is called



From solipsis at pitrou.net  Wed Dec 18 16:25:43 2013
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 18 Dec 2013 16:25:43 +0100
Subject: [Python-Dev] thread issues when embedding Python
References: <52B0DBFB.8040500@pocock.com.au>
Message-ID: <20131218162543.382fae67@fsol>

On Wed, 18 Dec 2013 00:19:23 +0100
Daniel Pocock <daniel at pocock.com.au> wrote:
> 
> If a main thread does things like importing a module and obtaining a
> reference to a Python method, can those things be used by other C++
> threads or do they have to repeat those lookups?

The C++ threads must use the PyGILState API to initialize corresponding
Python thread states, and to hold the GIL.

However, you don't have to *repeat* the lookups - pointers valid in
one thread are valid in other threads, as long as you own a strong
reference to the PyObject (beware functions which return a borrowed
reference).

> Is there any logic that needs to be executed once only as each thread is
> started? (the doc suggests just PyGILState_Ensure/PyGILState_Release
> each time a thread accesses Python methods - is there anything else?)

If you use the PyGILState API, there shouldn't be anything else.

> (e.g. should users always
> explicitly call PyEval_InitThreads() in their main thread or worker
> threads or both?)

You only need to call PyEval_InitThreads() once in the main Python
thread.

Regards

Antoine.



From victor.stinner at gmail.com  Wed Dec 18 16:29:00 2013
From: victor.stinner at gmail.com (Victor Stinner)
Date: Wed, 18 Dec 2013 16:29:00 +0100
Subject: [Python-Dev] thread issues when embedding Python
In-Reply-To: <20131218162543.382fae67@fsol>
References: <52B0DBFB.8040500@pocock.com.au> <20131218162543.382fae67@fsol>
Message-ID: <CAMpsgwYrdyiq6p+_-31sydCCWFZPW7Kz0KOcG=6sxkHyiH4Y5g@mail.gmail.com>

2013/12/18 Antoine Pitrou <solipsis at pitrou.net>:
> You only need to call PyEval_InitThreads() once in the main Python
> thread.

This is not well documented. For your information, PyGILState_Ensure()
now calls PyEval_InitThreads() in Python 3.4, see:
http://bugs.python.org/issue19576

Victor

From guido at python.org  Wed Dec 18 16:49:17 2013
From: guido at python.org (Guido van Rossum)
Date: Wed, 18 Dec 2013 07:49:17 -0800
Subject: [Python-Dev] Backward-incompatible change to random.randrange
	in 2.7.6
In-Reply-To: <CADiSq7fey-gJiyRyh3EtS2b75xqd5EH7=36jU3c0JBrE89L_Pg@mail.gmail.com>
References: <l8q4h5$ujb$1@ger.gmane.org> <20131218002024.6dff72b6@fsol>
 <CAPZV6o-VWfn_sNAKQCqKfxYGsb0vgYDkuP80ZL9E6A2zDrHkiA@mail.gmail.com>
 <BC54CBDC-276B-4FD0-AF07-0329FD588DCD@stufft.io>
 <CAPZV6o_LEcEAArHbyNNb=LEfEY+=X_DUsAgVfoGufQfVUOVXMg@mail.gmail.com>
 <l8rqng$psg$1@ger.gmane.org>
 <CAPTjJmo=KDzWhS=k8gX0yRxOo2CWM+0rxMw_jpMG9rBHXTNydg@mail.gmail.com>
 <CADiSq7fey-gJiyRyh3EtS2b75xqd5EH7=36jU3c0JBrE89L_Pg@mail.gmail.com>
Message-ID: <CAP7+vJLqJJzn3R+pR+F2eLSYghMSjSeTugOxbPXUOkHiW33Bog@mail.gmail.com>

BTW, I bet a lavish dinner at PyCon that it is *only* Zope/ZODB that
does this. In the time we added this bogus dependency on undocumented
parameters, the PythonLabs team was at Zope and we didn't always get
our boundaries straight.

On Wed, Dec 18, 2013 at 2:51 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 18 December 2013 20:17, Chris Angelico <rosuav at gmail.com> wrote:
>> On Wed, Dec 18, 2013 at 8:43 PM, Serhiy Storchaka <storchaka at gmail.com> wrote:
>>> 18.12.13 04:40, Benjamin Peterson ???????(??):
>>>
>>>> Mostly yes, but at least you could tell people to upgrade straight to
>>>> 2.7.7 and skip 2.7.6.
>>>
>>>
>>> It'll make the people to postpone the upgrade to 2.7.6 (which fixes many
>>> security bugs) until 2.7.7 release,  instead of correcting their
>>> morally-broken programs.
>>
>> If this is considered enough breakage to be a problem, would it be
>> possible to issue a 2.7.6.1 or 2.7.6+fixed release that's identical to
>> 2.7.6 but with this change reverted? It'd be a minor mess, but then
>> people would still get those security fixes, and it means not breaking
>> stuff in a point release.
>
> If we revert it, it means we do 2.7.7 ASAP so that *everyone* can just
> skip straight to 2.7.7.
>
> That kind of user visible change shouldn't have been made in a point
> release, regardless of what the docs said. It just isn't worth the
> risk of breaking the code of people that are relying on what's
> possible rather than what the docs say.
>
> Cheers,
> Nick.
>
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org



-- 
--Guido van Rossum (python.org/~guido)

From dholth at gmail.com  Wed Dec 18 17:31:47 2013
From: dholth at gmail.com (Daniel Holth)
Date: Wed, 18 Dec 2013 11:31:47 -0500
Subject: [Python-Dev] Backward-incompatible change to random.randrange
	in 2.7.6
In-Reply-To: <CAP7+vJLqJJzn3R+pR+F2eLSYghMSjSeTugOxbPXUOkHiW33Bog@mail.gmail.com>
References: <l8q4h5$ujb$1@ger.gmane.org> <20131218002024.6dff72b6@fsol>
 <CAPZV6o-VWfn_sNAKQCqKfxYGsb0vgYDkuP80ZL9E6A2zDrHkiA@mail.gmail.com>
 <BC54CBDC-276B-4FD0-AF07-0329FD588DCD@stufft.io>
 <CAPZV6o_LEcEAArHbyNNb=LEfEY+=X_DUsAgVfoGufQfVUOVXMg@mail.gmail.com>
 <l8rqng$psg$1@ger.gmane.org>
 <CAPTjJmo=KDzWhS=k8gX0yRxOo2CWM+0rxMw_jpMG9rBHXTNydg@mail.gmail.com>
 <CADiSq7fey-gJiyRyh3EtS2b75xqd5EH7=36jU3c0JBrE89L_Pg@mail.gmail.com>
 <CAP7+vJLqJJzn3R+pR+F2eLSYghMSjSeTugOxbPXUOkHiW33Bog@mail.gmail.com>
Message-ID: <CAG8k2+4Mc6Oc8WUmiapvZ7d3VSrdppr0i7naJRhmuKrVZ8iLsQ@mail.gmail.com>

But who could forget njzrs' wasp UAV software line 107, using
int=float? https://github.com/nzjrs/wasp/blob/master/sw/groundstation/wasp/__init__.py#L107

On Wed, Dec 18, 2013 at 10:49 AM, Guido van Rossum <guido at python.org> wrote:
> BTW, I bet a lavish dinner at PyCon that it is *only* Zope/ZODB that
> does this. In the time we added this bogus dependency on undocumented
> parameters, the PythonLabs team was at Zope and we didn't always get
> our boundaries straight.
>
> On Wed, Dec 18, 2013 at 2:51 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On 18 December 2013 20:17, Chris Angelico <rosuav at gmail.com> wrote:
>>> On Wed, Dec 18, 2013 at 8:43 PM, Serhiy Storchaka <storchaka at gmail.com> wrote:
>>>> 18.12.13 04:40, Benjamin Peterson ???????(??):
>>>>
>>>>> Mostly yes, but at least you could tell people to upgrade straight to
>>>>> 2.7.7 and skip 2.7.6.
>>>>
>>>>
>>>> It'll make the people to postpone the upgrade to 2.7.6 (which fixes many
>>>> security bugs) until 2.7.7 release,  instead of correcting their
>>>> morally-broken programs.
>>>
>>> If this is considered enough breakage to be a problem, would it be
>>> possible to issue a 2.7.6.1 or 2.7.6+fixed release that's identical to
>>> 2.7.6 but with this change reverted? It'd be a minor mess, but then
>>> people would still get those security fixes, and it means not breaking
>>> stuff in a point release.
>>
>> If we revert it, it means we do 2.7.7 ASAP so that *everyone* can just
>> skip straight to 2.7.7.
>>
>> That kind of user visible change shouldn't have been made in a point
>> release, regardless of what the docs said. It just isn't worth the
>> risk of breaking the code of people that are relying on what's
>> possible rather than what the docs say.
>>
>> Cheers,
>> Nick.
>>
>>
>> --
>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/dholth%40gmail.com

From solipsis at pitrou.net  Wed Dec 18 17:36:50 2013
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 18 Dec 2013 17:36:50 +0100
Subject: [Python-Dev] Backward-incompatible change to random.randrange
	in 2.7.6
References: <l8q4h5$ujb$1@ger.gmane.org> <20131218002024.6dff72b6@fsol>
 <CAPZV6o-VWfn_sNAKQCqKfxYGsb0vgYDkuP80ZL9E6A2zDrHkiA@mail.gmail.com>
 <BC54CBDC-276B-4FD0-AF07-0329FD588DCD@stufft.io>
 <CAPZV6o_LEcEAArHbyNNb=LEfEY+=X_DUsAgVfoGufQfVUOVXMg@mail.gmail.com>
 <l8rqng$psg$1@ger.gmane.org>
 <CAPTjJmo=KDzWhS=k8gX0yRxOo2CWM+0rxMw_jpMG9rBHXTNydg@mail.gmail.com>
 <CADiSq7fey-gJiyRyh3EtS2b75xqd5EH7=36jU3c0JBrE89L_Pg@mail.gmail.com>
 <CAP7+vJLqJJzn3R+pR+F2eLSYghMSjSeTugOxbPXUOkHiW33Bog@mail.gmail.com>
 <CAG8k2+4Mc6Oc8WUmiapvZ7d3VSrdppr0i7naJRhmuKrVZ8iLsQ@mail.gmail.com>
Message-ID: <20131218173650.422b6a6b@fsol>

On Wed, 18 Dec 2013 11:31:47 -0500
Daniel Holth <dholth at gmail.com> wrote:
> But who could forget njzrs' wasp UAV software line 107, using
> int=float? https://github.com/nzjrs/wasp/blob/master/sw/groundstation/wasp/__init__.py#L107
> 

And the purpose is quite Pythonesque:
    """
    Generates a noisy random walk
    """

Regards

Antoine.



From tim.peters at gmail.com  Wed Dec 18 17:54:26 2013
From: tim.peters at gmail.com (Tim Peters)
Date: Wed, 18 Dec 2013 10:54:26 -0600
Subject: [Python-Dev] Backward-incompatible change to random.randrange
	in 2.7.6
In-Reply-To: <CAG8k2+4Mc6Oc8WUmiapvZ7d3VSrdppr0i7naJRhmuKrVZ8iLsQ@mail.gmail.com>
References: <l8q4h5$ujb$1@ger.gmane.org> <20131218002024.6dff72b6@fsol>
 <CAPZV6o-VWfn_sNAKQCqKfxYGsb0vgYDkuP80ZL9E6A2zDrHkiA@mail.gmail.com>
 <BC54CBDC-276B-4FD0-AF07-0329FD588DCD@stufft.io>
 <CAPZV6o_LEcEAArHbyNNb=LEfEY+=X_DUsAgVfoGufQfVUOVXMg@mail.gmail.com>
 <l8rqng$psg$1@ger.gmane.org>
 <CAPTjJmo=KDzWhS=k8gX0yRxOo2CWM+0rxMw_jpMG9rBHXTNydg@mail.gmail.com>
 <CADiSq7fey-gJiyRyh3EtS2b75xqd5EH7=36jU3c0JBrE89L_Pg@mail.gmail.com>
 <CAP7+vJLqJJzn3R+pR+F2eLSYghMSjSeTugOxbPXUOkHiW33Bog@mail.gmail.com>
 <CAG8k2+4Mc6Oc8WUmiapvZ7d3VSrdppr0i7naJRhmuKrVZ8iLsQ@mail.gmail.com>
Message-ID: <CAExdVNnf=PoS-9DdANmLki5xewVj6F622aF330R5zQjEz81JaA@mail.gmail.com>

[Daniel Holth]
> But who could forget njzrs' wasp UAV software line 107, using
> int=float? https://github.com/nzjrs/wasp/blob/master/sw/groundstation/wasp/__init__.py#L107

I could forget it ;-)  The remarkable thing about the two instances of:

     random.randrange(0.0,1.0, int=float)

in that file is that they're obscure and inefficient ways to spell:

     random.random()

Which reminds me.  I used to think there was no such thing as a stupid
question.  Then I discovered Stack Overflow ;-)

From dholth at gmail.com  Wed Dec 18 18:22:18 2013
From: dholth at gmail.com (Daniel Holth)
Date: Wed, 18 Dec 2013 12:22:18 -0500
Subject: [Python-Dev] Backward-incompatible change to random.randrange
	in 2.7.6
In-Reply-To: <CAExdVNnf=PoS-9DdANmLki5xewVj6F622aF330R5zQjEz81JaA@mail.gmail.com>
References: <l8q4h5$ujb$1@ger.gmane.org> <20131218002024.6dff72b6@fsol>
 <CAPZV6o-VWfn_sNAKQCqKfxYGsb0vgYDkuP80ZL9E6A2zDrHkiA@mail.gmail.com>
 <BC54CBDC-276B-4FD0-AF07-0329FD588DCD@stufft.io>
 <CAPZV6o_LEcEAArHbyNNb=LEfEY+=X_DUsAgVfoGufQfVUOVXMg@mail.gmail.com>
 <l8rqng$psg$1@ger.gmane.org>
 <CAPTjJmo=KDzWhS=k8gX0yRxOo2CWM+0rxMw_jpMG9rBHXTNydg@mail.gmail.com>
 <CADiSq7fey-gJiyRyh3EtS2b75xqd5EH7=36jU3c0JBrE89L_Pg@mail.gmail.com>
 <CAP7+vJLqJJzn3R+pR+F2eLSYghMSjSeTugOxbPXUOkHiW33Bog@mail.gmail.com>
 <CAG8k2+4Mc6Oc8WUmiapvZ7d3VSrdppr0i7naJRhmuKrVZ8iLsQ@mail.gmail.com>
 <CAExdVNnf=PoS-9DdANmLki5xewVj6F622aF330R5zQjEz81JaA@mail.gmail.com>
Message-ID: <CAG8k2+4rMK6QNURVjagFWd7PhTgiWbxLegbqjrMKv8PZdiP1gw@mail.gmail.com>

On Dec 18, 2013 11:54 AM, "Tim Peters" <tim.peters at gmail.com> wrote:

> [Daniel Holth]
> > But who could forget njzrs' wasp UAV software line 107, using
> > int=float?
> https://github.com/nzjrs/wasp/blob/master/sw/groundstation/wasp/__init__.py#L107
>
> I could forget it ;-)  The remarkable thing about the two instances of:
>
>      random.randrange(0.0,1.0, int=float)
>
> in that file is that they're obscure and inefficient ways to spell:
>
>      random.random()
>

You can keep your "premature optimizations" thank you :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131218/0d24621e/attachment.html>

From ethan at stoneleaf.us  Wed Dec 18 18:42:50 2013
From: ethan at stoneleaf.us (Ethan Furman)
Date: Wed, 18 Dec 2013 09:42:50 -0800
Subject: [Python-Dev] Backward-incompatible change to random.randrange
 in 2.7.6
In-Reply-To: <CAExdVNnf=PoS-9DdANmLki5xewVj6F622aF330R5zQjEz81JaA@mail.gmail.com>
References: <l8q4h5$ujb$1@ger.gmane.org> <20131218002024.6dff72b6@fsol>
 <CAPZV6o-VWfn_sNAKQCqKfxYGsb0vgYDkuP80ZL9E6A2zDrHkiA@mail.gmail.com>
 <BC54CBDC-276B-4FD0-AF07-0329FD588DCD@stufft.io>
 <CAPZV6o_LEcEAArHbyNNb=LEfEY+=X_DUsAgVfoGufQfVUOVXMg@mail.gmail.com>
 <l8rqng$psg$1@ger.gmane.org>
 <CAPTjJmo=KDzWhS=k8gX0yRxOo2CWM+0rxMw_jpMG9rBHXTNydg@mail.gmail.com>
 <CADiSq7fey-gJiyRyh3EtS2b75xqd5EH7=36jU3c0JBrE89L_Pg@mail.gmail.com>
 <CAP7+vJLqJJzn3R+pR+F2eLSYghMSjSeTugOxbPXUOkHiW33Bog@mail.gmail.com>
 <CAG8k2+4Mc6Oc8WUmiapvZ7d3VSrdppr0i7naJRhmuKrVZ8iLsQ@mail.gmail.com>
 <CAExdVNnf=PoS-9DdANmLki5xewVj6F622aF330R5zQjEz81JaA@mail.gmail.com>
Message-ID: <52B1DE9A.60508@stoneleaf.us>

On 12/18/2013 08:54 AM, Tim Peters wrote:
>
> Which reminds me.  I used to think there was no such thing as a stupid
> question.  Then I discovered Stack Overflow ;-)

+1 QOTW

From daniel at pocock.com.au  Wed Dec 18 22:58:27 2013
From: daniel at pocock.com.au (Daniel Pocock)
Date: Wed, 18 Dec 2013 22:58:27 +0100
Subject: [Python-Dev] thread issues when embedding Python
In-Reply-To: <CAMpsgwYrdyiq6p+_-31sydCCWFZPW7Kz0KOcG=6sxkHyiH4Y5g@mail.gmail.com>
References: <52B0DBFB.8040500@pocock.com.au> <20131218162543.382fae67@fsol>
 <CAMpsgwYrdyiq6p+_-31sydCCWFZPW7Kz0KOcG=6sxkHyiH4Y5g@mail.gmail.com>
Message-ID: <52B21A83.4000906@pocock.com.au>



On 18/12/13 16:29, Victor Stinner wrote:
> 2013/12/18 Antoine Pitrou <solipsis at pitrou.net>:
>> You only need to call PyEval_InitThreads() once in the main Python
>> thread.
> 
> This is not well documented. For your information, PyGILState_Ensure()
> now calls PyEval_InitThreads() in Python 3.4, see:
> http://bugs.python.org/issue19576


I did see that - but from my own experience, I do not believe it is
calling PyThreadState_New(..) and it is not even checking if
PyThreadState_New(..) has ever been called for the active thread

Consequently, the thread is blocked or there is a seg fault

I've now written up a much more thorough overview of my experience on my
blog:

http://danielpocock.com/embedding-python-multi-threaded-cpp

From greg at krypto.org  Thu Dec 19 02:17:59 2013
From: greg at krypto.org (Gregory P. Smith)
Date: Wed, 18 Dec 2013 17:17:59 -0800
Subject: [Python-Dev] cffi in stdlib
In-Reply-To: <20131217164308.GA24264@sleipnir.bytereef.org>
References: <CAK5idxQA+9zbBGhG0Thxzg9aBEko9UBtFTGK9_uJJ1vkyrGXwg@mail.gmail.com>
 <20131217164308.GA24264@sleipnir.bytereef.org>
Message-ID: <CAGE7PNJ6CF995rFtGogBfHPZ6uwM__JBBQFJywe4HbEt5WOAYg@mail.gmail.com>

On Tue, Dec 17, 2013 at 8:43 AM, Stefan Krah <stefan at bytereef.org> wrote:

> Maciej Fijalkowski <fijall at gmail.com> wrote:
> > I would like to discuss on the language summit a potential inclusion
> > of cffi[1] into stdlib. This is a project Armin Rigo has been working
> > for a while, with some input from other developers.
>
> I've tried cffi (admittedly only in a toy script) and find it very nice
> to use.
>
> Here's a comparison (pi benchmark) between wrapping libmpdec using a
> C-extension (_decimal), cffi and ctypes:
>
>
> +-------------------------------+----------+----------+---------+
> |                               | _decimal |  ctypes  |   cffi  |
> +===============================+==========+==========+=========+
> | cpython-tip (with-system-ffi) |   0.19s  |   5.40s  |  5.14s  |
> +-------------------------------+----------+----------+---------+
> | cpython-2.7 (with-system-ffi) |    n/a   |   4.46s  |  5.18s  |
> +-------------------------------+----------+----------+---------+
> |      Ubuntu-cpython-2.7       |    n/a   |   3.63s  |    -    |
> +-------------------------------+----------+----------+---------+
> |      pypy-2.2.1-linux64       |    n/a   |  125.9s  |  0.94s  |
> +-------------------------------+----------+----------+---------+
> |     pypy3-2.1-beta1-linux64   |    n/a   |  264.9s  |  2.93s  |
> +-------------------------------+----------+----------+---------+
>
>
> I guess the key points are that C-extensions are hard to beat and that
> cffi performance on pypy-2 is outstanding. Additionally it's worth noting
> that Ubuntu does something in their Python build that we should do, too.
>

Ubuntu compiles their Python with FDO (feedback directed optimization /
profile guided optimization) enabled. All distros should do this if they
don't already. It's generally 20% interpreter speedup. Our makefile already
supports it but it isn't the default build as it takes a long time given
that it needs to compile everything twice and do a profiled benchmark run
between compilations.

-gps


>
> +1 for cffi in the stdlib.
>
>
>
> Stefan Krah
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131218/f2280c0b/attachment.html>

From fijall at gmail.com  Thu Dec 19 11:07:48 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 19 Dec 2013 12:07:48 +0200
Subject: [Python-Dev] cffi in stdlib
In-Reply-To: <CAGE7PNJ6CF995rFtGogBfHPZ6uwM__JBBQFJywe4HbEt5WOAYg@mail.gmail.com>
References: <CAK5idxQA+9zbBGhG0Thxzg9aBEko9UBtFTGK9_uJJ1vkyrGXwg@mail.gmail.com>
 <20131217164308.GA24264@sleipnir.bytereef.org>
 <CAGE7PNJ6CF995rFtGogBfHPZ6uwM__JBBQFJywe4HbEt5WOAYg@mail.gmail.com>
Message-ID: <CAK5idxRokGGkR4PPpHfutgQhr13pEfTwhAEbPQUso9EV6ZZ8ow@mail.gmail.com>

On Thu, Dec 19, 2013 at 3:17 AM, Gregory P. Smith <greg at krypto.org> wrote:
>
>
>
> On Tue, Dec 17, 2013 at 8:43 AM, Stefan Krah <stefan at bytereef.org> wrote:
>>
>> Maciej Fijalkowski <fijall at gmail.com> wrote:
>> > I would like to discuss on the language summit a potential inclusion
>> > of cffi[1] into stdlib. This is a project Armin Rigo has been working
>> > for a while, with some input from other developers.
>>
>> I've tried cffi (admittedly only in a toy script) and find it very nice
>> to use.
>>
>> Here's a comparison (pi benchmark) between wrapping libmpdec using a
>> C-extension (_decimal), cffi and ctypes:
>>
>>
>> +-------------------------------+----------+----------+---------+
>> |                               | _decimal |  ctypes  |   cffi  |
>> +===============================+==========+==========+=========+
>> | cpython-tip (with-system-ffi) |   0.19s  |   5.40s  |  5.14s  |
>> +-------------------------------+----------+----------+---------+
>> | cpython-2.7 (with-system-ffi) |    n/a   |   4.46s  |  5.18s  |
>> +-------------------------------+----------+----------+---------+
>> |      Ubuntu-cpython-2.7       |    n/a   |   3.63s  |    -    |
>> +-------------------------------+----------+----------+---------+
>> |      pypy-2.2.1-linux64       |    n/a   |  125.9s  |  0.94s  |
>> +-------------------------------+----------+----------+---------+
>> |     pypy3-2.1-beta1-linux64   |    n/a   |  264.9s  |  2.93s  |
>> +-------------------------------+----------+----------+---------+
>>
>>
>> I guess the key points are that C-extensions are hard to beat and that
>> cffi performance on pypy-2 is outstanding. Additionally it's worth noting
>> that Ubuntu does something in their Python build that we should do, too.
>
>
> Ubuntu compiles their Python with FDO (feedback directed optimization /
> profile guided optimization) enabled. All distros should do this if they
> don't already. It's generally 20% interpreter speedup. Our makefile already
> supports it but it isn't the default build as it takes a long time given
> that it needs to compile everything twice and do a profiled benchmark run
> between compilations.
>
> -gps

Hey Greg.

We found out that this only speedups benchmarks that you tried during
profiling and not others, so we disabled it for the default pypy
build. Can you provide me with some more detailed study on how it
speeds up interpreters in general and CPython in particular?

Cheers,
fijal

From ncoghlan at gmail.com  Thu Dec 19 12:22:20 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 19 Dec 2013 21:22:20 +1000
Subject: [Python-Dev] thread issues when embedding Python
In-Reply-To: <52B21A83.4000906@pocock.com.au>
References: <52B0DBFB.8040500@pocock.com.au> <20131218162543.382fae67@fsol>
 <CAMpsgwYrdyiq6p+_-31sydCCWFZPW7Kz0KOcG=6sxkHyiH4Y5g@mail.gmail.com>
 <52B21A83.4000906@pocock.com.au>
Message-ID: <CADiSq7dWiqnt2N=H=_iv80h0DOqLapvnWCcjJSPJWD4u5cDpVg@mail.gmail.com>

On 19 December 2013 07:58, Daniel Pocock <daniel at pocock.com.au> wrote:
>
>
> On 18/12/13 16:29, Victor Stinner wrote:
>> 2013/12/18 Antoine Pitrou <solipsis at pitrou.net>:
>>> You only need to call PyEval_InitThreads() once in the main Python
>>> thread.
>>
>> This is not well documented. For your information, PyGILState_Ensure()
>> now calls PyEval_InitThreads() in Python 3.4, see:
>> http://bugs.python.org/issue19576
>
>
> I did see that - but from my own experience, I do not believe it is
> calling PyThreadState_New(..) and it is not even checking if
> PyThreadState_New(..) has ever been called for the active thread
>
> Consequently, the thread is blocked or there is a seg fault
>
> I've now written up a much more thorough overview of my experience on my
> blog:
>
> http://danielpocock.com/embedding-python-multi-threaded-cpp

You absolutely should *NOT* have to call PyThreadState_New before
calling PyGILState_Ensure, as it is designed to call it for you (see
http://hg.python.org/cpython/file/2.7/Python/pystate.c#l598). If
calling PyThreadState_New works, but calling PyGILState_Ensure does
not, then something else is broken (such as not initialising the
thread local storage for the GIL state APIs).

I don't see anything in your article about how you ensure that the
main thread of the application *before anything else related to the
embedded Python happens* calls both Py_Initialize() and
PyEval_InitThreads(). If you don't do that, then all bets are off in
terms of multithreading support.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From daniel at pocock.com.au  Thu Dec 19 12:28:16 2013
From: daniel at pocock.com.au (Daniel Pocock)
Date: Thu, 19 Dec 2013 12:28:16 +0100
Subject: [Python-Dev] thread issues when embedding Python
In-Reply-To: <CADiSq7dWiqnt2N=H=_iv80h0DOqLapvnWCcjJSPJWD4u5cDpVg@mail.gmail.com>
References: <52B0DBFB.8040500@pocock.com.au> <20131218162543.382fae67@fsol>
 <CAMpsgwYrdyiq6p+_-31sydCCWFZPW7Kz0KOcG=6sxkHyiH4Y5g@mail.gmail.com>
 <52B21A83.4000906@pocock.com.au>
 <CADiSq7dWiqnt2N=H=_iv80h0DOqLapvnWCcjJSPJWD4u5cDpVg@mail.gmail.com>
Message-ID: <52B2D850.1030805@pocock.com.au>

On 19/12/13 12:22, Nick Coghlan wrote:
> On 19 December 2013 07:58, Daniel Pocock <daniel at pocock.com.au> wrote:
>>
>> On 18/12/13 16:29, Victor Stinner wrote:
>>> 2013/12/18 Antoine Pitrou <solipsis at pitrou.net>:
>>>> You only need to call PyEval_InitThreads() once in the main Python
>>>> thread.
>>> This is not well documented. For your information, PyGILState_Ensure()
>>> now calls PyEval_InitThreads() in Python 3.4, see:
>>> http://bugs.python.org/issue19576
>>
>> I did see that - but from my own experience, I do not believe it is
>> calling PyThreadState_New(..) and it is not even checking if
>> PyThreadState_New(..) has ever been called for the active thread
>>
>> Consequently, the thread is blocked or there is a seg fault
>>
>> I've now written up a much more thorough overview of my experience on my
>> blog:
>>
>> http://danielpocock.com/embedding-python-multi-threaded-cpp
> You absolutely should *NOT* have to call PyThreadState_New before
> calling PyGILState_Ensure, as it is designed to call it for you (see
> http://hg.python.org/cpython/file/2.7/Python/pystate.c#l598). If
> calling PyThreadState_New works, but calling PyGILState_Ensure does
> not, then something else is broken (such as not initialising the
> thread local storage for the GIL state APIs).
>
> I don't see anything in your article about how you ensure that the
> main thread of the application *before anything else related to the
> embedded Python happens* calls both Py_Initialize() and
> PyEval_InitThreads(). If you don't do that, then all bets are off in
> terms of multithreading support.

I definitely do both of those things in the method PyRoutePlugin::init(..)

It is in PyRoutePlugin.cxx:

http://svn.resiprocate.org/viewsvn/resiprocate/main/repro/plugins/pyroute/PyRoutePlugin.cxx?view=markup#l88



From ncoghlan at gmail.com  Thu Dec 19 13:22:57 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 19 Dec 2013 22:22:57 +1000
Subject: [Python-Dev] thread issues when embedding Python
In-Reply-To: <52B2D850.1030805@pocock.com.au>
References: <52B0DBFB.8040500@pocock.com.au> <20131218162543.382fae67@fsol>
 <CAMpsgwYrdyiq6p+_-31sydCCWFZPW7Kz0KOcG=6sxkHyiH4Y5g@mail.gmail.com>
 <52B21A83.4000906@pocock.com.au>
 <CADiSq7dWiqnt2N=H=_iv80h0DOqLapvnWCcjJSPJWD4u5cDpVg@mail.gmail.com>
 <52B2D850.1030805@pocock.com.au>
Message-ID: <CADiSq7dVu5Kpzdzt=To5-N+np_Zf089a8eQEjLGeRhiyPxdNGA@mail.gmail.com>

On 19 December 2013 21:28, Daniel Pocock <daniel at pocock.com.au> wrote:
> On 19/12/13 12:22, Nick Coghlan wrote:
>> I don't see anything in your article about how you ensure that the
>> main thread of the application *before anything else related to the
>> embedded Python happens* calls both Py_Initialize() and
>> PyEval_InitThreads(). If you don't do that, then all bets are off in
>> terms of multithreading support.
>
> I definitely do both of those things in the method PyRoutePlugin::init(..)
>
> It is in PyRoutePlugin.cxx:
>
> http://svn.resiprocate.org/viewsvn/resiprocate/main/repro/plugins/pyroute/PyRoutePlugin.cxx?view=markup#l88

I can't see an immediately obvious explanation for why your current
approach based on PyExternalUser::Use gets things working, while the
PyThreadSupport approach fails immediately. However, you'd need to be
able to reproduce the problem with a much simpler embedding
application and without PyCXX involved anywhere to confirm it as a
possible CPython bug, or to identify exactly what is missing from the
current embedding initialisation instructions.

The reason for that is the fact that the GIL state API is unit tested
on a wide variety of platforms inside a fully initialised interpreter
and that means we know this *does* work in the absence of external
interference: http://hg.python.org/cpython/file/16bfddf5a091/Modules/_testcapimodule.c#l1335

I also asked Graham Dumpleton (author of mod_wsgi, one of the more
complex CPython embedding scenarios currently in existence) to take a
look, and he didn't see any obvious explanation for the discrepancy
either, so you may want to try a cut down implementation without PyCXX
to see if that's the culprit.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From stefan at bytereef.org  Thu Dec 19 19:32:59 2013
From: stefan at bytereef.org (Stefan Krah)
Date: Thu, 19 Dec 2013 19:32:59 +0100
Subject: [Python-Dev] cffi in stdlib
In-Reply-To: <CAGE7PNJ6CF995rFtGogBfHPZ6uwM__JBBQFJywe4HbEt5WOAYg@mail.gmail.com>
References: <CAK5idxQA+9zbBGhG0Thxzg9aBEko9UBtFTGK9_uJJ1vkyrGXwg@mail.gmail.com>
 <20131217164308.GA24264@sleipnir.bytereef.org>
 <CAGE7PNJ6CF995rFtGogBfHPZ6uwM__JBBQFJywe4HbEt5WOAYg@mail.gmail.com>
Message-ID: <20131219183259.GA23957@sleipnir.bytereef.org>

Gregory P. Smith <greg at krypto.org> wrote:
> Ubuntu compiles their Python with FDO (feedback directed optimization / profile
> guided optimization) enabled. All distros should do this if they don't already.
> It's generally 20% interpreter speedup. Our makefile already supports it but it
> isn't the default build as it takes a long time given that it needs to compile
> everything twice and do a profiled benchmark run between compilations.

Yes, I didn't know we already had `make profile-opt`.  With that option
the self-compiled results are nearly the same as with the Ubuntu version,
the remaining difference might be due to Ubuntu's use of -flto, as
Matthias suggests in http://bugs.python.org/issue17781 .


Stefan Krah



From greg at krypto.org  Thu Dec 19 19:51:30 2013
From: greg at krypto.org (Gregory P. Smith)
Date: Thu, 19 Dec 2013 10:51:30 -0800
Subject: [Python-Dev] cffi in stdlib
In-Reply-To: <CAK5idxRokGGkR4PPpHfutgQhr13pEfTwhAEbPQUso9EV6ZZ8ow@mail.gmail.com>
References: <CAK5idxQA+9zbBGhG0Thxzg9aBEko9UBtFTGK9_uJJ1vkyrGXwg@mail.gmail.com>
 <20131217164308.GA24264@sleipnir.bytereef.org>
 <CAGE7PNJ6CF995rFtGogBfHPZ6uwM__JBBQFJywe4HbEt5WOAYg@mail.gmail.com>
 <CAK5idxRokGGkR4PPpHfutgQhr13pEfTwhAEbPQUso9EV6ZZ8ow@mail.gmail.com>
Message-ID: <CAGE7PN+CM8d1zZxf0KRJDu-OJssXVpY3n7kS3b6fvmFCK_3avw@mail.gmail.com>

On Thu, Dec 19, 2013 at 2:07 AM, Maciej Fijalkowski <fijall at gmail.com>wrote:

> On Thu, Dec 19, 2013 at 3:17 AM, Gregory P. Smith <greg at krypto.org> wrote:
> >
> >
> >
> > On Tue, Dec 17, 2013 at 8:43 AM, Stefan Krah <stefan at bytereef.org>
> wrote:
> >>
> >> Maciej Fijalkowski <fijall at gmail.com> wrote:
> >> > I would like to discuss on the language summit a potential inclusion
> >> > of cffi[1] into stdlib. This is a project Armin Rigo has been working
> >> > for a while, with some input from other developers.
> >>
> >> I've tried cffi (admittedly only in a toy script) and find it very nice
> >> to use.
> >>
> >> Here's a comparison (pi benchmark) between wrapping libmpdec using a
> >> C-extension (_decimal), cffi and ctypes:
> >>
> >>
> >> +-------------------------------+----------+----------+---------+
> >> |                               | _decimal |  ctypes  |   cffi  |
> >> +===============================+==========+==========+=========+
> >> | cpython-tip (with-system-ffi) |   0.19s  |   5.40s  |  5.14s  |
> >> +-------------------------------+----------+----------+---------+
> >> | cpython-2.7 (with-system-ffi) |    n/a   |   4.46s  |  5.18s  |
> >> +-------------------------------+----------+----------+---------+
> >> |      Ubuntu-cpython-2.7       |    n/a   |   3.63s  |    -    |
> >> +-------------------------------+----------+----------+---------+
> >> |      pypy-2.2.1-linux64       |    n/a   |  125.9s  |  0.94s  |
> >> +-------------------------------+----------+----------+---------+
> >> |     pypy3-2.1-beta1-linux64   |    n/a   |  264.9s  |  2.93s  |
> >> +-------------------------------+----------+----------+---------+
> >>
> >>
> >> I guess the key points are that C-extensions are hard to beat and that
> >> cffi performance on pypy-2 is outstanding. Additionally it's worth
> noting
> >> that Ubuntu does something in their Python build that we should do, too.
> >
> >
> > Ubuntu compiles their Python with FDO (feedback directed optimization /
> > profile guided optimization) enabled. All distros should do this if they
> > don't already. It's generally 20% interpreter speedup. Our makefile
> already
> > supports it but it isn't the default build as it takes a long time given
> > that it needs to compile everything twice and do a profiled benchmark run
> > between compilations.
> >
> > -gps
>
> Hey Greg.
>
> We found out that this only speedups benchmarks that you tried during
> profiling and not others, so we disabled it for the default pypy
> build. Can you provide me with some more detailed study on how it
> speeds up interpreters in general and CPython in particular?
>

That's a common concern for profile based builds but it turns out not to
matter a whole lot which workloads you choose for the CPython interpreter
to collect profiles for a FDO build. I believe ubuntu's packages just use
the test suite. In our own tests at work this produced good results.
Interpreter loops and other common code paths in the interpreter have a
*lot* of low hanging fruit in terms of more optimal code generation.

Link time optimization adds additional benefits IF you can get it working
(not always easy or reliable right now as Matthias mentions in issue17781).

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131219/4b252fef/attachment.html>

From eric at trueblade.com  Thu Dec 19 20:06:53 2013
From: eric at trueblade.com (Eric V. Smith)
Date: Thu, 19 Dec 2013 14:06:53 -0500
Subject: [Python-Dev] How long the wrong type of argument should we
 limit (or not) in the error message (C-api)?
In-Reply-To: <CADiSq7ecveZ+jgg_+nJN+UPUrYKtEedgJyZXFZCeYDdOHOeExw@mail.gmail.com>
References: <CAB+fVUWrWvvZiyfs3Msd4=7VR4YUtLtZED3rkLv1pnJgK0NDKQ@mail.gmail.com>
 <CADiSq7fEBjOtB9iZzdbnngWXnDJW4OJrgq0W74wG879o2CDELA@mail.gmail.com>
 <20131215001654.089a9c35@fsol>
 <CAMpsgwbS6ggmjD5K-wndyK0Jrev9K3mxJSSF+gf5is=tdyNiOQ@mail.gmail.com>
 <CADiSq7e5ZHp3MyQgStzCPwzC6RK0V4iStU5yHhUaOGx1J4opgw@mail.gmail.com>
 <20131215035128.GV29356@ando> <52ADD9DA.9030706@stoneleaf.us>
 <52AF1C45.4080208@livinglogic.de> <52AF2886.5090501@trueblade.com>
 <CADiSq7ecveZ+jgg_+nJN+UPUrYKtEedgJyZXFZCeYDdOHOeExw@mail.gmail.com>
Message-ID: <52B343CD.4000202@trueblade.com>

On 12/16/2013 03:49 PM, Nick Coghlan wrote:
> 
> On 17 Dec 2013 02:23, "Eric V. Smith" <eric at trueblade.com
> <mailto:eric at trueblade.com>> wrote:
>>
>> On 12/16/2013 10:29 AM, Walter D?rwald wrote:
>> > I'd vote for including the module name in the string and using
>> > __qualname__ instead of __name__, i.e. make "{:T}".format(obj)
>> > equivalent to
>> > "{0.__class__.__module__}.{0.__class__.qualname__}".format(obj).
>>
>> That's not possible in general. The format specifier interpretation is
>> done by each type. So, you could add this to str.__format__ and
>> int.__format__, but you can't add it to an arbitrary type's __format__.
>> For example, types not in the stdlib would never know about it.
> 
> That just suggests it would need to be a type coercion code, like !a,
> !r, and !s. However, that observation also suggests that starting with a
> "classname" or "typename" builtin would be more appropriate than jumping
> directly to a formatting code.

That's an excellent observation, Nick, including that it should be based
on a builtin. But I'd suggest something like classof(), and have it's
__format__ "do the right thing". But it all seems like overkill for this
problem.

> We've definitely drifted well into python-ideas territory at this point,
> though :)


True enough!

Eric.

> Cheers,
> Nick.
> 
>>
>> There's no logic for calling through to object.__format__ for unknown
>> specifiers. Look at datetime, for example. It uses strftime, so "T"
>> currently just prints a literal "T".
>>
>> And for object.__format__, we recently made it an error to specify any
>> format string. This is to prevent you from calling
>> format(an_object, ".30")
>> and "knowning" that it's interpreted by str.__format__ (because that's
>> the default conversion for object.__format__). If in the future
>> an_object's class added its own __format__, this code would break (or at
>> least do the wrong thing).
>>
>> But I really do like the idea! Maybe there's a way to just make
>> obj.__class__ recognize "T", so you could at least do:
>> format(obj.__class__, "T")
>> or equivalently:
>> "{:T}".format(obj.__class__)
>>
>> I realize that having to use .__class__ defeats some of the beauty of
>> this scheme.
>>
>> Eric.
>>
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org <mailto:Python-Dev at python.org>
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
> 
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com
> 


From g.brandl at gmx.net  Fri Dec 20 09:00:04 2013
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 20 Dec 2013 09:00:04 +0100
Subject: [Python-Dev] cpython (3.3): Issue #17576: Deprecation warning
 emitted now when __int__() or __index__()
In-Reply-To: <20131212152240.95242250934@webabinitio.net>
References: <3dfp8M5ZFMz7Lmp@mail.python.org> <20131211232447.5fa02d4a@fsol>
 <l8btj5$vne$1@ger.gmane.org> <20131212152240.95242250934@webabinitio.net>
Message-ID: <l90td7$3eh$1@ger.gmane.org>

Am 12.12.2013 16:22, schrieb R. David Murray:
> On Thu, 12 Dec 2013 10:54:05 +0200, Serhiy Storchaka <storchaka at gmail.com> wrote:
>> 12.12.13 00:24, Antoine Pitrou ??????????????(????):
>> > On Wed, 11 Dec 2013 20:28:19 +0100 (CET)
>> > serhiy.storchaka <python-checkins at python.org> wrote:
>> >> http://hg.python.org/cpython/rev/618cca51a27e
>> >> changeset:   87899:618cca51a27e
>> >> branch:      3.3
>> >> parent:      87896:46186736e91c
>> >> user:        Serhiy Storchaka <storchaka at gmail.com>
>> >> date:        Wed Dec 11 21:07:54 2013 +0200
>> >> summary:
>> >>    Issue #17576: Deprecation warning emitted now when __int__() or __index__()
>> >> return not int instance.  Introduced _PyLong_FromNbInt() and refactored
>> >> PyLong_As*() functions.
>> >
>> > Is it ok to add deprecation warnings in bugfix versions?
>> 
>> Some clarifications. This is a precursor of a bugfix. I split a patch on 
>> two parts for simplicity. First part doesn't change behavior besides 
>> introducing warnings. Second part is simple and will change behavior (I 
>> still doubt how many behavior it should change).
> 
> That doesn't address the question of why the deprecation is added
> to a bug-fix release.  Normal policy is deprecate in the current
> feature release and make the change in the next feature release.
> 
> Is there a reason why the normal deprecation process should not be
> followed in this case?  It being a not-likely-to-be-encountered
> in-the-real-world bug could be one such reason, if the release
> managers agree.

I don't think it's useful to add the warning (although it won't break
anything).  Deprecations should be treated like features: their status
should only change in a minor (3.x.0) release.

Now the second part (changing behavior) also sounds potentially
dangerous :)

Georg


From status at bugs.python.org  Fri Dec 20 18:07:47 2013
From: status at bugs.python.org (Python tracker)
Date: Fri, 20 Dec 2013 18:07:47 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20131220170747.E8BF9568E4@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2013-12-13 - 2013-12-20)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    4323 ( +1)
  closed 27484 (+56)
  total  31807 (+57)

Open issues with patches: 1980 


Issues opened (44)
==================

#18283: shutil.which() should support bytes
http://bugs.python.org/issue18283  reopened by haypo

#19766: test_venv: test_with_pip() failed on "AMD64 Fedora without thr
http://bugs.python.org/issue19766  reopened by ncoghlan

#19967: asyncio: remove _TracebackLogger
http://bugs.python.org/issue19967  reopened by pitrou

#19979: Missing nested scope vars in class scope (bis)
http://bugs.python.org/issue19979  opened by arigo

#19980: Improve help('non-topic') response
http://bugs.python.org/issue19980  opened by terry.reedy

#19982: Add a "target" parameter to runpy.run_path and runpy.run_modul
http://bugs.python.org/issue19982  opened by ncoghlan

#19983: Ctrl-C at startup can end in a Py_FatalError call
http://bugs.python.org/issue19983  opened by Jurko.Gospodneti??

#19984: Add new format of fixed length string for PyErr_Format
http://bugs.python.org/issue19984  opened by vajrasky

#19985: Not so correct error message when initializing Struct with ill
http://bugs.python.org/issue19985  opened by vajrasky

#19989: Error while sending function code over queue (multiprocessing)
http://bugs.python.org/issue19989  opened by Filip.Malczak

#19990: Add unittests for imghdr module
http://bugs.python.org/issue19990  opened by Claudiu.Popa

#19991: configparser instances cannot be pretty printed
http://bugs.python.org/issue19991  opened by Andrei.Kucharavy

#19992: subprocess documentation not explicit about fileno()
http://bugs.python.org/issue19992  opened by Thayne.McCombs

#19993: Pool.imap doesn't work as advertised
http://bugs.python.org/issue19993  opened by jneb

#19995: hex() and %x, oct() and %o do not behave the same
http://bugs.python.org/issue19995  opened by ethan.furman

#19996: httplib infinite read on invalid header
http://bugs.python.org/issue19996  opened by Lukasa

#19997: imghdr.what doesn't accept bytes paths
http://bugs.python.org/issue19997  opened by Claudiu.Popa

#19998: Python 2.7.6 fails to build _ctypes on GCC 2.x toolchain
http://bugs.python.org/issue19998  opened by jamercee

#20000: SSLContext.get_ca_certs() and self-signed certs
http://bugs.python.org/issue20000  opened by christian.heimes

#20001: pathlib inheritance diagram too large
http://bugs.python.org/issue20001  opened by pitrou

#20002: Cleanup and microoptimize pathlib
http://bugs.python.org/issue20002  opened by serhiy.storchaka

#20003: Language Ref "raise" doc misssing "from None"
http://bugs.python.org/issue20003  opened by rurpy2

#20008: Clean up/refactor/make discoverable test_decimal
http://bugs.python.org/issue20008  opened by zach.ware

#20009: Property should expose wrapped function.
http://bugs.python.org/issue20009  opened by hardkrash

#20010: time.strftime('%z') didn't make +HHMM return in windows xp
http://bugs.python.org/issue20010  opened by civalin

#20011: Changing the signature for Parameter's constructor
http://bugs.python.org/issue20011  opened by Antony.Lee

#20012: Re: Allow Path.relative_to() to accept non-ancestor paths
http://bugs.python.org/issue20012  opened by javawizard

#20013: imaplib behaviour when deleting selected folder
http://bugs.python.org/issue20013  opened by dveeden

#20014: Makes array.array constructor accepts ascii-unicode typecode
http://bugs.python.org/issue20014  opened by vajrasky

#20015: Allow 1-character ASCII unicode where 1-character str is requi
http://bugs.python.org/issue20015  opened by serhiy.storchaka

#20020: "modernize" the modulefinder module
http://bugs.python.org/issue20020  opened by eric.snow

#20021: "modernize" makeopcodetargets.py
http://bugs.python.org/issue20021  opened by eric.snow

#20022: "modernize" the Mac bundlebuilder.py script
http://bugs.python.org/issue20022  opened by eric.snow

#20024: Py_BuildValue() can call Python code with an exception set
http://bugs.python.org/issue20024  opened by haypo

#20026: sqlite: handle correctly invalid isolation_level
http://bugs.python.org/issue20026  opened by haypo

#20027: Fixed support for Indian locales
http://bugs.python.org/issue20027  opened by serhiy.storchaka

#20028: Confusing error message when giving invalid quotechar in initi
http://bugs.python.org/issue20028  opened by vajrasky

#20029: asyncio.SubprocessProtocol is missing
http://bugs.python.org/issue20029  opened by akira

#20030: unittest.TestLoader.discover return value incorrectly document
http://bugs.python.org/issue20030  opened by arnaut-billings

#20031: unittest.TextTestRunner missing run() documentation.
http://bugs.python.org/issue20031  opened by arnaut-billings

#20032: asyncio.Future.set_exception() creates a reference cycle
http://bugs.python.org/issue20032  opened by haypo

#20033: Fix makelocalealias.py for Python 3
http://bugs.python.org/issue20033  opened by serhiy.storchaka

#20035: Suppress 'os.environ was modified' warning on Tcl/Tk tests
http://bugs.python.org/issue20035  opened by zach.ware

#992389: attribute error due to circular import
http://bugs.python.org/issue992389  reopened by ncoghlan



Most recent 15 issues with no replies (15)
==========================================

#20035: Suppress 'os.environ was modified' warning on Tcl/Tk tests
http://bugs.python.org/issue20035

#20033: Fix makelocalealias.py for Python 3
http://bugs.python.org/issue20033

#20031: unittest.TextTestRunner missing run() documentation.
http://bugs.python.org/issue20031

#20030: unittest.TestLoader.discover return value incorrectly document
http://bugs.python.org/issue20030

#20029: asyncio.SubprocessProtocol is missing
http://bugs.python.org/issue20029

#20021: "modernize" makeopcodetargets.py
http://bugs.python.org/issue20021

#20009: Property should expose wrapped function.
http://bugs.python.org/issue20009

#20003: Language Ref "raise" doc misssing "from None"
http://bugs.python.org/issue20003

#19992: subprocess documentation not explicit about fileno()
http://bugs.python.org/issue19992

#19989: Error while sending function code over queue (multiprocessing)
http://bugs.python.org/issue19989

#19979: Missing nested scope vars in class scope (bis)
http://bugs.python.org/issue19979

#19978: Update multiprocessing.spawn to use runpy.run_path
http://bugs.python.org/issue19978

#19966: Wrong mtimes of files in 3.3.3 tarballs
http://bugs.python.org/issue19966

#19962: Create a 'python.bat' script to invoke interpreter from source
http://bugs.python.org/issue19962

#19961: MacOSX: Tkinter build failure when building without command-li
http://bugs.python.org/issue19961



Most recent 15 issues waiting for review (15)
=============================================

#20035: Suppress 'os.environ was modified' warning on Tcl/Tk tests
http://bugs.python.org/issue20035

#20033: Fix makelocalealias.py for Python 3
http://bugs.python.org/issue20033

#20032: asyncio.Future.set_exception() creates a reference cycle
http://bugs.python.org/issue20032

#20028: Confusing error message when giving invalid quotechar in initi
http://bugs.python.org/issue20028

#20027: Fixed support for Indian locales
http://bugs.python.org/issue20027

#20026: sqlite: handle correctly invalid isolation_level
http://bugs.python.org/issue20026

#20024: Py_BuildValue() can call Python code with an exception set
http://bugs.python.org/issue20024

#20022: "modernize" the Mac bundlebuilder.py script
http://bugs.python.org/issue20022

#20015: Allow 1-character ASCII unicode where 1-character str is requi
http://bugs.python.org/issue20015

#20014: Makes array.array constructor accepts ascii-unicode typecode
http://bugs.python.org/issue20014

#20013: imaplib behaviour when deleting selected folder
http://bugs.python.org/issue20013

#20011: Changing the signature for Parameter's constructor
http://bugs.python.org/issue20011

#20008: Clean up/refactor/make discoverable test_decimal
http://bugs.python.org/issue20008

#20002: Cleanup and microoptimize pathlib
http://bugs.python.org/issue20002

#19998: Python 2.7.6 fails to build _ctypes on GCC 2.x toolchain
http://bugs.python.org/issue19998



Top 10 most discussed issues (10)
=================================

#19995: hex() and %x, oct() and %o do not behave the same
http://bugs.python.org/issue19995  28 msgs

#19713: Deprecate various things in importlib thanks to PEP 451
http://bugs.python.org/issue19713  12 msgs

#19996: httplib infinite read on invalid header
http://bugs.python.org/issue19996  10 msgs

#19518: Add new PyRun_xxx() functions to not encode the filename
http://bugs.python.org/issue19518   9 msgs

#19967: asyncio: remove _TracebackLogger
http://bugs.python.org/issue19967   9 msgs

#19983: Ctrl-C at startup can end in a Py_FatalError call
http://bugs.python.org/issue19983   9 msgs

#14455: plistlib unable to read json and binary plist files
http://bugs.python.org/issue14455   7 msgs

#19537: Fix misalignment in fastsearch_memchr_1char
http://bugs.python.org/issue19537   6 msgs

#19940: ssl.cert_time_to_seconds() returns wrong results if local time
http://bugs.python.org/issue19940   6 msgs

#19977: Use "surrogateescape" error handler for sys.stdin and sys.stdo
http://bugs.python.org/issue19977   6 msgs



Issues closed (56)
==================

#5815: locale.getdefaultlocale() missing corner case
http://bugs.python.org/issue5815  closed by serhiy.storchaka

#12263: punycode codec ignores the error handler argument
http://bugs.python.org/issue12263  closed by haypo

#13024: cgitb uses stdout encoding
http://bugs.python.org/issue13024  closed by haypo

#16404: Uses of PyLong_FromLong that don't check for errors
http://bugs.python.org/issue16404  closed by serhiy.storchaka

#16492: Add a load_parents argument to importlib.find_loader()
http://bugs.python.org/issue16492  closed by eric.snow

#17919: AIX POLLNVAL definition causes problems
http://bugs.python.org/issue17919  closed by serhiy.storchaka

#17976: file.write doesn't raise IOError when it should
http://bugs.python.org/issue17976  closed by serhiy.storchaka

#18036: "How do I create a .pyc file?" FAQ entry is out of date
http://bugs.python.org/issue18036  closed by r.david.murray

#18215: Script to test multiple versions of OpenSSL
http://bugs.python.org/issue18215  closed by christian.heimes

#18227: Use Python memory allocators in external libraries like zlib o
http://bugs.python.org/issue18227  closed by haypo

#18421: Refactor call_with_frame() function of pyexpat.c
http://bugs.python.org/issue18421  closed by haypo

#18733: elementtree: stop the parser more quickly on error
http://bugs.python.org/issue18733  closed by haypo

#18829: csv produces confusing error message when passed a non-string 
http://bugs.python.org/issue18829  closed by serhiy.storchaka

#18877: tkinter askopenfilenames does not work in Windows library fold
http://bugs.python.org/issue18877  closed by serhiy.storchaka

#19045: Make on Solaris 11 x64 with OracleStudio12.3 failed
http://bugs.python.org/issue19045  closed by christian.heimes

#19167: sqlite3 cursor.description varies across Linux (3.3.1), Win32 
http://bugs.python.org/issue19167  closed by r.david.murray

#19229: operator.py: move the Python implementation in the else block 
http://bugs.python.org/issue19229  closed by haypo

#19492: Report skipped distutils tests as skipped
http://bugs.python.org/issue19492  closed by serhiy.storchaka

#19532: compileall -f doesn't force to write bytecode files
http://bugs.python.org/issue19532  closed by r.david.murray

#19562: Added description for assert statement
http://bugs.python.org/issue19562  closed by belopolsky

#19623: Support for writing aifc to unseekable file
http://bugs.python.org/issue19623  closed by serhiy.storchaka

#19700: Update runpy for PEP 451
http://bugs.python.org/issue19700  closed by ncoghlan

#19701: Update multiprocessing for PEP 451
http://bugs.python.org/issue19701  closed by brett.cannon

#19704: Update test.test_threaded_import to PEP 451
http://bugs.python.org/issue19704  closed by brett.cannon

#19705: Update test.test_namespace_pkgs to PEP 451
http://bugs.python.org/issue19705  closed by brett.cannon

#19710: Make sure documentation for PEP 451 is finished
http://bugs.python.org/issue19710  closed by eric.snow

#19736: posixmodule.c: Add flags for statvfs.f_flag to constant list
http://bugs.python.org/issue19736  closed by doko

#19855: uuid._find_mac fails if an executable not in /sbin or /usr/sbi
http://bugs.python.org/issue19855  closed by r.david.murray

#19887: Path.resolve() fails on complex symlinks
http://bugs.python.org/issue19887  closed by pitrou

#19902: logging docs don't document integer constants
http://bugs.python.org/issue19902  closed by vinay.sajip

#19911: ntpath.splitdrive() fails when UNC part contains \u0130
http://bugs.python.org/issue19911  closed by serhiy.storchaka

#19912: ntpath.splitunc() is broken and not tested
http://bugs.python.org/issue19912  closed by serhiy.storchaka

#19913: TR/Crypt.XPACK.Gen-4 in easy_install.exe
http://bugs.python.org/issue19913  closed by vinay.sajip

#19914: help([object]) returns "Not enough memory." on standard Python
http://bugs.python.org/issue19914  closed by terry.reedy

#19921: Path.mkdir(0, True) always fails
http://bugs.python.org/issue19921  closed by pitrou

#19963: Update docs for importlib.import_module()
http://bugs.python.org/issue19963  closed by brett.cannon

#19970: Typo of `immediatly` and `agin` words
http://bugs.python.org/issue19970  closed by r.david.murray

#19972: Leak in pickle (?)
http://bugs.python.org/issue19972  closed by skrah

#19975: Remove unused imports from webbrowser
http://bugs.python.org/issue19975  closed by r.david.murray

#19981: Typo in mailbox documentation
http://bugs.python.org/issue19981  closed by ezio.melotti

#19986: ???mpd_del??? discards qualifiers from pointer target type
http://bugs.python.org/issue19986  closed by skrah

#19987: Winsound: test_alias_fallback fails on WS 2008
http://bugs.python.org/issue19987  closed by zach.ware

#19988: hex() and oct() use __index__ instead of __int__
http://bugs.python.org/issue19988  closed by gvanrossum

#19994: re.match does not return or takes long time
http://bugs.python.org/issue19994  closed by tim.peters

#19999: test_monotonic fails on x86 OpenIndiana
http://bugs.python.org/issue19999  closed by python-dev

#20004: csv.DictReader classic class has a property with setter
http://bugs.python.org/issue20004  closed by r.david.murray

#20005: Minor typo in operator documentation
http://bugs.python.org/issue20005  closed by python-dev

#20006: Sporadic failures of test_weakset
http://bugs.python.org/issue20006  closed by pitrou

#20007: .read(0) on http.client.HTTPResponse drops the rest of the con
http://bugs.python.org/issue20007  closed by serhiy.storchaka

#20016: make site.py Quitter call itself on repr
http://bugs.python.org/issue20016  closed by eric.araujo

#20017: SimpleHTTPServer: UnicodeDecodeError on Windows 8 (64-bit)
http://bugs.python.org/issue20017  closed by haypo

#20018: Replace dead URL with link to mirror
http://bugs.python.org/issue20018  closed by python-dev

#20019: platform.py line _sys_version function
http://bugs.python.org/issue20019  closed by lemburg

#20023: _csv.Dialect() does not check type for delimiter, escapechar a
http://bugs.python.org/issue20023  closed by haypo

#20025: ssl.RAND_bytes() and ssl.RAND_pseudo_bytes() don't check if nu
http://bugs.python.org/issue20025  closed by haypo

#20034: Update locale alias table
http://bugs.python.org/issue20034  closed by serhiy.storchaka

From prasadjoshi124 at gmail.com  Tue Dec 24 07:41:41 2013
From: prasadjoshi124 at gmail.com (Prasad Joshi)
Date: Tue, 24 Dec 2013 12:11:41 +0530
Subject: [Python-Dev] Interested in GSoC 2014
Message-ID: <CAFEQX0dRubjF8eTqBASafvHUrxAcQpqzR-zFLnhw00RJ56Bk2g@mail.gmail.com>

Hello All,

I am interested in participating GSoC 2014. I have went through last
year's eligibility criterion, I think I am qualified to participate. I
know GSoC 2014 still has more than 2-3 months, however I would like to
start early. Please let me know suggestions.

After going through GSoC 2013 page
(https://wiki.python.org/moin/SummerOfCode/2013), I think I would be
interested in Core Python or PyPy. Please let me know how should I
start.

Thanks a lot for your inputs.

Thanks and Regards,
Prasad

From daniel at pocock.com.au  Tue Dec 24 08:52:41 2013
From: daniel at pocock.com.au (Daniel Pocock)
Date: Tue, 24 Dec 2013 08:52:41 +0100
Subject: [Python-Dev] Interested in GSoC 2014
In-Reply-To: <CAFEQX0dRubjF8eTqBASafvHUrxAcQpqzR-zFLnhw00RJ56Bk2g@mail.gmail.com>
References: <CAFEQX0dRubjF8eTqBASafvHUrxAcQpqzR-zFLnhw00RJ56Bk2g@mail.gmail.com>
Message-ID: <52B93D49.4010808@pocock.com.au>

On 24/12/13 07:41, Prasad Joshi wrote:
> Hello All,
>
> I am interested in participating GSoC 2014. I have went through last
> year's eligibility criterion, I think I am qualified to participate. I
> know GSoC 2014 still has more than 2-3 months, however I would like to
> start early. Please let me know suggestions.


Hi Prasad,

We recently introduced a Python scripting API into reSIProcate

You would be welcome to contribute some code to exercise the API.

Here are some details:

   http://www.resiprocate.org/Python

It would be particularly interesting to try and integrate the new WebRTC
/ WebSocket cookie support with some existing Python-based web
framework, e.g. Django.  This would allow a user with a Django login,
shopping cart or some other long running session to pass their state
through the cookies.

Regards,

Daniel



From rdmurray at bitdance.com  Tue Dec 24 15:39:26 2013
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 24 Dec 2013 09:39:26 -0500
Subject: [Python-Dev] Interested in GSoC 2014
In-Reply-To: <CAFEQX0dRubjF8eTqBASafvHUrxAcQpqzR-zFLnhw00RJ56Bk2g@mail.gmail.com>
References: <CAFEQX0dRubjF8eTqBASafvHUrxAcQpqzR-zFLnhw00RJ56Bk2g@mail.gmail.com>
Message-ID: <20131224143927.6981025003A@webabinitio.net>

On Tue, 24 Dec 2013 12:11:41 +0530, Prasad Joshi <prasadjoshi124 at gmail.com> wrote:
> I am interested in participating GSoC 2014. I have went through last
> year's eligibility criterion, I think I am qualified to participate. I
> know GSoC 2014 still has more than 2-3 months, however I would like to
> start early. Please let me know suggestions.
> 
> After going through GSoC 2013 page
> (https://wiki.python.org/moin/SummerOfCode/2013), I think I would be
> interested in Core Python or PyPy. Please let me know how should I
> start.

If you want to work on CPython or PyPy, the best thing to do is to
get involved in the community.  For CPython, that means following the
python-dev mailing list and exploring the bug tracker.  (pypy has its own
mailing list and bug tracker, and I'm sure they will respond there...it
is best not to cross post messages like this, by the way; I've removed
pypy-dev from the followups on this message.)

For CPython, the place to start is the devguide:

    http://docs.python.org/devguide

There's also a Core Mentorship mailing list (core-mentorship at python.org,
see mail.python.org for signup details).  There you can ask any questions
you want about the development process and get mentoring on fixing bugs,
which is the best way to get involved.

For any Python project you will be required to submit a patch on the
relevant project's tracker as part of your qualification, so getting
started on this now is a great idea.  I should warn you, though, that
the CPython team tends to only come up with GSoc projects at the last
minute...

--David

From status at bugs.python.org  Fri Dec 27 18:07:45 2013
From: status at bugs.python.org (Python tracker)
Date: Fri, 27 Dec 2013 18:07:45 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20131227170745.7173456A24@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2013-12-20 - 2013-12-27)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    4332 ( +9)
  closed 27520 (+36)
  total  31852 (+45)

Open issues with patches: 1973 


Issues opened (29)
==================

#20039: Missing documentation for argparse.ArgumentTypeError
http://bugs.python.org/issue20039  opened by arnaut-billings

#20040: Tracing not disabled in generator when the system trace functi
http://bugs.python.org/issue20040  opened by xdegaye

#20041: TypeError when f_trace is None and tracing.
http://bugs.python.org/issue20041  opened by xdegaye

#20042: Python Launcher for Windows fails to invoke scripts with non-l
http://bugs.python.org/issue20042  opened by zart

#20044: gettext.install() ignores previous call to locale.setlocale()
http://bugs.python.org/issue20044  opened by fmoreau

#20047: bytearray partition bug
http://bugs.python.org/issue20047  opened by BreamoreBoy

#20050: distutils should check PyPI certs when connecting to it
http://bugs.python.org/issue20050  opened by pitrou

#20051: PA-RISC buildbot: compiler cannot create executables
http://bugs.python.org/issue20051  opened by skrah

#20053: venv and ensurepip are affected by default pip config file
http://bugs.python.org/issue20053  opened by ncoghlan

#20055: On Windows NT 6 with administrator account, there are two fail
http://bugs.python.org/issue20055  opened by vajrasky

#20056: Got deprecation warning when running test_shutil.py on Windows
http://bugs.python.org/issue20056  opened by vajrasky

#20057: wrong behavior with fork and mmap
http://bugs.python.org/issue20057  opened by btiplitz

#20059: Inconsistent urlparse/urllib.parse handling of invalid port va
http://bugs.python.org/issue20059  opened by chad.birch

#20061: make pdb through separate terminal more convenient
http://bugs.python.org/issue20061  opened by Chiel92

#20062: Add section on vim to devguide
http://bugs.python.org/issue20062  opened by r.david.murray

#20064: PyObject_Malloc is not documented
http://bugs.python.org/issue20064  opened by r.david.murray

#20065: Python-3.3.3/Modules/socketmodule.c:1660:14: error: 'CAN_RAW' 
http://bugs.python.org/issue20065  opened by lanthruster

#20066: PyStructSequence_NewType() not setting proper heap allocation 
http://bugs.python.org/issue20066  opened by Wolf.Ihlenfeldt

#20068: collections.Counter documentation leaves out interesting useca
http://bugs.python.org/issue20068  opened by Julian.Gindi

#20069: Add unit test for os.chown
http://bugs.python.org/issue20069  opened by vajrasky

#20071: What should happen if someone runs ./python -m ensurepip in th
http://bugs.python.org/issue20071  opened by r.david.murray

#20072: Ttk tests fail when wantobjects is false
http://bugs.python.org/issue20072  opened by serhiy.storchaka

#20074: open() of read-write non-seekable streams broken
http://bugs.python.org/issue20074  opened by Dolda2000

#20075: help(open) eats first line
http://bugs.python.org/issue20075  opened by serhiy.storchaka

#20076: Add UTF-8 locale aliases
http://bugs.python.org/issue20076  opened by serhiy.storchaka

#20077: Format of TypeError differs between comparison and arithmetic 
http://bugs.python.org/issue20077  opened by MLModel

#20078: zipfile - ZipExtFile.read goes into 100% CPU infinite loop on 
http://bugs.python.org/issue20078  opened by nandiya

#20079: Add support for glibc supported locales
http://bugs.python.org/issue20079  opened by serhiy.storchaka

#20080: Unused variable in Lib/sqlite3/test/factory.py
http://bugs.python.org/issue20080  opened by vajrasky



Most recent 15 issues with no replies (15)
==========================================

#20078: zipfile - ZipExtFile.read goes into 100% CPU infinite loop on 
http://bugs.python.org/issue20078

#20077: Format of TypeError differs between comparison and arithmetic 
http://bugs.python.org/issue20077

#20076: Add UTF-8 locale aliases
http://bugs.python.org/issue20076

#20071: What should happen if someone runs ./python -m ensurepip in th
http://bugs.python.org/issue20071

#20068: collections.Counter documentation leaves out interesting useca
http://bugs.python.org/issue20068

#20066: PyStructSequence_NewType() not setting proper heap allocation 
http://bugs.python.org/issue20066

#20065: Python-3.3.3/Modules/socketmodule.c:1660:14: error: 'CAN_RAW' 
http://bugs.python.org/issue20065

#20059: Inconsistent urlparse/urllib.parse handling of invalid port va
http://bugs.python.org/issue20059

#20056: Got deprecation warning when running test_shutil.py on Windows
http://bugs.python.org/issue20056

#20051: PA-RISC buildbot: compiler cannot create executables
http://bugs.python.org/issue20051

#20050: distutils should check PyPI certs when connecting to it
http://bugs.python.org/issue20050

#20044: gettext.install() ignores previous call to locale.setlocale()
http://bugs.python.org/issue20044

#20031: unittest.TextTestRunner missing run() documentation.
http://bugs.python.org/issue20031

#20030: unittest.TestLoader.discover return value incorrectly document
http://bugs.python.org/issue20030

#20021: "modernize" makeopcodetargets.py
http://bugs.python.org/issue20021



Most recent 15 issues waiting for review (15)
=============================================

#20080: Unused variable in Lib/sqlite3/test/factory.py
http://bugs.python.org/issue20080

#20079: Add support for glibc supported locales
http://bugs.python.org/issue20079

#20076: Add UTF-8 locale aliases
http://bugs.python.org/issue20076

#20075: help(open) eats first line
http://bugs.python.org/issue20075

#20072: Ttk tests fail when wantobjects is false
http://bugs.python.org/issue20072

#20069: Add unit test for os.chown
http://bugs.python.org/issue20069

#20064: PyObject_Malloc is not documented
http://bugs.python.org/issue20064

#20055: On Windows NT 6 with administrator account, there are two fail
http://bugs.python.org/issue20055

#20042: Python Launcher for Windows fails to invoke scripts with non-l
http://bugs.python.org/issue20042

#20041: TypeError when f_trace is None and tracing.
http://bugs.python.org/issue20041

#20035: Suppress 'os.environ was modified' warning on Tcl/Tk tests
http://bugs.python.org/issue20035

#20028: Confusing error message when giving invalid quotechar in initi
http://bugs.python.org/issue20028

#20026: sqlite: handle correctly invalid isolation_level
http://bugs.python.org/issue20026

#20024: Py_BuildValue() can call Python code with an exception set
http://bugs.python.org/issue20024

#20022: "modernize" the Mac bundlebuilder.py script
http://bugs.python.org/issue20022



Top 10 most discussed issues (10)
=================================

#19927: Path-based loaders lack a meaningful __eq__() implementation.
http://bugs.python.org/issue19927  12 msgs

#20074: open() of read-write non-seekable streams broken
http://bugs.python.org/issue20074  11 msgs

#20075: help(open) eats first line
http://bugs.python.org/issue20075  10 msgs

#19861: Update What's New for Python 3.4
http://bugs.python.org/issue19861   6 msgs

#20061: make pdb through separate terminal more convenient
http://bugs.python.org/issue20061   6 msgs

#20042: Python Launcher for Windows fails to invoke scripts with non-l
http://bugs.python.org/issue20042   5 msgs

#16136: Removal of VMS support
http://bugs.python.org/issue16136   4 msgs

#18566: In unittest.TestCase docs for setUp() and tearDown() don't men
http://bugs.python.org/issue18566   4 msgs

#19463: assertGdbRepr depends on hash randomization / endianess
http://bugs.python.org/issue19463   4 msgs

#20047: bytearray partition bug
http://bugs.python.org/issue20047   4 msgs



Issues closed (33)
==================

#7171: Add inet_ntop and inet_pton support for Windows
http://bugs.python.org/issue7171  closed by pitrou

#12226: use HTTPS by default for uploading packages to pypi
http://bugs.python.org/issue12226  closed by pitrou

#15340: OSError with "import random" when /dev/urandom doesn't exist (
http://bugs.python.org/issue15340  closed by pitrou

#16832: Expose cache validity checking support in ABCMeta
http://bugs.python.org/issue16832  closed by r.david.murray

#17538: Document XML Vulnerabilties
http://bugs.python.org/issue17538  closed by pitrou

#18879: tempfile.NamedTemporaryFile can close the file too early, if n
http://bugs.python.org/issue18879  closed by pitrou

#19508: Add warning that Python doesn't verify SSL certs by default
http://bugs.python.org/issue19508  closed by pitrou

#19563: Changing barry's email  to barry at python.org
http://bugs.python.org/issue19563  closed by python-dev

#19734: venv and ensurepip are affected by pip environment variable se
http://bugs.python.org/issue19734  closed by python-dev

#19938: Re-enable test_bug_1333982 on 3.x
http://bugs.python.org/issue19938  closed by zach.ware

#19998: Python 2.7.6 fails to build _ctypes on GCC 2.x toolchain
http://bugs.python.org/issue19998  closed by terry.reedy

#20003: Language Ref "raise" doc misssing "from None"
http://bugs.python.org/issue20003  closed by terry.reedy

#20014: Makes array.array constructor accepts ascii-unicode typecode
http://bugs.python.org/issue20014  closed by terry.reedy

#20015: Allow 1-character ASCII unicode where 1-character str is requi
http://bugs.python.org/issue20015  closed by terry.reedy

#20027: Fixed support for Indian locales
http://bugs.python.org/issue20027  closed by serhiy.storchaka

#20032: asyncio.Future.set_exception() creates a reference cycle
http://bugs.python.org/issue20032  closed by haypo

#20033: Fix makelocalealias.py for Python 3
http://bugs.python.org/issue20033  closed by serhiy.storchaka

#20036: Running same doctests not possible on both py3 and py2
http://bugs.python.org/issue20036  closed by r.david.murray

#20037: Calling traceback.format_exception() during Pyhon shutdown doe
http://bugs.python.org/issue20037  closed by pitrou

#20038: Crash due to I/O in __del__
http://bugs.python.org/issue20038  closed by pitrou

#20043: test_multiprocessing_main_handling fails --without-threads
http://bugs.python.org/issue20043  closed by berker.peksag

#20045: setup.py register --list-classifiers is broken
http://bugs.python.org/issue20045  closed by pitrou

#20046: Optimize locale aliases table
http://bugs.python.org/issue20046  closed by serhiy.storchaka

#20048: zipfile's readline() drops data in universal newline mode
http://bugs.python.org/issue20048  closed by serhiy.storchaka

#20049: string.lowercase and string.uppercase can contain garbage
http://bugs.python.org/issue20049  closed by r.david.murray

#20052: input() crashes in 2.7.6
http://bugs.python.org/issue20052  closed by christian.heimes

#20054: IDLE won't work (Mac)
http://bugs.python.org/issue20054  closed by ned.deily

#20058: IDLE's shell returns a multiple-line string to input() or read
http://bugs.python.org/issue20058  closed by serhiy.storchaka

#20060: float() and int() TypeError messages differ
http://bugs.python.org/issue20060  closed by r.david.murray

#20063: Docs imply that set does not support .pop() method
http://bugs.python.org/issue20063  closed by r.david.murray

#20067: Tkinter variables no works with wantobject is false
http://bugs.python.org/issue20067  closed by serhiy.storchaka

#20070: test_urllib2net is run even when the network resource is disab
http://bugs.python.org/issue20070  closed by doko

#20073: IDLE crashes on Unicode characters
http://bugs.python.org/issue20073  closed by ned.deily

From ethan at stoneleaf.us  Sat Dec 28 01:53:33 2013
From: ethan at stoneleaf.us (Ethan Furman)
Date: Fri, 27 Dec 2013 16:53:33 -0800
Subject: [Python-Dev] assert(blah blah) in the C code base
Message-ID: <52BE210D.2000201@stoneleaf.us>

Greetings!

I'm working on Issue19995, and I'm seeing stuff like this:

   assert(PyLong_Check(val));

My question is:  Are these asserts in final production code?

My possible scenarios are:

   - the assert isn't in place
   - the assert isn't working correctly
   - PyLong_Check isn't working correctly
   - the non-ints are being converted before the function
     containing the assert is called

The fourth possibility is the most likely, but since I don't know how 
assert() works in C I can't be sure.

Any quick pointers?

--
~Ethan~

From eric at trueblade.com  Sat Dec 28 02:45:29 2013
From: eric at trueblade.com (Eric V. Smith)
Date: Fri, 27 Dec 2013 20:45:29 -0500
Subject: [Python-Dev] assert(blah blah) in the C code base
In-Reply-To: <52BE210D.2000201@stoneleaf.us>
References: <52BE210D.2000201@stoneleaf.us>
Message-ID: <52BE2D39.5070804@trueblade.com>

On 12/27/2013 7:53 PM, Ethan Furman wrote:
> Greetings!
> 
> I'm working on Issue19995, and I'm seeing stuff like this:
> 
>   assert(PyLong_Check(val));
> 
> My question is:  Are these asserts in final production code?
> 
> My possible scenarios are:
> 
>   - the assert isn't in place
>   - the assert isn't working correctly
>   - PyLong_Check isn't working correctly
>   - the non-ints are being converted before the function
>     containing the assert is called
> 
> The fourth possibility is the most likely, but since I don't know how
> assert() works in C I can't be sure.
> 
> Any quick pointers?

http://www.cplusplus.com/reference/cassert/assert/

They should be completely removed in a non-debug build (when NDEBUG is
defined).

Eric.



From benjamin at python.org  Sat Dec 28 02:53:08 2013
From: benjamin at python.org (Benjamin Peterson)
Date: Fri, 27 Dec 2013 19:53:08 -0600
Subject: [Python-Dev] assert(blah blah) in the C code base
In-Reply-To: <52BE210D.2000201@stoneleaf.us>
References: <52BE210D.2000201@stoneleaf.us>
Message-ID: <CAPZV6o_zLvrZqFS1_SLg_8Bhv-NqFr8swd4COqy9Z1kS5-40Mg@mail.gmail.com>

2013/12/27 Ethan Furman <ethan at stoneleaf.us>:
> Greetings!
>
> I'm working on Issue19995, and I'm seeing stuff like this:
>
>   assert(PyLong_Check(val));
>
> My question is:  Are these asserts in final production code?

They are compiled in when --with-pydebug is passed to configure. They
should "never" fail.

-- 
Regards,
Benjamin

From gennad.zlobin at gmail.com  Sat Dec 28 02:53:43 2013
From: gennad.zlobin at gmail.com (Gennadiy Zlobin)
Date: Sat, 28 Dec 2013 05:53:43 +0400
Subject: [Python-Dev] assert(blah blah) in the C code base
In-Reply-To: <52BE2D39.5070804@trueblade.com>
References: <52BE210D.2000201@stoneleaf.us> <52BE2D39.5070804@trueblade.com>
Message-ID: <CADdNHZB9i4bW6sKmybq6+hOe-o=Yp=NGWSeYUivBpVp-4QHbbg@mail.gmail.com>

Yes, looks like NDEBUG is not defined only when you run

./configure --with-pydebug



if test "$Py_DEBUG" = 'true'; then
  :
else
  OPT="-DNDEBUG $OPT"
fi



- Gennadiy <gennad.zlobin at gmail.com>


On Sat, Dec 28, 2013 at 5:45 AM, Eric V. Smith <eric at trueblade.com> wrote:

> On 12/27/2013 7:53 PM, Ethan Furman wrote:
> > Greetings!
> >
> > I'm working on Issue19995, and I'm seeing stuff like this:
> >
> >   assert(PyLong_Check(val));
> >
> > My question is:  Are these asserts in final production code?
> >
> > My possible scenarios are:
> >
> >   - the assert isn't in place
> >   - the assert isn't working correctly
> >   - PyLong_Check isn't working correctly
> >   - the non-ints are being converted before the function
> >     containing the assert is called
> >
> > The fourth possibility is the most likely, but since I don't know how
> > assert() works in C I can't be sure.
> >
> > Any quick pointers?
>
> http://www.cplusplus.com/reference/cassert/assert/
>
> They should be completely removed in a non-debug build (when NDEBUG is
> defined).
>
> Eric.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/gennad.zlobin%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131228/b8a19687/attachment.html>

From sim at linux.vnet.ibm.com  Sun Dec 29 14:09:56 2013
From: sim at linux.vnet.ibm.com (Narasimhan V)
Date: Sun, 29 Dec 2013 18:39:56 +0530
Subject: [Python-Dev] Request to release new version of python-defaults with
 ppc64le support
Message-ID: <1388322596.3743.4.camel@narasimhan-TP>

Hi,

I am working on a new architecture - ppc64le (powerpc 64-bit Little  
Endian) and I was building python-defaults. I  picked up the release
tarball from the following link 
(http://www.python.org/ftp/python/2.7.6/Python-2.7.6.tgz) and built on
our ppc64le environment and I find that package python-defaults failed
to build due to an outdated config.guess.

A fix for config.guess with ppc64le support is available at :
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD

Could you please spin a new version of python-defaults by using the
above mentioned config.guess.


Thanks,
Narasimhan V
IBM Linux Technology Centre.


From benjamin at python.org  Sun Dec 29 17:23:45 2013
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 29 Dec 2013 10:23:45 -0600
Subject: [Python-Dev] Request to release new version of python-defaults
 with ppc64le support
In-Reply-To: <1388322596.3743.4.camel@narasimhan-TP>
References: <1388322596.3743.4.camel@narasimhan-TP>
Message-ID: <CAPZV6o-KXWYsfO_=keGvifEyCw-nxv0SKvmj38vOHFU+LBvGjg@mail.gmail.com>

This is the wrong list for this. I suggest you contact the
Debian/Ubuntu maintainers.

2013/12/29 Narasimhan V <sim at linux.vnet.ibm.com>:
> Hi,
>
> I am working on a new architecture - ppc64le (powerpc 64-bit Little
> Endian) and I was building python-defaults. I  picked up the release
> tarball from the following link
> (http://www.python.org/ftp/python/2.7.6/Python-2.7.6.tgz) and built on
> our ppc64le environment and I find that package python-defaults failed
> to build due to an outdated config.guess.
>
> A fix for config.guess with ppc64le support is available at :
> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
>
> Could you please spin a new version of python-defaults by using the
> above mentioned config.guess.
>
>
> Thanks,
> Narasimhan V
> IBM Linux Technology Centre.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/benjamin%40python.org



-- 
Regards,
Benjamin

From rosuav at gmail.com  Mon Dec 30 14:05:18 2013
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 31 Dec 2013 00:05:18 +1100
Subject: [Python-Dev] Buildbot running Debian amd64 as root
In-Reply-To: <CAPTjJmpB7foyaQZMuOWPaxoLb96keTJsKta9qdiyK5hi-y+DqA@mail.gmail.com>
References: <CAPTjJmpB7foyaQZMuOWPaxoLb96keTJsKta9qdiyK5hi-y+DqA@mail.gmail.com>
Message-ID: <CAPTjJmrxrQ0gbYSBVJJz7znmU3h8zS5KsY-ZZqB=faPCcoxirA@mail.gmail.com>

On Sun, Dec 8, 2013 at 12:35 AM, Chris Angelico <rosuav at gmail.com> wrote:
> In another thread it was suggested that a new buildbot running as root
> would be of value. I've spun up a virtual machine running Debian
> Wheezy amd64, have installed buildbot from the repository (version
> 0.8.6p1), and am ready to have it join the farm. How do I go about
> doing this?

Is there any interest in this build slave? I haven't heard back from
anyone as to where to go from here.

ChrisA

From rosuav at gmail.com  Mon Dec 30 15:02:24 2013
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 31 Dec 2013 01:02:24 +1100
Subject: [Python-Dev] Buildbot running Debian amd64 as root
In-Reply-To: <CAPTjJmrxrQ0gbYSBVJJz7znmU3h8zS5KsY-ZZqB=faPCcoxirA@mail.gmail.com>
References: <CAPTjJmpB7foyaQZMuOWPaxoLb96keTJsKta9qdiyK5hi-y+DqA@mail.gmail.com>
 <CAPTjJmrxrQ0gbYSBVJJz7znmU3h8zS5KsY-ZZqB=faPCcoxirA@mail.gmail.com>
Message-ID: <CAPTjJmr9OBbm+TtAPS7W1KRneFgH_MJBJDqoN8eU8zPUo__RuA@mail.gmail.com>

On Tue, Dec 31, 2013 at 12:05 AM, Chris Angelico <rosuav at gmail.com> wrote:
> On Sun, Dec 8, 2013 at 12:35 AM, Chris Angelico <rosuav at gmail.com> wrote:
>> In another thread it was suggested that a new buildbot running as root
>> would be of value. I've spun up a virtual machine running Debian
>> Wheezy amd64, have installed buildbot from the repository (version
>> 0.8.6p1), and am ready to have it join the farm. How do I go about
>> doing this?
>
> Is there any interest in this build slave? I haven't heard back from
> anyone as to where to go from here.

Antoine's contacted me off-list and sorted out the details. Bruce the
Aussie Buildbot is now in operation. (And yes, the hostname is
'bruce'.)

Thanks Antoine!

ChrisA

From christian at python.org  Mon Dec 30 19:18:43 2013
From: christian at python.org (Christian Heimes)
Date: Mon, 30 Dec 2013 19:18:43 +0100
Subject: [Python-Dev] Buildbot running Debian amd64 as root
In-Reply-To: <CAPTjJmr9OBbm+TtAPS7W1KRneFgH_MJBJDqoN8eU8zPUo__RuA@mail.gmail.com>
References: <CAPTjJmpB7foyaQZMuOWPaxoLb96keTJsKta9qdiyK5hi-y+DqA@mail.gmail.com>
 <CAPTjJmrxrQ0gbYSBVJJz7znmU3h8zS5KsY-ZZqB=faPCcoxirA@mail.gmail.com>
 <CAPTjJmr9OBbm+TtAPS7W1KRneFgH_MJBJDqoN8eU8zPUo__RuA@mail.gmail.com>
Message-ID: <l9sddn$lvg$1@ger.gmane.org>

Am 30.12.2013 15:02, schrieb Chris Angelico:
> On Tue, Dec 31, 2013 at 12:05 AM, Chris Angelico <rosuav at gmail.com> wrote:
>> On Sun, Dec 8, 2013 at 12:35 AM, Chris Angelico <rosuav at gmail.com> wrote:
>>> In another thread it was suggested that a new buildbot running as root
>>> would be of value. I've spun up a virtual machine running Debian
>>> Wheezy amd64, have installed buildbot from the repository (version
>>> 0.8.6p1), and am ready to have it join the farm. How do I go about
>>> doing this?
>>
>> Is there any interest in this build slave? I haven't heard back from
>> anyone as to where to go from here.
> 
> Antoine's contacted me off-list and sorted out the details. Bruce the
> Aussie Buildbot is now in operation. (And yes, the hostname is
> 'bruce'.)
> 
> Thanks Antoine!

Thanks guys!

The buildbot is missing some vital header files. Please run:

  # apt-get build-dep python3.3

to install all required dependencies.

Christian


From zachary.ware+pydev at gmail.com  Mon Dec 30 21:31:07 2013
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Mon, 30 Dec 2013 14:31:07 -0600
Subject: [Python-Dev] Buildbot running Debian amd64 as root
In-Reply-To: <l9sddn$lvg$1@ger.gmane.org>
References: <CAPTjJmpB7foyaQZMuOWPaxoLb96keTJsKta9qdiyK5hi-y+DqA@mail.gmail.com>
 <CAPTjJmrxrQ0gbYSBVJJz7znmU3h8zS5KsY-ZZqB=faPCcoxirA@mail.gmail.com>
 <CAPTjJmr9OBbm+TtAPS7W1KRneFgH_MJBJDqoN8eU8zPUo__RuA@mail.gmail.com>
 <l9sddn$lvg$1@ger.gmane.org>
Message-ID: <CAKJDb-N_Na4D7gtF_aKKSJS5yK3DYyQyu2q5gaLmaVbq31zmAw@mail.gmail.com>

On Mon, Dec 30, 2013 at 12:18 PM, Christian Heimes <christian at python.org> wrote:
> Am 30.12.2013 15:02, schrieb Chris Angelico:
>> On Tue, Dec 31, 2013 at 12:05 AM, Chris Angelico <rosuav at gmail.com> wrote:
>>> On Sun, Dec 8, 2013 at 12:35 AM, Chris Angelico <rosuav at gmail.com> wrote:
>>>> In another thread it was suggested that a new buildbot running as root
>>>> would be of value. I've spun up a virtual machine running Debian
>>>> Wheezy amd64, have installed buildbot from the repository (version
>>>> 0.8.6p1), and am ready to have it join the farm. How do I go about
>>>> doing this?
>>>
>>> Is there any interest in this build slave? I haven't heard back from
>>> anyone as to where to go from here.
>>
>> Antoine's contacted me off-list and sorted out the details. Bruce the
>> Aussie Buildbot is now in operation. (And yes, the hostname is
>> 'bruce'.)
>>
>> Thanks Antoine!
>
> Thanks guys!
>
> The buildbot is missing some vital header files. Please run:
>
>   # apt-get build-dep python3.3
>
> to install all required dependencies.

It looks like it compiled and ran the tests fine, except for two
failures due to a lack of zlib.  If zlib is a required dependency, the
build process should die without it (or fall back to the version
living in Modules/zlib), and needs to be fixed.  If it is as optional
as it seems to look, then it might be good to keep a buildbot that
explicitly doesn't have all (or even any) of the optional dependencies
and we should just fix the tests that expect zlib unconditionally.
Perhaps not this buildbot, though, since it's the only one running as
root.

Either way, this buildbot's first and thus far only run has already
shown up something that needs to be fixed ;)

-- 
Zach

From zachary.ware+pydev at gmail.com  Mon Dec 30 22:00:02 2013
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Mon, 30 Dec 2013 15:00:02 -0600
Subject: [Python-Dev] Buildbot running Debian amd64 as root
In-Reply-To: <CAKJDb-N_Na4D7gtF_aKKSJS5yK3DYyQyu2q5gaLmaVbq31zmAw@mail.gmail.com>
References: <CAPTjJmpB7foyaQZMuOWPaxoLb96keTJsKta9qdiyK5hi-y+DqA@mail.gmail.com>
 <CAPTjJmrxrQ0gbYSBVJJz7znmU3h8zS5KsY-ZZqB=faPCcoxirA@mail.gmail.com>
 <CAPTjJmr9OBbm+TtAPS7W1KRneFgH_MJBJDqoN8eU8zPUo__RuA@mail.gmail.com>
 <l9sddn$lvg$1@ger.gmane.org>
 <CAKJDb-N_Na4D7gtF_aKKSJS5yK3DYyQyu2q5gaLmaVbq31zmAw@mail.gmail.com>
Message-ID: <CAKJDb-PpNswg3SmJ7pDU-46m2KnM29ZJgQjv-sErh-tZyr3x8w@mail.gmail.com>

On Mon, Dec 30, 2013 at 2:31 PM, Zachary Ware
<zachary.ware+pydev at gmail.com> wrote:
> and we should just fix the tests that expect zlib unconditionally.

Both of which turned out to be trivial; the import of zlib was already
guarded in both places, but one skip was checking the wrong name and
the other just didn't try to skip, so I've fixed both.

-- 
Zach

From rdmurray at bitdance.com  Mon Dec 30 22:30:17 2013
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 30 Dec 2013 16:30:17 -0500
Subject: [Python-Dev] Buildbot running Debian amd64 as root
In-Reply-To: <CAKJDb-PpNswg3SmJ7pDU-46m2KnM29ZJgQjv-sErh-tZyr3x8w@mail.gmail.com>
References: <CAPTjJmpB7foyaQZMuOWPaxoLb96keTJsKta9qdiyK5hi-y+DqA@mail.gmail.com>
 <CAPTjJmrxrQ0gbYSBVJJz7znmU3h8zS5KsY-ZZqB=faPCcoxirA@mail.gmail.com>
 <CAPTjJmr9OBbm+TtAPS7W1KRneFgH_MJBJDqoN8eU8zPUo__RuA@mail.gmail.com>
 <l9sddn$lvg$1@ger.gmane.org>
 <CAKJDb-N_Na4D7gtF_aKKSJS5yK3DYyQyu2q5gaLmaVbq31zmAw@mail.gmail.com>
 <CAKJDb-PpNswg3SmJ7pDU-46m2KnM29ZJgQjv-sErh-tZyr3x8w@mail.gmail.com>
Message-ID: <20131230213018.5F1C025016A@webabinitio.net>

On Mon, 30 Dec 2013 15:00:02 -0600, Zachary Ware <zachary.ware+pydev at gmail.com> wrote:
> On Mon, Dec 30, 2013 at 2:31 PM, Zachary Ware
> <zachary.ware+pydev at gmail.com> wrote:
> > and we should just fix the tests that expect zlib unconditionally.
> 
> Both of which turned out to be trivial; the import of zlib was already
> guarded in both places, but one skip was checking the wrong name and
> the other just didn't try to skip, so I've fixed both.

We've gone through spates before of fixing the tests that rely on various
optional modules (especially zlib).  Yeah, having a buildbot configured
without all the optional modules would be nice.

--David

From rosuav at gmail.com  Tue Dec 31 00:31:32 2013
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 31 Dec 2013 10:31:32 +1100
Subject: [Python-Dev] Buildbot running Debian amd64 as root
In-Reply-To: <l9sddn$lvg$1@ger.gmane.org>
References: <CAPTjJmpB7foyaQZMuOWPaxoLb96keTJsKta9qdiyK5hi-y+DqA@mail.gmail.com>
 <CAPTjJmrxrQ0gbYSBVJJz7znmU3h8zS5KsY-ZZqB=faPCcoxirA@mail.gmail.com>
 <CAPTjJmr9OBbm+TtAPS7W1KRneFgH_MJBJDqoN8eU8zPUo__RuA@mail.gmail.com>
 <l9sddn$lvg$1@ger.gmane.org>
Message-ID: <CAPTjJmqXKW+a1JTODn6ijPkhoc=JJZaqYNnixgtMQLU-DDPPxw@mail.gmail.com>

On Tue, Dec 31, 2013 at 5:18 AM, Christian Heimes <christian at python.org> wrote:
> The buildbot is missing some vital header files. Please run:
>
>   # apt-get build-dep python3.3
>
> to install all required dependencies.

Debian Wheezy doesn't package 3.3 but only 3.2, so I grabbed 3.2's
build-deps. They're now installed, so the next build should have
everything for that. Does anyone happen to know what (if anything) 3.3
needs that 3.2 doesn't?

I hit Force Build on the 3.3 one, so hopefully that'll show up. It's
busily checking out now.

ChrisA

From rosuav at gmail.com  Tue Dec 31 01:24:26 2013
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 31 Dec 2013 11:24:26 +1100
Subject: [Python-Dev] Buildbot - "slave lost"
Message-ID: <CAPTjJmqvPEE_86ab4OeNFz1gDcZZrgpq5qE3sVQ4_MjKYMgw9A@mail.gmail.com>

Does Buildbot retain a constant TCP socket to its server? I'm seeing this:

http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.3/builds/0

"""

Results:

Retry exception slave lost

"""

I have two internet connections; one is faster, but tends to drop
socket connections after a few hours, and the other is a bit slower
but more reliable (as long as the connection doesn't go idle for too
long - neither of my upstreams is particularly MUD-friendly). Would it
help to set a routing rule to send traffic to python.org:9020 via the
connection that won't drop out?

ChrisA

From solipsis at pitrou.net  Tue Dec 31 01:42:59 2013
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 31 Dec 2013 01:42:59 +0100
Subject: [Python-Dev] Buildbot - "slave lost"
References: <CAPTjJmqvPEE_86ab4OeNFz1gDcZZrgpq5qE3sVQ4_MjKYMgw9A@mail.gmail.com>
Message-ID: <20131231014259.073fb7f2@fsol>

On Tue, 31 Dec 2013 11:24:26 +1100
Chris Angelico <rosuav at gmail.com> wrote:
> Does Buildbot retain a constant TCP socket to its server? I'm seeing this:
> 
> http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.3/builds/0

I'm quite sure it does. It's necessary to get a real-time view of the
test log.

> Would it
> help to set a routing rule to send traffic to python.org:9020 via the
> connection that won't drop out?

The only way to know is to try it out :)

Regards

Antoine.



From rosuav at gmail.com  Tue Dec 31 01:46:49 2013
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 31 Dec 2013 11:46:49 +1100
Subject: [Python-Dev] Buildbot - "slave lost"
In-Reply-To: <20131231014259.073fb7f2@fsol>
References: <CAPTjJmqvPEE_86ab4OeNFz1gDcZZrgpq5qE3sVQ4_MjKYMgw9A@mail.gmail.com>
 <20131231014259.073fb7f2@fsol>
Message-ID: <CAPTjJmr=_P=0-KYC=jRchTKoP2Aibbiz5TrO1mddJin8s-dkcA@mail.gmail.com>

On Tue, Dec 31, 2013 at 11:42 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Tue, 31 Dec 2013 11:24:26 +1100
> Chris Angelico <rosuav at gmail.com> wrote:
>> Does Buildbot retain a constant TCP socket to its server? I'm seeing this:
>>
>> http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.3/builds/0
>
> I'm quite sure it does. It's necessary to get a real-time view of the
> test log.
>
>> Would it
>> help to set a routing rule to send traffic to python.org:9020 via the
>> connection that won't drop out?
>
> The only way to know is to try it out :)

If that's what it does, then it almost certainly will help. I put all
my MUD connections through the other connection. The change is made,
I'll trigger another build and see if it works.

Thanks for the help!

ChrisA

From zachary.ware+pydev at gmail.com  Tue Dec 31 02:35:00 2013
From: zachary.ware+pydev at gmail.com (Zach Ware)
Date: Mon, 30 Dec 2013 19:35:00 -0600
Subject: [Python-Dev] Buildbot running Debian amd64 as root
In-Reply-To: <CAPTjJmqXKW+a1JTODn6ijPkhoc=JJZaqYNnixgtMQLU-DDPPxw@mail.gmail.com>
References: <CAPTjJmpB7foyaQZMuOWPaxoLb96keTJsKta9qdiyK5hi-y+DqA@mail.gmail.com>
 <CAPTjJmrxrQ0gbYSBVJJz7znmU3h8zS5KsY-ZZqB=faPCcoxirA@mail.gmail.com>
 <CAPTjJmr9OBbm+TtAPS7W1KRneFgH_MJBJDqoN8eU8zPUo__RuA@mail.gmail.com>
 <l9sddn$lvg$1@ger.gmane.org>
 <CAPTjJmqXKW+a1JTODn6ijPkhoc=JJZaqYNnixgtMQLU-DDPPxw@mail.gmail.com>
Message-ID: <03993a7a-3e53-4fb2-8cb9-b2b88868fec7@email.android.com>



Chris Angelico <rosuav at gmail.com> wrote:
>On Tue, Dec 31, 2013 at 5:18 AM, Christian Heimes
><christian at python.org> wrote:
>> The buildbot is missing some vital header files. Please run:
>>
>>   # apt-get build-dep python3.3
>>
>> to install all required dependencies.
>
>Debian Wheezy doesn't package 3.3 but only 3.2, so I grabbed 3.2's
>build-deps. They're now installed, so the next build should have
>everything for that. Does anyone happen to know what (if anything) 3.3
>needs that 3.2 doesn't?

You'll need sources for lzma, but I think that should be it.

From rosuav at gmail.com  Tue Dec 31 02:37:01 2013
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 31 Dec 2013 12:37:01 +1100
Subject: [Python-Dev] Buildbot running Debian amd64 as root
In-Reply-To: <03993a7a-3e53-4fb2-8cb9-b2b88868fec7@email.android.com>
References: <CAPTjJmpB7foyaQZMuOWPaxoLb96keTJsKta9qdiyK5hi-y+DqA@mail.gmail.com>
 <CAPTjJmrxrQ0gbYSBVJJz7znmU3h8zS5KsY-ZZqB=faPCcoxirA@mail.gmail.com>
 <CAPTjJmr9OBbm+TtAPS7W1KRneFgH_MJBJDqoN8eU8zPUo__RuA@mail.gmail.com>
 <l9sddn$lvg$1@ger.gmane.org>
 <CAPTjJmqXKW+a1JTODn6ijPkhoc=JJZaqYNnixgtMQLU-DDPPxw@mail.gmail.com>
 <03993a7a-3e53-4fb2-8cb9-b2b88868fec7@email.android.com>
Message-ID: <CAPTjJmp-dZxvra09udz-6p9RGfoTjTJ_FyQuYBsDMhAe+NFKUg@mail.gmail.com>

On Tue, Dec 31, 2013 at 12:35 PM, Zach Ware
<zachary.ware+pydev at gmail.com> wrote:
>>Debian Wheezy doesn't package 3.3 but only 3.2, so I grabbed 3.2's
>>build-deps. They're now installed, so the next build should have
>>everything for that. Does anyone happen to know what (if anything) 3.3
>>needs that 3.2 doesn't?
>
> You'll need sources for lzma, but I think that should be it.

Done, lzma-dev installed. Thanks.

ChrisA

From drsalists at gmail.com  Tue Dec 31 06:31:14 2013
From: drsalists at gmail.com (Dan Stromberg)
Date: Mon, 30 Dec 2013 21:31:14 -0800
Subject: [Python-Dev] Fwd: Python 2.x and 3.x usage survey
In-Reply-To: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
References: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
Message-ID: <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>

So far the results are looking good for 3.x.

---------- Forwarded message ----------
From: Dan Stromberg <drsalists at gmail.com>
Date: Mon, Dec 30, 2013 at 1:56 PM
Subject: Python 2.x and 3.x usage survey
To: Python List <python-list at python.org>


I keep hearing naysayers, nay saying about Python 3.x.

Here's a 9 question, multiple choice survey I put together about
Python 2.x use vs Python 3.x use.

I'd be very pleased if you could take 5 or 10 minutes to fill it out.

Here's the URL:
https://www.surveymonkey.com/s/N5N5PG2

From tim.peters at gmail.com  Tue Dec 31 07:12:44 2013
From: tim.peters at gmail.com (Tim Peters)
Date: Tue, 31 Dec 2013 00:12:44 -0600
Subject: [Python-Dev] Fwd: Python 2.x and 3.x usage survey
In-Reply-To: <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
References: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
 <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
Message-ID: <CAExdVNmCC-C+rx5cyDODECHNnnHwDpSdAybamKzVF1TwUf=7Wg@mail.gmail.com>

[Dan Stromberg]
> I keep hearing naysayers, nay saying about Python 3.x.
>
> Here's a 9 question, multiple choice survey I put together about
> Python 2.x use vs Python 3.x use.
>
> I'd be very pleased if you could take 5 or 10 minutes to fill it out.

If you run Python 3 while filling out the survey, like I did, it takes
less than 1 minute to complete.  This may be surprising, since people
usually say Python 3 is slower than Python 2.  Those must people who
don't fill out surveys ;-)


> Here's the URL:
> https://www.surveymonkey.com/s/N5N5PG2

From regebro at gmail.com  Tue Dec 31 08:16:33 2013
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 31 Dec 2013 08:16:33 +0100
Subject: [Python-Dev] Fwd: Python 2.x and 3.x usage survey
In-Reply-To: <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
References: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
 <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
Message-ID: <CAL0kPAXz+ni-wgn9M=HS5boO6PTFxxe_dudrYtymxTgMVts_Jw@mail.gmail.com>

On Tue, Dec 31, 2013 at 6:31 AM, Dan Stromberg <drsalists at gmail.com> wrote:
> So far the results are looking good for 3.x.

Python-dev probably is a bit special.

//Lennart

From p.f.moore at gmail.com  Tue Dec 31 10:50:06 2013
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 31 Dec 2013 09:50:06 +0000
Subject: [Python-Dev] Fwd: Python 2.x and 3.x usage survey
In-Reply-To: <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
References: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
 <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
Message-ID: <CACac1F-has6+dJoneAy-xjYisdpTVnrv5MhMeEteVZwRMnf0-A@mail.gmail.com>

On 31 December 2013 05:31, Dan Stromberg <drsalists at gmail.com> wrote:
> So far the results are looking good for 3.x.

Where can the results be seen?
Paul

From steve at pearwood.info  Tue Dec 31 11:04:08 2013
From: steve at pearwood.info (Steven D'Aprano)
Date: Tue, 31 Dec 2013 21:04:08 +1100
Subject: [Python-Dev] Fwd: Python 2.x and 3.x usage survey
In-Reply-To: <CAL0kPAXz+ni-wgn9M=HS5boO6PTFxxe_dudrYtymxTgMVts_Jw@mail.gmail.com>
References: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
 <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
 <CAL0kPAXz+ni-wgn9M=HS5boO6PTFxxe_dudrYtymxTgMVts_Jw@mail.gmail.com>
Message-ID: <20131231100407.GH29356@ando>

On Tue, Dec 31, 2013 at 08:16:33AM +0100, Lennart Regebro wrote:
> On Tue, Dec 31, 2013 at 6:31 AM, Dan Stromberg <drsalists at gmail.com> wrote:
> > So far the results are looking good for 3.x.
> 
> Python-dev probably is a bit special.

Why? Most Python-Dev people have day jobs, and the version of Python 
that they use in their day job is subject to exactly the same outside 
pressures as everyone else ("RedHat ships with Python 2.6, so that's the 
version we're using").



-- 
Steven

From martin at v.loewis.de  Tue Dec 31 11:34:49 2013
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 31 Dec 2013 11:34:49 +0100
Subject: [Python-Dev] Fwd: Python 2.x and 3.x usage survey
In-Reply-To: <CAExdVNmCC-C+rx5cyDODECHNnnHwDpSdAybamKzVF1TwUf=7Wg@mail.gmail.com>
References: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
 <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
 <CAExdVNmCC-C+rx5cyDODECHNnnHwDpSdAybamKzVF1TwUf=7Wg@mail.gmail.com>
Message-ID: <52C29DC9.1070308@v.loewis.de>

Am 31.12.13 07:12, schrieb Tim Peters:
> [Dan Stromberg]
>> I keep hearing naysayers, nay saying about Python 3.x.
>>
>> Here's a 9 question, multiple choice survey I put together about
>> Python 2.x use vs Python 3.x use.
>>
>> I'd be very pleased if you could take 5 or 10 minutes to fill it out.
> 
> If you run Python 3 while filling out the survey, like I did, it takes
> less than 1 minute to complete.  This may be surprising, since people
> usually say Python 3 is slower than Python 2.  Those must people who
> don't fill out surveys ;-)

So for the Python 4 survey, I propose to have just a single question:

* Have you heard of Python 4?

That will prove that Python 4 is even faster than Python 3 :-)
Of course, that is also because it has a JIT compiler, and runs
on 16 cores with no GIL.

Regards,
Martin


From martin at v.loewis.de  Tue Dec 31 11:43:56 2013
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 31 Dec 2013 11:43:56 +0100
Subject: [Python-Dev] Fwd: Python 2.x and 3.x usage survey
In-Reply-To: <20131231100407.GH29356@ando>
References: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
 <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
 <CAL0kPAXz+ni-wgn9M=HS5boO6PTFxxe_dudrYtymxTgMVts_Jw@mail.gmail.com>
 <20131231100407.GH29356@ando>
Message-ID: <52C29FEC.7070505@v.loewis.de>

Am 31.12.13 11:04, schrieb Steven D'Aprano:
> On Tue, Dec 31, 2013 at 08:16:33AM +0100, Lennart Regebro wrote:
>> On Tue, Dec 31, 2013 at 6:31 AM, Dan Stromberg <drsalists at gmail.com> wrote:
>>> So far the results are looking good for 3.x.
>>
>> Python-dev probably is a bit special.
> 
> Why? Most Python-Dev people have day jobs, and the version of Python 
> that they use in their day job is subject to exactly the same outside 
> pressures as everyone else ("RedHat ships with Python 2.6, so that's the 
> version we're using").

Yes and no. I answered "more 2.x" to that question because my current
projects have dependencies (Twisted in particular); however, I also
answered that I ported code - which actually wasn't my own, and I ported
it only to promote Python 3.

Regards,
Martin



From regebro at gmail.com  Tue Dec 31 13:12:59 2013
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 31 Dec 2013 13:12:59 +0100
Subject: [Python-Dev] Fwd: Python 2.x and 3.x usage survey
In-Reply-To: <20131231100407.GH29356@ando>
References: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
 <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
 <CAL0kPAXz+ni-wgn9M=HS5boO6PTFxxe_dudrYtymxTgMVts_Jw@mail.gmail.com>
 <20131231100407.GH29356@ando>
Message-ID: <CAL0kPAX2BC62RZgwANPtmg94hojSggJojn7FAtN58HHQCa0K9g@mail.gmail.com>

Yeah, but I'd still expect more people on Python-dev to at least have
used Python 3 and possibly be maintainers of libraries that have been
ported to Python 3 etc.

On Tue, Dec 31, 2013 at 11:04 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Tue, Dec 31, 2013 at 08:16:33AM +0100, Lennart Regebro wrote:
>> On Tue, Dec 31, 2013 at 6:31 AM, Dan Stromberg <drsalists at gmail.com> wrote:
>> > So far the results are looking good for 3.x.
>>
>> Python-dev probably is a bit special.
>
> Why? Most Python-Dev people have day jobs, and the version of Python
> that they use in their day job is subject to exactly the same outside
> pressures as everyone else ("RedHat ships with Python 2.6, so that's the
> version we're using").
>
>
>
> --
> Steven
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/regebro%40gmail.com

From ncoghlan at gmail.com  Tue Dec 31 13:13:53 2013
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 31 Dec 2013 22:13:53 +1000
Subject: [Python-Dev] Fwd: Python 2.x and 3.x usage survey
In-Reply-To: <20131231100407.GH29356@ando>
References: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
 <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
 <CAL0kPAXz+ni-wgn9M=HS5boO6PTFxxe_dudrYtymxTgMVts_Jw@mail.gmail.com>
 <20131231100407.GH29356@ando>
Message-ID: <CADiSq7cbwZkjAj0Mp1tN47mCgi414ggUvyCq0FJGN9=h-V=GTw@mail.gmail.com>

On 31 December 2013 20:04, Steven D'Aprano <steve at pearwood.info> wrote:
> On Tue, Dec 31, 2013 at 08:16:33AM +0100, Lennart Regebro wrote:
>> On Tue, Dec 31, 2013 at 6:31 AM, Dan Stromberg <drsalists at gmail.com> wrote:
>> > So far the results are looking good for 3.x.
>>
>> Python-dev probably is a bit special.
>
> Why? Most Python-Dev people have day jobs, and the version of Python
> that they use in their day job is subject to exactly the same outside
> pressures as everyone else ("RedHat ships with Python 2.6, so that's the
> version we're using").

Or moreso in some cases *cough* ;)

Cheers,
Nick.

P.S. We're actively working on eliminating that particular rationale.
While some of the key elements have already been released, there's
still more work to be done :)

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ron3200 at gmail.com  Tue Dec 31 17:55:32 2013
From: ron3200 at gmail.com (Ron Adam)
Date: Tue, 31 Dec 2013 10:55:32 -0600
Subject: [Python-Dev] Fwd: Python 2.x and 3.x usage survey
In-Reply-To: <52C29DC9.1070308@v.loewis.de>
References: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
 <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
 <CAExdVNmCC-C+rx5cyDODECHNnnHwDpSdAybamKzVF1TwUf=7Wg@mail.gmail.com>
 <52C29DC9.1070308@v.loewis.de>
Message-ID: <l9ustp$f7h$1@ger.gmane.org>



On 12/31/2013 04:34 AM, "Martin v. L?wis" wrote:
> So for the Python 4 survey, I propose to have just a single question:
>
> * Have you heard of Python 4?
>
> That will prove that Python 4 is even faster than Python 3:-)
> Of course, that is also because it has a JIT compiler, and runs
> on 16 cores with no GIL.

If the question is...

    * What is Python 4?

I think you get much more interesting answers.  ;-)

Cheers,
    Ron



From chris.barker at noaa.gov  Tue Dec 31 18:33:21 2013
From: chris.barker at noaa.gov (Chris Barker)
Date: Tue, 31 Dec 2013 09:33:21 -0800
Subject: [Python-Dev] Fwd: Python 2.x and 3.x usage survey
In-Reply-To: <CAL0kPAXz+ni-wgn9M=HS5boO6PTFxxe_dudrYtymxTgMVts_Jw@mail.gmail.com>
References: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
 <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
 <CAL0kPAXz+ni-wgn9M=HS5boO6PTFxxe_dudrYtymxTgMVts_Jw@mail.gmail.com>
Message-ID: <CALGmxEJSOa+mcmCx8djHS2TfFjLCN0owcXF+puEcjvajgACW8g@mail.gmail.com>

On Mon, Dec 30, 2013 at 11:16 PM, Lennart Regebro <regebro at gmail.com> wrote:

> Python-dev probably is a bit special.
>
>
Indeed -- I expect it to be totally non-representative of the broader
Python community.

Everyone on python-dev is at least interested in the process of moving
Python forward.

And Py2 is frozen, so there really is no reason to be on this list if
you primarily care about Python2.

There are an enormous number of people that use pyton to simply get work
done, and many, many, of those are still using only 2, if only because of
inertia.

It might be interesting to toss that survey out into the wild more and see
what happens...

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131231/357b4030/attachment.html>

From stephen at xemacs.org  Tue Dec 31 18:40:13 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 01 Jan 2014 02:40:13 +0900
Subject: [Python-Dev] Fwd: Python 2.x and 3.x usage survey
In-Reply-To: <l9ustp$f7h$1@ger.gmane.org>
References: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
 <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
 <CAExdVNmCC-C+rx5cyDODECHNnnHwDpSdAybamKzVF1TwUf=7Wg@mail.gmail.com>
 <52C29DC9.1070308@v.loewis.de> <l9ustp$f7h$1@ger.gmane.org>
Message-ID: <87vby4kjgi.fsf@uwakimon.sk.tsukuba.ac.jp>

Ron Adam writes:

 >     * What is Python 4?

"Due in 2025" (the next Year of the Snake).

Happy New Year to all and best wishes for 2014!


From solipsis at pitrou.net  Tue Dec 31 19:00:28 2013
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 31 Dec 2013 19:00:28 +0100
Subject: [Python-Dev] Python 2.x and 3.x usage survey
References: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
 <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
 <CAL0kPAXz+ni-wgn9M=HS5boO6PTFxxe_dudrYtymxTgMVts_Jw@mail.gmail.com>
 <CALGmxEJSOa+mcmCx8djHS2TfFjLCN0owcXF+puEcjvajgACW8g@mail.gmail.com>
Message-ID: <20131231190028.3e93769d@fsol>

On Tue, 31 Dec 2013 09:33:21 -0800
Chris Barker <chris.barker at noaa.gov> wrote:
> 
> It might be interesting to toss that survey out into the wild more and see
> what happens...

It's already been tossed in the wild, since the message originally was
posted on python-list.
Feel free to spread the URL a bit more.

Regards

Antoine.



From francismb at email.de  Tue Dec 31 19:08:27 2013
From: francismb at email.de (francis)
Date: Tue, 31 Dec 2013 19:08:27 +0100
Subject: [Python-Dev] Fwd: Python 2.x and 3.x usage survey
In-Reply-To: <CALGmxEJSOa+mcmCx8djHS2TfFjLCN0owcXF+puEcjvajgACW8g@mail.gmail.com>
References: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
 <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
 <CAL0kPAXz+ni-wgn9M=HS5boO6PTFxxe_dudrYtymxTgMVts_Jw@mail.gmail.com>
 <CALGmxEJSOa+mcmCx8djHS2TfFjLCN0owcXF+puEcjvajgACW8g@mail.gmail.com>
Message-ID: <52C3081B.1050205@email.de>


>
> There are an enormous number of people that use pyton to simply get 
> work done, and many, many, of those are still using only 2, if only 
> because of inertia.
>

I agree, but I expected the question:

?Do you plan to write/port some of you Python 2.x code to Python 3.x 
next year? (at work)

Regards,
francis




From drsalists at gmail.com  Tue Dec 31 19:13:29 2013
From: drsalists at gmail.com (Dan Stromberg)
Date: Tue, 31 Dec 2013 10:13:29 -0800
Subject: [Python-Dev] Fwd: Python 2.x and 3.x usage survey
In-Reply-To: <CACac1F-has6+dJoneAy-xjYisdpTVnrv5MhMeEteVZwRMnf0-A@mail.gmail.com>
References: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
 <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
 <CACac1F-has6+dJoneAy-xjYisdpTVnrv5MhMeEteVZwRMnf0-A@mail.gmail.com>
Message-ID: <CAGGBd_rAfG_+HfPSqLd8Lu-cJVkQxy+iMkWNb-csSOX=ahhuQQ@mail.gmail.com>

On Tue, Dec 31, 2013 at 1:50 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 31 December 2013 05:31, Dan Stromberg <drsalists at gmail.com> wrote:
>> So far the results are looking good for 3.x.
>
> Where can the results be seen?

I don't think there's a publicly-available results page yet.  I'll
summarize them after more people have had a chance to fill it out.

I'm trying to get it onto planet python - that should help.  But I
created the blog post without a Python label initially, and added it
afterward - not sure if that'll work or not.

From janzert at janzert.com  Tue Dec 31 21:05:36 2013
From: janzert at janzert.com (Janzert)
Date: Tue, 31 Dec 2013 15:05:36 -0500
Subject: [Python-Dev] Fwd: Python 2.x and 3.x usage survey
In-Reply-To: <CAGGBd_rAfG_+HfPSqLd8Lu-cJVkQxy+iMkWNb-csSOX=ahhuQQ@mail.gmail.com>
References: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
 <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
 <CACac1F-has6+dJoneAy-xjYisdpTVnrv5MhMeEteVZwRMnf0-A@mail.gmail.com>
 <CAGGBd_rAfG_+HfPSqLd8Lu-cJVkQxy+iMkWNb-csSOX=ahhuQQ@mail.gmail.com>
Message-ID: <l9v82d$uim$1@ger.gmane.org>

On 12/31/2013 1:13 PM, Dan Stromberg wrote:
> On Tue, Dec 31, 2013 at 1:50 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>> On 31 December 2013 05:31, Dan Stromberg <drsalists at gmail.com> wrote:
>>> So far the results are looking good for 3.x.
>>
>> Where can the results be seen?
>
> I don't think there's a publicly-available results page yet.  I'll
> summarize them after more people have had a chance to fill it out.
>
> I'm trying to get it onto planet python - that should help.  But I
> created the blog post without a Python label initially, and added it
> afterward - not sure if that'll work or not.
>

I submitted it to hacker news[1] and it has been sitting around #5 on 
the front page for about 3 hours now. That should've helped broaden the 
responses a bit.

Janzert

1. https://news.ycombinator.com/item?id=6990481


From gokoproject at gmail.com  Tue Dec 31 20:54:21 2013
From: gokoproject at gmail.com (John Wong)
Date: Tue, 31 Dec 2013 14:54:21 -0500
Subject: [Python-Dev] Fwd: Python 2.x and 3.x usage survey
In-Reply-To: <CAGGBd_rAfG_+HfPSqLd8Lu-cJVkQxy+iMkWNb-csSOX=ahhuQQ@mail.gmail.com>
References: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
 <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
 <CACac1F-has6+dJoneAy-xjYisdpTVnrv5MhMeEteVZwRMnf0-A@mail.gmail.com>
 <CAGGBd_rAfG_+HfPSqLd8Lu-cJVkQxy+iMkWNb-csSOX=ahhuQQ@mail.gmail.com>
Message-ID: <CACCLA54Jcm4ZnbRFqWSz5hoxNjg9kwGUCh4kusv29TfYOgJ-vw@mail.gmail.com>

Hackernews is a good place to start.
https://news.ycombinator.com/item?id=6992482


On Tue, Dec 31, 2013 at 1:13 PM, Dan Stromberg <drsalists at gmail.com> wrote:

> On Tue, Dec 31, 2013 at 1:50 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> > On 31 December 2013 05:31, Dan Stromberg <drsalists at gmail.com> wrote:
> >> So far the results are looking good for 3.x.
> >
> > Where can the results be seen?
>
> I don't think there's a publicly-available results page yet.  I'll
> summarize them after more people have had a chance to fill it out.
>
> I'm trying to get it onto planet python - that should help.  But I
> created the blog post without a Python label initially, and added it
> afterward - not sure if that'll work or not.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/gokoproject%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131231/71251f01/attachment.html>

From gokoproject at gmail.com  Tue Dec 31 21:07:32 2013
From: gokoproject at gmail.com (John Wong)
Date: Tue, 31 Dec 2013 15:07:32 -0500
Subject: [Python-Dev] Fwd: Python 2.x and 3.x usage survey
In-Reply-To: <l9v82d$uim$1@ger.gmane.org>
References: <CAGGBd_rC3GMGhS8yJFNEQNC8PK6=NBbzUx7t1BREur+Z7b40Ww@mail.gmail.com>
 <CAGGBd_qU0pOsyVvtXQfUiwEs1AddwfDAOV2o=5oByVZN3FFzcA@mail.gmail.com>
 <CACac1F-has6+dJoneAy-xjYisdpTVnrv5MhMeEteVZwRMnf0-A@mail.gmail.com>
 <CAGGBd_rAfG_+HfPSqLd8Lu-cJVkQxy+iMkWNb-csSOX=ahhuQQ@mail.gmail.com>
 <l9v82d$uim$1@ger.gmane.org>
Message-ID: <CACCLA562iPBfhgzDQiuXm1SCeNEhA3H2Vnx1Hq-hoS--TgJrFw@mail.gmail.com>

Ah interesting. I just saw that in my newsfeed. Thanks. Deleted mine! Yeah
there is certain hours that can make a post popular :)


On Tue, Dec 31, 2013 at 3:05 PM, Janzert <janzert at janzert.com> wrote:

> On 12/31/2013 1:13 PM, Dan Stromberg wrote:
>
>> On Tue, Dec 31, 2013 at 1:50 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>>
>>> On 31 December 2013 05:31, Dan Stromberg <drsalists at gmail.com> wrote:
>>>
>>>> So far the results are looking good for 3.x.
>>>>
>>>
>>> Where can the results be seen?
>>>
>>
>> I don't think there's a publicly-available results page yet.  I'll
>> summarize them after more people have had a chance to fill it out.
>>
>> I'm trying to get it onto planet python - that should help.  But I
>> created the blog post without a Python label initially, and added it
>> afterward - not sure if that'll work or not.
>>
>>
> I submitted it to hacker news[1] and it has been sitting around #5 on the
> front page for about 3 hours now. That should've helped broaden the
> responses a bit.
>
> Janzert
>
> 1. https://news.ycombinator.com/item?id=6990481
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> gokoproject%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131231/a91610f5/attachment.html>