blems with trying to search for packages
on pypi, namely the huge number of "mytestpackage1"-type packages.
Third, this is what conda-forge does and it seems to be working pretty
well there.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where ther
mvent conda's consistency
checking, for instance by installing a package with pip rather than with
conda.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_
ation). I'm not sure what
the best solution is, but just wanted to mention this issue.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
Pyth
On 2022-12-19 13:59, Chris Angelico wrote:
On Tue, 20 Dec 2022 at 07:13, Brendan Barnwell wrote:
> See my example regarding a StrEnum and tell me whether that would be
> more irritating.
I can't run that example myself as I don't have Python 3.11 set up.
The
Sorry, accidentally replied off-list. . .
On 2022-12-19 11:36, Chris Angelico wrote:
On Tue, 20 Dec 2022 at 06:29, Brendan Barnwell wrote:
On 2022-12-19 03:45, Chris Angelico wrote:
On Mon, 19 Dec 2022 at 22:37, Steven D'Aprano wrote:
But this much (say with a better validator) get
en so, this is still possible in current Python, because
we *can* monkeypatch things. But it's a bad idea and most libraries
don't do it; also, our ability to monkeypatch builtins is limited . It
seems what you're describing is a system for encouraging more
monkeypatching (includi
On 2022-06-25 13:41, Chris Angelico wrote:
On Sun, 26 Jun 2022 at 04:41, Brendan Barnwell wrote:
In contrast, what I would want out of deferred evaluation is precisely
the ability to evaluate the deferred expression in the *evaluating*
scope (not the definition scope) --- or in a
oposal right now. But I
wanted to mention these ideas here to at least handwave about what to me
the gain would be from deferred evaluation, as I'm coming at it from a
somewhat different angle than the proto-PEP. I have a suspicion that
the response will be a combination of disg
equirement to provide any alternative proposal whatsoever ---
whether vague or specific, real or potential, conceptual or concrete ---
merely to justify opposing this PEP.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave
ded anyway? What would/could the
surrounding code do differently with the deferred object based on
knowing that it is deferred, since any other operations you would do it
on would evaluate it anyway?
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there i
thon is actually better than what it would be if
the PEP were adopted. I believe it is better to wait until we think of
a better idea than to implement this PEP, and, if we never think of a
better idea, then never change the existing argument-default behavior of
Python.
--
Brendan Barnwel
nions there's no reason I
can't do so as well. :-) Also, to avoid people coming back later and
saying that some kind of consensus emerged in the second round because
no one objected, etc.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where t
rything. I don't see any benefit to
leaving it ambiguous.
This is all academic to me, however, since even if you did that I still
wouldn't support the PEP for various more basic reasons that I've
mentioned in the earlier iteration of this
hange.
--
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 unsubscribe send an email to python-ideas-le...@p
sound harsh, but if `class A(B,
C)` doesn't "feel" different to you from `class(C, B)` then I think you
need to adjust your feelings rather than expect Python to adjust its
behavior.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where ther
all a third-party module if you want
to teach some mathematical background about how some operations work,
because we only put into the stdlib what was necessary to actually do
those operations, not teach and demo their underpinnings".
--
Brendan Barnwell
"Do not follow where the pa
t different from what
you might expect from "vanilla" Python. This is the "Python isn't for
DSLs" argument that I've seen mentioned on this list and elsewhere
(although I agree that it's a pretty loose use of "DSL").
--
Brendan Barnwell
ing. But if super doesn't call
the right thing, you can just not use super and instead explicitly call
the method you want, so I don't get what this proposal gains.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail.&
"requirement" for static typing. I would most heartily prefer to avoid
that.
--
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
ly
"assign" to a tuple element, which is not zero but also not exactly a
burning need. I don't think you're going to get much traction on this
suggestion unless you at least engage with this idea of cost and
benefits of *your proposed feature* itself, rather than just focusi
On 2022-03-07 21:32, Stephen J. Turnbull wrote:
Brendan Barnwell writes:
> I would be happier if fewer typing-related changes made it in.
I'm curious: do you use type annotations yourself? If yes, do you
just prefer minimal hints to a precise typing system, or have there
been chan
On 2022-03-07 15:32, Chris Angelico wrote:
On Tue, 8 Mar 2022 at 10:20, Brendan Barnwell wrote:
On 2022-03-06 14:43, Chris Angelico wrote:
> This keeps happening. All the successful ideas seem to happen
> elsewhere, notably on typing-sig.
You seem to see that as a positive thin
On 2022-03-06 14:43, Chris Angelico wrote:
This keeps happening. All the successful ideas seem to happen
elsewhere, notably on typing-sig.
You seem to see that as a positive thing, but I would be happier if
fewer typing-related changes made it in.
--
Brendan Barnwell
"Do not follow
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
"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
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
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
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
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 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
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
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
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,
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
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.
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
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."
;.
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
;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
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
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
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
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.
--
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
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
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
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
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
_
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
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
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
'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,
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
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
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.
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.
--
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.
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
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.
-
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
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
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
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
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
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
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
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
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
___
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
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
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.
1 - 100 of 239 matches
Mail list logo