Re: [Python-Dev] http.client Nagle/delayed-ack optimization

2012-12-20 Thread Kristján Valur Jónsson 
How serendipitous, I was just reporting a similar problem to Sony in one of 
their console sdks yesterday :)
Indeed, the Nagle problem only shows up if you are sending more than one 
segments that are not full size.
It will not occur in a sequence of full segments.  Therefore, it is perfectly 
ok to send the headers + payload as a set of large chunks.
The problem only occurs if sending two or more short segments.  So, if sending 
even the short headers, followed by the large payload, there is no problem.
The problem exists only if, in addition to the short headers, you are sending 
the short payload.

In summary:  If the payload is less than the MSS (consider this perhaps 2k) 
send it along with the headers.  Otherwise, you can go ahead and send the 
headers, and thepayload (in large chunks if you want) without fear.

See:
http://en.wikipedia.org/wiki/Nagle%27s_algorithm
and
http://en.wikipedia.org/wiki/TCP_delayed_acknowledgment

K

> -Original Message-
> From: Python-Dev [mailto:python-dev-
> [email protected]] On Behalf Of Antoine Pitrou
> Sent: 14. desember 2012 19:27
> To: [email protected]
> Subject: Re: [Python-Dev] http.client Nagle/delayed-ack optimization
> 
> On Sat, 15 Dec 2012 06:17:19 +1100
> Ben Leslie  wrote:
> > The http.client HTTPConnection._send_output method has an optimization
> > for avoiding bad interactions between delayed-ack and the Nagle
> algorithm:
> >
> > http://hg.python.org/cpython/file/f32f67d26035/Lib/http/client.py#l884
> >
> > Unfortunately this interacts rather poorly if the case where the
> > message_body is a bytes instance and is rather large.
> >
> > If the message_body is bytes it is appended to the headers, which
> > causes a copy of the data. When message_body is large this duplication
> > of data can cause a significant spike in memory usage.
> >
> > (In my particular case I was uploading a 200MB file to 30 hosts at the
> > same leading to memory spikes over 6GB.
> >
> > I've solved this by subclassing and removing the optimization, however
> > I'd appreciate thoughts on how this could best be solved in the library 
> > itself.
> >
> > Options I have thought of are:
> >
> > 1: Have some size threshold on the copy. A little bit too much magic.
> > Unclear what the size threshold should be.
> 
> I think a hardcoded threshold is the right thing to do. It doesn't sound very
> useful to try doing a single send() call when you have a large chunk of data
> (say, more than 1 MB).
> 
> Regards
> 
> Antoine.
> 
> 
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-
> dev/kristjan%40ccpgames.com


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-20 Thread Barry Warsaw 
On Dec 20, 2012, at 11:18 AM, Ben Finney wrote:

>Terry Reedy  writes:
>
>> On 12/12/2012 10:56 AM, Lennart Regebro wrote:
>>
>> >> It seems like calling get_timezone() with an unknown timezone
>> >> should just throw ValueError, not necessarily some custom
>> >> Exception?
>> >
>> > That could very well be. What are others opinions on this?
>>
>> ValueError. That is what it is. Nothing special here.
>
>I think it's useful to have this raise a custom exception
>UnknownTimeZoneError, subclassed from ValueError. That satisfies those
>(including me!) who think it should be a ValueError, while also making
>the exception more specific so it can be handled apart from other
>possible ValueError causes.
>
>In short: +1 to ‘class UnknownTimeZoneError(ValueError)’.

That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PandaBoard, Raspberry Pi coming to Buildbot fleet

2012-12-20 Thread Brian Curtin 
Last week in Raymond's dictionary thread, the topic of ARM came up,
along with the relative lack of build slave coverage. Today Trent
Nelson received the PandaBoard purchased by the PSF, and a Raspberry
Pi should be coming shortly as well.

http://blog.python.org/2012/12/pandaboard-raspberry-pi-coming-to.html

Thanks to the PSF for purchasing and thanks to Trent for offering to
host them in Snakebite!
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3145 (With Contents)

2012-12-20 Thread Glyph 

On Dec 19, 2012, at 7:46 PM, anatoly techtonik  wrote:
>  
>> On *nix it really shouldn't be select.  select cannot wait upon a file 
>> descriptor whose value is greater than FD_SETSIZE, which means it sets a 
>> hard (and small) limit on the number of things that a process which wants to 
>> use this facility can be doing.
>> 
>> I didn't know that. Should a note be added to 
>> http://docs.python.org/2/library/select ?
> 
> The note that should be added there is simply "you should know how the select 
> system call works in C if you want to use this module".
> 
> Why spreading FUD if it is possible to define a good entrypoint for those who 
> want to learn, but don't have enough time? Why not to say directly that 
> select interface is outdated?

It's not FUD.  If you know how select() works in C, you may well want to call 
it.  It's the most portable multiplexing API, although it has a number of 
limitations.  Really, what most users in this situation ought to be using is 
Twisted, but it seems there is not sufficient interest to bundle Twisted's core 
in the stdlib.  However, the thing Guido is working on lately may be 
interoperable enough with Twisted that you can upgrade to it more easily in 
future versions of Python, so one day it may be reasonable to say select is 
outdated.

(Maybe not though.  It's a good thing nobody told me that select was deprecated 
in favor of asyncore.)

>> On the other hand, if you hard-code another arbitrary limit like this into 
>> the stdlib subprocess module, it will just be another great reason why 
>> Twisted's spawnProcess is the best and everyone should use it instead, so be 
>> my guest ;-).
>> 
>> spawnProcess requires a reactor. This PEP is an alternative for the 
>> proponents of green energy. =)
> 
> Do you know what happens when you take something that is supposed to be 
> happening inside a reactor, and then move it outside a reactor?  It's not 
> called "green energy", it's called "a bomb" ;-).
> 
> The biggest complain about nuclear physics is that to understand what's going 
> on it should have been gone 3D long ago. =) I think Twisted needs to organize 
> competition on the best visualization of underlying concepts. It will help 
> people grasp the concepts behind and different problems much faster (as well 
> as gain an ability to compare different reactors).

I would love for someone to do this, of course, but now we're _really_ off 
topic.

-glyph


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PandaBoard, Raspberry Pi coming to Buildbot fleet

2012-12-20 Thread Eli Bendersky 
On Thu, Dec 20, 2012 at 9:33 AM, Brian Curtin  wrote:

> Last week in Raymond's dictionary thread, the topic of ARM came up,
> along with the relative lack of build slave coverage. Today Trent
> Nelson received the PandaBoard purchased by the PSF, and a Raspberry
> Pi should be coming shortly as well.
>
> http://blog.python.org/2012/12/pandaboard-raspberry-pi-coming-to.html
>
> Thanks to the PSF for purchasing and thanks to Trent for offering to
> host them in Snakebite!
> __
>

 That's good news. A related question about Snakebite, though. Maybe I
missed something obvious, but is there an overview of how the core devs can
use it? In particular, I'd want to know if Snakebite runs Python's tests
regularly - and if it does, how can I see the status. How do I know if any
commit of mine broke some host Snakebite has? How can I SSH to that host in
order to reproduce and fix the problem? Some sort of a blog post about
this, at least, would be very helpful for me and possibly other developers
as well.

Eli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PandaBoard, Raspberry Pi coming to Buildbot fleet

2012-12-20 Thread Benjamin Peterson 
2012/12/20 Eli Bendersky :
> On Thu, Dec 20, 2012 at 9:33 AM, Brian Curtin  wrote:
>>
>> Last week in Raymond's dictionary thread, the topic of ARM came up,
>> along with the relative lack of build slave coverage. Today Trent
>> Nelson received the PandaBoard purchased by the PSF, and a Raspberry
>> Pi should be coming shortly as well.
>>
>> http://blog.python.org/2012/12/pandaboard-raspberry-pi-coming-to.html
>>
>> Thanks to the PSF for purchasing and thanks to Trent for offering to
>> host them in Snakebite!
>> __
>
>
>  That's good news. A related question about Snakebite, though. Maybe I
> missed something obvious, but is there an overview of how the core devs can
> use it? In particular, I'd want to know if Snakebite runs Python's tests
> regularly - and if it does, how can I see the status. How do I know if any
> commit of mine broke some host Snakebite has? How can I SSH to that host in
> order to reproduce and fix the problem? Some sort of a blog post about this,
> at least, would be very helpful for me and possibly other developers as
> well.

http://mail.python.org/pipermail/python-dev/2012-September/121651.html

Presumably that should go somewhere more permanent.

-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Possible GIL/threading issue involving subprocess and PyMem_MALLOC...

2012-12-20 Thread Trent Nelson 
This seems odd to me so I wanted to see what others think.  The unit
test Lib/unittest/test/test_runner.py:Test_TextRunner.test_warnings
will eventually hit subprocess.Popen._communicate.

The `mswindows` implementation of this method relies on threads to
buffer stdin/stdout.  That'll eventually result in PyOs_StdioReadline
being called without the GIL being held.  PyOs_StdioReadline calls
PyMem_MALLOC, PyMem_FREE and possibly PyMem_REALLOC.

On a debug build, these macros are redirected to their _PyMem_Debug*
counterparts.  The call hierarchy for _PyMem_DebugMalloc looks like
this:

void *
_PyMem_DebugMalloc(size_t nbytes)
{
return _PyObject_DebugMallocApi(_PYMALLOC_MEM_ID, nbytes);
}

/* generic debug memory api, with an "id" to
   identify the API in use */
void *
_PyObject_DebugMallocApi(char id, size_t nbytes)
{
uchar *p;   /* base address of malloc'ed block */
uchar *tail;/* p + 2*SST + nbytes ==
   pointer to tail pad bytes */
size_t total;   /* nbytes + 4*SST */

bumpserialno();
^^^

total = nbytes + 4*SST;
if (total < nbytes)
/* overflow:  can't represent total as a size_t */
return NULL;

p = (uchar *)PyObject_Malloc(total);
-^^^
if (p == NULL)
return NULL;



Both bumpserialno() and PyObject_Malloc affect global state.  The latter
also has a bunch of LOCK() and UNLOCK() statements, but these end up being
no-ops:

/*
 * Python's threads are serialized,
 * so object malloc locking is disabled.
 */
#define SIMPLELOCK_DECL(lock) /* simple lock declaration */
#define SIMPLELOCK_INIT(lock) /* allocate (if needed) and ... */
#define SIMPLELOCK_FINI(lock) /* free/destroy an existing */
#define SIMPLELOCK_LOCK(lock) /* acquire released lock */
#define SIMPLELOCK_UNLOCK(lock) /* release acquired lock */
...
/*
 * This malloc lock
 */
SIMPLELOCK_DECL(_malloc_lock)
#define LOCK()  SIMPLELOCK_LOCK(_malloc_lock)
#define UNLOCK()SIMPLELOCK_UNLOCK(_malloc_lock)
#define LOCK_INIT() SIMPLELOCK_INIT(_malloc_lock)
#define LOCK_FINI() SIMPLELOCK_FINI(_malloc_lock)

The PyObject_Malloc() one concerns me the most, as it affects huge
amounts of global state.  Also, I just noticed PyOs_StdioReadline()
can call PyErr_SetString, which will result in a bunch of other
calls that should only be made whilst the GIL is held.

So, like I said, this seems like a bit of a head scratcher.  Legit
issue or am I missing something?

Trent.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PandaBoard, Raspberry Pi coming to Buildbot fleet

2012-12-20 Thread Trent Nelson 
On Thu, Dec 20, 2012 at 10:10:45AM -0800, Benjamin Peterson wrote:
> 2012/12/20 Eli Bendersky :
> > On Thu, Dec 20, 2012 at 9:33 AM, Brian Curtin  wrote:
> >>
> >> Last week in Raymond's dictionary thread, the topic of ARM came up,
> >> along with the relative lack of build slave coverage. Today Trent
> >> Nelson received the PandaBoard purchased by the PSF, and a Raspberry
> >> Pi should be coming shortly as well.
> >>
> >> http://blog.python.org/2012/12/pandaboard-raspberry-pi-coming-to.html
> >>
> >> Thanks to the PSF for purchasing and thanks to Trent for offering to
> >> host them in Snakebite!
> >> __
> >
> >
> >  That's good news. A related question about Snakebite, though. Maybe I
> > missed something obvious, but is there an overview of how the core devs can
> > use it? In particular, I'd want to know if Snakebite runs Python's tests
> > regularly - and if it does, how can I see the status. How do I know if any
> > commit of mine broke some host Snakebite has? How can I SSH to that host in
> > order to reproduce and fix the problem? Some sort of a blog post about this,
> > at least, would be very helpful for me and possibly other developers as
> > well.
> 
> http://mail.python.org/pipermail/python-dev/2012-September/121651.html
> 
> Presumably that should go somewhere more permanent.

Indeed, I'm going to carve out some time over the Christmas/NY break
to work on this.  There should really be a "Developer's Guide" that
explains how to get the most out of the network.

Trent.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PandaBoard, Raspberry Pi coming to Buildbot fleet

2012-12-20 Thread Trent Nelson 
On Thu, Dec 20, 2012 at 09:33:27AM -0800, Brian Curtin wrote:
> Last week in Raymond's dictionary thread, the topic of ARM came up,
> along with the relative lack of build slave coverage. Today Trent
> Nelson received the PandaBoard purchased by the PSF, and a Raspberry
> Pi should be coming shortly as well.
> 
> http://blog.python.org/2012/12/pandaboard-raspberry-pi-coming-to.html
> 
> Thanks to the PSF for purchasing and thanks to Trent for offering to
> host them in Snakebite!

No problemo'.  If only all the other Snakebite servers could fit in
my palm and run off 0.25A.  (The HP-UX and Tru64 boxes in particular
take up 7U/8U, weigh 160/140lbs, and chew about ~12A each.)

I'll work on setting the ARM boards up next week.

Trent.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PandaBoard, Raspberry Pi coming to Buildbot fleet

2012-12-20 Thread a.cavallo 
How about folding them??? 
I did it, now I don't need a power supply anymore :O


On Thu 20/12/12 19:52, Trent Nelson [email protected] wrote:
> No problemo'.  If only all the other Snakebite servers could fit in
> my palm and run off 0.25A. 

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PandaBoard, Raspberry Pi coming to Buildbot fleet

2012-12-20 Thread Antoine Pitrou 
On Thu, 20 Dec 2012 13:52:56 -0500
Trent Nelson  wrote:
> On Thu, Dec 20, 2012 at 09:33:27AM -0800, Brian Curtin wrote:
> > Last week in Raymond's dictionary thread, the topic of ARM came up,
> > along with the relative lack of build slave coverage. Today Trent
> > Nelson received the PandaBoard purchased by the PSF, and a Raspberry
> > Pi should be coming shortly as well.
> > 
> > http://blog.python.org/2012/12/pandaboard-raspberry-pi-coming-to.html
> > 
> > Thanks to the PSF for purchasing and thanks to Trent for offering to
> > host them in Snakebite!
> 
> No problemo'.  If only all the other Snakebite servers could fit in
> my palm and run off 0.25A.  (The HP-UX and Tru64 boxes in particular
> take up 7U/8U, weigh 160/140lbs, and chew about ~12A each.)
> 
> I'll work on setting the ARM boards up next week.

For the record, Barry's ARM buildbot has been failing for a long time:
http://buildbot.python.org/all/buildslaves/warsaw-ubuntu-arm

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PandaBoard, Raspberry Pi coming to Buildbot fleet

2012-12-20 Thread Trent Nelson 
On Thu, Dec 20, 2012 at 10:52:56AM -0800, Trent Nelson wrote:
> I'll work on setting the ARM boards up next week.

Does anyone have a preference regarding the operating system?  There
are a bunch of choices listed here:

http://www.omappedia.org/wiki/Main_Page

As long as it can run a recent sshd and zsh, I have no preference.

Trent.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3145 (With Contents)

2012-12-20 Thread Brett Cannon 
You cannot rewrite an existing PEP if you are not one of the original
owners, nor can you add yourself as an author to a PEP without permission
from the original authors.

And please do not CC the peps mailing list on discussions. It should only
be used to mail in new PEPs or acceptable patches to PEPs.


On Wed, Dec 19, 2012 at 5:20 PM, anatoly techtonik wrote:

> On Sun, Dec 9, 2012 at 7:17 AM, Gregory P. Smith  wrote:
>
>> I'm really not sure what this PEP is trying to get at given that it
>> contains no examples and sounds from the descriptions to be adding a
>> complicated api on top of something that already, IMNSHO, has too much it
>> (subprocess.Popen).
>>
>> Regardless, any user can use the stdout/err/in file objects with their
>> own code that handles them asynchronously (yes that can be painful but that
>> is what is required for _any_ socket or pipe I/O you don't want to block
>> on).
>>
>
> And how to use stdout/stderr/in asynchronously in cross-platform manner?
> IIUC the problem is that every read is blocking.
>
>
>> It *sounds* to me like this entire PEP could be written and released as
>> a third party module on PyPI that offers a subprocess.Popen subclass adding
>> some more convenient non-blocking APIs.  That's where I'd start if I were
>> interested in this as a future feature.
>>
>
> I've rewritten the PEP based on how do I understand the code. I don't know
> how to update it and how to comply with open documentation license, so I
> just attach it and add PEPs list to CC. Me too has a feeling that the PEP
> should be stripped of additional high level API until low level
> functionality is well understood and accepted.
>
> --
> anatoly t.
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PandaBoard, Raspberry Pi coming to Buildbot fleet

2012-12-20 Thread Barry Warsaw 
On Dec 20, 2012, at 02:54 PM, Trent Nelson wrote:

>On Thu, Dec 20, 2012 at 10:52:56AM -0800, Trent Nelson wrote:
>> I'll work on setting the ARM boards up next week.
>
>Does anyone have a preference regarding the operating system?  There
>are a bunch of choices listed here:
>
>http://www.omappedia.org/wiki/Main_Page
>
>As long as it can run a recent sshd and zsh, I have no preference.

Well, I'm biased of course, but Ubuntu should be easy to install and should
run just fine AFAIK.  I'm running 12.10 on my ARM buildbot (an iMX.53 board).

-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3145 (With Contents)

2012-12-20 Thread Chris Jerdonek 
On Thu, Dec 20, 2012 at 12:18 PM, Brett Cannon  wrote:
>
> And please do not CC the peps mailing list on discussions. It should only be
> used to mail in new PEPs or acceptable patches to PEPs.

PEP 1 should perhaps be clarified if the above is the case.
Currently, PEP 1 says all PEP-related e-mail should be sent there:

"The PEP editors assign PEP numbers and change their status. Please
send all PEP-related email to  (no cross-posting
please). Also see PEP Editor Responsibilities & Workflow below."

as well as:

"A PEP editor must subscribe to the  list. All
PEP-related correspondence should be sent (or CC'd) to
 (but please do not cross-post!)."

(Incidentally, the statement not to cross-post seems contradictory if
a PEP-related e-mail is also sent to python-dev, for example.)

--Chris



> On Wed, Dec 19, 2012 at 5:20 PM, anatoly techtonik 
> wrote:
>>
>> On Sun, Dec 9, 2012 at 7:17 AM, Gregory P. Smith  wrote:
>>>
>>> I'm really not sure what this PEP is trying to get at given that it
>>> contains no examples and sounds from the descriptions to be adding a
>>> complicated api on top of something that already, IMNSHO, has too much it
>>> (subprocess.Popen).
>>>
>>> Regardless, any user can use the stdout/err/in file objects with their
>>> own code that handles them asynchronously (yes that can be painful but that
>>> is what is required for _any_ socket or pipe I/O you don't want to block
>>> on).
>>
>>
>> And how to use stdout/stderr/in asynchronously in cross-platform manner?
>> IIUC the problem is that every read is blocking.
>>
>>>
>>> It sounds to me like this entire PEP could be written and released as a
>>> third party module on PyPI that offers a subprocess.Popen subclass adding
>>> some more convenient non-blocking APIs.  That's where I'd start if I were
>>> interested in this as a future feature.
>>
>>
>> I've rewritten the PEP based on how do I understand the code. I don't know
>> how to update it and how to comply with open documentation license, so I
>> just attach it and add PEPs list to CC. Me too has a feeling that the PEP
>> should be stripped of additional high level API until low level
>> functionality is well understood and accepted.
>>
>> --
>> anatoly t.
>>
>> ___
>> Python-Dev mailing list
>> [email protected]
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/chris.jerdonek%40gmail.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3145 (With Contents)

2012-12-20 Thread Brett Cannon 
On Thu, Dec 20, 2012 at 3:55 PM, Chris Jerdonek wrote:

> On Thu, Dec 20, 2012 at 12:18 PM, Brett Cannon  wrote:
> >
> > And please do not CC the peps mailing list on discussions. It should
> only be
> > used to mail in new PEPs or acceptable patches to PEPs.
>
> PEP 1 should perhaps be clarified if the above is the case.
> Currently, PEP 1 says all PEP-related e-mail should be sent there:
>
> "The PEP editors assign PEP numbers and change their status. Please
> send all PEP-related email to  (no cross-posting
> please). Also see PEP Editor Responsibilities & Workflow below."
>
> as well as:
>
> "A PEP editor must subscribe to the  list. All
> PEP-related correspondence should be sent (or CC'd) to
>  (but please do not cross-post!)."
>
> (Incidentally, the statement not to cross-post seems contradictory if
> a PEP-related e-mail is also sent to python-dev, for example.)
>

But it very clearly states to NOT cross-post which is exactly what Anatoly
did and that is what I take issue with the most. I personally don't see any
confusion with the wording. It clearly states that if you are a PEP author
you should mail the peps editors and NOT cross-post. If you are an editor,
make sure any emailing you do with an individual CCs the list but do NOT
cross-post.

-Brett


>
> --Chris
>
>
>
> > On Wed, Dec 19, 2012 at 5:20 PM, anatoly techtonik 
> > wrote:
> >>
> >> On Sun, Dec 9, 2012 at 7:17 AM, Gregory P. Smith 
> wrote:
> >>>
> >>> I'm really not sure what this PEP is trying to get at given that it
> >>> contains no examples and sounds from the descriptions to be adding a
> >>> complicated api on top of something that already, IMNSHO, has too much
> it
> >>> (subprocess.Popen).
> >>>
> >>> Regardless, any user can use the stdout/err/in file objects with their
> >>> own code that handles them asynchronously (yes that can be painful but
> that
> >>> is what is required for _any_ socket or pipe I/O you don't want to
> block
> >>> on).
> >>
> >>
> >> And how to use stdout/stderr/in asynchronously in cross-platform manner?
> >> IIUC the problem is that every read is blocking.
> >>
> >>>
> >>> It sounds to me like this entire PEP could be written and released as a
> >>> third party module on PyPI that offers a subprocess.Popen subclass
> adding
> >>> some more convenient non-blocking APIs.  That's where I'd start if I
> were
> >>> interested in this as a future feature.
> >>
> >>
> >> I've rewritten the PEP based on how do I understand the code. I don't
> know
> >> how to update it and how to comply with open documentation license, so I
> >> just attach it and add PEPs list to CC. Me too has a feeling that the
> PEP
> >> should be stripped of additional high level API until low level
> >> functionality is well understood and accepted.
> >>
> >> --
> >> anatoly t.
> >>
> >> ___
> >> Python-Dev mailing list
> >> [email protected]
> >> http://mail.python.org/mailman/listinfo/python-dev
> >> Unsubscribe:
> >> http://mail.python.org/mailman/options/python-dev/brett%40python.org
> >>
> >
> >
> > ___
> > Python-Dev mailing list
> > [email protected]
> > http://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> >
> http://mail.python.org/mailman/options/python-dev/chris.jerdonek%40gmail.com
> >
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Mention OSError instead of IOError in the docs.

2012-12-20 Thread Andrew Svetlov 
Don't sure about applying doc changes to 3.3.
They are very minor.
The main change will be deprecation of aliases in the docs, that can
be applied only to upcoming release.

On Wed, Dec 19, 2012 at 7:05 PM, Serhiy Storchaka  wrote:
> On 19.12.12 09:24, Nick Coghlan wrote:
>>
>> With any of these changes in the docs, please don't forget to include
>> appropriate "versionchanged" directives. Many people using the Python 3
>> docs at "docs.python.org/3/ " will still be
>>
>> on Python 3.2, and thus relying on the presence of such directives to
>> let them know that while the various OS-related exception names are now
>> just aliases for OSError in 3.3+, the distinctions still matter in 3.2.
>
>
> I also propose to apply all this documentation changes to 3.3.
>
>
> ___
> Python-checkins mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-checkins



-- 
Thanks,
Andrew Svetlov
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PandaBoard, Raspberry Pi coming to Buildbot fleet

2012-12-20 Thread Nick Coghlan 
I'd vote for Fedora on at least one of them (like Barry, I'm biased,
though)

Cheers,
Nick.

--
Sent from my phone, thus the relative brevity :)
On Dec 21, 2012 6:27 AM, "Barry Warsaw"  wrote:

> On Dec 20, 2012, at 02:54 PM, Trent Nelson wrote:
>
> >On Thu, Dec 20, 2012 at 10:52:56AM -0800, Trent Nelson wrote:
> >> I'll work on setting the ARM boards up next week.
> >
> >Does anyone have a preference regarding the operating system?  There
> >are a bunch of choices listed here:
> >
> >http://www.omappedia.org/wiki/Main_Page
> >
> >As long as it can run a recent sshd and zsh, I have no preference.
>
> Well, I'm biased of course, but Ubuntu should be easy to install and should
> run just fine AFAIK.  I'm running 12.10 on my ARM buildbot (an iMX.53
> board).
>
> -Barry
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PandaBoard, Raspberry Pi coming to Buildbot fleet

2012-12-20 Thread Meador Inge 
On Thu, Dec 20, 2012 at 2:23 PM, Barry Warsaw  wrote:

> On Dec 20, 2012, at 02:54 PM, Trent Nelson wrote:
>
>>On Thu, Dec 20, 2012 at 10:52:56AM -0800, Trent Nelson wrote:
>>> I'll work on setting the ARM boards up next week.
>>
>>Does anyone have a preference regarding the operating system?  There
>>are a bunch of choices listed here:
>>
>>http://www.omappedia.org/wiki/Main_Page
>>
>>As long as it can run a recent sshd and zsh, I have no preference.
>
> Well, I'm biased of course, but Ubuntu should be easy to install and should
> run just fine AFAIK.  I'm running 12.10 on my ARM buildbot (an iMX.53 board).

+1 for Ubuntu.  I have setup a PandaBoard at home with Ubuntu and
built/tested Python
with it.  The installation was very easy.

-- 
# Meador
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PandaBoard, Raspberry Pi coming to Buildbot fleet

2012-12-20 Thread Eli Bendersky 
> > >
> > >  That's good news. A related question about Snakebite, though. Maybe I
> > > missed something obvious, but is there an overview of how the core
> devs can
> > > use it? In particular, I'd want to know if Snakebite runs Python's
> tests
> > > regularly - and if it does, how can I see the status. How do I know if
> any
> > > commit of mine broke some host Snakebite has? How can I SSH to that
> host in
> > > order to reproduce and fix the problem? Some sort of a blog post about
> this,
> > > at least, would be very helpful for me and possibly other developers as
> > > well.
> >
> > http://mail.python.org/pipermail/python-dev/2012-September/121651.html
> >
> > Presumably that should go somewhere more permanent.
>
> Indeed, I'm going to carve out some time over the Christmas/NY break
> to work on this.  There should really be a "Developer's Guide" that
> explains how to get the most out of the network.
>
>
Thanks, indeed a more permanent place would be nice. So from reading the
above, am I correct in the understanding that these hosts don't actually
run tests at the moment? They only do if we log into them to test stuff? I
think it would be really nice if they could actually run as buildbot slaves
and execute Python tests continuously.

Eli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PandaBoard, Raspberry Pi coming to Buildbot fleet

2012-12-20 Thread Benjamin Peterson 
2012/12/20 Eli Bendersky :
>
>> > >
>> > >  That's good news. A related question about Snakebite, though. Maybe I
>> > > missed something obvious, but is there an overview of how the core
>> > > devs can
>> > > use it? In particular, I'd want to know if Snakebite runs Python's
>> > > tests
>> > > regularly - and if it does, how can I see the status. How do I know if
>> > > any
>> > > commit of mine broke some host Snakebite has? How can I SSH to that
>> > > host in
>> > > order to reproduce and fix the problem? Some sort of a blog post about
>> > > this,
>> > > at least, would be very helpful for me and possibly other developers
>> > > as
>> > > well.
>> >
>> > http://mail.python.org/pipermail/python-dev/2012-September/121651.html
>> >
>> > Presumably that should go somewhere more permanent.
>>
>> Indeed, I'm going to carve out some time over the Christmas/NY break
>> to work on this.  There should really be a "Developer's Guide" that
>> explains how to get the most out of the network.
>>
>
> Thanks, indeed a more permanent place would be nice. So from reading the
> above, am I correct in the understanding that these hosts don't actually run
> tests at the moment? They only do if we log into them to test stuff? I think
> it would be really nice if they could actually run as buildbot slaves and
> execute Python tests continuously.

Some of them are buildbots, some are not.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3145 (With Contents)

2012-12-20 Thread Chris Jerdonek 
On Thu, Dec 20, 2012 at 1:12 PM, Brett Cannon  wrote:
>
> On Thu, Dec 20, 2012 at 3:55 PM, Chris Jerdonek 
> wrote:
>>
>> On Thu, Dec 20, 2012 at 12:18 PM, Brett Cannon  wrote:
>> >
>> > And please do not CC the peps mailing list on discussions. It should
>> > only be
>> > used to mail in new PEPs or acceptable patches to PEPs.
>>
>> PEP 1 should perhaps be clarified if the above is the case.
>> Currently, PEP 1 says all PEP-related e-mail should be sent there:
>>
>> "The PEP editors assign PEP numbers and change their status. Please
>> send all PEP-related email to  (no cross-posting
>> please). Also see PEP Editor Responsibilities & Workflow below."
>>
>> as well as:
>>
>> "A PEP editor must subscribe to the  list. All
>> PEP-related correspondence should be sent (or CC'd) to
>>  (but please do not cross-post!)."
>>
>> (Incidentally, the statement not to cross-post seems contradictory if
>> a PEP-related e-mail is also sent to python-dev, for example.)
>
>
> But it very clearly states to NOT cross-post which is exactly what Anatoly
> did and that is what I take issue with the most. I personally don't see any
> confusion with the wording. It clearly states that if you are a PEP author
> you should mail the peps editors and NOT cross-post. If you are an editor,
> make sure any emailing you do with an individual CCs the list but do NOT
> cross-post.

I don't disagree that he shouldn't have cross-posted.  I was just
pointing out that the language should be clarified.  What's confusing
is that the current language implies that one shouldn't send any
PEP-related e-mails to any mailing list other than peps@.  In
particular, how can one discuss PEPs on python-dev or python-ideas
without violating that language (e.g. this e-mail which is related to
PEP 1)?  It is probably just a matter of clarifying what "PEP-related"
means.

--Chris
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Possible GIL/threading issue involving subprocess and PyMem_MALLOC...

2012-12-20 Thread Gregory P. Smith 
On Thu, Dec 20, 2012 at 10:43 AM, Trent Nelson  wrote:

> This seems odd to me so I wanted to see what others think.  The unit
> test Lib/unittest/test/test_runner.py:Test_TextRunner.test_warnings
> will eventually hit subprocess.Popen._communicate.
>
> The `mswindows` implementation of this method relies on threads to
> buffer stdin/stdout.  That'll eventually result in PyOs_StdioReadline
> being called without the GIL being held.  PyOs_StdioReadline calls
> PyMem_MALLOC, PyMem_FREE and possibly PyMem_REALLOC.
>

Those threads are implemented in Python so how would the GIL ever not be
held?

-gps


>
> On a debug build, these macros are redirected to their _PyMem_Debug*
> counterparts.  The call hierarchy for _PyMem_DebugMalloc looks like
> this:
>
> void *
> _PyMem_DebugMalloc(size_t nbytes)
> {
> return _PyObject_DebugMallocApi(_PYMALLOC_MEM_ID, nbytes);
> }
>
> /* generic debug memory api, with an "id" to
>identify the API in use */
> void *
> _PyObject_DebugMallocApi(char id, size_t nbytes)
> {
> uchar *p;   /* base address of malloc'ed block */
> uchar *tail;/* p + 2*SST + nbytes ==
>pointer to tail pad bytes */
> size_t total;   /* nbytes + 4*SST */
>
> bumpserialno();
> ^^^
>
> total = nbytes + 4*SST;
> if (total < nbytes)
> /* overflow:  can't represent total as a size_t */
> return NULL;
>
> p = (uchar *)PyObject_Malloc(total);
> -^^^
> if (p == NULL)
> return NULL;
>
> 
>
> Both bumpserialno() and PyObject_Malloc affect global state.  The
> latter
> also has a bunch of LOCK() and UNLOCK() statements, but these end up
> being
> no-ops:
>
> /*
>  * Python's threads are serialized,
>  * so object malloc locking is disabled.
>  */
> #define SIMPLELOCK_DECL(lock) /* simple lock declaration */
> #define SIMPLELOCK_INIT(lock) /* allocate (if needed) and ... */
> #define SIMPLELOCK_FINI(lock) /* free/destroy an existing */
> #define SIMPLELOCK_LOCK(lock) /* acquire released lock */
> #define SIMPLELOCK_UNLOCK(lock) /* release acquired lock */
> ...
> /*
>  * This malloc lock
>  */
> SIMPLELOCK_DECL(_malloc_lock)
> #define LOCK()  SIMPLELOCK_LOCK(_malloc_lock)
> #define UNLOCK()SIMPLELOCK_UNLOCK(_malloc_lock)
> #define LOCK_INIT() SIMPLELOCK_INIT(_malloc_lock)
> #define LOCK_FINI() SIMPLELOCK_FINI(_malloc_lock)
>
> The PyObject_Malloc() one concerns me the most, as it affects huge
> amounts of global state.  Also, I just noticed PyOs_StdioReadline()
> can call PyErr_SetString, which will result in a bunch of other
> calls that should only be made whilst the GIL is held.
>
> So, like I said, this seems like a bit of a head scratcher.  Legit
> issue or am I missing something?
>
> Trent.
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Possible GIL/threading issue involving subprocess and PyMem_MALLOC...

2012-12-20 Thread Trent Nelson 
On Thu, Dec 20, 2012 at 05:47:40PM -0800, Gregory P. Smith wrote:
>On Thu, Dec 20, 2012 at 10:43 AM, Trent Nelson 
>wrote:
> 
>  This seems odd to me so I wanted to see what others think.  The unit
>  test Lib/unittest/test/test_runner.py:Test_TextRunner.test_warnings
>  will eventually hit subprocess.Popen._communicate.
> 
>  The `mswindows` implementation of this method relies on threads to
>  buffer stdin/stdout.  That'll eventually result in
>  PyOs_StdioReadline
>  being called without the GIL being held.  PyOs_StdioReadline calls
>  PyMem_MALLOC, PyMem_FREE and possibly PyMem_REALLOC.
> 
>Those threads are implemented in Python so how would the GIL ever not be
>held?
>-gps

PyOS_Readline drops the GIL prior to calling PyOS_StdioReadline:

Py_BEGIN_ALLOW_THREADS
^^
#ifdef WITH_THREAD
PyThread_acquire_lock(_PyOS_ReadlineLock, 1);
#endif

/* This is needed to handle the unlikely case that the
 * interpreter is in interactive mode *and* stdin/out are not
 * a tty.  This can happen, for example if python is run like
 * this: python -i < test1.py
 */
if (!isatty (fileno (sys_stdin)) || !isatty (fileno (sys_stdout)))
rv = PyOS_StdioReadline (sys_stdin, sys_stdout, prompt);
-^^^
else
rv = (*PyOS_ReadlineFunctionPointer)(sys_stdin, sys_stdout,
 prompt);
Py_END_ALLOW_THREADS


Trent.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PandaBoard, Raspberry Pi coming to Buildbot fleet

2012-12-20 Thread Trent Nelson 
On Thu, Dec 20, 2012 at 03:10:49PM -0800, Eli Bendersky wrote:
>  > >
>  > >  That's good news. A related question about Snakebite, though. Maybe
>  I
>  > > missed something obvious, but is there an overview of how the core
>  devs can
>  > > use it? In particular, I'd want to know if Snakebite runs Python's
>  tests
>  > > regularly - and if it does, how can I see the status. How do I know
>  if any
>  > > commit of mine broke some host Snakebite has? How can I SSH to that
>  host in
>  > > order to reproduce and fix the problem? Some sort of a blog post
>  about this,
>  > > at least, would be very helpful for me and possibly other developers
>  as
>  > > well.
>  >
>  > http://mail.python.org/pipermail/python-dev/2012-September/121651.html
>  >
>  > Presumably that should go somewhere more permanent.
> 
>  Indeed, I'm going to carve out some time over the Christmas/NY break
>  to work on this.  There should really be a "Developer's Guide" that
>  explains how to get the most out of the network.
> 
>Thanks, indeed a more permanent place would be nice. So from reading the
>above, am I correct in the understanding that these hosts don't actually
>run tests at the moment? They only do if we log into them to test stuff? I
>think it would be really nice if they could actually run as buildbot
>slaves and execute Python tests continuously.

Almost all of them are running slaves, and have been since ~August.
Take a look at our buildbot page -- any host with [SB] in the name
is a Snakebite host.

Trent.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PandaBoard, Raspberry Pi coming to Buildbot fleet

2012-12-20 Thread Eli Bendersky 
On Thu, Dec 20, 2012 at 7:13 PM, Trent Nelson  wrote:

> On Thu, Dec 20, 2012 at 03:10:49PM -0800, Eli Bendersky wrote:
> >  > >
> >  > >  That's good news. A related question about Snakebite, though.
> Maybe
> >  I
> >  > > missed something obvious, but is there an overview of how the
> core
> >  devs can
> >  > > use it? In particular, I'd want to know if Snakebite runs
> Python's
> >  tests
> >  > > regularly - and if it does, how can I see the status. How do I
> know
> >  if any
> >  > > commit of mine broke some host Snakebite has? How can I SSH to
> that
> >  host in
> >  > > order to reproduce and fix the problem? Some sort of a blog post
> >  about this,
> >  > > at least, would be very helpful for me and possibly other
> developers
> >  as
> >  > > well.
> >  >
> >  >
> http://mail.python.org/pipermail/python-dev/2012-September/121651.html
> >  >
> >  > Presumably that should go somewhere more permanent.
> >
> >  Indeed, I'm going to carve out some time over the Christmas/NY
> break
> >  to work on this.  There should really be a "Developer's Guide"
> that
> >  explains how to get the most out of the network.
> >
> >Thanks, indeed a more permanent place would be nice. So from reading
> the
> >above, am I correct in the understanding that these hosts don't
> actually
> >run tests at the moment? They only do if we log into them to test
> stuff? I
> >think it would be really nice if they could actually run as buildbot
> >slaves and execute Python tests continuously.
>
> Almost all of them are running slaves, and have been since ~August.
> Take a look at our buildbot page -- any host with [SB] in the name
> is a Snakebite host.
>
> Trent.
>

Ah, I see. Thanks.
Eli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] compile python 3.3 with bz2 support

2012-12-20 Thread Isml 
hi, everyone:
 I want to compile python 3.3 with bz2 support on RedHat 5.5 but fail to do 
that. Here is how I do it:
 1??download bzip2 and compile it(make??make -f Makefile_libbz2_so??make 
install)
 2??chang to python 3.3 source directory : ./configure 
--with-bz2=/usr/local/include
 3??make
 4??make install
  
 after installation complete, I test it??
 [root@localhost Python-3.3.0]# python3 -c "import bz2"
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python3.3/bz2.py", line 21, in 
from _bz2 import BZ2Compressor, BZ2Decompressor
ImportError: No module named '_bz2'

 By the way, RedHat 5.5 has a built-in python 2.4.3. Would it be a problem?___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] compile python 3.3 with bz2 support

2012-12-20 Thread Isml 
OK, thanks



-- Original --

From:  "Oleg Broytman";
Date:  Fri, Dec 21, 2012 02:17 PM
To:  "Isml"<[email protected]>; 
Cc:  "python-dev"; 
Subject:  Re: [Python-Dev] compile python 3.3 with bz2 support
Hello.   We are sorry but we cannot help you. This mailing list is to work ondeveloping Python (adding new features to Python itself and fixing bugs);if you're having problems learning, understanding or using Python, pleasefind another forum. Probably python-list/comp.lang.python mailing list/newsgroup is the best place; there are Python developers who participate in it;you may get a faster, and probably more complete, answer there. Seehttp://www.python.org/community/ for other lists/news groups/fora. Thankyou for understanding.On Fri, Dec 21, 2012 at 02:03:40PM +0800, Isml <[email protected]> wrote:> hi, everyone:>  I want to compile python 3.3 with bz2 support on RedHat 5.5 but fail to do that. Here is how I do it:>  1??download bzip2 and compile it(make??make -f Makefile_libbz2_so??make install)>  2??chang to python 3.3 source directory : ./configure --with-bz2=/usr/local/include>  3??make>  4??make install>   >  after installation complete, I test it??>  [root@localhost Python-3.3.0]# python3 -c "import bz2"> Traceback (most recent call last):>   File "", line 1, in >   File "/usr/local/lib/python3.3/bz2.py", line 21, in > from _bz2 import BZ2Compressor, BZ2Decompressor> ImportError: No module named '_bz2'   You have to install bz2 development files (headers and libraries)before recompiling python.>  By the way, RedHat 5.5 has a built-in python 2.4.3. Would it be a problem?   Depends on what are you going to do.Oleg.--  Oleg Broytman    http://phdru.name/    [email protected]   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] What is the "sequence"? ([issue16728] collections.abc.Sequence shoud provide __subclasshook__

2012-12-20 Thread INADA Naoki 
I've report http://bugs.python.org/issue16728 , but I am confused
about what is the sequence now.


Glossary defines sequence as iteratable having __getitem__ and __len__.
Objects doesn't have __iter__ is iterable when it having __getitem__.

http://docs.python.org/3/reference/datamodel.html says:

> Sequences also support slicing: a[i:j] selects all items with index *k*such 
> that
*i* <= *k* < *j*. When used as an expression, a slice is a sequence of the
same type. This implies that the index set is renumbered so that it starts
at 0.

But I think this sentence explains about standard types and not definition
of sequence.


http://docs.python.org/3/library/collections.abc.html says:

> This module provides *abstract base 
> classes*that 
> can be used to test whether a class provides a particular interface;
for example, whether it is hashable or whether it is a mapping.

And collections.abc.Sequence requires "index()" and "count()".

What is the requirement for calling something is "sequence"?

Off Topc: Sequence.__iter__ uses __len__ and __getitem__ but default
iterator uses only __getitem__. This difference is ugly.


-- 
INADA Naoki  
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com