Re: [Python-Dev] Contribute to Python.org
On 30 July 2014 01:40, Victor Stinner wrote: > Hi, > > You should read the Python Developer Guide: > > https://docs.python.org/devguide/ > > You can also join the core mentorship mailing list: > > http://pythonmentors.com/ For python.org *itself* (as in, the Django application now powering the site), the contribution process is not yet as clear, but the code and issue tracker are at https://github.com/python/pythondotorg and https://mail.python.org/mailman/listinfo/pydotorg-www is the relevant mailing list. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #22003: When initialized from a bytes object, io.BytesIO() now
Le 30/07/2014 02:11, Serhiy Storchaka a écrit : 30.07.14 06:59, Serhiy Storchaka написав(ла): 30.07.14 02:45, antoine.pitrou написав(ла): http://hg.python.org/cpython/rev/79a5fbe2c78f changeset: 91935:79a5fbe2c78f parent: 91933:fbd104359ef8 user:Antoine Pitrou date:Tue Jul 29 19:41:11 2014 -0400 summary: Issue #22003: When initialized from a bytes object, io.BytesIO() now defers making a copy until it is mutated, improving performance and memory use on some use cases. Patch by David Wilson. Did you compare this with issue #15381 [1]? Not really, but David's patch is simple enough and does a good job of accelerating the read-only BytesIO case. $ ./python -m timeit -s 'import i' 'i.readlines()' Before patch: 10 loops, best of 3: 46.9 msec per loop After issue22003 patch: 10 loops, best of 3: 36.4 msec per loop After issue15381 patch: 10 loops, best of 3: 27.6 msec per loop I'm surprised your patch does better here. Any idea why? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #22003: When initialized from a bytes object, io.BytesIO() now
Hi Serhiy, At least conceptually, 15381 seems the better approach, but getting a correct implementation may take more iterations than the (IMHO) simpler change in 22003. For my tastes, the current 15381 implementation seems a little too magical in relying on Py_REFCNT() as the sole indication that a PyBytes can be mutated. For the sake of haste, 22003 only addresses the specific regression introduced in Python 3.x BytesIO, compared to 2.x StringI, where 3.x lacked an equivalent no-copies specialization. David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bluetooth 4.0 support in "socket" module
Am 14.07.14 15:57, schrieb Tim Tisdall: > Also, is there a method to test changes against all the different *nix > variations? Is Bluez the standard across the different *nix variations? Perhaps not the answer you expected, but: Python uses autoconf for feature testing. You can be certain that the API *will* vary across system vendors. For example, FreeBSD apparently uses ng_hci(4): http://www.unix.com/man-page/freebsd/4/ng_hci/ If you add features, all you need to make sure that Python continues to compile when the platform feature is not present. People using the other systems are then free to contribute support for their platforms. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #22003: When initialized from a bytes object, io.BytesIO() now
30.07.14 16:59, Antoine Pitrou написав(ла): Le 30/07/2014 02:11, Serhiy Storchaka a écrit : 30.07.14 06:59, Serhiy Storchaka написав(ла): 30.07.14 02:45, antoine.pitrou написав(ла): http://hg.python.org/cpython/rev/79a5fbe2c78f changeset: 91935:79a5fbe2c78f parent: 91933:fbd104359ef8 user:Antoine Pitrou date:Tue Jul 29 19:41:11 2014 -0400 summary: Issue #22003: When initialized from a bytes object, io.BytesIO() now defers making a copy until it is mutated, improving performance and memory use on some use cases. Patch by David Wilson. Did you compare this with issue #15381 [1]? Not really, but David's patch is simple enough and does a good job of accelerating the read-only BytesIO case. Ignoring tests and comments my patch adds/removes/modifies about 200 lines, and David's patch -- about 150 lines of code. But it's __sizeof__ looks not correct, correcting it requires changing about 50 lines. In sum the complexity of both patches is about equal. $ ./python -m timeit -s 'import i' 'i.readlines()' Before patch: 10 loops, best of 3: 46.9 msec per loop After issue22003 patch: 10 loops, best of 3: 36.4 msec per loop After issue15381 patch: 10 loops, best of 3: 27.6 msec per loop I'm surprised your patch does better here. Any idea why? I didn't look at David's patch too close yet. But my patch includes optimization for end-of-line scanning. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #22003: When initialized from a bytes object, io.BytesIO() now
I'd like to point out a couple of compiler warnings on Windows:
On Tue, Jul 29, 2014 at 6:45 PM, antoine.pitrou
wrote:
> diff --git a/Modules/_io/bytesio.c b/Modules/_io/bytesio.c
> --- a/Modules/_io/bytesio.c
> +++ b/Modules/_io/bytesio.c
> @@ -33,6 +37,45 @@
> return NULL; \
> }
>
> +/* Ensure we have a buffer suitable for writing, in the case that an
> initvalue
> + * object was provided, and we're currently borrowing its buffer. `size'
> + * indicates the new buffer size allocated as part of unsharing, to avoid a
> + * redundant reallocation caused by any subsequent mutation. `truncate'
> + * indicates whether truncation should occur if `size` < self->string_size.
> + *
> + * Do nothing if the buffer wasn't shared. Returns 0 on success, or sets an
> + * exception and returns -1 on failure. Existing state is preserved on
> failure.
> + */
> +static int
> +unshare(bytesio *self, size_t preferred_size, int truncate)
> +{
> +if (self->initvalue) {
> +Py_ssize_t copy_size;
> +char *new_buf;
> +
> +if((! truncate) && preferred_size < self->string_size) {
..\Modules\_io\bytesio.c(56): warning C4018: '<' : signed/unsigned mismatch
> +preferred_size = self->string_size;
> +}
> +
> +new_buf = (char *)PyMem_Malloc(preferred_size);
> +if (new_buf == NULL) {
> +PyErr_NoMemory();
> +return -1;
> +}
> +
> +copy_size = self->string_size;
> +if (copy_size > preferred_size) {
..\Modules\_io\bytesio.c(67): warning C4018: '>' : signed/unsigned mismatch
> +copy_size = preferred_size;
> +}
> +
> +memcpy(new_buf, self->buf, copy_size);
> +Py_CLEAR(self->initvalue);
> +self->buf = new_buf;
> +self->buf_size = preferred_size;
> +self->string_size = (Py_ssize_t) copy_size;
> +}
> +return 0;
> +}
>
> /* Internal routine to get a line from the buffer of a BytesIO
> object. Returns the length between the current position to the
--
Zach
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #22003: When initialized from a bytes object, io.BytesIO() now
Le 30/07/2014 15:48, Serhiy Storchaka a écrit : Ignoring tests and comments my patch adds/removes/modifies about 200 lines, and David's patch -- about 150 lines of code. But it's __sizeof__ looks not correct, correcting it requires changing about 50 lines. In sum the complexity of both patches is about equal. I meant that David's approach is conceptually simpler, which makes it easier to review. Regardless, there is no exclusive-OR here: if you can improve over the current version, there's no reason not to consider it/ I didn't look at David's patch too close yet. But my patch includes optimization for end-of-line scanning. Ahah, unrelated stuff :-) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
