On Fri, 14 May 2021 at 20:06, Martin Teichmann
wrote:
> > Also consider the section in the PEP format "How would we teach this?"
> > How would you explain to someone with no programming background, maybe
> > a high school student, that 3/4 and 3 / 4 mean different things in
> > Python? Your
On Tue, 18 May 2021 at 15:16, Martin Teichmann
wrote:
>
> Because reality. People would like to write 1/2 * m * v**2 to mean the
> obvious thing, without having to think about the details. And there are many
> people like this, this is why it shows up on this mailing list regularly. I
> have
On Tue, 18 May 2021 at 16:55, Martin Teichmann
wrote:
>
> Hi Paul,
>
> > > I'd actually prefer to write (m*v**2)/2. Or (m/2)*v**2. But those
> > wouldn't work, the way you describe your proposal. And I'd be very
> > concerned if they behaved differently than 1/2 * m * v**2...
>
> Sure they do
On Wed, 19 May 2021 at 07:41, Martin Teichmann
wrote:
> that worked well, but actually we would like to write the last line simply as
>
> >>> solve(x**2 == 1/2)
>
> as you might notice, this is fully legal Python syntax. Unfortunately the
> semantics is such that sympy has no way to
On Fri, 14 May 2021 at 16:29, David Mertz wrote:
>
> The memory simply blows up too fast for this to be practical (at least as a
> default) a float is always 64 bits, a fraction is unboundedly large if
> numerator and denominator are coprime.
>
> A toy example with a half dozen operations won't
On Fri, 14 May 2021 at 16:54, Martin Teichmann
wrote:
> That is absolutely what I would like to have. The fractions module is very
> small, it can easily be made a builtin. This would also speed it up
> significantly, I hope. Probably close to the speed of floats, given that most
> of the time
On Wed, 26 May 2021 at 12:59, Shreyan Avigyan wrote:
> 4. constant pi = 3.14
> # later
> pi = 3.1415 # Error
Steven's already asked what error, and is it compile time or runtime. I'll add
foo.py:
constant x = 12
bar.py
import foo
foo.x = 19
You can only detect this at runtime.
On Wed, 26 May 2021 at 13:13, Shreyan Avigyan wrote:
>
> Reply to Paul Moore:
>
> In Python terms, a constant is a name that binds itself to a value in memory
> and that name cannot bind itself to a different value now (unlike variables).
> The value can be mutated (if mut
On Wed, 26 May 2021 at 12:55, Shreyan Avigyan wrote:
>
> > What's a const *ptr and a const *ptr const?
>
> In C, a const pointer means a pointer that can only point to one value while
> const pointer const means a pointer that can only point to one constant value.
Python has names that bind to
On Wed, 26 May 2021 at 14:33, Shreyan Avigyan wrote:
>
> Reply to Paul Moore:
>
> > But you just said it was runtime, so it definitely *isn't* similar to
> > the syntax error "Can't assign to literal here". You're making
> > inconsistent statements aga
On Thu, 27 May 2021 at 15:04, Chris Angelico wrote:
> Hmm.
>
> def static(**kw):
> def deco(func):
> statics = types.SimpleNamespace(**kw)
> @functools.wraps(func)
> def f(*a, **kw):
> func(*a, **kw, _statics=statics)
> return f
> return deco
>
On Thu, 27 May 2021 at 15:49, Chris Angelico wrote:
>
> On Fri, May 28, 2021 at 12:25 AM Paul Moore wrote:
> >
> > On Thu, 27 May 2021 at 15:04, Chris Angelico wrote:
> > def static(**statics):
> > def deco(func):
> > for name, value in statics.i
On Thu, 27 May 2021 at 14:22, Chris Angelico wrote:
> Note that the statics *must* be defined on the function, NOT on the
> code object. Just like function defaults, they need to be associated
> with individual instances of a function.
>
> >>> f = []
> >>> for n in range(10):
> ... def
On Fri, 28 May 2021 at 13:11, Steven D'Aprano wrote:
> We might not even need new syntax if we could do that transformation
> using a decorator.
>
>
> @static(var=initial)
> def func():
> body
The problem here is injecting the "nonlocal var" statement and
adjusting all of the
On Tue, 1 Jun 2021 at 13:16, Steven D'Aprano wrote:
> We can distinguish the two contexts by using different signatures. The
> signature used depends entirely on the call site, not the decorator, so
> it is easy for the interpreter to deal with.
>
> If the decorator is called on a function or
On Sun, 27 Jun 2021 at 08:11, Paul Bryan wrote:
>
> It looks like you're suggesting hard-coding specific language escape
> conventions into f-strings?
That's how I understood the proposal too. Hard coding specific
conventions shouldn't be part of a language construct IMO.
> What if instead you
On Wed, 5 May 2021 at 11:33, Matt del Valle wrote:
>> To give an example:
>>
>> def spam():
>> return "spam spam spam!"
>>
>> def eggs():
>> return spam()
>>
>> namespace Shop:
>> def spam():
>> return "There's not much call for spam here."
>>
On Mon, 3 May 2021 at 04:00, David Álvarez Lombardi
wrote:
> This is the mindset that I had. I understand there are other ways to do what
> I am asking. (I provided one in my initial post.) I am saying it relies on
> what I believe to be a notoriously unintuitive method (str.join) and an even
On Tue, 9 Feb 2021 at 17:32, Inada Naoki wrote:
>
> On Tue, Feb 9, 2021 at 7:42 PM M.-A. Lemburg wrote:
> >
> > Here's a good blog post about setting env vars on Windows:
> >
> >
On Wed, 10 Feb 2021 at 07:14, Christopher Barker wrote:
>
> On Tue, Feb 9, 2021 at 1:04 PM Paul Moore wrote:
>>
>> Why is that an issue? In the first instance, do the sorts of
>> "beginner" we're discussing here have multiple python installs? Would
>>
On Wed, 10 Feb 2021 at 13:31, Inada Naoki wrote:
>
> I'm sorry about it. I have not chose actual implementation yet so I
> can not write concrete PEP yet.
It's not a problem. I appreciate all of the time you're putting into
considering the responses and keeping the discussion going. (And
please
On Wed, 10 Feb 2021 at 11:01, Inada Naoki wrote:
>
> On Wed, Feb 10, 2021 at 5:33 PM Paul Moore wrote:
> >
> > So get PYTHONUTF8 added to the environment activate script. That's a
> > simple change to venv. And virtualenv, and conda - yes, it need to
> > happen
On Thu, 11 Feb 2021 at 15:09, J. Pic wrote:
>
> I think you also need return, and double space pound space qa to pass linters:
>
> def foo(): return 1 # noqa
>
> Instead of
>
> foo = lambda: 1
>
> And this proposal:
>
> foo(): 1
>
> The benefit is just to get more out of the 80 characters when we
On Fri, 12 Mar 2021 at 15:53, Paul Bryan wrote:
>
> My inclination would be to cede code formatting to a tool like Black and
> focus on function:
> https://black.readthedocs.io/en/stable/
... and if you try that out, what you'll find is that black adds parentheses:
y = (
x.rstrip("\n")
On Fri, 12 Mar 2021 at 13:22, roland.puntaier--- via Python-ideas
wrote:
>
> I had posted this as https://github.com/python/peps/issues/1867
> The discussion so far is below.
>
> Please make some arguments.
>
> The major point to me is, that the symmetry is broken,
> which leads to extra editing
On Fri, 12 Mar 2021 at 16:06, Ned Batchelder wrote:
>
> I think the only reason anyone ever used leading commas to begin with was
> because of languages that didn't allow a final trailing comma. In those
> worlds, to keep the editing smooth, people moved the commas to the beginning
> of the
On Wed, 24 Feb 2021 at 13:12, Antoine Pitrou wrote:
>
> On Wed, 24 Feb 2021 13:47:40 +0100
> Stéfane Fermigier wrote:
> > The 3rd solution is probably the best of the 3, but the sharing mechanism
> > still needs to be specified (and, if needed, implemented) properly.
>
> I wouldn't want to
On Thu, 25 Feb 2021 at 19:22, Mike Miller wrote:
> Mr. Random had an interesting point to start this thread, that over-reliance
> on
> venvs may have slowed fixes and improvements on the standard tools and
> distributions. I suspect there is some truth to the assertion.
Arguably, your claim
On Wed, 24 Feb 2021 at 10:55, Stéfane Fermigier wrote:
> There is probably a clever way to reuse common packages (probably via clever
> symlinking) and reduce the footprint of these installations.
Ultimately the problem is that a general tool can't deal with
conflicts (except by raising an
On Sat, 6 Mar 2021 at 07:52, Vincent Cheong wrote:
>
> So I thought, 'Why do we need to make a reversed copy to assign it to the
> original part, when we can simply reverse the original part itself.' That's
> the paradigm.
A few points strike me here:
1. The question you asked ("why do we
On Sat, 6 Mar 2021 at 10:42, Vincent Cheong wrote:
>
> I see.
>
> You have coined the term exactly, partial-reverse. Nice. You have also put
> forward a realistic question of 'why do we need'. Well, surely not everyone
> needs it and definitely it's not urgently needed, but its just the
>
On Tue, 23 Feb 2021 at 15:52, M.-A. Lemburg wrote:
>
> On 23.02.2021 15:29, Paul Moore wrote:
> > On Tue, 23 Feb 2021 at 14:10, M.-A. Lemburg wrote:
> >>
> >> The natural way in Python to write an anonymous function would
> >> be to simply drop th
On Tue, 23 Feb 2021 at 09:25, Steven D'Aprano wrote:
>
> On Mon, Feb 15, 2021 at 09:29:45AM -0800, Guido van Rossum wrote:
>
> > Proposals like this always baffle me. Python already has both anonymous and
> > named functions. They are spelled with 'lambda' and 'def', respectively.
> > What good
On Tue, 23 Feb 2021 at 14:10, M.-A. Lemburg wrote:
>
> The natural way in Python to write an anonymous function would
> be to simply drop the name in a regular function definition:
>
> def (a): return a**2
>
> The lambda notation is less verbose and closer to computer
> science theory, though:
>
On Mon, 12 Apr 2021 at 11:41, M.-A. Lemburg wrote:
> > Right, except that in practice:
> >
> > 1) Many useful libraries are not documented or properly documented.
>
> In those cases, I'd argue that such libraries then do not really care
> for a specific public API either :-)
>
> > 2) People
On Mon, 12 Apr 2021 at 19:52, Christopher Barker wrote:
>
> Over the years, I've seen __version__ used very broadly but not *quite* in
> all packages. I've always known it was a convention, not a requirement. But
> it turns out it's not even a "official" convention.
>
> But it really would be
On Tue, 13 Apr 2021 at 18:14, Christopher Barker wrote:
>
> I agree here -- I think what needs to be official is what is In an installed
> package/distribution -- not how it gets there. But I do think the standard
> approach should be easy to do, even without special tools.
That's already
On Wed, 21 Apr 2021 at 09:01, Serhiy Storchaka wrote:
>
> Currently format strings (and f-string expressions) support three
> conversions: !s -- str, !r -- repr and !a for ascii.
>
> I propose to add support of additional conversions: for int, float and
> operator.index. It will help to convert
l. I just told him
> to imagine it like def _(args): return something. Assign it to a variable and
> that variable replaces the underscore. He got it but he found it weird.
> Sent from my iPhone
>
> > On 12 Feb 2021, at 1:41 PM, Paul Moore wrote:
> >
> > I'm not sur
On Tue, 16 Feb 2021 at 16:40, Ned Batchelder wrote:
>
> "lambda" is unnecessarily obscure.
>
> Beginner: "why is it called lambda?"
>
> Teacher: "Don't worry about it, just use it to define a function"
>
> I'm not taking a side on whether to change Python, but let's please not
> lose sight of
On Fri, 12 Feb 2021 at 09:26, Abdulla Al Kathiri
wrote:
>
> I actually like the “(x, y=7) => x + y” and “async (x, y) => asyncio.sleep(x
> + y)” for both normal and async anonymous functions respectfully.
I think it's a reasonable syntax, although it could be over-used.
That's not an issue with
On Tue, 24 Aug 2021 at 12:07, Tim Hoffmann via Python-ideas
wrote:
> Just like length is. It's a basic concept and like __bool__ and __len__ it
> should be upon the objects to specify what empty means.
It feels like these arguments in the abstract are mostly going round
in circles. It's
On Tue, 24 Aug 2021 at 23:06, Tim Hoffmann via Python-ideas
wrote:
>
> I also have the feeling that this is going round in circles. So let me get
> back to the core question:
>
> **How do you check if a container is empty?**
>
> IMHO the answer should not depend on the container. While emptiness
On Wed, 25 Aug 2021 at 14:13, Tim Hoffmann via Python-ideas
wrote:
>
> Guido van Rossum wrote:
> > So then the next question is, what's the use case? What code are people
> > writing that may receive either a stdlib container or a numpy array, and
> > which needs to do something special if there
On Wed, 25 Aug 2021 at 14:00, Tim Hoffmann via Python-ideas
wrote:
>
> I can agree that "len(c) == 0" should mean "c is empty" for all practical
> purposes (and numpy and pandas conform with that).
OK
> But "bool(c)" should mean "c is empty" is an arbitrary additional constraint.
> For some
On Mon, 30 Aug 2021 at 23:27, Nick Parlante wrote:
> I don't know Chris, doesn't this just show that If you construct a class with
> a, shall we say, "oddball" definition of ==, then using == on that class gets
> oddball results. And it goes without saying that we all understand that None
>
You can already do this using filter(None, a)
>>> list(filter(None, [None, "", "-filove-python", "CFLAGS=-O3"]))
['-filove-python', 'CFLAGS=-O3']
There's arguably a minor readability improvement (compress(a) suggests
"remove the unneeded elements") but I'm not sure that's enough to
On Tue, 14 Sept 2021 at 08:38, m...@dyatkovskiy.com
wrote:
> Main motivation was a use case where we gather command line options, and some
> of them are… optional.
[...]
> And yet I’m solid that we need some compact and nice way for rendering
> strings with command options. That would be a
I doubt it, it seems way too specialised to be worth making into a
language feature.
If you want to, you can write a function:
def limits(a, b):
return a+b, a-b
Paul
On Tue, 14 Sept 2021 at 14:55, wrote:
>
> Hi all,
>
> I was wondering on whether there is any interest in introducing a
>
On Tue, 14 Sept 2021 at 20:44, Marc-Andre Lemburg wrote:
>
> I sometimes write Python scripts which need to work in specific
> work directories.
>
> When putting such code into functions, the outer function typically
> does not expect the current work dir (CWD) to be changed, so wrap the
> code
On Tue, 14 Sept 2021 at 19:58, Tim Peters wrote:
> Except it's not that simple:
Apologies, Tim, it took me a couple of reads to work out what you were
saying here. I hope you won't mind if I restate the point for the
benefit of anyone else who might have got confused it like I did...
> def
On Wed, 15 Sept 2021 at 08:02, Christian Heimes wrote:
> The "better way" to handle current working directory is to use the
> modern *at() variants of syscalls, e.g. openat() instead open(). The
> variants take an additional file descriptor dirfd that is used as the
> current working directory
On Tue, 13 Jul 2021 at 15:56, Jonathan Fine wrote:
>
> The interactive help message for writelines gives no help. I've made an
> enhancement request to b.p.o.
>
> help(open('/dev/zero').writelines) gives no help
> https://bugs.python.org/issue44623
>
> Please take a look.
Works for me on Python
On Thu, 29 Jul 2021 at 15:39, Leonardo Freua
wrote:
>
> Would it be interesting to create a @deprecated decorator to avoid adding
> warnings.warn("deprecation message", DeprecationWarning, stacklevel=2) in
> methods body?
I don't see the value personally.
> Using the decorator approach to
I assume that such a feature would simply behave exactly the same as a
match statement:
def fib(arg):
match arg:
case 0:
return 0
case 1:
return 1
case n:
return fib(n-1) + fib(n-2)
# I know this is only a trivial example,
On Sat, 25 Sept 2021 at 06:09, Stephen J. Turnbull
wrote:
>
> Guido van Rossum writes:
>
> > I think this is by far the best option. Pytest can evolve much faster than
> > the stdlib.
>
> Is there no room for making it easier to do this with less invasive
> changes to the stdlib, or are Steven
On Sun, 10 Oct 2021 at 03:20, Finn Mason wrote:
>
> Hello all,
>
> I was thinking about the following idioms:
>
> __version__ = "1.0"
>
> import sys
> if sys.version_info < (3, 6):
> # Yell at the user
>
>
> I feel like there could be a better way to define versions. There's no real
>
On Sun, 10 Oct 2021 at 05:06, Finn Mason wrote:
>
> Let's get back to the original topic. Should `dict.items()` be indexable now
> that dicts are ordered? I say yes. Why shouldn't it?
I say no.
"Why shouldn't it?" isn't sufficient justification for a change.
Because it costs someone time and
On Thu, 14 Oct 2021 at 13:04, Ricky Teachey wrote:
>
> I think all of this additional syntax is just a mistake.
>
> The reason is it will encourage people to not properly annotate their input
> types for duck typing. Some of these shortcuts might be nice for output
> types. But the more general
On Fri, 15 Oct 2021 at 18:07, Sebastian M. Ernst wrote:
> Ignoring typeguard, my suggestion still stands, although slightly
> changed: Annotating a dictionary as described earlier in such a way that
> type inference is not required OR in such a way that run-time checkers
> have a chance to work
Mypy correctly rejects this:
❯ type .\t.py
from numbers import Number
from typing import Dict
Data = Dict[str, Number]
def foo(bar: Data):
print(bar)
bar[1.0] = b'hello'
PS 17:48 00:00.008 C:\Work\Scratch\foo
❯ mypy .\t.py
t.py:9: error: Invalid index type "float" for "Dict[str,
On Sat, 16 Oct 2021 at 14:07, Alex Waygood wrote:
>
> Indeed — we essentially lie to mypy about the method resolution order for
> list, dict, etc (mypy thinks that list directly inherits from
> collections.abc.MutableSequence — see the typeshed stub here:
>
On Mon, 11 Oct 2021 at 13:05, Chris Angelico wrote:
> In any case, there's not a lot of need to support Python 2 any more,
> so most of this sort of check doesn't exist in my code any more.
... and in particular, "useful to help with code that needs to support
Python 2" won't work as an
On Sat, 16 Oct 2021 at 18:01, Steven D'Aprano wrote:
>
> On Sat, Oct 16, 2021 at 02:49:42PM +0100, Paul Moore wrote:
>
> > I'd be more likely to just remove the types (the type checking
> > equivalent of `#noqa` when you don't agree with what your style
> > checker
On Mon, 18 Oct 2021 at 11:20, Mathew Elman wrote:
>
> I don't know if this has been suggested before, or if this is outlandishly
> impossible (though I would be surprised if it was), so apologies in advance
> if so.
>
> I have on occasion come across a situation where I use/write a signature
On Mon, 18 Oct 2021 at 12:49, Mathew Elman wrote:
>
> The point is that at the moment to set this sort of api up requires a lot of
> work, defeating 50% of the value i.e. to define a new function with the
> attribute access behaviour requires defining each individual function to
> return a
On Wed, 13 Oct 2021 at 19:02, <2qdxy4rzwzuui...@potatochowder.com> wrote:
> So aside from filename extensions, what are the real use cases for
> suffix removal? Plurals? No, too locale-dependent and too many
> exceptions. Whitespace left over from external data? No, there's
> already other
On Fri, 1 Oct 2021 at 15:50, Christopher Barker wrote:
>
> The fact that the built in “any” is not a type is not an implementation
> detail. any() and typing.Any are completely different things/concepts. They
> just happen to be spelled the same.
Agreed.
> I don’t think it’s a bad thing that
On Sat, 2 Oct 2021 at 13:22, Aaron Stacy wrote:
>
> I’d like to propose an enhancement to the wonderful pathlib module: make Path
> instances iterable, where the iterator returns subpaths.
>
> This would be functionally very similar to Path(some_directory).rglob(‘*’).
... which is of course the
On Fri, 24 Sept 2021 at 12:05, Noam Tenne wrote:
> Caveats
> ---
>
> It is important to note that expressions with side effects are affected by
> this feature. This is because in order to display this information, we must
> store references to the instances and not just the values.
One
This should probably reference PEP 661 (Sentinel Values) which is
being discussed on Discourse:
https://discuss.python.org/t/pep-661-sentinel-values/9126
It's a different proposal, but one of the major motivating use cases
(if not the only one) for sentinels is handling function default
values
On Mon, 6 Dec 2021 at 09:45, Stephen J. Turnbull
wrote:
>
> Rob Cliffe via Python-ideas writes:
>
> > Nobody has attempted (or at least completed) a PEP, never mind an
> > implementation, of a "generalized deferred object/type", in the last N
> > years or decades.
>
> Haskell anything. Ruby
On Mon, 6 Dec 2021 at 11:21, Chris Angelico wrote:
> The reason I consider this to be an independent proposal, and NOT a
> mechanism for late-bound defaults, is this problem:
>
> def f(lst, n=>len(lst)):
> lst.append(1)
> print(n)
>
> f([10, 20, 30])
>
> A late-bound default should print
Let's just say up front that I'm a strong -1 on this proposal, as I
think it is needless churn, and while it may be *technically* backward
compatible, in reality it will be immensely disruptive.
There's one particular point I want to pick up on, though.
On Thu, 11 Nov 2021 at 15:25, Matt del
On Thu, 11 Nov 2021 at 17:13, Carl Meyer wrote:
>
> I'm also -1 on churning the stdlib in search of a global consistency
> that PEP 8 itself disavows, but this particular argument against it
> doesn't make sense:
>
> On Thu, Nov 11, 2021 at 9:14 AM Paul Moore wrote:
> >
On Thu, 11 Nov 2021 at 22:22, Brendan Barnwell wrote:
>
> On 2021-11-11 09:33, Paul Moore wrote:
> > I understand that. However, PEP 8 states "Names that are visible to
> > the user as public parts of the API should
> > follow conventions that reflect*usage* rather t
On Fri, 12 Nov 2021 at 03:46, Steven D'Aprano wrote:
>
> On Thu, Nov 11, 2021 at 10:06:45PM -0500, Ricky Teachey wrote:
>
> > Is there a standard idiom-- perhaps using a type-hint-- to signal to the
> > IDE/linter that my user-defined class is intended to be used as a
> > function/factory, and
On Sat, 13 Nov 2021 at 08:47, Stephen J. Turnbull
wrote:
>
> A final comment: I wonder if you're being too conservative. It's true
> that generally we prefer small targeted modules in the stdlib, but
> everybody needs tests (even if they don't know it ;-), and there might
> be quite large
On Fri, 26 Nov 2021 at 14:39, Raimi bin Karim wrote:
> So this is more of a heartfelt note rather than an objective one — I would
> love
> my fellow Python programmers to be exposed to this mental model, and that
> could only be done by implementing it in the standard library.
I'm somewhat
On Sat, 30 Oct 2021 at 23:13, Brendan Barnwell wrote:
>
> On 2021-10-30 15:07, David Mertz, Ph.D. wrote:
> > I'm -100 now on "deferred evaluation, but contorted to be useless
> > outside of argument declarations."
> >
> > At first I thought it might be harmless, but nothing I really care
> >
On Tue, 26 Oct 2021 at 16:48, Eric V. Smith wrote:
>
> And also the "No Loss of Abilities If Removed" section sort of applies
> to late-bound function arguments: there's nothing proposed that can't
> currently be done in existing Python. I'll grant you that they might
> (might!) be more
On Tue, 26 Oct 2021 at 19:25, Chris Angelico wrote:
>
> On Wed, Oct 27, 2021 at 5:05 AM Paul Moore wrote:
> >
> > On Tue, 26 Oct 2021 at 16:48, Eric V. Smith wrote:
> > >
> > > And also the "No Loss of Abilities If Removed" section sort of applies
&
On Sun, 31 Oct 2021 at 12:45, Eric V. Smith wrote:
>
> I think it's safe to say people are opposed to the PEP as it current
> stands, not in it's final, as yet unseen, shape. But I'm willing to use
> other words that "I'm -1 on PEP 671". You can read my opposition as "as
> it currently stands,
On Sat, 23 Oct 2021 at 17:09, Chris Angelico wrote:
>
> Proposal: Proper syntax and support for late-bound argument defaults.
>
> def spaminate(thing, count=:thing.getdefault()):
> ...
>
> def bisect(a, x, lo=0, hi=:len(a)):
> if lo < 0:
> raise ValueError('lo must be
On Wed, 1 Dec 2021 at 15:24, David Mertz, Ph.D. wrote:
>
> On Wed, Dec 1, 2021 at 9:24 AM Paul Moore wrote:
>>
>> I think that the only
>> thing I might use it for is to make it easier to annotate defaults (as
>> f(a: list[int] => []) rather than as f(a: li
On Wed, 1 Dec 2021 at 06:19, Chris Angelico wrote:
>
> I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/
> with some additional information about the reference implementation,
> and some clarifications elsewhere.
>
> *PEP 671: Syntax for late-bound function argument defaults*
>
On Thu, 9 Dec 2021 at 11:51, Chris Angelico wrote:
>
> Are = and := confusing? They are also very similar, and they have some
> subtle distinctions. Is it a problem for two different operators to
> look similar when they do very similar things?
Maybe. I don't use assignment expressions - I don't
On Thu, 9 Dec 2021 at 06:49, Christopher Barker wrote:
>
> (I started writing this this morning, and there’s been quite a bit more
> discussion since, but I don’t think it’s completely too late)
Your email client is doing "white on white" again. You should try to
get that fixed :-(
I agree,
On Wed, 8 Dec 2021 at 23:40, Chris Angelico wrote:
>
> I have attempted to explain the syntax. What is confusing?
>
> def f(x=spam): ...
>
> def f(x=>spam): ...
Are we using the term "confusing" in different ways? I'm saying that
it's easy to confuse the two forms = and =>, as they look very
On Wed, 8 Dec 2021 at 18:09, Chris Angelico wrote:
>
> On Thu, Dec 9, 2021 at 4:55 AM Stephen J. Turnbull
> wrote:
> > But the "good idea" of general deferreds is only marginally relevant
> > to our -1s. It's those -1s that constitute the main issue for Chris,
> > since they're a noisy signal
On Thu, 9 Dec 2021 at 20:55, deavid wrote:
>
> So well, my question here is: why is this not a thing? Has anyone proposed
> something like this before? I feel I must have missed something important.
IMO, making types mandatory would severely penalise the use of Python
for scripting, exploratory
On Thu, 2 Dec 2021 at 08:29, Paul Moore wrote:
>
> On Wed, 1 Dec 2021 at 22:27, Greg Ewing wrote:
> >
> > On 2/12/21 4:40 am, Paul Moore wrote:
> > > the
> > > intended use is that people must supply a list[int] or not supply the
> > > argument *a
On Wed, 1 Dec 2021 at 22:27, Greg Ewing wrote:
>
> On 2/12/21 4:40 am, Paul Moore wrote:
> > the
> > intended use is that people must supply a list[int] or not supply the
> > argument *at all*.
>
> I don't think this is a style of API that we should be encouragi
https://pypi.org/project/platformdirs/ is intended to cover this sort
of requirement.
Paul
On Wed, 15 Dec 2021 at 13:47, JGoutin via Python-ideas
wrote:
>
> Hello,
>
> The idea is to add 3 functions to get "config", "data" and "cache"
> directories that are commonly used to store application
On Wed, 8 Dec 2021 at 23:18, Chris Angelico wrote:
> Part of the problem is that it is really REALLY hard to figure out
> what the actual objections are. I asked, and the one clear answer I
> got was one subjective opinion that the cognitive load exceeded the
> benefit. Great! That's one person's
On Wed, 8 Dec 2021 at 22:53, Chris Angelico wrote:
> Most of that is a *massive* YAGNI as regards function default
> arguments. We do not need parallel execution just to figure out the
> length of a list passed as a previous parameter. So you've just added
> weight to my argument that a generic
On Wed, 8 Dec 2021 at 19:59, Rob Cliffe via Python-ideas
wrote:
>
> On 08/12/2021 19:27, Paul Moore wrote:
> >
> > The reason deferred objects keep coming up is because they *do* have a
> > much more compelling benefit - they help in a much broader range of
> > cases
You've given some examples of what flatten() does, but I still don't
really understand how it's expected to work. Could you provide a
specification, rather than just examples? Also, I've never needed a
function like this in anything I've ever done - that may mean nothing,
but it does suggest that
Maybe your examples aren't making it clear what you're suggesting,
then. I'm in agreement with Chris, your "nested iteration tool" sounds
like something that would have so many configuration options and
parameters that it would be harder to use than traversing "by hand".
But maybe you imagine
On Mon, 17 Jan 2022 at 01:11, Chris Angelico wrote:
>
> On Mon, Jan 17, 2022 at 10:14 AM Paul Moore wrote:
> >
> > On Sun, 16 Jan 2022 at 22:55, Steven D'Aprano wrote:
> > > >>> def f():
> > > ... return frozenset({1, 2, 3})
&
601 - 700 of 793 matches
Mail list logo
