Great, and thanks for the info! -Ben
On Sep 13, 2016 5:31 PM, "Brett Cannon" wrote:
>
>
> On Tue, 13 Sep 2016 at 13:56 Ben Hoyt wrote:
>
>> I noticed in [PEP 512 - Document steps to commit a pull request](
>> https://www.python.org/dev/peps/pep-0512/#document-steps-to-commit-a-
>> pull-request)
On 2016-09-14 00:42, Greg Ewing wrote:
MRAB wrote:
On 2016-09-13 07:57, Mark Lawrence via Python-Dev wrote:
"tables the idea" has the US meaning of close it down, not the UK
meaning of open it up? :)
A better phrase would've been "shelves the idea". There's even a module
in Python called "s
MRAB wrote:
On 2016-09-13 07:57, Mark Lawrence via Python-Dev wrote:
"tables the idea" has the US meaning of close it down, not the UK
meaning of open it up? :)
A better phrase would've been "shelves the idea". There's even a module
in Python called "shelve", which makes it Pythonic. :-)
On Tue, 13 Sep 2016 at 13:56 Ben Hoyt wrote:
> I noticed in [PEP 512 - Document steps to commit a pull request](
> https://www.python.org/dev/peps/pep-0512/#document-steps-to-commit-a-pull-request)
> it says that CPython on GitHub won't be able to use GitHub's "Merge" button
> on pull requests, b
I noticed in [PEP 512 - Document steps to commit a pull request](
https://www.python.org/dev/peps/pep-0512/#document-steps-to-commit-a-pull-request)
it says that CPython on GitHub won't be able to use GitHub's "Merge" button
on pull requests, because we want a linear history with one commit per
cha
On Tue, Sep 13, 2016 at 12:01 PM, Yurij Alexandrovich
wrote:
>
> Cssdbpy is a simple SSDB client written on Cython. Faster standart SSDB
> client.
>
> https://github.com/deslum/cssdbpy
>
Congrats. You should post this in python-annouce@ list. This list
python-dev is about CPython development.
Hello!
Post my open source client for take feedback.
Cssdbpy is a simple SSDB client written on Cython. Faster standart SSDB
client.
https://github.com/deslum/cssdbpy
Thanks.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
On 13.09.2016 20:21, Tres Seaver wrote:
*Lots* of library authors have to straddle Python versions: consumers of
those libraries only get to pick and choose when their code is at the
"leaf" of the dependency tree (the application).
Maybe, I didn't express myself well but this was not my intende
Nikolaus Rath writes:
> Out of curiosity: is this test repeated periodically on different
> architectures? Or could it be that it only ever was true 10 years
> ago on Tim's Power Mac G5 (or whatever he used)?
This is the same Tim Peters of the eponymous test for readability of
syntax: "Syntax
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/13/2016 02:11 PM, Sven R. Kunze wrote:
> On 13.09.2016 19:59, MRAB wrote:
>> The recommended way of dealing with features across different
>> versions of Python is to check for them and see if they raise
>> NameError or whatever, but I wonder if
On 13.09.2016 19:59, MRAB wrote:
The recommended way of dealing with features across different versions
of Python is to check for them and see if they raise NameError or
whatever, but I wonder if there would be any benefit to recording such
things somewhere, e.g. sys.features['ordered_args'] re
[Terry Reedy ]
>> Tim Peters investigated and empirically determined that an
>> O(n*n) binary insort, as he optimized it on real machines, is faster
>> than O(n*logn) sorting for up to around 64 items.
[Nikolaus Rath ]
> Out of curiosity: is this test repeated periodically on different
> architect
On 2016-09-13 11:44, Nick Coghlan wrote:
On 13 September 2016 at 08:25, Gregory P. Smith wrote:
At this point I think coding up an example patch against beta1 offering a
choice of disordered iteration capability that does not increase memory or
iteration overhead in any significant way is neede
On 2016-09-13 07:57, Mark Lawrence via Python-Dev wrote:
On 12/09/2016 23:25, Gregory P. Smith wrote:
[snip]
The problem is... I don't know how to express this as an API. Which
sinks my whole though process and tables the idea.
"tables the idea" has the US meaning of close it down, not the
On Tue, Sep 13, 2016, at 13:24, Nikolaus Rath wrote:
> On Sep 11 2016, Terry Reedy wrote:
> > Tim Peters investigated and empirically determined that an
> > O(n*n) binary insort, as he optimized it on real machines, is faster
> > than O(n*logn) sorting for up to around 64 items.
>
> Out of curios
On Sep 11 2016, Terry Reedy wrote:
> Tim Peters investigated and empirically determined that an
> O(n*n) binary insort, as he optimized it on real machines, is faster
> than O(n*logn) sorting for up to around 64 items.
Out of curiosity: is this test repeated periodically on different
architecture
On 5 September 2016 at 21:19, Paul Moore wrote:
>
> The code I'm looking at doesn't use the raw stream (I think). The
> problem I had (and the reason I was concerned) is that the code does
> some rather messy things, and without tracing back through the full
> code path, I'm not 100% sure *what* l
Ok, it's start listing regressions/major issues :-)
* Bug in _PyDict_Pop() on a splitted table:
http://bugs.python.org/issue28120 -- bug in the new compact dict
implementation
Victor
2016-09-13 1:35 GMT+02:00 Ned Deily :
> On behalf of the Python development community and the Python 3.6 release
On 13 September 2016 at 08:25, Gregory P. Smith wrote:
> At this point I think coding up an example patch against beta1 offering a
> choice of disordered iteration capability that does not increase memory or
> iteration overhead in any significant way is needed.
>
> The problem is... I don't know
On 13 September 2016 at 12:37, Tim Delaney wrote:
> Personally I expect all Python 3.6 implementations will have
> order-preserving dict as that's the easiest way to achieve the existing
> guarantees.
Not all Python 3 implementation will be able to afford the memory hit
that comes from doing that
20 matches
Mail list logo
