u mean by "protocols from dict"? What are these protocols?
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
Python-ideas mailing list -- pytho
ange or isn't
useful, but as long as the result is consistent with the protocol,
that's fine. Just don't use **-unpacking with ranges if you don't want to.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail.&
well. I don't like the idea of relying
on a non-dunder method like .keys() to implement syntax like ** unpacking.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
s far as I can tell, it's not
even documented behavior, so it doesn't constrain anything.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
__
On 2020-12-26 21:02, Steven D'Aprano wrote:
On Sat, Dec 26, 2020 at 06:52:46PM -0800, Brendan Barnwell wrote:
On 2020-12-26 18:44, Steven D'Aprano wrote:
>>>> >I think if we were designing mapping protocols now, that would be an
>>>> >excellent idea, b
ys reflective and in fact definitional of the
language's behavior. In other words, what the language is accountable
to is the documentation on python.org/docs and nothing else.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where ther
On 2020-12-29 12:44, Christopher Barker wrote:
On Tue, Dec 29, 2020 at 11:18 AM Brendan Barnwell mailto:brenb...@brenbarn.net>> wrote:
On 2020-12-29 10:30, Guido van Rossum wrote:
> Long ago we decided that the distinctive
> feature is that mappings have a `keys()` me
that that isn't used as the
main organizing principle of the documentation.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
Python-ide
On 2020-12-29 16:18, Steven D'Aprano wrote:
On Tue, Dec 29, 2020 at 02:20:05PM -0800, Brendan Barnwell wrote:
So, to give an example, the iterator protocol should be documented
right where the `for` statement is documented, and it should be
explicitly framed as "this is the
r the kind of see-also thing that Steven
mentioned --- give the documentation for lists with their methods and so
on, and say "lists implement the iterator protocol (link)".
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where ther
protocol!) and that's enough. But cases where syntax implicitly
invokes the protocol, those are the ones that must be exhaustively listed.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
raise an exception if it wound up recursing through the same object more
than once, rather than getting stuck in an infinite loop?
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a tra
o Python, and even if they were they would and should be
rejected because they don't make any sense, so they don't belong on this
list.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail
that with `return a_dict.setdefault(key,
your_expression_here)`. If the expression is expensive to evaluate you
can use a short-circuiting conditional expression to guard it.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail
hen they don't think so, and leave the rest up to the editor.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
Python-ideas mailing list -- python-ide
y detailed decisions about how it's going to look.
How it looks should be up to the person reading it, and the best way to
do that is to include line breaks in semantically meaningful places and
let the editor (as configured by the reader) choose how to map that onto
a visual display.
So like "func x: x+2" would be better than "lambda x: x+2".
That probably won't happen because no one wants to add new keywords.
But adding new non-keyword ways to do this isn't worth it just to save a
few keystrokes.
--
Brendan Barnwell
"Do not follow whe
On 2021-02-12 03:18, Chris Angelico wrote:
On Fri, Feb 12, 2021 at 7:57 PM Brendan Barnwell wrote:
On 2021-02-11 03:24, J. Pic wrote:
> Hi all,
>
> Lambdas can be defined as such:
>
> w = lambda: [12]
> x = lambda y: len(y)
>
> I'd like to propose the followi
ll-designed" they're only well-designed to
fit into the crappy design that already exists.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
roject/attrdict/ , And I feel like I've seen other
examples of similar names where someone wrote their own
mini-implementation of such a thing.)
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and l
e without adding
complexity of any kind.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
Python-ideas mailing list -- python-ideas@python.o
as a sort of
documentation aid ("this is the public API").
I do think something like __exclude_all__ would be handy. It can be
annoying to have to define __all__ just to exclude a few things. But
it's not a huge issue.
--
Brendan Barnwell
"Do not follow where the path
syntax to implement arbitrary runtime behavior, and we should accept
that doing that may break typecheckers or make life painful for their
maintainers.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--auth
ody influences *different* attributes based on their *relative*
sequential position. . . I find that much more confusing and strange. I
think Simão's version where you give a class-level default for
keyword-only-ness and then override it with field() arguments where
necessary is much cleaner.
--
B
ython has zero need for RPN and adding RPN to Python (assuming that
is what is being proposed here) would be a bad idea in every way
3) There is no point in discussing this further.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and lea
are being foolish. Again, I'm not convinced by the argument
that "in practice" people do foolish things and that therefore we should
encourage them to do more of that.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
ent from different places and putting it together in a template-like
fashion, in the way that f-strings or str.format() facilitate. So I
don't think this proposal would have much practical use in string creation.
So overall I think your proposed string comprehensions would tend to
make Pyth
that would be confusing, because the
behavior is totally different. Even with your __decorator_call__
proposal, there's still a jarring shift from, in some cases, using just
the object, and in other cases stuffing a new parameter (the name) into
the parameter list. That seems awkward to me.
-
stores the data in a way
that's more transparent and more clearly connected to the normal ways of
storing state in Python. It just isn't worth adding yet another
complexity to the language for this minor use case.
--
Brendan Barnwell
"Do not follow
GLOBAL level, meaning that all
functions in the module could always assume it referred to the same
thing. (It's true this might require something different from what was
proposed in the other thread about constants.)
--
Brendan Barnwell
"Do not follow where the path may lead.
It's that ANY ability to create a local variable that is
a fast-lookup shortcut for a global one is enough. My point is that
manually creating fast-lookup local-variable shortcuts is inherently a
performance hack and there's no real use in making it slightly
nicer-looking.
--
On 2021-05-27 14:33, Steven D'Aprano wrote:
But even if we did have actual constants, how does that help get static
*variables*, you know, things that aren't constant but can vary?
All of those use cases can already be handled with a class that stores
its data in an attribute.
On 2021-05-28 04:53, Steven D'Aprano wrote:
On Thu, May 27, 2021 at 07:13:56PM -0700, Brendan Barnwell wrote:
On 2021-05-27 14:33, Steven D'Aprano wrote:
>But even if we did have actual constants, how does that help get static
>*variables*, you know, things that aren't
repr of an empty list is [], but lists are pretty basic and
ubiquitous Python objects that people usually learn about quite early.
Ellipsis is a more obscure thing so it seems worthwhile to label it
somehow rather than just giving a cryptic three dots.
--
Brendan Barnwell
"Do not follow w
's identity, you know its MRO, which tells you
all you need to know about what __getattribute__ calls might happen.
You don't need to know anything about where the object "came from" or
what file you're using it in. But it seems with this proposal you would
need to know,
now
every time you do 2 + 2 you might be invoking some extension behavior.
In my view that is unambiguously a road to madness, and as far as I can
tell the extension mechanism you're proposing is equally ill-advised.
--
Brendan Barnwell
"Do not follow where the p
d for code to
heavily depend on "top down" information that requires you to know
"where you are" (in one module or another) to understand how things
work. That increases cognitive burden and makes code more difficult to
understand.
Personally I'm opposed to anyt
mistake. We need to specifically show
that this will make writing and/or reading code easier and better in
Python, and I think this proposal would do the opposite, making code
harder to read.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
expects people to adjust the options by manually setting attributes one
by one after instance creation.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_
ice to
have the ability to do NAN-aware max and min as well.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
Python-ideas mailing list -- p
unlikely to be a huge deal
for students to later learn the "correct" (aka PEP8-endorsed) way, once
they have a more nuanced understanding of how comparisons work in
Python. There are all kinds of recommendations in PEP8 that aren't
worth worrying about at the initial stages of l
hether or not a specific flag was included.
The repr of such a combination is useful and readable, too.
In general I find that harder to grok than just using separate boolean
arguments for each flag.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is n
cepts about equality,
identity, and how to use them, I think you'll have succeeded. If there
was a moment or a day or even a week in the middle where some people
erroneously thought they should use `== None`, that doesn't really
matter as long as they learn to use `is None` by th
t you could call `my_list.multiget(1, 2, 3)` or
`my_dict.multiget(*some_keys)` and have it do a series of nested
indexes. But I don't think we should add syntax for this, or at least I
think we should not use `*`-unpacking-like syntax for it.
--
On 2021-09-04 05:47, Matsuoka Takuo wrote:
On Sat, 4 Sept 2021 at 16:33, Brendan Barnwell wrote:
In other words, currently `*` can turn what looks like one function
call with one thing inside it into one function call with several things
inside it. You are proposing to make it so
don't see how requiring the user to open the file first on their
own gains anything. In my experience 90% of the time that's just more
cumbersome and I would prefer the library to handle the entire file
operation internally (like pandas does).
--
Brendan Barnwell
"Do not follow wh
n the lexical function
definition would behave differently from one raised deeper in the call
stack. I think that breaks some pretty basic assumptions about how
exceptions work, and I wouldn't support such a change.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, i
;shortdef" or (perhaps with these new parser possibilities
I've heard vague references to) just allow "def" to be used for lambdas
somehow. To my eye, adding arrow-like syntax doesn't help anything.
--
Brendan Barnwell
"Do not follo
allow extracting the logic out of the function
definition into a separate variable (holding the "inline lambda"), which
could help with cases similar to the bisect examples discussed elsewhere
in the thread, where multiple functions share late-binding logic.
--
Brendan Barnwell
&quo
On 2021-10-23 23:33, Steven D'Aprano wrote:
On Sat, Oct 23, 2021 at 08:29:54PM -0700, Brendan Barnwell wrote:
For me the biggest problem with this idea is that it only handles a
subset of cases, namely those that can be expressed as an expression
inlined into the function defin
s I said, I don't support this proposal at all, but I
appear to be in the minority on that, and if does go through I think it
would be even worse if it raises SyntaxError.
--
Brendan Barnwell
"Do not follow where the path may lead. G
egins. The details would have to be worked out (just like they do
for your PEP) but it's not automatically impossible.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
time when we're defining a function" and
restrict this to apply to function parameters rather than, well,
anything? Why not just say we can tag stuff as not being evaluated
right now and then later evaluate it?
--
Brendan Barnwell
"Do not follow where the path may lead.
as argument-passing just to avoid having to type
`if arg is None`.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
Python-ideas mailing list
On 2021-10-26 19:50, Rob Cliffe via Python-ideas wrote:
On 27/10/2021 03:12, Brendan Barnwell wrote:
On 2021-10-26 17:41, Christopher Barker wrote:
Python used to be such a simple language, not so much anymore :-(
I quite agree, and I feel like this is my biggest reason why I
don't
handle
(what I see as) a quite narrow range of expressions.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
Python-ideas mailing list -- python-ideas@py
dimension is worth the gain in expressiveness. Of course there is a lot
of subjectivity here and it seems I am in the minority, but to me the
ability to concisely express short, simple expressions for late-binding
defaults doesn't fall in that sweet spot.
--
Brendan Barnwell
"Do no
create deferred expressions we
should try to make them more generally usable.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
Python-ideas ma
why you seem so resistant to the idea of a more
general deferred evaluation approach to this problem. Generalizing
deferred evaluation somehow would make the proposal MORE orthogonal to
other features, because it would mean you could use a deferred
expression as an argument in the same way you
you have to type it in the docstring yourself". I don't
see that as a big deal. So yes, the status quo is better, because it is
not really any worse, and it avoids the complications that are arising
in this thread (i.e., what order are the arguments evaluated in, can
they reference
unctions to derive
human-readable forms from machine-readable code is handy, but it's not
ALWAYS automatically good regardless of other considerations, and I
don't see that it outweighs the costs here. The benefit of
autogenerating the string "len(a)" from the argument spec isn't q
ation protocol, etc., worked by building on
this object model. But this proposal seems to diverge quite markedly
from that.
If the "late-bound default" is not an object of some kind just like the
early-bound ones are, then I can't
;.
Apart from all the other things about this proposal I don't support, I
don't support the creation of a mysterious "expression" which is not a
first class value and cannot be used or evaluated in any way except
automatically in t
still see it as involving too much of a departure from existing
conventions, too much hairiness in the details, and too little real
benefit, to justify the change.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
he other can be expressed.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscri
on would be nice, but I'm not saying "we need to not do
PEP 671 right away because we should instead do this other thing right
away". We don't need to take any action on this matter at all. I would
rather we do nothing for another 10 years than adopt the current proposal.
checks on
arguments). But the new proposal is something that would actually have
to be learned as a separate thing because of its in-between nature
(i.e., now the argument list becomes a mix of things, some of which
execute in the defining context and some in the calling context).
--
Bre
r `some_name(a, b, c)` doesn't tell you anything about
"usage". That syntax is completely consistent with usage as a class and
as a function.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path,
tools out
there (flake8 being one of them) that purport to "improve" or "fix" your
code (or warn you to do it yourself), and various companies and
organizations that adopt policies tied to those tools (e.g., "your pull
request must pass this PEP 8 linter to be accepted&q
No, I don't.
I know I said this before, but I really hope this change is not
adopted. It is to me a classic example of adding significant complexity
to the language and reducing readability for only a very small benefit
in expressiveness.
--
Brendan Barnwell
"Do not fol
t is bad for the function to
store that late-bound default only in some private format for its
exclusive future use without providing any means for other code to
access it as a first-class value.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
re-execute it as a whole.
Actually this raises a question that maybe was answered in the earlier
thread but if so I forgot: if a function has a late-bound default, will
the code to evaluate it be stored as part of the function's code object?
--
Brendan Barnwell
"Do not follow wh
t-whatchamacallit and 'use' it (in some defined way) to get
the default value". This is what we already have for early-bound
defaults in the function's `__defaults__` attribute.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, a
y this is just "I want any kind of late-bound
default to really be an early-bound default whose value is some object
that provides a way to evaluate it later". (I'm trying to think of
different ways to say this because it seems what I'm saying is not clear
to you. :-)
--
Br
hings that happen when the function is
defined. It is too confusing to have the function signature mix
definition-time and call-time behavior.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
"the true behavior of the function". We should not worry ourselves
in the slightest about the fact that "the true behavior of the function"
may not be transparently represented in the signature. Sure, we should
choose good names for the parameters, but that's about all
* don't like the idea that some types of argument will be
inlined into the function body instead of being stored as first-class
values like other `__defaults__`, just because there happens to be this
one extra character next to the equals sign in the function signature.
That strikes me as
useful but I don't see any mention there of
languages that allow BOTH late-binding and early-binding, and
distinguishes them with some kind of syntactic flag in the signature.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
p
of whether they
could assign in this manner to names already used by other arguments, so
that one argument's default could potentially override the default of
another.)
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a tra
fault"
but is not a "default VALUE".
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
Python-ideas mailing list -- python-ideas@python.org
To unsu
On 2021-12-06 11:21, Chris Angelico wrote:
On Tue, Dec 7, 2021 at 6:16 AM Brendan Barnwell wrote:
On 2021-12-05 08:14, Chris Angelico wrote:
> Closures cannot be executed without a context. Consider:
>
> def f(x=lambda: (a:=[])):
> if isinstance(x, FunctionType): x = x()
&g
other words there are too many devils in the
details that I feel would lead to difficult-to-reason-about code and
traps for the unwary.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave
ovide benefits OUTSIDE of function signatures. Because your
proposal focuses only on function signatures, it can provide no benefit
outside of function signatures, and (in my view) there simply isn't
enough potential benefit available within function signatur
it in another post, there would not "be" a late-bound default at
all; there would just be some behavior in the function to do some stuff
when that argument isn't passed.)
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave
e you have
changed it to "late-bound" (aka "behavior inside the function"). I
realize this was probably just a thinko, but perhaps it also gently
illustrates my point that peril lies in allowing early and late-bound
defaults to mix within the same signature. It's not alway
On 2021-12-08 23:12, Chris Angelico wrote:
On Thu, Dec 9, 2021 at 5:52 PM Brendan Barnwell wrote:
To try stating this in yet another way, currently if I have:
def f(a=)
must be something that evaluates to a first-class
object, and the "argument default" IS that f
On 2021-12-08 23:22, Chris Angelico wrote:
On Thu, Dec 9, 2021 at 5:54 PM Brendan Barnwell wrote:
On 2021-12-08 20:36, Chris Angelico wrote:
> Remember, though: The comparison should be to a function that looks like this:
>
> def f(a=[], b=_SENTINEL1, c=_SENTINEL2, d=_SENTINEL3):
&g
alled Annotated "Tagged" or "Labeled" or some such thing
to make it clear that when you using it you are defining a new
special-purpose type for use in later annotations./
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, a
nd
deprecating the old name but keeping it for backward compatibility).
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
Python-ideas mailing list -- python-idea
an
entire string literal with the same color, whereas they don't typically
do that for other kinds of delimited chunks, instead highlighting only
the delimiters themselves.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a
from that perspective I'd much rather have a frozen-dict type
and then a syntax for it. :-)
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
P
half round.
>
>And THAT is why this is a bad idea.
It doesn't mean it's a bad idea in general, just that we would have to
be careful what kinds of brackets we allow.
We already are, we just allow (), [], and {}.
--
Brendan Barnwell
"Do not follow where the path may l
e way things worked in Python
2, where (-1)**(1/3) would raise an error, and you had to explicitly do
(-1 + 0j)**(1/3) if you wanted a complex root. I'm willing to bet that
the vast majority of users doing arithmetic with Python never want nor
can make any use of a complex value for any
fundamental flaws, and especially the rapid feature churn in
recent years, suggests to me that their model should be viewed with
skepticism.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--auth
opposed to the creation of things that look like
augmented assignment but don't follow the same pattern, which is what
this proposal does.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
that
reading the source code is not an acceptable substitute for making the
documentation a complete and self-sufficient vehicle for total
understanding of the function's behavior. It doesn't matter if the
function behaves as the author intended; it only matters if it behaves
as d
ighed by the cases where I want
everything to be converted into a string, because, dangit, I'm joining
them into a bigger string.
I agree that a list method would be nice, but we then have to think
about should we add similar methods to all iterable types, since
str.join can take any itera
On 2019-01-29 16:14, MRAB wrote:
On 2019-01-29 23:38, Greg Ewing wrote:
Brendan Barnwell wrote:
Personally what I find is perverse is that .join is a method of
strings but does NOT call str() on the items to be joined.
Neither do most other string methods:
>>> s = &q
On 2019-01-29 15:38, Greg Ewing wrote:
Brendan Barnwell wrote:
Personally what I find is perverse is that .join is a method of
strings but does NOT call str() on the items to be joined.
Neither do most other string methods:
>>> s = "hovercraft"
>>> s.coun
don't necessarily think this needs to be added to the
language. Things like pandas already provide this and so much more that
it's unclear whether the gain from adding vectorization on its own would
be worth it.
--
Brendan Barnwell
"Do not follow where the path may lead.
1 - 100 of 239 matches
Mail list logo
