On 30 April 2015 at 06:39, Greg Ewing wrote:
> Aaargh, this is what we get for overloading the word
> "coroutine". The Wikipedia article is talking about a
> technique where coroutines yield control to other
> explicitly identified coroutines.
Yep, I understand that. It's just that that's what I
On 30 April 2015 at 02:52, Nick Coghlan wrote:
> This request isn't about understanding the implementation details,
> it's about understanding what Python *users* will gain from the PEP
> without *needing* to understand the implementation details.
>
> For that, I'd like to see some not-completely-
On 30 April 2015 at 09:58, Greg Ewing wrote:
> Ethan Furman wrote:
>>
>> Having gone through the PEP again, I am still no closer to understanding
>> what happens here:
>>
>> data = await reader.read(8192)
>>
>> What does the flow of control look like at the interpreter level?
>
>
> Are you sure
On 29 April 2015 at 20:19, Paul Moore wrote:
> However, just to make my point precise, here's a more or less direct
> translation of the Wikipedia code into Python. It doesn't actually
> work, because getting the right combinations of yield and send stuff
> is confusing
On 30 April 2015 at 20:32, Guido van Rossum wrote:
>> Then I strongly request a more specific name than coroutine.
>
> No, this is the name we've been using since PEP 342 and it's still the same
> concept.
However, it is (as I noted in my other email) not very well
documented. There isn't a gloss
On 1 May 2015 at 12:54, Steven D'Aprano wrote:
> You mean we could write code like this?
>
> def await(x):
> ...
>
>
> if condition:
> async def spam():
> await (eggs or cheese)
> else:
> def spam():
> await(eggs or cheese)
>
>
> I must admit that's kind of cool, but I'
On 5 May 2015 at 19:25, Yury Selivanov wrote:
> On 2015-05-05 7:27 AM, Wolfgang wrote:
>> Even the discussion on python-dev suggests there is some time needed
>> to finalize all this.
>
> I'd say that:
>
> 80% of the recent discussion of the PEP is about terminology.
> 10% is about whether we shou
(Yury gave similar responses, so (a) I'll just respond here, and (b)
it's encouraging that you both responded so quickly with the same
message)
On 5 May 2015 at 20:44, Brett Cannon wrote:
>> That's not to say that everything needs to be beginner-friendly, but
>> it *does* mean that it's hard for
On 5 May 2015 at 21:38, Guido van Rossum wrote:
> Jumping in to correct one fact.
>
> On Tue, May 5, 2015 at 12:44 PM, Brett Cannon wrote:
>>
>>
>> On Tue, May 5, 2015 at 3:14 PM Paul Moore wrote:
>>>
>>> Well, twisted always had defer_to_thread. As
On 5 May 2015 at 21:00, Yury Selivanov wrote:
> On 2015-05-05 3:40 PM, Jim J. Jewett wrote:
>>
>> On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated PEP492.
>>
>> Where are the following over-simplifications wrong?
>>
>> (1) The PEP is intended for use (almost exclusively) with
>>
On 5 May 2015 at 21:57, Guido van Rossum wrote:
> On Tue, May 5, 2015 at 1:39 PM, Paul Moore wrote:
>>
>> It's very hard to separate coroutines from asyncio, because there's no
>> other example (not even a toy one) to reason about.
>
> Wh
On 5 May 2015 at 22:12, Guido van Rossum wrote:
> I apologize for the confusing documentation. We need more help from
> qualified tech writers! Writing PEP 3156 was a huge undertaking for me;
> after that I was exhausted and did not want to take on writing the end user
> documentation as well, so
On 5 May 2015 at 22:09, Jim J. Jewett wrote:
> Proposed second paragraph of the abstract:
>
> This PEP assumes that the asynchronous tasks are scheduled and
> coordinated by an Event Loop similar to that of stdlib module
> asyncio.events.AbstractEventLoop. While the PEP is not tied to
> any speci
On 5 May 2015 at 22:25, Guido van Rossum wrote:
>> I'd be interested in writing, for instructional purposes, a toy but
>> complete event loop. But I'm *not* really interested in trying to
>> reverse engineer the required interface.
>
> This is a great idea. What kind of application do you have in
On 5 May 2015 at 22:38, Yury Selivanov wrote:
> n 2015-05-05 5:01 PM, Paul Moore wrote:
>>
>> On 5 May 2015 at 21:00, Yury Selivanov wrote:
>>>
>>> On 2015-05-05 3:40 PM, Jim J. Jewett wrote:
>>>>
>>>> On Tue May 5 18:29:44 CEST 2015, Yury
On 5 May 2015 at 23:25, Yury Selivanov wrote:
>> Note that I don't have a problem with there being no existing
>> implementation other than asyncio. I'd just like it if we could be
>> clear over exactly what we mean when we say "the PEP is not tied to
>> asyncio".
>
> Well, "the PEP is not tied to
On 5 May 2015 at 23:28, Guido van Rossum wrote:
>> At this point, *all* I'm thinking of is a toy. So, an implementation
>> somewhat parallel to asyncio, but where the event loop just passes
>> control to the next task - so no IO multiplexing. Essentially Greg
>> Ewing's example up to, but not incl
On 6 May 2015 at 00:58, Guido van Rossum wrote:
> I totally forgot to publicly congratulate Yury on this PEP. He's put a huge
> effort into writing the PEP and the implementation and managing the
> discussion, first on python-ideas, later on python-dev. Congrats, Yury! And
> thanks for your effort
On 6 May 2015 at 07:46, Greg Ewing wrote:
> Another problem with the "core" idea is that
> you can't start with an event loop that "just does
> scheduling" and then add on other features such
> as I/O *from the outside*. There has to be some
> point at which everything comes together, which
> mean
On 6 May 2015 at 09:20, Greg Ewing wrote:
>> That doesn't cover any of the higher level abstractions like tasks or
>> futures (at least not by those names or with those interfaces).
>
> Because a minimal event loop doesn't *need* those.
It doesn't *need* them, but as abstractions they allow easie
On 10 May 2015 at 17:34, Mark Rosenblitt-Janssen
wrote:
> Here's something that might be wrong in Python (tried on v2.7):
>
class int(str): pass
>
int(3)
> '3'
It's not wrong as such. It is allowed to define your own class that
subclasses a builtin class, and it's allowed to shadow buil
On 11 May 2015 at 19:50, yury.selivanov wrote:
> https://hg.python.org/cpython/rev/b78127eafad7
> changeset: 95956:b78127eafad7
> branch: 3.4
> parent: 95953:a983d63e3321
> user:Yury Selivanov
> date:Mon May 11 14:48:38 2015 -0400
> summary:
> asyncio: async() functi
On 11 May 2015 at 20:47, Yury Selivanov wrote:
> Yes, I'm in the process of writing it ;) (as well as for new
> set_task_factory())
Cool - sorry for being a nag :-)
Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/
On 6 May 2015 at 16:46, Guido van Rossum wrote:
> This is actually a great idea, and I encourage you to go forward with it.
> The biggest piece missing from your inventory is probably Task, which is
> needed to wrap a Future around a coroutine.
OK, I've been doing some work on this. You're right,
On 8 September 2017 at 15:57, Eric V. Smith wrote:
> I've written a PEP for what might be thought of as "mutable namedtuples with
> defaults, but not inheriting tuple's behavior" (a mouthful, but it sounded
> simpler when I first thought of it). It's heavily influenced by the attrs
> project. It u
On 9 September 2017 at 00:04, Eric Snow wrote:
>add_recv_fifo(name=None):
>
> Create a new FIFO, associate the two ends with the involved
> interpreters, and return the side associated with the interpreter
> in which "add_recv_fifo()" was called. A FIFOReader gets tied to
>
On 2 October 2017 at 06:13, Raymond Hettinger
wrote:
>
>> On Oct 1, 2017, at 7:34 PM, Nathaniel Smith wrote:
>>
>> In principle re.compile() itself could be made lazy -- return a
>> regular exception object that just holds the string, and then compiles
>> and caches it the first time it's used. M
On 16 October 2017 at 02:33, Yury Selivanov wrote:
> Stage 1. A new execution context PEP to solve the problem *just for
> async code*. The PEP will target Python 3.7 and completely ignore
> synchronous generators and asynchronous generators. It will be based
> on PEP 550 v1 (no chained lookups,
On 16 October 2017 at 12:44, Nick Coghlan wrote:
> The downside is that you'll still need to explicitly revert the decimal
> context before yielding from a generator if you didn't want the context
> change to "leak", but that's not a new constraint - it's one that already
> exists for the thread-l
On 26 October 2017 at 10:24, Victor Stinner wrote:
> We are using Mailman 3 for the new buildbot-status mailing list and it
> works well:
>
> https://mail.python.org/mm3/archives/list/buildbot-sta...@python.org/
>
> I prefer to read archives with this UI, it's simpler to follow
> threads, and it's
On 30 October 2017 at 11:00, Victor Stinner wrote:
> Except of Antoine Pitrou, does everybody else like the new UI? :-)
As I said, I don't particularly like it, but I don't expect to need it
if we get an archived-at header in the mails, and Google indexes
individual mails in the archive correctly
On 3 November 2017 at 14:50, Serhiy Storchaka wrote:
> 03.11.17 16:36, Guido van Rossum пише:
>> Maybe we should remove typing from the stdlib?
>> https://github.com/python/typing/issues/495
>
> I didn't use typing, but AFAIK the most used feature from typing is
> NamedTuple. If move NamedTuple an
On 3 November 2017 at 17:47, Antoine Pitrou wrote:
> On Fri, 3 Nov 2017 12:46:33 -0400
> "Eric V. Smith" wrote:
>> On 11/3/2017 12:15 PM, Victor Stinner wrote:
>> > Hi,
>> >
>> > 2017-11-03 15:36 GMT+01:00 Guido van Rossum :
>> >> Maybe we should remove typing from the stdlib?
>> >> https://githu
On 3 November 2017 at 17:00, Steve Dower wrote:
>
> I'm torn.
>
> If not having typing installed means you can't use "Any" or "Optional" in an
> annotation, that basically kills the whole thing. Some primitives need to be
> there.
Thinking some more about this, I think that it's now established t
On 4 November 2017 at 03:53, Nick Coghlan wrote:
> If I understand correctly, a lot of the complexity in the current
> typing.py implementation is there to make isinstance and issubclass do
> something "useful" at runtime, and to allow generics to be used as
> base classes.
>
> If it wasn't for th
On 6 November 2017 at 03:41, Lukasz Langa wrote:
>
>> On 4 Nov, 2017, at 3:39 AM, Paul Moore wrote:
>>
>> Lukasz Langa said:
>>> So, the difference is in perceived usability. It's psychological.
>>
>> Please, let's not start the "not in
On 6 November 2017 at 03:38, Nick Coghlan wrote:
> - if we ever write "import foo" ourselves, then we're a Python
> developer, and it's our responsibility to work out how to manage
> DeprecationWarning when it gets raised by either our own code, or the
> libraries and frameworks that we use
As so
On 6 November 2017 at 14:16, Gustavo Carneiro wrote:
> But eventually, the warnings in 3rd-party Python modules gradually increased
> because, since warnings are disabled by default, authors of command-line
> tools, or even python modules, don't even realise they are triggering the
> warning.
>
>
On 7 November 2017 at 04:09, Nick Coghlan wrote:
> Given the status quo, how do educators learn that the examples they're
> teaching to their students are using deprecated APIs?
By reading the documentation on what they are teaching, and by testing
their examples with new versions with deprecatio
On 7 November 2017 at 00:35, Donald Stufft wrote:
> Maybe we just need to fully flesh out the idea of a "Python Core" (What
> exists now as “Python”) and a “Python Platform” (Python Core + A select set
> of preinstalled libraries). Then typing can just be part of the Python
> Platform, and gets in
On 7 November 2017 at 05:20, Ethan Smith wrote:
> I'm not so keen on this because I think some things in typing (such as
> NamedTuple) probably deserve to be in the collections module. And some of
> the ABCs could probably also be merged with collections.abc but doing this
> correctly and not all
On 7 November 2017 at 06:39, Nick Coghlan wrote:
> On 7 November 2017 at 09:23, Chris Barker wrote:
>> in short -- we don't have a choice (unless we add an explicit randomization
>> as some suggested -- but that just seems perverse...)
>
> And this is the key point for me: "choosing not to choose
On 7 November 2017 at 10:18, Steve Holden wrote:
> On Tue, Nov 7, 2017 at 12:35 AM, Donald Stufft wrote:
> [..]
>
>>
>> Maybe we just need to fully flesh out the idea of a "Python Core" (What
>> exists now as “Python”) and a “Python Platform” (Python Core + A select set
>> of preinstalled librari
On 7 November 2017 at 13:35, Philipp A. wrote:
> Sorry, I still don’t understand how any of this is a problem.
>
> If you’re an application developer, google “python disable
> DeprecationWarning” and paste the code you found, so your users don’t see
> the warnings.
> If you’re a library developer,
On 7 November 2017 at 14:21, Ethan Furman wrote:
> On 11/07/2017 05:44 AM, Paul Moore wrote:
>
>> If you're a user and your application developer didn't do (1) or a
>> library developer developing one of the libraries your application
>> developer chose to u
On 7 November 2017 at 20:35, Paul G wrote:
> If dictionary order is *not* guaranteed in the spec and the dictionary order
> isn't randomized (which I think everyone agrees is a bit messed up), it would
> probably be useful if you could enable "random order mode" in CPython, so you
> can stress-
On 7 November 2017 at 21:13, Chris Barker wrote:
> the "only until first deletion" part is really hard -- I hope we don't go
> that route. But I don't think insertion-order is non-obvious -- particularly
> with literals.
But I thought we *had* gone that route. Actually, there's no "route"
to go h
On 8 November 2017 at 18:56, Barry Warsaw wrote:
> On Nov 8, 2017, at 08:47, Guido van Rossum wrote:
>>
>> You seem to have missed Nick's posts where he clearly accepts that a middle
>> ground is necessary. R D Murray is also still unconvinced. (And obviously I
>> myself am against reverting to
On 9 November 2017 at 02:17, Barry Warsaw wrote:
> I suppose there are lots of ways to do this, but at least I’m pretty sure we
> all agree that end users shouldn’t see DeprecationWarnings, while developers
> should.
Agreed. Most of the debate to me seems to be around who is an end user
and who
On 22 November 2017 at 13:53, Ivan Levkivskyi wrote:
> On 22 November 2017 at 14:38, Antoine Pitrou wrote:
>>
>> On Wed, 22 Nov 2017 15:03:09 +0200
>> Serhiy Storchaka wrote:
>> > From
>> >
>> > https://stackoverflow.com/questions/45190729/differences-between-generator-comprehension-expressions
On 22 November 2017 at 14:15, Ivan Levkivskyi wrote:
> On 22 November 2017 at 15:09, Paul Moore wrote:
>>
>> On 22 November 2017 at 13:53, Ivan Levkivskyi
>> wrote:
>> > On 22 November 2017 at 14:38, Antoine Pitrou
>> > wrote:
>> >>
&g
On 22 November 2017 at 15:10, Ivan Levkivskyi wrote:
> I think there may be a small misunderstanding here. The situation is
> different for comprehensions and generator expressions,
> let me summarize the current state:
[...]
> What do you think?
Can you point me to where in the docs it explains
On 22 November 2017 at 15:56, Yury Selivanov wrote:
> "await" in generator expressions works *correct*. I explained it here:
> https://bugs.python.org/issue32113
>
> To clarify a bit more:
>
>r = (V for I in X)
>
> is equivalent to:
>
>def _():
> for I in X:
> yield V
>r
On 22 November 2017 at 16:08, Ivan Levkivskyi wrote:
> On 22 November 2017 at 16:56, Yury Selivanov
> wrote:
>>
>> On Wed, Nov 22, 2017 at 10:10 AM, Ivan Levkivskyi
>> wrote:
>> > On 22 November 2017 at 15:47, Paul Moore wrote:
>> [...]
>> I'
On 22 November 2017 at 15:56, Yury Selivanov wrote:
> For synchronous generator expression:
>
>r = (f(i) for i in range(3))
>
> is really:
>
>def _():
> for i in range(3):
> yield f(i)
>r = _()
>
> For an asynchronous generator expression:
>
>r = (await f(i) for i in
On 22 November 2017 at 16:30, Ivan Levkivskyi wrote:
> On 22 November 2017 at 17:24, Antoine Pitrou wrote:
>> Given a comprehension (e.g. list comprehension) is expected to work
>> nominally as `constructor(generator expression)`
>
> As Yury just explained, these two are not equivalent if there i
On 22 November 2017 at 16:38, Ivan Levkivskyi wrote:
> On 22 November 2017 at 17:16, Paul Moore wrote:
>>
>> Docs more importantly than PEP IMO. And are you implying that there's
>> a difference between generator expressions and comprehensions? I
>> thought bo
On 22 November 2017 at 16:47, Ivan Levkivskyi wrote:
> On 22 November 2017 at 17:43, Paul Moore wrote:
>>
>> On 22 November 2017 at 16:30, Ivan Levkivskyi
>> wrote:
>> > On 22 November 2017 at 17:24, Antoine Pitrou
>> > wrote:
>> >> Given a
On 23 November 2017 at 09:14, Steve Holden wrote:
> I would urge developers, in their improvements to the language to support
> asynchronous programming, to bear in mind that this is (currently) a
> minority use case. Why the rush to set complex semantics in stone?
+1
Also, given that languages
On 23 November 2017 at 12:01, Ivan Levkivskyi wrote:
> "I don't use it, therefore it is not needed" is a great argument, thanks.
> Lets just forget about two SO questions and dozens people who up-voted it.
> Do you use async comprehensions? If not, then we don't need them either.
For those of u
On 23 November 2017 at 12:28, Ivan Levkivskyi wrote:
> On 23 November 2017 at 13:11, Paul Moore wrote:
>>
>> On 23 November 2017 at 12:01, Ivan Levkivskyi
>> wrote:
>>
>> > "I don't use it, therefore it is not needed" is a great argume
On 23 November 2017 at 12:42, Ivan Levkivskyi wrote:
>> See e.g. http://www.tornadoweb.org/en/stable/gen.html
>>
>
> Great, so I open this page and see this code:
>
> results = []
> for future in list_of_futures:
> results.append(yield future)
>
> Interesting, why don't they use a comprehensio
On 23 November 2017 at 13:04, Ivan Levkivskyi wrote:
> Let us forget for a moment about other problems and focus on this one: list
> comprehension is currently not equivalent to a for-loop.
> There are two options:
> - Fix this, i.e. make comprehension equivalent to a for-loop even in edge
> cases
On 23 November 2017 at 14:24, Ivan Levkivskyi wrote:
>> My main concern is that comprehension is not equivalent to a for loop
>> for a specific reason - the scope issue. Has anyone looked back at the
>> original discussions to confirm *why* a function was used?
>>
>> My recollection:
>>
>> >>> i =
On 23 November 2017 at 15:37, Ethan Furman wrote:
> On 11/22/2017 11:51 PM, Sven R. Kunze wrote:
>
>> A "yield" within a comprehension is like a "return" in a comprehension. It
>> makes no sense at all.
>> Also a "yield" and a "return with value" is also rarely seen.
>>
>> Comprehensions build new
On 25 November 2017 at 14:55, Ivan Levkivskyi wrote:
> Continuing the topic of the ban, what exactly should be banned? For example
> will this still be valid?
>
> def pack_two():
> return [(yield), (yield)] # Just a list display
>
> I don't see how this is controversial. It is clear t
On 28 November 2017 at 20:38, Barry Warsaw wrote:
> On Nov 28, 2017, at 15:31, Raymond Hettinger
> wrote:
>
>> Put me down for a strong -1. The proposal would occasionally save a few
>> keystokes but comes at the expense of giving Python a more Perlish look and
>> a more arcane feel.
>
> I a
On 6 December 2017 at 13:13, Serhiy Storchaka wrote:
> 05.12.17 22:26, Terry Reedy пише:
>>
>> On 12/4/2017 6:21 PM, MRAB wrote:
>>>
>>> I've finally come to a conclusion as to what the "correct" behaviour of
>>> zero-width matches should be: """always return the first match, but never a
>>> zero-
On 15 December 2017 at 05:28, Raymond Hettinger
wrote:
> In contrast, I gave collections.OrderedDict a different design (later coded
> in C by Eric Snow). The primary goal was to have efficient maintenance of
> order even for severe workloads such at that imposed by the lru_cache which
> frequ
On 15 December 2017 at 18:19, Serhiy Storchaka wrote:
> 15.12.17 17:53, Guido van Rossum пише:
>>
>> Make it so. "Dict keeps insertion order" is the ruling. Thanks!
>
> What should dict.popitem() return? The first item, the last item, or
> unspecified?
I'd say leave it as unspecified.
Paul
__
On 15 December 2017 at 20:07, Chris Barker wrote:
> And if I understand the rest of the PEP, while typing itself is optional,
> the use of type Annotation is not -- it is exactly what's being used to
> generate the fields the user wants.
>
> And the examples are all using typing -- granted, primar
On 19 December 2017 at 07:49, Eric V. Smith wrote:
> Data Classes is also not the first use of type annotations in the stdlib:
> https://docs.python.org/3/library/typing.html#typing.NamedTuple
>
Also, the fact that no-one raised this issue during the whole time the
PEP was being discussed (at lea
On 19 December 2017 at 08:27, Nathaniel Smith wrote:
> On Mon, Dec 18, 2017 at 11:38 PM, Steve Dower wrote:
>> On 18Dec2017 2309, Steven D'Aprano wrote:
>>> [A LOT OF THINGS I AGREE WITH]
>> I agree completely with Steven's reasoning here, and it bothers me that
>> what is an irrelevant change to
On 19 December 2017 at 17:57, Steve Holden wrote:
> On Tue, Dec 19, 2017 at 4:49 PM, Stephen J. Turnbull
> wrote:
>>
>> Nathaniel Smith writes:
>>
>> > To make sure I understand, do you actually have a script like this, or
>> > is this hypothetical?
>>
>> I have a couple of doctests that assume
On 22 December 2017 at 19:50, Gregory P. Smith wrote:
> My preference for this is "just use Any" for anyone not concerned about the
> type. But if we wanted to make it more opaque so that people need not
> realizing that they are actually type annotations, I suggest adding an alias
> for Any in
On 28 December 2017 at 06:08, Yury Selivanov wrote:
> This is a second version of PEP 567.
Overall, I like the proposal. It's relatively straightforward to follow, and
makes sense.
One thing I *don't* see in the PEP is an example of how code using thread-local
storage should be modified to use c
On 4 January 2018 at 00:17, Greg Ewing wrote:
> Guido van Rossum wrote:
>>
>> contextvars.copy_context().run(func, )
>
>
> If contexts are immutable, why is there something
> called copy_context?
Agreed. This was something that bothered me, too. I mentioned it in my
review, but that seemed to get
On 4 January 2018 at 02:15, Nathaniel Smith wrote:
> On Wed, Jan 3, 2018 at 5:42 PM, Victor Stinner
> wrote:
>> Hi,
>>
>> It seems like many people, including myself, are confused by the lack
>> of concrete current context in the PEP 567 (contextvars). But it isn't
>> difficult to implement the
On 4 January 2018 at 15:56, Guido van Rossum wrote:
> It was get_context() in an earlier version of PEP 567. We changed it to
> copy_context() believing that that would clarify that you get a clone that
> is unaffected by subsequent ContextVar.set() operations (which affect the
> *current* context
On 4 January 2018 at 23:58, Guido van Rossum wrote:
> On Thu, Jan 4, 2018 at 9:27 AM, Paul Moore wrote:
>>
>> On 4 January 2018 at 15:56, Guido van Rossum wrote:
>> > It was get_context() in an earlier version of PEP 567. We changed it to
>> > copy_context()
On 5 January 2018 at 11:06, Victor Stinner wrote:
>> Le 5 janv. 2018 11:42 AM, "Paul Moore" a écrit :
>> """
>> A Context is a mapping from ContextVar objects to their values. The
>> Context itself exposes the Mapping interface, so cannot be modi
On 5 January 2018 at 23:02, Guido van Rossum wrote:
> I don't like those examples -- "nonlocal foo = bar" sounds like bar is used
> as the *initializer*, but it actually is just an assignment that overwrites
> the actual initial value. IMO those shouldn't be combined.
That was my immediate reacti
On 11 January 2018 at 07:39, Chris Jerdonek wrote:
> But to your question, like it or not, I think the API encourages this
> way of thinking because the get() method is on the ContextVar itself,
> and so it's the ContextVar which is doing the looking up rather than
> just fulfilling the role of a
On 30 January 2018 at 17:10, Antoine Pitrou wrote:
>
> This is missing a bit of context. Is this about python-dev? Some
> other ML?
While I'll admit to being curious about what prompted this, honestly,
it's none of my business - and so I think that Brett's posting should
be viewed as a general
On 1 February 2018 at 00:42, Gregory P. Smith wrote:
> TL;DR of Steve's post - MSVC is the compiler of choice for most serious
> software on Windows. So we use it to best integrate with the world. There is
> no compelling reason to change that.
>
> The free-as-in-beer MSVC community edition is fin
On 2 February 2018 at 15:38, Elvis Pranskevichus wrote:
> On Friday, February 2, 2018 10:08:43 AM EST Eric V. Smith wrote:
>> However, I don't feel very strongly about this. As I've said, I expect
>> the use cases for hash=True to be very, very rare.
>
> Why do you think that the requirement to ma
On 3 February 2018 at 22:40, Alex Walters wrote:
> I am still working on porting code from 2.x to 3.x. As of late on the lists
> I've seen comments about making somewhat major changes in 4.0 - now I'm
> concerned that I should pause my porting effort until that is released. Is
> python 4 going t
On 22 February 2018 at 16:08, Antoine Pitrou wrote:
> On Thu, 22 Feb 2018 07:51:17 -0800
> Steve Dower wrote:
>> It then becomes grunt work for reviewers, who also have to carefully balance
>> encouraging new contributors against preventing the code base from getting
>> worse.
>
> That's a fair
On 23 February 2018 at 09:12, Stefan Behnel wrote:
> Stephen J. Turnbull schrieb am 23.02.2018 um 03:31:
>> Barry Warsaw writes:
>> > rather than having to pause to reason about what that 1-element
>> > list-like syntax actually means, and 2) will this encourage even
>> > more complicated compr
On 12 March 2018 at 17:59, Serhiy Storchaka wrote:
> 12.03.18 18:49, Raymond Hettinger пише:
>>
>> There is a feature request and patch to propagate the float.is_integer()
>> API through rest of the numeric types ( https://bugs.python.org/issue26680
>> ).
>>
>> While I don't think it is a good ide
On 24 March 2018 at 10:50, Nick Coghlan wrote:
> On 24 March 2018 at 18:50, Serhiy Storchaka wrote:
>>
>> Currently the repository contains bundled pip and setuptools (2 MB total)
>> which are updated with every release of pip and setuptools. This increases
>> the size of the repository by around
On 28 March 2018 at 19:44, Serhiy Storchaka wrote:
> 28.03.18 19:20, Guido van Rossum пише:
>
>> Hm, without thinking too much about it I'd say it's okay to change the
>> evaluation order.
>
> Do you mean the option 3, right? This is the simplest option. I have already
> wrote a PR for optimizing
On 28 March 2018 at 20:12, Serhiy Storchaka wrote:
> 28.03.18 22:05, Paul Moore пише
>
> I can't imagine (non-contrived) code where the fact that a is
> formatted before b is evaluated would matter, so I'm fine with option
> 3.
>
>
> If formatting a and evalu
On 29 March 2018 at 09:49, Chris Angelico wrote:
> On Thu, Mar 29, 2018 at 7:18 PM, Nathaniel Smith wrote:
>> Another example is the multiprocessing module: it's very safe to
>> assume that the parent and the child are using the same interpreter
>> :-). There's no fundamental reason you shouldn't
On 3 April 2018 at 13:51, Paul G wrote:
> Maybe this has already been discussed ad nauseum, but is the idea here that
> Python will stay on Python 3.x, but also start breaking backwards
> compatibility with old versions? That would seem to be a violation of
> semantic versioning.
Python's vers
On 7 April 2018 at 04:13, Steve Dower wrote:
> Better to deprecate it before it becomes broken, in my opinion.
>
> Having someone willing and able to review and merge changes is the best
> criteria for whether a module is still supported or not.
I think there's a difference between not being will
On 17 April 2018 at 14:01, David Mertz wrote:
> Strongly agree with Nick that only simple name targets should be permitted
> (at least initially). NONE of the motivating cases use more complex targets,
> and allowing them encourages obscurity and code golf.
I also agree. Originally I would have s
On 17 April 2018 at 14:07, Paul Moore wrote:
> On 17 April 2018 at 14:01, David Mertz wrote:
>> Strongly agree with Nick that only simple name targets should be permitted
>> (at least initially). NONE of the motivating cases use more complex targets,
>> and allowing them enc
On 17 April 2018 at 16:12, Ethan Furman wrote:
> On 04/17/2018 06:26 AM, Paul Moore wrote:
>
>> I should also point out that I remain -0 on this proposal (I'd already
>> said this on python-ideas, but I should probably repeat it here). For
>> me, the use cases are m
On 20 April 2018 at 07:46, Chris Angelico wrote:
> On Fri, Apr 20, 2018 at 1:30 PM, Stephen J. Turnbull
> wrote:
>> Christoph Groth writes:
>>
>> > Wouldn't it be a pity not to liberate assignments from their boring
>> > statement existence?
>>
>> Maybe not. While it would be nice to solve the
201 - 300 of 1862 matches
Mail list logo
