On Mon, Apr 20, 2015 at 1:15 PM, Robert Collins
wrote:
> On 21 April 2015 at 08:07, Guido van Rossum wrote:
>
> > The situation is possibly even bleaker (or happier, depending on your
> > position :-) for inline type hints in 3rd party packages -- few package
> > author
want a module itself to be type-checked you have to use inline type hints.
(Though it has been suggested to combine the hints from the stub with the
implementation and use this to type-check the implementation, and some tool
chains may actually implement this.)
--
--Guido van Rossum (python.org/~
primitive types, or perhaps a user-defined class or List of such.
And you can always leave the annotation out if you find yourself fighting
the type checker -- it will default to Any and the type checker will just
shut up. That's the beauty of gradual typing (and it differs greatly from
str
ng?
>
It's not fundamental, it's just more in line with the original purpose of
stubs (to describe C extensions).
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/lis
nts(func) this is not intended to give you access to
hints defined in stubs (it would require a huge amount of machinery to
implement that right).
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.
everyone they had to install a different
> python implementation they wouldn't. This is much worse than that - it is
> Python4 hidden away inside a PEP.
>
But the nice thing is that this time you really *can* mix Python 3 and
Python 4 together in one app. :-P
> There are many fine l
On Tue, Apr 21, 2015 at 12:33 AM, M.-A. Lemburg wrote:
> On 21.04.2015 05:37, Guido van Rossum wrote:
> > On Mon, Apr 20, 2015 at 4:41 PM, Jack Diederich
> wrote:
> >> * Uploading stubs for other people's code is a terrible idea. Who do I
> >> contact when I
ng
back fondly about the argument we're currently having, it will be the
choice of the author of new (and *only* new) stdlib modules whether and how
to use type hints. Such a hypothetical author would also be reviewing
updates to "their" module and point out lack of type hints just like
sorted out packages). During the run of 3.5 we'll hopefully get feedback on
where duck typing is most needed and how to specify it -- valuable input
that would be much harder to obtain of *no* part of the type hints notation
were standardized.
--
--Guido van Rossum (python.org/~guido)
_
It will not. It may not prove the solution to all Python's problems
-- there's always 3.6. (Oh wait, Python 2.7 is perfect. I've heard that
before -- Paul Everitt famously said the same of Python 1.5.2. Aren't you
glad I didn't take him
On Tue, Apr 21, 2015 at 9:47 AM, Antoine Pitrou wrote:
> On Tue, 21 Apr 2015 09:28:45 -0700
> Guido van Rossum wrote:
> > On Tue, Apr 21, 2015 at 12:49 AM, Antoine Pitrou
> > wrote:
> >
> > > On Mon, 20 Apr 2015 20:43:38 -0400
> > > "R. David Murr
's anything anyone else wants to see before I shut it down, speak up
> soon.
>
> ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
>
to predict. Anecdotally, some
people believe this will be catnip, while others believe it to be poison.
The truth will surely be somewhere in the middle. At this point we don't
know what drives Python 3 adoption except time -- it's definitely going up.
:-)
--
--Guido van Rossum (python.org
On Tue, Apr 21, 2015 at 1:18 PM, Robert Collins
wrote:
> On 22 April 2015 at 04:28, Guido van Rossum wrote:
> > Until some point in a possible but distant future when we're all thinking
> > back fondly about the argument we're currently having, it will be the
> cho
e that was nothing more than a dump of pylint output when
> run over Requests', where *every single line* was a false positive.
>
> This ends up having negative network effects as well, because the next
> time someone opens a GitHub issue with the word 'pylint' in it I
rhaps to be renamed
to ensure_task() to make way for the async keyword).
--
--Guido van Rossum (python.org/~guido)
___
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
On Wed, Apr 22, 2015 at 9:12 AM, Skip Montanaro
wrote:
>
> On Wed, Apr 22, 2015 at 10:43 AM, Guido van Rossum
> wrote:
>
>> For Requests, it looks like it may be better not to have stubs at all.
>
>
> Can you expand on this? Why would Requests be any different than
your package (as .pyi files living alongside the .py files) so that
you don't have to deal with typeshed being out of date.
There are many other possible workflows; we haven't discovered the best
one(s) yet. It's a work in progress.
--
--Guido van Rossum (python.org/~guido)
___
ecord to become available from the query, and `async with` may block
in the implied `finally` clause in order to wait for a commit. (Both may
also suspend at the top, but that's less important.)
--
--Guido van Rossum (python.org/~guido)
___
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing
wrote:
> Guido van Rossum wrote:
>
>> On Wed, Apr 22, > OTOH I'm still struggling with what you have to do to
>> wrap a coroutine in a Task, the way its done in asyncio by the Task()
>> constructor, the loop.cre
a, str):
return [a]
else:
return a
and call this in those functions that have an Interable[str] argument. Now
instead of getting errors for all the places where a caller mistakenly
passes a single str, you've *fixed* all those call sites. Isn't that more
Pyt
On Wed, Apr 22, 2015 at 5:55 PM, Yury Selivanov
wrote:
> On 2015-04-22 8:35 PM, Guido van Rossum wrote:
>
>> On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing
>> wrote:
>>
>> Guido van Rossum wrote:
>>>
>>> On Wed, Apr 22, > OTOH I'm
ng list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Pytho
ry that comes with 3.5
must seamlessly support mixing code that uses `await` and code that uses
`yield from`. And this should go both ways -- if you have some code that
uses PEP 492 and some code that uses pre-3.5 asyncio, they should be able
to pass their coroutines to each other and wait for ea
On Fri, Apr 24, 2015 at 11:03 AM, Ethan Furman wrote:
> On 04/24, Yury Selivanov wrote:
> > On 2015-04-24 1:03 PM, Guido van Rossum wrote:
>
> >> Ditto for `__aiter__` and `__anext__`. I guess this means that the async
> >> equivalent to obtaining an iterator throu
Sorry, when I wrote "future" (lower-case 'f') I really meant what Yury
calls *awaitable*. That's either a coroutine or something with an __await__
emthod.
On Fri, Apr 24, 2015 at 3:17 PM, Łukasz Langa wrote:
>
> On Apr 24, 2015, at 10:03 AM, Guido van Rossum wr
+1 for option 3.
On Sat, Apr 25, 2015 at 1:18 PM, Yury Selivanov
wrote:
> Hi Guido,
>
> On 2015-04-24 1:03 PM, Guido van Rossum wrote:
>
>> *3. syntactic priority of `await`*
>>
>> Yury, could you tweak the syntax for `await` so that we can write the most
>&g
the other new features proposed, just the
> new syntax.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-de
inst the PEP and the
implementation.)
--
--Guido van Rossum (python.org/~guido)
___
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
On Tue, Apr 28, 2015 at 11:51 AM, Stefan Behnel wrote:
> Mark Shannon schrieb am 27.04.2015 um 09:48:
> > On 27/04/15 00:13, Guido van Rossum wrote:
> >> Currently this means looking for yield [from]; PEP 492 just adds looking
> >> for await and async [for|with]
code.
And it's not just generating different code -- it's also the desire to
issue static errors (SyntaxError) when await (or async for/with) is used
outside a coroutine, or when yield [from] is use inside one.
The motivation is clear enough to me (and AFAIR I'm the BDFL for this PEP
On Tue, Apr 28, 2015 at 1:22 PM, Mark Shannon wrote:
>
>
> On 28/04/15 21:06, Guido van Rossum wrote:
>
>> On Tue, Apr 28, 2015 at 11:44 AM, Mark Shannon > <mailto:m...@hotpy.org>> wrote:
>>
>> Hi,
>>
>> I still think that there are s
gt; Performance
> ===
>
> Overall Impact
> --
>
> This proposal introduces no observable performance impact. Here is an
> output of python's official set of benchmarks [4]_:
>
> ::
>
> python perf.py -r -b default ../cpython/python.exe
&g
s
too. The current proposal is a pretty clever hack -- and we've done similar
hacks in the past (last I remember when "import ... as ..." was introduced
but we didn't want to make 'as' a keyword right away).
--
--Guido van Rossum (python.org/~guido)
_
I don't care for await await x.
On Apr 28, 2015 6:53 PM, "Yury Selivanov" wrote:
> Looking at the grammar -- the only downside of the current approach is that
> you can't do 'await await fut'. I still think that it reads better with
> parens. If we put 'await' to 'factor' terminal we would allo
> u'\u03b1' but eval(u"u'\u03b1'".encode('utf-8')) -> u'\xce\xb1'.
>>
>> There is a simple option to get this flag: call eval() with unicode, not
>> with encoded bytes.
>>
>> Victor
>>
>
>
> ___
> Python-Dev mailing
J. Smith -- http://vorpus.org
> ___
> 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/guido%40python.org
>
ings clear to the parser *and*
humans. Yury's proposal satisfies my requirements, and if we really find
some unpleasant edge case we can fix it during the 3.5 release (the PEP
will be provisional).
--
--Guido van Rossum (python.org/~guido)
___
Python
of*what it is*. AFAICT the PEP
>> currently doesn't have that.
>>
>
> How to define human-readable description of how unary
> minus operator works?
>
In a PEP you should probably give grammar that is not the actual grammar
from the implementation, but matches the grammar used i
ere.
>
That's fair. But because of the difficulty in introducing new keywords,
many proposals have been shot down or discouraged (or changed to use
punctuation characters or abuse existing keywords) -- we should give Yury
some credit for figuring out a way around this. Honestly I&#x
print_function __future__ disables the
keyword-ness of 'print', except here it's toggled on or off depending on
whether the nearest surrounding scope is 'async def' or not. The PEP could
probably be clearer about this; it's all hidden in the Transition Plan
sectio
Belt and suspenders. :-)
We may need help with the implementation though -- PEP 479 is still waiting
on implementation help with __future__ too AFAIK.
On Wed, Apr 29, 2015 at 8:01 PM, Nick Coghlan wrote:
> On 30 April 2015 at 12:31, Guido van Rossum wrote:
> > On Wed, Apr 29, 2015 a
ot;- not x". This is because they have different priorities:
'not' has a very low priority so it binds less tight than comparisons
(which bind less tight than arithmetic), but '-' has a high priority.
(There are other quirks, e.g. -2**2 means -(2**2) a
cal discussion
about the PEP is on getting the details right so that users won't have to
worry about them, and can instead just continue to write *almost*
sequential code when using the asyncio package (or some other framework
that offers an eve
osc.canterbury.ac.nz/greg.ewing/python/yield-from/yield_from.html
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.
--
--Guido van Rossum (python.org/~guido)
___
improvement often leads the way to another
improvement -- one that wasn't obvious before. And that's fine. If I had
laid awake worrying about the best way to spell async functions while
designing asyncio, PEP 3156 probably still wouldn't have been finished
today.
On Thu, Apr 30, 2015
there is much
code like that (I haven't seen much mention of yield-from outside its use
in asyncio). So I think the interop problem is mostly limited to
asyncio-using code that plays loose with the @coroutine decorator
requirement and now wants to work with the new async functions. That's easy
xample.
>
You can call me weird, but I *like* fine-tuning operator binding rules to
suit my intuition for an operator. 'await' is not arithmetic, so I don't
see why it should be lumped in with '-'. It's not like the proposed grammar
change introducing 'await'
disambiguate the expression above in the given way, it
> becomes an arguably regrettable, yet inevitable, consequence that
> await -fut
> await +fut
> await ~fut
> become parse errors.
>
Why is that regrettable? Do you have a plan for overloading one of those
on Fu
e.
The solution to that would be to have __aiter__ return an instance of a
different class than __iter__, but that's not always convenient.
Thus, aware of the choice, I would still prefer a separate __anext__ method.
--
--Guido van Rossum (python.org/~guido)
___
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
ons with the same word. Given the
feedback I'd call "native coroutine" suboptimal (even though I proposed it
myself) and I am now in favor of using "async function".
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mail
On Fri, May 1, 2015 at 8:55 AM, Gustavo Carneiro
wrote:
>
>
>
> On 1 May 2015 at 16:31, Guido van Rossum wrote:
>
>> On Fri, May 1, 2015 at 5:50 AM, Stefan Behnel
>> wrote:
>>
>>> Yury Selivanov schrieb am 30.04.2015 um 03:30:
>>> > 1. Te
On Fri, May 1, 2015 at 11:26 AM, Jim J. Jewett wrote:
> On Thu, Apr 30, 2015 at 3:32 PM, Guido van Rossum
> wrote:
>
> (me:)
> >> A badly worded attempt to say
> >> Normal generator: yield (as opposed to return) means
> >> that the function isn'
ables run.
>
> That's really up to the scheduler, and a function like this should be
provided by the event loop or scheduler framework you're using.
>
> If the async loop only has one coroutine (awaitable) in it, then it will
> be just like calling a regular function. No
On Fri, May 1, 2015 at 12:24 PM, Ethan Furman wrote:
> On 05/01, Guido van Rossum wrote:
> > On Fri, May 1, 2015 at 11:26 AM, Jim J. Jewett
> wrote:
>
> >> So does this mean that yield should NOT be used just to yield control
> >> if a task isn't blocked?
>
Could you dig up the actual references? It seems rather odd to me to mix
coroutines and threads this way.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/py
On Fri, May 1, 2015 at 1:22 PM, Antoine Pitrou wrote:
> On Fri, 1 May 2015 13:10:01 -0700
> Guido van Rossum wrote:
> > On Fri, May 1, 2015 at 12:48 PM, Jim J. Jewett
> wrote:
> >
> > > If there are more tasks than executors, yield is a way to release your
> &
On Sat, May 2, 2015 at 1:18 PM, Arnaud Delobelle wrote:
> On 1 May 2015 at 20:59, Guido van Rossum wrote:
> > On Fri, May 1, 2015 at 12:49 PM, Ron Adam wrote:
> >>
> >>
> >> Another useful async function might be...
> >>
> >>async def
outine
> generators be decorated.
>
> --
> ~Ethan~
> ___
> 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/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
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
ribe:
>> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>>
>>
>
>
> --
> Ryan
> [ERROR]: Your autotools build scripts are 200 lines longer than your
> program. Something’s wrong.
> http://kirbyfan64.github.io/
>
>
> ___
> 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/guido%40python.org
>
>
--
--Guido van Rossum (python.org/~guido)
___
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
k with await by adding an __await__ method.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pyt
er pair than 'async functions' and 'coroutines'.
>
Yes. This subtopic is now closed for further debate (please).
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mail
In a PEP 492 coroutine substitute await for yield from.)
--
--Guido van Rossum (python.org/~guido)
___
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
ver regular (synchronous) streams using for-loops.)
--
--Guido van Rossum (python.org/~guido)
___
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
from/yf_current/Examples/Scheduler/scheduler.txt
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/p
lias for Future.__iter__);
- "asyncio coroutine" maps to "PEP 492 coroutine object" (either defined
with `async def` or a generator decorated with @types.coroutine -- note
that @asyncio.coroutine incorporates the latter);
- "either of the above" maps to "awaitable&
rder to get their result you must use an await expression, which in
turn may only be used in a coroutine. Thus all code that may invoke an I/O
call ends up being a coroutine. This is exactly the type of constraint
we're trying to introduce into Python with PEP 492 (
On Tue, May 5, 2015 at 2:29 PM, Paul Moore wrote:
> 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 exhau
On Tue, May 5, 2015 at 3:01 PM, Nathaniel Smith wrote:
On May 5, 2015 2:14 PM, "Guido van Rossum" wrote:
> >
> > In the PEP 492 world, these concepts map as follows:
> >
> > - Future translates to "something with an __await__ method" (and async
On Tue, May 5, 2015 at 2:40 PM, Paul Moore wrote:
> On 5 May 2015 at 22:25, Guido van Rossum wrote:
>
[Paul:]
> >> I'd be interested in writing, for instructional purposes, a toy but
> >> complete event loop. But I'm *not* really interested in trying to
your purpose, but it would provide a real-life example of an event loop
that's not built for network I/O.
On Tue, May 5, 2015 at 3:52 PM, Paul Moore wrote:
> On 5 May 2015 at 23:28, Guido van Rossum wrote:
> >> At this point, *all* I'm thinking of is a toy. So, an implem
anguage in the PEP that needs updating
(check the PEP 484 tracker <https://github.com/ambv/typehinting/issues>).
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listin
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 efforts. Godspeed.
On Tue, May 5, 2015 at 4:53 PM, Guid
ated to a tk event likely require a
> patch to tk?
>
> --
> Terry Jan Reedy
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.p
) that
adds I/O, subprocesses, and integrates with the selectors module (or with
IOCP, on Windows).
I don't see any particular hurry to get this in before 3.5; the refactoring
of asyncio can be done later, in a backward compatible way. It would be a
good way to test the architecture of asyncio!
--
--Guido van Rossum (python.org/~guido)
___
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
cx/publish/programming/charming_python_b7.txt
Enjoy!
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pyt
n Wed, May 6, 2015 at 2:32 PM, Terry Reedy wrote:
> On 5/5/2015 10:59 PM, Guido van Rossum wrote:
>
>> For this you should probably use an integration of asyncio (which can do
>> async subprocess output nicely) with Tkinter. Over in tulip-land there
>> is an demo of such
in the above thread
to work but I couldn't (then again Tk on OS X is difficult). If someone
could turn this into a useful event loop that blends asyncio and Tkinter
that would be truly awesome!
On Wed, May 6, 2015 at 6:32 PM, Terry Reedy wrote:
> On 5/6/2015 5:39 PM, Guido van Rossum w
tub is present the implementation source code is
not read at all by the type checker (and, conversely, information from
stubs is not available at all at runtime). But it is possible for some type
checker to improve upon this model.
> An example in PEP would be good.
>
Can you give a
#file-sieve-py
> https://gist.github.com/vrajivk/c505310fb79d412afcd5#file-channel-py
>
> [2] https://golang.org/doc/play/sieve.go
>
--
--Guido van Rossum (python.org/~guido)
___
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
On Mon, May 11, 2015 at 1:37 PM, Paul Moore wrote:
> 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 w
-- Forwarded message --
From: "Dakshesh Vyas"
Date: May 12, 2015 1:08 AM
Subject: Coverity Scan update
To: "gu...@python.org"
Cc:
Hello Guido van Rossum,
Thank you for using Coverity Scan.
With more than 4000 open source projects now registered at C
you have no way of getting
> back to the cleaned-up address.
>
> * One design reviewer summarized her thoughts like this:
> "There is a learning curve to be climbed to figure out what
> it does, how to use it, and what the applications [are].
> But, the [working out
le, AFAICT, is that CPython 'list' is a weird type with
> > undocumented behaviour that you can't actually define using pure
> > Python code.
> >
> > Should I be worried?
> >
> > -n
> >
> > [1] https://github.com/numpy/numpy/pull/5864
awake thinking about it for two nights since then.
I need to sit down and think more about the problem we're trying to solve,
what are the constraints (and why), and what would the minimal solution.
--
--Guido van Rossum (python.org/~guido)
___
I write it in a new thread, but I also want to write it here -- I need a
time out in this discussion so I can think about it more.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org
)
will *also* break into the IDE's debugger. My use case is that sometimes I
have a need for a *conditional* breakpoint where it's just much simpler to
decide whether to break or not in Python code than it would be to use the
IDE's conditional breakpoint facilities.
(Plus there'
ith the idea for this PEP while awake.
> ___
> 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/
> guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
On Thu, Sep 7, 2017 at 2:40 PM, Benjamin Peterson
wrote:
>
>
> On Thu, Sep 7, 2017, at 14:19, Guido van Rossum wrote:
> > Nice one.
> >
> > It would be nice to specify the various APIs needed as well.
>
> The compileall and py_compile ones?
>
Yes, and th
No worries. We all learned stuff!
On Wed, Sep 6, 2017 at 4:22 PM, R. David Murray
wrote:
> On Wed, 06 Sep 2017 09:43:53 -0700, Guido van Rossum
> wrote:
> > I'm actually not in favor of this. It's another way to do the same thing.
> > Sorry to rain on your dream!
at we can easily avoid the annoyance of dual
> magic numbers and encodings which must be maintained in parallel.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org
/levkivsky
>> i%40gmail.com
>>
>
> ___
> 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/
> guido%40python.org
&
not exactly what I'm
>> asking
>> above.
>>
>
> The problem is: how do you know what's a mutable type? There's no general
> way to know. The behavior in the PEP is just mean to stop the worst of it.
>
> I guess we could have an option that says: c
in.
>
>
> ..
>Local Variables:
>mode: indented-text
>indent-tabs-mode: nil
> sentence-end-double-space: t
>fill-column: 70
>coding: utf-8
>End:
>
>
> ___
> Python-Dev mailing list
> Pytho
ople can write `from
dataclasses import *` and they will only get things that are clearly part
of dataclasses (I guess dataclass, field, asdict, and a few more like
that). That way people who really want this to look like a builtin can just
violate PEP 8.
--
--Guido van Rossum (python.org/~guido)
_
choose to implement
> that in sys.breakpointhook(), it might still makes sense.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.pytho
lready voluntarily give up seeing any later assignments to
x.y. If this prevents a certain use case for lazy import, then so be it --
I don't think lazy import can ever be made so transparent that everything
will work lazily without understanding the difference between lazy and
eager import. (P
mainstream. You won't have to use
them, but some newer features of the language will be inaccessible if you
don't. This has already started with the pattern based on inheriting from
typing.NamedTuple and using field annotations. Dataclasses are simply
another example.
" instead of "unordered"; better to say what they are rather
> than what they are not.
>
> --
> ~Ethan~
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-d
tinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>
--
--Guido van Rossum (python.org/~guido)
___
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
201 - 300 of 6462 matches
Mail list logo
