On 17 October 2017 at 16:32, Nick Coghlan 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 that there's
(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* containment
rgument 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...@g
On 15 October 2017 at 20:45, Paul Moore wrote:
> On 15 October 2017 at 06:43, Nick Coghlan wrote:
>
> > # Generator form
> > def _results_gen(data):
> > for item in data:
> > with adjusted_context():
> >
at 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
_
they will impact the active execution context.
Code for which the 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 |
s that will make them *more*
like explicit iterator __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
On 15 October 2017 at 14:53, M.-A. Lemburg wrote:
> On 15.10.2017 06:39, Nick Coghlan wrote:
> > On 15 October 2017 at 05:47, Paul Moore > <mailto:p.f.mo...@gmail.com>> wrote:
> >
> > On 14 October 2017 at 17:50, Nick Coghlan > <mailto:ncogh
On 15 October 2017 at 05:47, Paul Moore wrote:
> On 14 October 2017 at 17:50, Nick Coghlan wrote:
> > If you capture the context eagerly, then there are fewer opportunities to
> > get materially different values from "data = list(iterable)" and "data =
>
to handle grabbing a webpage.
> I'm uncertain whether the intent is for the core async features to
> follow this model, or whether we'd expect in the longer term for
> "utility adoption" of async to happen (tactical use of async for
> something like web crawling or collectin
s.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 different numeric type (floats vs complex numbers).
7;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 maili
they retrieve a new 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 generators.
Cheers,
Nick.
On 13 October 2017 at 10:56, Guido van Rossum wrote:
> I'm out of energy to debate every point (Steve said it well -- that
> decimal/generator example is too contrived), but I found one nit in Nick's
> email that I wish to correct.
>
> On Wed, Oct 11, 2017 at 1:2
but it's also code that will work all the
way back to when the decimal module was first introduced. Because of the
way I've named the rounding generator, it's also clear to readers that the
code is aware of the existing semantics, and is intentionally relying on
them.
The curr
that couldn't be addressed by a combination 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/
semantics by *default*, then that's going to be a much harder
case to make because it's a gratuitous compatibility break - code that
currently works one way will suddenly start doing something different, and
end users will have difficulty getting it to behave the same way on 3.7 as
it does
wn 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
Cod
On 10 October 2017 at 01:24, Guido van Rossum wrote:
> On Sun, Oct 8, 2017 at 11:46 PM, Nick Coghlan wrote:
>
>> On 8 October 2017 at 08:40, Koos Zevenhoven wrote:
>>
>>> I do remember Yury mentioning that the first draft of PEP 550 captured
>>> somet
i
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)
def throw(self,
On 4 October 2017 at 15:47, Serhiy Storchaka wrote:
> 04.10.17 07:58, Nick Coghlan пише:
>>
>> For deque specifically, I like Steven D'Aprano's suggestion of a
>> "__dropped__" or "__discard__" subclassing API that makes it
>> straight
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
_
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
* supporting a new arg
e C API
is the main reason I think redefining the semantics of the existing
int parameter is worth considering.
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/
c files would be somewhat cryptic-to-humans, but
still relatively easy to translate back to readable strings given the
bitfield values, and common patterns (like 0x14 -> 20 for
nodebug+nodocstrings) would likely become familiar pretty quickly.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gm
On 29 September 2017 at 08:04, Ivan Levkivskyi wrote:
> On 28 September 2017 at 08:27, Nick Coghlan wrote:
>>
>> On 27 September 2017 at 19:28, Ivan Levkivskyi
>> wrote:
>> > If an object that is not a class object appears in the bases of a class
>> > d
t;__orig_bases__"] set
exec_body(ns)
mcl(name, resolved_bases, ns, **updated_kwds)
By contrast, if we decide that we're going do the full MRO resolution
twice, then every metaclass will need to be updated to resolve the
bases correctly (and make sure to use "cls.__base
Forwarding my reply, since Google Groups still can't get the Reply-To
headers for the mailing list right, and we still don't know how to
categorically prohibit posting from there.
-- Forwarded message ------
From: Nick Coghlan
Date: 26 September 2017 at 12:51
Subject: R
rought it up though, I think it's a very good point,
and it's enough to switch me from +0 to -1.
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/
point numbers in those formats, and for floats to gain support for the
corresponding print formatting codes.
So overall, I'm still +0, on the grounds of improving int/float API consistency.
While I'm sympathetic to the concerns about potentially changing the
way the binary/decimal repre
imarily on instinct and experience (which is the way we tend to do
things in the open source community, since it's more fun, and less
effort).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing
ould improve interface
consistency between integers and floating point values, and make it
easier to write correctness tests for IEEE754 floating point hardware
and algorithms in Python (where your input & output test vectors are
going to use binary or hex representations, not decimal).
Cheers,
Ni
was dropped for
Python 3.0.
Cheers,
Nick.
* One case where it was actually fairly common for folks to define
their own str subclasses, rich filesystem path objects, finally gained
its own protocol in Python 3.6
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
pproachable (similar to what we're aiming to do
with packaging.python.org for the software distribution space), a PEP
isn't the right vehicle for it.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-idea
On 14 September 2017 at 08:25, Nick Coghlan wrote:
> On 13 September 2017 at 20:45, Koos Zevenhoven wrote:
>> It's still just *an* interpreter that happens to run __main__. And who says
>> it even needs to be the only one?
>
> Koos, I've asked multiple times now fo
On 14 September 2017 at 09:43, Lukasz Langa wrote:
>> On Sep 13, 2017, at 6:37 PM, Nick Coghlan wrote:
>> That way, during the "from __future__ import lazy_annotations" period,
>> folks will have clearer guidance on how to explicitly opt-in to eager
>>
On 14 September 2017 at 08:46, Nick Coghlan wrote:
> On 13 September 2017 at 14:10, Nathaniel Smith wrote:
>> Subinterpreters are basically an attempt to reimplement the OS's
>> process isolation in user-space, right?
>
> Not really, they're more an attempt to mak
f).
Right now, the closest equivalent to this programming model that
Python offers is to combine threads with queue.Queue, and it requires
a lot of programming discipline to ensure that you don't access an
object again once you've submitted to a queue.
Cheers,
Nick.
--
Nick Co
t; period,
folks will have clearer guidance on how to explicitly opt-in to eager
evaluation via function and class decorators.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-i
On 13 September 2017 at 20:45, Koos Zevenhoven wrote:
> On Wed, Sep 13, 2017 at 6:14 AM, Nick Coghlan wrote:
>>
>> On 13 September 2017 at 00:35, Koos Zevenhoven wrote:>
>>
>> > I don't see how the situation benefits from calling something the "main
On 13 September 2017 at 14:33, Ethan Smith wrote:
> On Tue, Sep 12, 2017 at 8:30 PM, Nick Coghlan wrote:
>> There are a lot of packaging tools in use other than distutils, so I
>> don't think the distutils update proposal belongs in the PEP. Rather,
>> the PEP should
globals() works -
we'd just add the caveat that amendments made that way may be ignored
for things defined as properties.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Py
ases we don't
generally test (e.g. folks rebinding sys.modules to nonsense), and it
would be nice to be able to upgrade those from "don't do that" to "the
obvious way of doing that just plain isn't allowed".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail
since installing under a different package
name is easier to manage using existing publishing tools than
installing to a different target directory?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing
On 13 September 2017 at 00:35, Koos Zevenhoven wrote:
> On Tue, Sep 12, 2017 at 1:40 PM, Nick Coghlan wrote:
>>
>> On 11 September 2017 at 18:02, Koos Zevenhoven wrote:
>> > On Mon, Sep 11, 2017 at 8:32 AM, Nick Coghlan
>> > wrote:
>> >> The line
e expression, whereas referencing a string constant
is faster:
$ python -m perf timeit "int"
.
Mean +- std dev: 27.7 ns +- 1.8 ns
$ python -m perf timeit "lambda: int"
.
Mean +- std dev: 66.0 ns +- 1.7 ns
$ python -m perf timeit "'int'"
Future readers of your code will thank you for
making the widget definitions easier to find, rather than having them
scattered through an arbitrarily large number of nested functions :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 11 September 2017 at 18:02, Koos Zevenhoven wrote:
> On Mon, Sep 11, 2017 at 8:32 AM, Nick Coghlan wrote:
>> The line between it and the "CPython Runtime" is fuzzy for both
>> practical and historical reasons, but the regular Python CLI will
>> always have a
the CPython Runtime can already get pretty
close to just having a pool of peer subinterpreters, and will
presumably be able to get closer over time as the subinterpreter
support becomes more robust.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
ate
"_subinterpreters" API for testing & experimentation purposes (see
https://bugs.python.org/issue30439 ), and reconsidering introducing it
as a public API after there's more concrete evidence as to what can
actually be achieved based on it.
Cheers,
Nick.
--
Nick Coghlan |
e the way the
current redirection into the Python 2 docs is. Given such a mapping,
it would also be possible to add the corresponding canonical URL
entries to the Python 2.7 documentation to merge their search ranking
in to the corresponding Python 3 pages.
Cheers,
Nick.
--
Nick Coghlan | nco
b: int, c: int = 0, *args: int,
d: int, e: int = 0, **kwargs: int
)""",
int]
Ideally, the runtime implementation of that would *skip* parsing the
signature, and instead just keep the string around for on-
ove to Python 3: while module reloading
is a fully supported operation, it also has a lot of subtleties that
make it easy to get wrong.
--
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 24 August 2017 at 08:20, Neil Girdhar wrote:
> On Wed, Aug 23, 2017 at 3:31 AM Nick Coghlan wrote:
>> However, PEP 550's execution contexts may provide a way to track the
>> test state reliably that's independent of being a method on a test
>> case instance
ing.locals() et al)
* context locals (PEP 550)
The fact contexts can be nested, and a failed lookup in the active
implicit context may then query outer namespaces in the current
execution context would then be directly analogous to the way name
lookups are resolved for frame locals.
Cheers,
Ni
the current visibly
object-oriented one.
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 22 August 2017 at 15:34, Nick Coghlan wrote:
> On 21 August 2017 at 11:32, Neil Girdhar wrote:
>> This question describes an example of the problem:
>> https://stackoverflow.com/questions/8416208/in-python-is-there-a-good-idiom-for-using-context-managers-in-setup-teardown.
Folks, this has come up before, but: please don't post through Google
Groups, as it breaks everyone else's ability to easily reply to the
entire mailing list.
-- Forwarded message ------
From: Nick Coghlan
Date: 22 August 2017 at 15:32
Subject: Re: [Python-ideas] Pleas
ut it
wouldn't be feasible to backport implicit isolation. The same would go
for the various other proposals for implicit isolation - when running
on older versions, the general principle would be "if you (or a
library/framework you're using) didn't explicitly isolate the
executi
On 17 August 2017 at 01:22, Yury Selivanov wrote:
> On Wed, Aug 16, 2017 at 4:07 AM, Nick Coghlan wrote:
>>> Coroutine Object Modifications
>>> ^^
>>>
>>> To achieve this, a small set of modifications to the corout
elf.coro.send)
Offering a combined API may still make sense for usability and
efficiency reasons, but it isn't strictly necessary.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python
If it *still* doesn't find one, then it will set the default value
in the outermost execution context and then return that value.
One thing I like about that phrasing is that we'd be using the word
dynamic in exactly the same sense that dynamic scoping uses it, and
the dynamic context
nd NULL meaning "use outside local context".
>
> I omitted this from the PEP to make it a bit easier to digest, as this
> seemed to be a low-level implementation detail.
Given that the field is writable, I think it makes more sense to just
choose a suitable default, and then rely
get_value() lookups, without making any particular claims about
what the internal implementation data structures actually are.
The run methods could then be sys.run_with_context_chain() (to ignore
the current context entirely and use a completely separate context
chain) and sys.run_with_active_con
efault_value = sys.run_with_local_context(base_context,
self.default_factory)
sys.run_with_local_context(base_context, self.set, default_value)
The default setting for default_factory could then be to raise
RuntimeError complaining that the context item isn't set in the
current context.
execution contexts then
becomes the responsibility of the event loop, which the PEP already
lists as a required change in 3rd party libraries to get this all to
work properly.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
.
This isn't like cr_await and gi_yieldfrom, where we wanted to use
different names because they refer to different kinds of objects.
> Acknowledgments
> ===
[snip]
> Thanks to Nick Coghlan for numerous suggestions and ideas on the
> mailing list, and for
ion in
their builtins as well.
Anyway, potentially a useful option to consider as you work on
revising the proposal - I'll refrain from further comments until you
have an updated draft available :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 14 August 2017 at 02:33, Yury Selivanov wrote:
> On Sat, Aug 12, 2017 at 10:09 PM, Nick Coghlan wrote:
>> That similarity makes me wonder whether the "isolated or not"
>> behaviour could be moved from the object being executed and directly
>> into the key/
ctures for the purpose, rather than being limited to the most
efficient data structures that can readily export a Python-style
mapping interface. The latter can then be provided purely for
introspection purposes.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
API still doesn't rule out adding features like this at a
later date.
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 13 August 2017 at 03:53, Yury Selivanov wrote:
> On Sat, Aug 12, 2017 at 1:09 PM, Nick Coghlan wrote:
>> Now that you raise this point, I think it means that generators need
>> to retain their current context inheritance behaviour, simply for
>> backwards compatibility
ot; explicitly)
Open question: whether having "yield" inside a with statement implies
the creation of an autonomous generator (synchronous or otherwise), or
whether you'd need a decorator to get your context management right in
such cases.
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/
instead of Pythonic ones, but JavaScript *is* one of the
languages we look at for syntactic consistency when considering
potential new additions to Python.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailin
ugin
API (hence why the *specific* proposal in PEP 406 has been withdrawn).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/p
by contextlib.contextmanager before starting
the underlying generator. (It may even make sense to break the naming
symmetry for that attribute, and call it something like "gi_owner",
since generators don't form a clean await-based logical call chain the
way native coroutines do).
On 11 August 2017 at 15:13, Steven D'Aprano wrote:
> On Fri, Aug 11, 2017 at 02:34:53PM +1000, Nick Coghlan wrote:
>> This is another good reason why a termination condition would need to
>> be checked before the filter condition rather than either after it, or
>> only
any of
them would be more readable given a for-while construct, whether as a
statement, or as part of the comprehension syntax. (Note: I'm not
interested enough in the idea to do that evidence gathering myself,
I'm just pointing it out in case anyone is curious enough to take the
gt; condition (var < 100), because we only test the termination condition
> if var is odd, which it never will be.
This is another good reason why a termination condition would need to
be checked before the filter condition rather than either after it, or
only when the filter condition
eness all that much, it just
has the potential to make static analysis easier by eagerly rendering
to an AST rather than having that be handled by the function receiving
the argument.
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 10 August 2017 at 01:49, Soni L. wrote:
> On 2017-08-09 11:54 AM, Nick Coghlan wrote:
>> Right, I was separating the original request to make "{x for x in
>> integers if 1000 <= x < 100}" work into the concrete proposal to
>> make exactly *that* syntax
On 10 August 2017 at 00:54, Nick Coghlan wrote:
> Yeah, if we ever did add something like this, I suspect a translation
> using takewhile would potentially be easier for at least some users to
> understand than the one to a break condition:
>
> {x for x in itertools.count(
e submitter wasn't interested in creating a
more minimalist patch that solved the specific problem (i.e. the list
was pretty out of date) without all the extraneous changes to how the
module actually worked :(
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 9 August 2017 at 18:19, Stephen J. Turnbull
wrote:
> Nick Coghlan writes:
>
> > To analyse and investigate this code, we need to "just know" that:
>
> You can of course hope that help(input().has_vowels) will tell you
> where to find it. If it doesn't,
On 9 August 2017 at 15:38, Guido van Rossum wrote:
> On Tue, Aug 8, 2017 at 10:06 PM, Nick Coghlan wrote:
>> The OP's proposal doesn't fit into that category though: rather it's
>> asking about the case where we have an infinite iterator (e.g.
>> itertools.cou
pretty compelling user-focused justification for incurring that extra
complexity at the language design level.
Cheers,
Nick.
[1] https://mail.python.org/pipermail/python-ideas/2010-April/006983.html
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
hich is why Python offers
features like wildcard imports, runtime support for monkeypatching of
user-defined types, and runtime support for dynamically replacing
builtins and module globals. However, the concerns around the
difficulties of complexity mana
On 2 August 2017 at 02:57, Clément Pit-Claudel wrote:
> On 2017-08-01 17:28, Nick Coghlan wrote:
>> The same rationale holds for any() and all(): supporting multiple
>> positional arguments would be redundant with the existing binary
>> operator syntax, with no clear reas
eing expected to use the
syntactic forms (e.g. [a, b, c], {a, b, c}, (a, b, c))
The same rationale holds for any() and all(): supporting multiple
positional arguments would be redundant with the existing binary
operator syntax, with no clear reason to
actually being an itertools module API has
certainly come up before, though.
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 31 July 2017 at 04:31, Paul Moore wrote:
> On 30 July 2017 at 16:24, Nick Coghlan wrote:
>> Rather than being about any changes on that front, these threads are
>> mostly about making it possible to write that first line as:
>>
>> MyNT = type(implicitly_typed_n
it possible to write that first line as:
MyNT = type(implicitly_typed_named_tuple_factory(foo=None, bar=None))
...
(While they do occasionally veer into discussing the idea of
yet-another-kind-of-data-storage-type, that is an extraordinarily
unlikely outcome)
Cheers,
Nick.
--
Nick Coghlan
needs to settable
from __new__, and Python doesn't provide any inherent mechanism from
distinguishing those cases from post-creation modifications).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mail
On 27 July 2017 at 10:38, Steven D'Aprano wrote:
> On Thu, Jul 27, 2017 at 11:46:45AM +1200, Greg Ewing wrote:
>> Nick Coghlan wrote:
>> >The same applies to the ntuple concept, expect there it's the fact
>> >that it's a *tuple* that conveys the "
On 27 July 2017 at 03:10, Steven D'Aprano wrote:
> On Thu, Jul 27, 2017 at 02:05:47AM +1000, Nick Coghlan wrote:
>> On 26 July 2017 at 11:05, Steven D'Aprano wrote:
>> > I don't see any way that this proposal can be anything by a subtle
>> >
r
conventions in the context of implicit typing: they're the ones where
it feels most annoying to have to separately define that order rather
than being able to just use it directly.
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/
plicitly defined one.
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 25 July 2017 at 11:57, Nick Coghlan wrote:
> Having such a builtin implictly create and cache new namedtuple type
> definitions so the end user doesn't need to care about pre-declaring
> them is still fine, and remains the most straightforward way of
> building a capability l
On 25 July 2017 at 02:46, Michel Desmoulin wrote:
> Le 24/07/2017 à 16:12, Nick Coghlan a écrit :
>> On 22 July 2017 at 01:18, Guido van Rossum wrote:
>>> Honestly I would like to declare the bare (x=1, y=0) proposal dead. Let's
>>> encourage the use of obje
objects, and it's a mess. I expect the bare ntuple to encourage the same
> chaos.
That sounds sensible to me - given ordered keyword arguments, anything
that bare syntax could do can be done with a new builtin instead, and
be inherently more self-documenting as a result.
Cheers,
Nick.
--
301 - 400 of 708 matches
Mail list logo
