Before jumping in:
In many cases, when you want to reverse an enumerate, it’s small and
fixed-sized, so there’s a trivial way to do this: Just store the enumerate
iterator in a tuple, and tuples are reversible.
for idx, value in reversed(tuple(enumerate(stuff))):
But of course there are som
Brandt Bucher wrote:
> This leads me to believe that we’re approaching the problem wrong. Rather
> than making a
> copy and working on it, I think the problem would be better served by a
> protocol that runs
> the default implementation, then calls some under hook on the subclass to
> build a
>
Some additional things that might be worth doing. I believe this exposes enough
to allow people to build an object graph walker out of the `pickle`/`copy`
protocol without having to access fragile internals, and without restricting
future evolution of the internals of the protocol. See [the same
This was [posted on -ideas][1], but apparently many people didn't see it
because of the GMane migration going on at exactly the same time. At any rate,
Antoine Pitrou suggested it should be discussed on -dev instead. And this gives
me a chance to edit it (apparently it was markdown-is enough to
On Mar 20, 2016, at 09:07, Michael Felt wrote:
>
>> On 2016-03-18 05:57, Andrew Barnert via Python-Dev wrote:
>> Yeah, C99 (6.7.2.1) allows "a qualified or unqualified version of _Bool,
>> signed int, unsigned int, or some other implementation-defined type", a
On Mar 19, 2016, at 18:18, Guido van Rossum wrote:
>
> Second, https://github.com/python/typing/issues/186. This builds on
> the previous syntax but deals with the other annoyance of long
> argument lists, this time in case you *do* care about the types. The
> proposal is to allow writing the arg
On Mar 17, 2016, at 18:35, MRAB wrote:
>
>> On 2016-03-18 00:56, Michael Felt wrote:
>> Update:
>> Is this going to be impossible?
> From what I've been able to find out, the C89 standard limits bitfields to
> int, signed int and unsigned int, and the C99 standard added _Bool, although
> some c
One alternative to consider is using Cygwin. A complete Cygwin environment,
including a GCC toolchain, is pretty small. And it can build a *nix-style
CPython that works inside the Cygwin environment. That may not be sufficient
for a lot of uses, but for your purpose, it should be.
Another alter
On Feb 17, 2016, at 10:44, MRAB wrote:
>
> Is this something that we need to worry about?
>
> Extremely severe bug leaves dizzying number of software and devices vulnerable
> http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/
Is t
On Feb 14, 2016, at 19:05, Guido van Rossum wrote:
>
> I think it's probably too soon to discuss on python-dev, but I do
> think that something like this could be attempted in 3.6 or (more
> likely) 3.7, if it really is faster.
>
> An unfortunate issue however is that many projects seem to make
On Feb 12, 2016, at 12:58, Glenn Linderman wrote:
>
>> On 2/12/2016 12:06 PM, Chris Barker wrote:
>> As for the SS# example -- it seems a bad idea to me to store a SS# number as
>> an integer anyway -- so all the weird IDs etc. formats aren't really
>> relevant...
>
> SS#... why not integer?
On Thursday, February 11, 2016 8:10 PM, Glenn Linderman
wrote:
>On 2/11/2016 7:56 PM, David Mertz wrote:
>
>Great PEP overall. We definitely don't want the restriction to grouping
>numbers only in threes. South Asian crore use grouping in twos.
>>https://en.m.wikipedia.org/wiki/Crore
>>
>Intere
On Thursday, February 11, 2016 7:20 PM, Stephen J. Turnbull
wrote:
> I think we should keep it around forever. Even my slowest colleagues
> are learning that they should record their seeds and PRNG algorithms
> for reproducibility's sake. :-)
+1
> For that matter, restore Wichmann-Hill.
So
On Thursday, February 11, 2016 10:35 AM, Jeff Hardy wrote:
>On Thu, Feb 11, 2016 at 10:15 AM, Andrew Barnert via Python-Dev
> wrote:
>
>>That's a good point: we need style rules for PEP 8.
...
>>It might be simpler to write a "whitelist" than a "bl
On Feb 11, 2016, at 10:15, Andrew Barnert via Python-Dev
wrote:
>
> That's a good point: we need style rules for PEP 8.
One more point: should the tutorial mention underscores? It looks like the
intro docs for a lot of the other languages do. And it would only take one
short
On Feb 11, 2016, at 09:39, Terry Reedy wrote:
>
> If trailing _ is allowed, to simplify the implementation, I would like PEP 8,
> while on the subject, to say something like "While trailing _s on numbers are
> allowed, to simplify the implementation, they serve no purpose and are
> strongly di
On Feb 11, 2016, at 00:22, Georg Brandl wrote:
>
> Allowing underscores in string arguments to the ``Decimal`` constructor. It
> could be argued that these are akin to literals, since there is no Decimal
> literal available (yet).
I'm +1 on this. Partly for consistency (see below)--but also,
On Feb 11, 2016, at 02:13, Steven D'Aprano wrote:
>
>> On Wed, Feb 10, 2016 at 08:41:27PM -0800, Andrew Barnert wrote:
>> They're both presented as something the syntax allows, and neither one
>> looks like something I'd ever want to write, much less promote in a
>> style guide or something, b
On Feb 10, 2016, at 16:21, Steven D'Aprano wrote:
>
>> On Wed, Feb 10, 2016 at 03:45:48PM -0800, Andrew Barnert via Python-Dev
>> wrote:
>> On Feb 10, 2016, at 14:20, Georg Brandl wrote:
>>
>> First, general questions: should the PEP mention the Decim
On Feb 10, 2016, at 15:11, eryk sun wrote:
>
> On Wed, Feb 10, 2016 at 2:30 PM, Andrew Barnert via Python-Dev
> wrote:
>> [^3]: Say you write a program that assumes it will only be run on Shift-JIS
>> systems, and you use
>> CreateFileA to create a file named
On Feb 10, 2016, at 14:20, Georg Brandl wrote:
First, general questions: should the PEP mention the Decimal constructor? What
about int and float (I'd assume int(s) continues to work as always, while
int(s, 0) gets the new behavior, but if that isn't obviously true, it may be
worth saying expl
On Wednesday, February 10, 2016 6:50 AM, Stephen J. Turnbull
wrote:
> Andrew Barnert via Python-Dev writes:
>
>> That doesn't mean the problem can't be solved. Apple solved their
>> equivalent problem, albeit by sacrificing backward compatibility in
>> a wa
On Wednesday, February 10, 2016 12:47 AM, Victor Stinner
wrote:
> > 2016-02-10 9:30 GMT+01:00 Paul Moore :
>> Whether removing the bytes interface is feasible, given that there's
>> then no way that works across Python 2 and 3 of writing code that
>> manipulates the sort of bytes-that-use-mul
On Feb 9, 2016, at 20:17, Stephen J. Turnbull wrote:
>> It really requires going through all the OS calls and either (a) making
>> them consistently decode bytes to str using the declared FS encoding
>> (currently 'mbcs', but I see no reason we can't make it 'utf_8'),
>
> If it were that easy,
On Feb 9, 2016, at 17:37, Steve Dower wrote:
>
> Could we perhaps redefine bytes paths on Windows as utf8 and use Unicode
> everywhere internally?
When you receive bytes from argv, stdin, a text file, a GUI, a named pipe,
etc., and then use them as a path, Python treating them as UTF-8 would b
On Feb 9, 2016, at 03:44, Phil Thompson wrote:
>
> There are a number of things I'd like to express but cannot find a way to do
> so...
>
> - objects that implement the buffer protocol
That seems like it should be filed as a bug with the typing repo. Presumably
this is just an empty type that
On Tuesday, February 9, 2016 8:14 AM, Michel Desmoulin
wrote:
> I give regular Python trainings and I see similar errors regularly such as:
>
> - not returning something;
> - using something without putting the result back in a variable.
>
> However, these are impossible to warn about.
>
> Wh
> On Feb 8, 2016, at 11:13, Guido van Rossum wrote:
>
>> On Mon, Feb 8, 2016 at 9:44 AM, Victor Stinner
>> wrote:
>> I changed the Python compiler to ignore any kind "constant
>> expressions", whereas it only ignored strings and integers before:
>> http://bugs.python.org/issue26204
>>
>> The c
On Monday, February 8, 2016 9:11 AM, Alexander Walters
wrote:
>
> On 2/8/2016 12:02, Brett Cannon wrote:
>>
>>
>> If Unicode string don't work in Python 2 then what is Python 2/3 to do
>> as a cross-platform solution if we completely remove bytes support in
>> Python 3? Wouldn't that me
On Monday, February 8, 2016 8:23 AM, Ben Hoyt wrote:
>Just a suggestion for a documentation tweak. Currently the docs for len() on a
>set say this:
>
> .. describe:: len(s)>
> Return the cardinality of set *s*.
>
>I'm a relatively seasoned programmer, but I don't really have a maths
>b
On Friday, February 5, 2016 11:57 AM, Emile van Sebille wrote:
> Aah, 'must' is less restrictive in this context than I expected. When
> you combine the two halves the first part might be more accurately
> phrased as 'The program must make source code available' rather than
> 'must include'
On Feb 1, 2016, at 19:44, Terry Reedy wrote:
>
>> On 2/1/2016 3:39 PM, Andrew Barnert via Python-Dev wrote:
>>
>> There are already multiple duplicate questions every month on
>> StackOverflow from people asking "how do I find the source to stdlib
>> modu
On Feb 1, 2016, at 09:59, mike.romb...@comcast.net wrote:
>
> If the stdlib were to use implicit namespace packages
> ( https://www.python.org/dev/peps/pep-0420/ ) and the various
> loaders/importers as well, then python could do what I've done with an
> embedded python application for years. Fr
Looking over the thread and the two issues, you've got good arguments for why
the improved code will be the most common code, and good benchmarks for various
kinds of real-life code, but it doesn't seem like you'd tried to stress it on
anything that could be made worse. From your explanations an
On Jan 25, 2016, at 19:32, INADA Naoki wrote:
>
>> On Tue, Jan 26, 2016 at 12:02 PM, Andrew Barnert wrote:
>> On Jan 25, 2016, at 18:21, INADA Naoki wrote:
>> >
>> > I'm very interested in it.
>> >
>> > Ruby 2.2 and PHP 7 are faster than Python 2.
>> > Python 3 is slower than Python 2.
>>
>> S
On Jan 25, 2016, at 18:21, INADA Naoki wrote:
>
> I'm very interested in it.
>
> Ruby 2.2 and PHP 7 are faster than Python 2.
> Python 3 is slower than Python 2.
Says who?
That was certainly true in the 3.2 days, but nowadays, most things that differ
seem to be faster in 3.x. Maybe it's just
On Jan 25, 2016, at 14:46, Victor Stinner wrote:
>
> You can design an AST optimizer to compile some functions to C and
> then register them as specialized code at runtime. I have a side
> project to use Cython and/or pythran to specialize some functions
> using type annotation on parameters.
Th
On Jan 25, 2016, at 13:43, Victor Stinner wrote:
>
> According to microbenchmarks, the most promising optimizations are
> functions inlining (Python function calls are slow :-/) and specialize
> the code for the type of arguments.
Can you specialize a function with a C API function, or only with
On Wednesday, January 20, 2016 4:10 PM, Brett Cannon wrote:
>I think Glenn was assuming we had a single, global version # that all dicts
>shared without having a per-dict version ID. The key thing here is that we
>have a global counter that tracks the number of mutations for all dictionaries
On Jan 20, 2016, at 00:35, Ben Finney wrote:
>
> francismb writes:
>
>> what's your opinion about a code-formatter bot for cpython.
>
> What is the proposal? The opinions will surely depend on:
... plus:
* How does the formatter bot deal with "legacy code"? Large parts of CPython
predate PE
> On Jan 19, 2016, at 08:56, Jim J. Jewett wrote:
>
> On Mon Jan 18 03:39:42 EST 2016, Andrew Barnert pointed out:
>>
>> Alternatively, it could say something like "braces must not be omitted;
>> when other C styles would use a braceless one-liner, a one-liner with
>> braces should be used inste
On Jan 17, 2016, at 11:10, Brett Cannon wrote:
>
> While doing a review of http://bugs.python.org/review/26129/ I asked to have
> curly braces put around all `if` statement bodies. Serhiy pointed out that
> PEP 7 says curly braces are optional:
> https://www.python.org/dev/peps/pep-0007/#id5.
On Jan 16, 2016, at 08:05, Aviv Cohn via Python-Dev
wrote:
>
> The `getargspec` function in the `inspect` module enforces the input
> parameter to be either a method or a function.
The `getargspec` already works with classes, callable objects, and some
builtins.
It's also deprecated, in part
On Jan 13, 2016, at 14:49, Matthew Paulson wrote:
>
> Hi Victor:
>
> No, I'm using the new heap analysis functions in DS2015.
Isn't that going to report any memory that Python's higher level allocators
hold in their freelists as leaked, even though it isn't leaked?
> We think we have found o
On Jan 11, 2016, at 15:24, Victor Stinner wrote:
>
> 2016-01-12 0:07 GMT+01:00 Gregory P. Smith :
>>> Changes
>>> ===
>>>
>>> (...)
>>
>> Please be more explicit about what tests you are performing on the values.
>> setitem's "if the value is different" really should mean "if value is not
>
On Jan 9, 2016, at 16:17, Blake Griffith wrote:
>
> A little update, I got ^, &, and | working for bytearrays. You can view the
> diff here:
> https://github.com/python/cpython/compare/master...cowlicks:bitwise-bytes?expand=1
If you upload the diff to the issue on the tracker, the reitveld code
On Jan 7, 2016, at 15:57, Martin Panter wrote:
>
>> On 7 January 2016 at 22:26, Blake Griffith
>> wrote:
>> I'm interested in adding the functionality to do something like:
>>
> b'a' ^ b'b'
>> b'\x03'
>>
>>
>> Instead of the good ol' TypeError.
>>
>> I think both bytes and bytearray sho
On Dec 29, 2015, at 13:03, Facundo Batista wrote:
>
>> On Tue, Dec 29, 2015 at 4:38 PM, Andrew Barnert wrote:
>> I usually just don't bother. You can violate PEP 257 when it makes sense,
>> just like PEP 8. They're just guidelines, not iron-clad rules.
>
> Yeap, but pep257 (the tool [0]) comp
On Dec 29, 2015, at 10:27, Facundo Batista wrote:
> I was reading PEP 257 and it says that all public methods from a class
> (including __init__) should have a docstring.
>
> Why __init__?
>
> It's behaviour is well defined (inits the instance), and the
> initialization parameters should be des
On Dec 21, 2015, at 14:07, Chris Barker wrote:
>
> and there are a LOT of next-to worthless docstrings in the stdlib -- it would
> be nice to clean them all up.
>
> Is there any reason not to, other than someone having to do the work?
Is this just a matter of _datetimemodule.c (and various oth
On Friday, December 18, 2015 1:09 PM, Guido van Rossum wrote:
>I guess we could make the default arg to sleep() 1e9. Or make it None and
>special-case it. I don't feel strongly about this -- I'm not sure how baffling
>it would be to accidentally leave out the delay and find your code sleeps
>
On Dec 18, 2015, at 10:36, Guido van Rossum wrote:
>
>> On Fri, Dec 18, 2015 at 10:25 AM, Szieberth Ádám wrote:
>> Thanks for your reply Guido!
>>
>> > - In theory, instead of waiting for a Future that is cancelled by a
>> > handler, you should be able to use asyncio.sleep() with a very large n
On Dec 18, 2015, at 10:25, Szieberth Ádám wrote:
>
>> - In theory, instead of waiting for a Future that is cancelled by a
>> handler, you should be able to use asyncio.sleep() with a very large number
>> (e.g. a million seconds).
>
> I was thinking on this too but it seemed less explicit to me t
> On Dec 18, 2015, at 04:56, Steven D'Aprano wrote:
>
>>> On Thu, Dec 17, 2015 at 09:30:24AM -0800, Andrew Barnert via Python-Dev
>>> wrote:
>>> On Dec 17, 2015, at 07:38, Franklin? Lee
>>> wrote:
>>>
>>> The nested dicti
the descriptor call, you can cache the descriptor itself but it will rarely
help, and the builtin method cache probably already takes care of 99% of the
cases where it would help, so I don't see what you're going to get here.
>> On Thu, Dec 17, 2015 at 5:17 PM, Andrew Barnert w
On Dec 17, 2015, at 13:37, Andrew Barnert via Python-Dev
wrote:
>
> On Thursday, December 17, 2015 11:19 AM, Franklin? Lee
> wrote:
>
>
>> ...
>> as soon as I figure out how descriptors actually work...
>
>
> I think you need to learn what LOAD_ATTR
On Thursday, December 17, 2015 11:19 AM, Franklin? Lee
wrote:
> ...
> as soon as I figure out how descriptors actually work...
I think you need to learn what LOAD_ATTR and the machinery around it actually
does before I can explain why trying to optimize it like globals-vs.-builtins
doesn't
On Dec 17, 2015, at 07:38, Franklin? Lee wrote:
>
> The nested dictionaries are only for nested scopes (and inner
> functions don't create nested scopes). Nested scopes will already
> require multiple lookups in parents.
I think I understand what you're getting at here, but it's a really confusi
> On Dec 16, 2015, at 03:25, Paul Sokolovsky wrote:
>
> Hello,
>
> On Tue, 15 Dec 2015 17:29:26 -0800
> Roy Williams wrote:
>
>> @Kevin correct, that's the point I'd like to discuss. Most other
>> mainstream languages that implements async/await expose the
>> programming model with Tasks/Futu
On Dec 15, 2015, at 17:29, Roy Williams wrote:
>
> My proposal would be to automatically wrap the return value from an `async`
> function or any object implementing `__await__` in a future with
> `asyncio.ensure_future()`. This would allow async/await code to behave in a
> similar manner to o
On Dec 9, 2015, at 03:43, טל ח wrote:
>
> Hi,
>
> I think it could be helpful for everyone if the function proposed by user
> "SomethingSomething" can be added as built-in
> in Python
Why? When he was asked what use it might have, he didn't have an answer.
Also, notice that the answer he prov
On Dec 4, 2015, at 00:38, Nick Coghlan wrote:
>
> On 4 December 2015 at 12:48, Andrew Barnert via Python-Dev
> wrote:
>> On Dec 3, 2015, at 17:25, Steven D'Aprano wrote:
>>>> On Thu, Dec 03, 2015 at 09:25:53AM -0800, Andrew Barnert via Python-Dev
>>>&
On Dec 3, 2015, at 17:25, Steven D'Aprano wrote:
>
> On Thu, Dec 03, 2015 at 09:25:53AM -0800, Andrew Barnert via Python-Dev wrote:
>>> On Dec 3, 2015, at 08:15, MRAB wrote:
>>>
>>>>> On 2015-12-03 15:09, Random832 wrote:
>>>>> On 201
> On Dec 3, 2015, at 08:15, MRAB wrote:
>
>>> On 2015-12-03 15:09, Random832 wrote:
>>> On 2015-12-03, Laura Creighton wrote:
>>> Who came up with the word 'display' and what does it have going for
>>> it that I have missed? Right now I think its chief virtue is that
>>> it is a meaningless nou
On Dec 2, 2015, at 07:01, Random832 wrote:
>
> On 2015-12-02, Victor Stinner wrote:
>>> Are there plans for a Python 4?
>>
>> No. Don't. Don't schedule any "removal" or *any* kind of "break
>> backward compatibility" anymore, or you will definetly kill the Python
>> community.
>
> I feel like
65 matches
Mail list logo
