sages should
generally be displayed on stdout.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct:
On 29 November 2017 at 02:03, Ivan Pozdeev via Python-ideas
<python-ideas@python.org> wrote:
> On 28.11.2017 16:36, Nick Coghlan wrote:
>> I'll make the same observation I usually do each time one of these
>> threads comes up:
>>
>> * I'm opposed to making as
_getframe(1)
line = frame.f_lineno
modname = frame.f_globals.get("__name__", "")
msg = f"Condition not met on line {line:d} in {modname!r}"
raise exc_type(msg)
Cheer
[1] https://xkcd.com/386/
P.S. For a longer version of the "What problem does it solve?"
question in relation to the respective APIs of the requests and urllib
modules, folks may be interested in
https://www.curiousefficiency.org/posts/2016/08/what-problem-does-it-solve.html
--
Nick Co
sn't actually align with the
preferred terminology in the documentation:
https://docs.python.org/3/glossary.html#term-generator
So I can understand the confusion here.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
ey get told they either need to be build a
DIY one from a list + the heapq functions, or else install a 3rd party
dependency to get a preassembled one.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ide
On 23 November 2017 at 16:34, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Nick Coghlan writes:
>
> > We're not going to start second-guessing the Unicode Consortium on this
> > point - human languages are complicated, and we don't have
I don't think it would be a major maintenance burden or future barrier to
learning to add it, either.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
ose settings that are right
*for them* (e.g. by defining a set of "permitted scripts" [1], specifying
the Unicode characters that should be allowed in identifiers beyond the
core set of "Latin" code points allowed by ASCII)
Cheers,
Nick.
[1] https://en.wikipedia.org/wiki/Script_(Uni
On 21 November 2017 at 12:34, Nick Coghlan <ncogh...@gmail.com> wrote:
> Right, but once you do that, then the existing resolver is already
> able to handle things:
>
> >>> class C: pass
> ...
> >>> class S(C): pass
> ...
> >&
On 21 November 2017 at 11:09, Neil Girdhar <mistersh...@gmail.com> wrote:
>
> On Sat, Nov 18, 2017 at 9:29 PM Nick Coghlan <ncogh...@gmail.com> wrote:
>>
>> >>> class C: pass
>> ...
>> >>> class S(C): pass
>> ...
or level modification would also extend itself well
to underscores in numeric literals, as there the appropriate
pseudo-separator shown when the literal wasn't being edited would be
locale dependent.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
On 19 November 2017 at 12:32, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 19 November 2017 at 12:01, Mikhail V <mikhail...@gmail.com> wrote:
>> Python allows underscore character as a separator in variables.
>> This is better than nothing, still it does no
acter.
Regardless of any potential readability merits, backwards
compatibility requirements combined with the use of the hyphen
character as a binary operator prohibit such a change:
>>> my = variable = 1
>>> my-variable
0
Cheers,
Nick.
--
Nick Coghlan | ncogh...
at "C" and "E"
appeared in the opposite order wouldn't really help, since that would
just flip the problematic case to be the "R(C, E)" declaration.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
On 18 November 2017 at 09:03, Neil Girdhar <mistersh...@gmail.com> wrote:
> On Fri, Nov 17, 2017 at 3:15 AM Nick Coghlan <ncogh...@gmail.com> wrote:
>> I'll note that an interesting side effect of
>> https://www.python.org/dev/peps/pep-0560/#mro-entries will be
ead of the list of
bases).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
of the current
PATH
* PATH in a venv will still put the regular python executable ahead of the
launcher
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
r issue.
>
I'd missed Steve's post before writing my last one. This sounds like a
really nice technical solution to me, too, especially as it will handle
Python 2 as well (even for Python 2 only systems, the launcher is available
as an independently installable executable).
Regardless of the underlying im
a properly working environment.
The update to the Windows installer would then start offering benefits as
soon as Python 3.7 becomes the default download, while the troubleshooting
guide would be beneficial as soon as folks start learning about it's
existence.
Cheers,
On 15 November 2017 at 19:51, Paul Moore <p.f.mo...@gmail.com> wrote:
> On 15 November 2017 at 08:22, Nick Coghlan <ncogh...@gmail.com> wrote:
> > On 15 November 2017 at 16:13, Steve Barnes <gadgetst...@live.co.uk>
> wrote:
> >>
> >> - "pip
tandard library adjustments are needed (e.g. updating
doctest to abide by any proposed conventions), or if the convention is
going to be captured as an informational PEP, rather than solely as a
recommended comment parsing library.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Br
ing-versions-of-python
`pipenv` also allows `pipenv --two` and `pipenv --three` when setting up
your initial virtual environment.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-idea
On 15 November 2017 at 01:23, Stephan Houben <stephan...@gmail.com> wrote:
> Hi Nick,
>
> 2017-11-14 11:07 GMT+01:00 Nick Coghlan <ncogh...@gmail.com>:
>
>> On 14 November 2017 at 16:47, Michel Desmoulin <desmoulinmic...@gmail.com
>> > wrote:
>>
ity pain point: one of the complications in importlib is that we
promise to keep the "sys.modules[__name__] = some_other_object" idiom
working. That means the need to do that check exists regardless of whether
importlib is passing the module itself around, or the module's dict.
Cheers
mote everywhere:
>
> pythonX.X -m cmd
>
> It will work most of the time.
The combination of:
pip install package
python -m venv
already works in most cases, *except* apparently the critical one of "New
Python user on Windows downloads the python.org installer and clicks
through all the buttons without changing any settings".
So I think the main near term step forward would be to convince Steve Dower
(as the Windows installer maintainer) to change that default behaviour yet
again for 3.7, and then work towards coming up with a solid environment
troubleshooting guide to include on packaging.python.org.
Cheers,
Nick.
[1] https://lwn.net/Articles/580399/
[2] https://lwn.net/Articles/711906/
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
On 14 November 2017 at 13:08, Nathaniel Smith <n...@pobox.com> wrote:
> On Nov 13, 2017 6:47 PM, "Nick Coghlan" <ncogh...@gmail.com> wrote:
>
> On 14 November 2017 at 11:51, Nathaniel Smith <n...@pobox.com> wrote:
> > What if instead of installing a s
py now with the PEP, except for one detail: maybe
> `__mro_entry__` should always return a tuple and then maybe renamed to
> `__mro_entries__`. (See debate at
> https://github.com/python/peps/pull/460#issuecomment-343969528 .)
I like that - very nice refinement.
Cheers,
Nick.
--
Nick Coghla
is would fix the problem with upgrading pip on
> Windows?)
Depending on how the batch file was written, I think the answer to
that is "maybe":
https://stackoverflow.com/questions/2888976/how-to-make-bat-file-delete-it-self-after-completion/20333152#20333152
Cheers,
Nick.
--
Nick Co
> own preferences.
It's also currently missing from
https://packaging.python.org/guides/installing-using-linux-tools/, but
we can amend that now that we know what the required fix is.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 13 November 2017 at 17:46, Stephan Houben <stephan...@gmail.com> wrote:
> 2017-11-13 3:32 GMT+01:00 Nick Coghlan <ncogh...@gmail.com>:
>> So technically it's ensurepip that's broken by default, but that
>> translates to venv also being broken by default.
>
by having a Recommends dep from python3 to python3-pip, and then
patching ensurepip to use rewheel to inject a copy of the system pip
into freshly created virtual environments. At least in theory, Debian
should be able to do something similar with dirtbike, but whether or
not they actually will
On 13 November 2017 at 09:29, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 13 November 2017 at 07:11, Chris Angelico <ros...@gmail.com> wrote:
>> On Mon, Nov 13, 2017 at 6:24 AM, Stephan Houben <stephan...@gmail.com> wrote:
>>> Hi Antoine,
>>>
clear. "python3 -m venv env" is the standard and
> recommended way to spin up a virtual environment.
It's further down in the page, under
https://docs.python.org/3/library/venv.html#creating-virtual-environments
I think the deprecation notice for pyvenv should just be deleted,
since it
On 13 November 2017 at 02:59, Brendan Barnwell <brenb...@brenbarn.net> wrote:
> On 2017-11-12 05:18, Nick Coghlan wrote:
>>
>> * the `pip install` option really is nicer looking than `python -m pip
>> install`, and it only has actual problems in the presence of multiple
d in the last option, there
are too many potential starting points, and it isn't even possible to
ask potential learners to self-assess what their starting point
actually is, since it's a tech support problem where the first task is
"assess the current state of the user's system" (hence the
On 12 November 2017 at 16:20, Michel Desmoulin
<desmoulinmic...@gmail.com> wrote:
> Le 10/11/2017 à 09:01, Nick Coghlan a écrit :
>> On 10 November 2017 at 17:05, Michel Desmoulin
>> <desmoulinmic...@gmail.com> wrote:
>> When we choose not to use venv, then it be
On 10 November 2017 at 19:50, Paul Moore <p.f.mo...@gmail.com> wrote:
> On 10 November 2017 at 08:01, Nick Coghlan <ncogh...@gmail.com> wrote:
>> That tooling is venv:
>>
>> * it ensures you have "pip" on your PATH
>> * it ensures you have &q
quot;
command that:
* created a default user environment if it didn't already exist
* launched a subshell with that environment already activated
This wouldn't be a full environment manager like vex or pew - it would
just be a way to bootstrap a single usable package management
environment in a cross-
esign - it's the
main reason why CPython bundles the wheel files).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/pytho
quot;3.10", but encoding it as "3A" in lexically ambiguous
contexts is another option that would let us get as far as 3.35 (aka
"3Z") before encountering ambiguity problems.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 7 November 2017 at 03:52, Michel Desmoulin <desmoulinmic...@gmail.com> wrote:
>
>
> Le 06/11/2017 à 09:47, Nick Coghlan a écrit :
>> On 6 November 2017 at 16:47, Michel Desmoulin <desmoulinmic...@gmail.com>
>> wrote:
>>> I really want some people fro
s just
the vehicle used for that purpose.
Software Carpentry starts out with the Anaconda distribution, as it
not only improves the cross-platform UX consistent situation, it also
deals with the external binary dependency problem (at least for the
core set of packages provided either natively o
nvironment as the first step, because it doesn't actually make
anything simpler, and in fact makes a lot of things harder and more
platform dependent.
The tutorial in the Python Packaging User Guide similarly starts with
venv creation:
https://packaging.python.org/tutorials/installing-packages/#creati
On 6 November 2017 at 16:42, Lukasz Langa <luk...@langa.pl> wrote:
>
>> On 5 Nov, 2017, at 10:30 PM, Michel Desmoulin <desmoulinmic...@gmail.com>
>> wrote:
>>
>> Le 06/11/2017 à 07:07, Nick Coghlan a écrit :
>>
>>> It's the default on Uni
ifically intended for updating;
> plus it'd mean you can get a directory listing of that, and go grab
> all the "blessed by python.org as an extension of the stdlib"
> packages.
When we say bundled, we mean bundled: the exact same bits you would
get from PyPI, installed the same way, and if y
On 5 November 2017 at 23:30, Paul Moore <p.f.mo...@gmail.com> wrote:
> On 5 November 2017 at 10:48, Antoine Pitrou <solip...@pitrou.net> wrote:
>> On Sun, 5 Nov 2017 13:46:59 +1000
>> Nick Coghlan <ncogh...@gmail.com> wrote:
>>> * ensurepip gains the a
On 5 November 2017 at 06:22, Guido van Rossum <gu...@python.org> wrote:
> On Sat, Nov 4, 2017 at 7:05 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
>>
>> Perhaps typing could switch to being a bundled module, such that it
>> had its own version, independent of the P
On 5 November 2017 at 01:29, Wolfgang <tds...@mailbox.org> wrote:
> On 04.11.2017 16:01, Nick Coghlan wrote:
>> We're currently more likely to go the other direction, and stick with
>> the 3.x numbering for an extended period (potentially reaching 3.10,
>> 3.11, 3.12
breaking any existing Python 2.x applications. We're not even
sure yet when we're going to update PEP 394 to say that we think it's
reasonable for distros to start using "python" to mean "python3" (see
https://www.python.org/dev/peps/pep-0394/ and
https://github.com/python/redistrib
ersions and
implementations where the packaging tools work (which is most of them)
- users can decide on a module-by-module basis whether they want the
baseline version or fast track updates
- those decisions are explicitly tracked in the project's dependency
metadata, rather than being implicit in the
(and pip if not already
> installed).
> The second one will run the GUI.
>
> This way it looks like pipgui can be simply published on PyPI without
> special-casing at all, or am I missing something?
This would also deal with the case where "ensurepip" hadn't been run
at insta
also not too hard to
implement a rudimentary version that just iterates over sys.path looking
for `entry_points.txt` files in `*.dist-info` subdirectories.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas m
asks why
"PyErr_CheckSignals" is expensive to call. And while it wouldn't surprise
at all if you're right and there are ways to make that call cheaper,
they're still never going to be cheaper than explicitly reducing the
frequency with which it is called.
Cheers,
Nick.
--
Nick Coghlan
).
Cheers,
Nick.
P.S. I'll also note that a useful feature Travis CI offers is the ability
to automate PyPI releases: https://docs.travis-ci.com/user/deployment/pypi/
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mail
handling any compatibility regressions that were subsequently reported
against the 3.7 re module, so I'd also take my +1 with a rather large grain
of salt - it's easy to be positive about a plan when the potential
downsides don't affect me personally :)
Chee
On 1 November 2017 at 00:53, Guido van Rossum <gu...@python.org> wrote:
> On Tue, Oct 31, 2017 at 4:42 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
>
>> On 31 October 2017 at 02:29, Guido van Rossum <gu...@python.org> wrote:
>>
>>> What's your proposed
tes).
The second two would be about enhancing IDLE's capabilities in this area,
as we *do* suggest that as a reasonable initial learning environment, even
though there are also plenty of alternatives out there now.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
(which I was talking to
Barry about at the dev sprint, but didn't end up actually creating any
content for since I went down a signal handling rabbit hole instead).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
P
On 31 October 2017 at 02:06, Paul Moore <p.f.mo...@gmail.com> wrote:
> On 30 October 2017 at 15:53, Antoine Pitrou <solip...@pitrou.net> wrote:
> > On Tue, 31 Oct 2017 01:44:10 +1000
> > Nick Coghlan <ncogh...@gmail.com> wrote:
> >> (We'd want a r
ake your case to your
supplier management organisation. Such declarations still aren'y always
sufficient, but they definitely don't hurt, and they sometimes help.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
P
be off by default
and enable it explicitly from the CPython CLI though, as otherwise it could
have some really annoying side effects in runtime embedding use cases.
I'm sure there'd be some thorny edge cases that would arise in trying to
make this work in practice, but at first glance, the general
e in site-packages.
>
Yep, that was my intent, although it may not have been clear in my initial
proposal. I've filed two separate RFEs in relation to that:
* Documentation only: https://bugs.python.org/issue31898
* Regression testing resource: https://bugs.python.org/is
ou've exhausted the other more maintainable alternatives, not
something we actually want to encourage.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org
collect these recommendations from the
documentation, and publish them within the `venv` module docs as a
"recommended-libraries.txt" file (using pip's requirements.txt format).
That would be sufficient to allow straightforward 3rd party automation,
without necessarily committing t
se RuntimeError("Engine is already installed in another
car")
engine._car = self
self._engine = engine
car = Car(GasEngine())
ORMs use this kind of descriptor based composition management extensively
in order to reliably model database foreign key relati
.
no explicitly declared dependencies) could then choose between relying on
just the standard library (as now), or on the standard library plus
independently versioned recommended packages.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
g them. It's just opt-in, the same way
that learning to define your own classes (rather than importing existing
ones defined elsewhere) is opt-in.
Cheers,
Nick.
[1] https://toolz.readthedocs.io/en/latest/
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
On 19 October 2017 at 08:34, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote:
> Nick Coghlan wrote:
>
>> since breaking up the current single level loops as nested loops would be
>> a pre-requisite for allowing these APIs to check for signals while they're
>>
On 18 October 2017 at 22:53, Serhiy Storchaka <storch...@gmail.com> wrote:
> 18.10.17 13:22, Nick Coghlan пише:
>
>> 2.. These particular cases can be addressed locally using existing
>> protocols, so the chances of negative side effects are low
>>
>
> Only t
On 18 October 2017 at 22:51, Stefan Krah <ste...@bytereef.org> wrote:
> On Wed, Oct 18, 2017 at 10:43:57PM +1000, Nick Coghlan wrote:
> > Per-process memory quotas *can* help avoid this, but enforcing them
> > requires that every process run in a resource controlled san
rpeter's own allocations,
even if it missed those in extension modules):
https://docs.python.org/dev/whatsnew/3.6.html#optimizations
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
On 18 October 2017 at 20:39, Koos Zevenhoven <k7ho...@gmail.com> wrote:
> On Oct 18, 2017 13:29, "Nick Coghlan" <ncogh...@gmail.com> wrote:
>
> On 18 October 2017 at 19:56, Koos Zevenhoven <k7ho...@gmail.com> wrote:
>
>> I'm unable to reprod
t;> for i in itertools.count():
> ... pass
> ...
>
That's interrupting the for loop, not the iterator. This is the test case
you want for the problem Jason raised:
>>> "a" in itertools.count()
Be prepared to suspend and terminate the affected process, because Ctrl-C
isn
On 18 October 2017 at 03:39, Koos Zevenhoven <k7ho...@gmail.com> wrote:
> On Tue, Oct 17, 2017 at 5:26 PM, Serhiy Storchaka <storch...@gmail.com>
> wrote:
>
>> 17.10.17 17:06, Nick Coghlan пише:
>>
>>> Keep in mind we're not talking about a regular loop
On 17 October 2017 at 23:17, Koos Zevenhoven <k7ho...@gmail.com> wrote:
> On Tue, Oct 17, 2017 at 2:46 PM, Serhiy Storchaka <storch...@gmail.com>
> wrote:
>
>> 17.10.17 14:10, Nick Coghlan пише:
>>
>>> 1. It's pretty easy to write "for x in y in y&
On 17 October 2017 at 21:46, Serhiy Storchaka <storch...@gmail.com> wrote:
> 17.10.17 14:10, Nick Coghlan пише:
>
>> 1. It's pretty easy to write "for x in y in y" when you really meant to
>> write "for x in y", and if "y" is an infinite ite
On 17 October 2017 at 19:19, Serhiy Storchaka <storch...@gmail.com> wrote:
> 17.10.17 09:42, Nick Coghlan пише:
>
>> On 17 October 2017 at 16:32, Nick Coghlan <ncogh...@gmail.com > ncogh...@gmail.com>> wrote:
>>
>> So this sounds like a reas
On 17 October 2017 at 17:44, Steven D'Aprano <st...@pearwood.info> wrote:
> On Tue, Oct 17, 2017 at 04:42:35PM +1000, Nick Coghlan wrote:
>
> > I should also note that there's another option here beyond just returning
> > "False": it would also be rea
On 17 October 2017 at 16:32, Nick Coghlan <ncogh...@gmail.com> wrote:
> So this sounds like a reasonable API UX improvement to me, but you'd need
> to ensure that you don't inadvertently change the external behaviour of
> *successful* containment tests.
>
I should also note th
you started (if the item wasn't found).
> itertools.repeat is even easier, just compare to the repeatable element
>
+1
So this sounds like a reasonable API UX improvement to me, but you'd need
to ensure that you don't inadvertently change the external behaviour of
*successful* containmen
ent for changing anything - rather, it's
about my changing my perspective on how beneficial it would be to have
generators default to maintaining their own distinct logical context (which
then becomes an argument for *not* changing anything).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail
On 15 October 2017 at 20:45, Paul Moore <p.f.mo...@gmail.com> wrote:
> On 15 October 2017 at 06:43, Nick Coghlan <ncogh...@gmail.com> wrote:
>
> > # Generator form
> > def _results_gen(data):
> > for item in data:
&
iciently
ubiquitous that we'll be able to rely on that as our 3rd generation time
representation (where the first gen is seconds as a 64 bit binary float and
the second gen is nanoseconds as a 64 bit integer).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
existing language level exception handling semantics
already work just fine should then also be able to rely on the default
execution context management semantics.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
ator __next__ methods"); and
* "Generator functions should otherwise continue to be unsurprising
syntactic sugar for objects that implement the regular iterator protocol"
(aka "generators shouldn't implicitly capture their creation context, as
that would make them *less* like
On 15 October 2017 at 14:53, M.-A. Lemburg <m...@egenix.com> wrote:
> On 15.10.2017 06:39, Nick Coghlan wrote:
> > On 15 October 2017 at 05:47, Paul Moore <p.f.mo...@gmail.com
> > <mailto:p.f.mo...@gmail.com>> wrote:
> >
> > On 14 October 20
On 15 October 2017 at 05:47, Paul Moore <p.f.mo...@gmail.com> wrote:
> On 14 October 2017 at 17:50, Nick Coghlan <ncogh...@gmail.com> wrote:
> > If you capture the context eagerly, then there are fewer opportunities to
> > get materially different values from "
al use of async for
> something like web crawling or collecting subprocess output in a
> largely non-async app). If that *does* happen, then async needs to be
> much more widely understandable - maintenance programmers who have
> never used async will start encountering it in corners of thei
:
* time_ns.time()
* time_ns.monotonic()
* time_ns.perf_counter()
* time_ns.clock_gettime()
* time_ns.clock_settime()
The idea here would be akin to the fact we have both math and cmath as
modules, where the common APIs conceptually implement the same algorithms,
they just work with a differ
change ("It's sometimes useful" isn't
compelling enough - we know it's sometimes useful, that's why it's listed
as an example recipe).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing
value) that can
provide easy execution context isolation without an event loop to manage
it, I just think that would be more appropriate as a wrapper API that can
be placed around any iterable, rather than being baked in as an intrinsic
property of generat
ted, I do concede that creation time context
capture would likely also work out OK for the coroutine case, which would
leave contextlib.contextmanager as the only special case (and it would turn
off both creation-time context capture *and* context isolation).
Cheers,
Nick.
--
Nick Coghlan |
tion of
map(), functools.partial(), and contextvars.run_in_execution_context().
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
lier versions.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
tics down and explain what the
try/finally equivalent looks like.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
On 10 October 2017 at 01:24, Guido van Rossum <gu...@python.org> wrote:
> On Sun, Oct 8, 2017 at 11:46 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
>
>> On 8 October 2017 at 08:40, Koos Zevenhoven <k7ho...@gmail.com> wrote:
>>
>>> I do remember Yu
init__(self, gi):
self._gi = gi
self._ec = contextvars.get_execution_context()
def __next__(self):
return self.send(None)
def send(self, value):
return contextvars.run_with_execution_context(self.ec,
self._gi.send, value)
d
emantics in a subclass such that if the
queue fills up, submitters start getting errors instead of silently
discarding older messages, allowing backpressure to be more easily
propagated through a system of queues).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
thon APIs.
The difference I see relates to the fact that in Python:
* sets of strings are easier to work with than integer bitfields
* adding a new keyword-only argument to existing APIs is straightforward
While in C:
* integer bitfields are easier to work with than Python sets of Python strings
*
201 - 300 of 592 matches
Mail list logo
