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 there is no
path, and leave a trail."
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
___
e 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
___
Python-ideas mailing list -- python-
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 enum
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) gets you
rrent 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 (including of builtins), which isn't a road I'd want to
g
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
st 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 disgust and deafening silence but
that's life.
--
Brendan Barnwell
"Do
rovide 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 a trail."
? 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 is no
r 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 Barnwell
"Do not follow whe
-) 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 there is no
path, and leave a trail."
--author unkn
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 thread.
--
Brendan Barnwell
"Do not follow where the path may lead.
.
--
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...@python
" 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 there is no
path, and leave a trail."
--author unknown
ule 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 path may lead. Go, instead
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
"Do not follow where the path may
ng, 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."
--author unknown
_
nt" 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 mailing list -
ng 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 focusing on
what you perceive as the low utility of things that are already part of
Python.
--
Brendan
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
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
square and 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 lead. Go,
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
___
Python-ideas mailing list -- py
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 trail."
ating 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-ideas@python.o
abeled" 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, and leave a trail."
--author unknown
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
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 always trivial to
remember which arguments are whi
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 a trail."
--auth
enefit
outside of function signatures, and (in my view) there simply isn't
enough potential benefit available within function signatures to
outweigh the possibility of confusion that I outlined above. The
cost-benefit account of function signatures is overdrawn.
-
re 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 a trail."
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()
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 unsubscribe send an emai
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 trail."
--auth
ny 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
path, and leave a trail."
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 sort of thing that should be inc
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 I expect from
a function signature.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and le
ed. 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
_
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. :-)
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where
e' 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, and leave a trail."
--author unk
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 where the path may lead. Go, instead
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
pat
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 follow where the path may lead.
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"). It
me(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, and leave a tra
al 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).
--
Brendan Barnwell
"Do not follow where the path m
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.
--
Brendan Barnwell
"Do not follo
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 unsubscribe send an emai
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."
--author unknown
___
Python-ideas mailing list -- python-i
his 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 the context of calling a function.
--
Brendan Barnwell
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 agree that both "are argument defaults&q
nd I
don't see that it outweighs the costs here. The benefit of
autogenerating the string "len(a)" from the argument spec isn't quite
zero but it's pretty tiny.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--
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 each other, what symbol do we use, how do we implemen
he 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 could use it in other plac
essions 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 mailing list -- pyt
nd 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 not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--a
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@python.org
To unsubscribe send an email to
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 want
nt-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 -- pyt
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. Go, instead, where there is no
pat
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
___
Python-idea
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. Go, instead, where there is no
path, and leave a t
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 definition
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
"Do not follow where the path
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 follow where the path may lead
cal 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, instead, where t
er 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 where the path may lead. Go, instead, where th
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
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.
--
Brendan Barnwell
"Do not follow where the path ma
ded. 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 the end of the course.
Isn't that enough?
--
Brendan Barnwell
"Do not f
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 no
path, and
udents 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 learning Python.
--
Brendan Barnwell
&q
in 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 -- python-ideas@python.org
To unsubscribe send an emai
ple 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
___
Python-ideas
nd 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 no
path, and leave a trail."
--author unknown
___
Python-ideas
uot;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 anything that moves in that direction.
g 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 path may lead. Go, instead, where there is no
path, an
_ 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, and that's kind of creepy to me.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, inst
st 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 where the
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 constant but ca
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.
--
Brendan
ate 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.
--
Brendan Barnwell
"Do not follow whe
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. Go, instead, where there is no
path, an
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 where the path may lead. Go, instead, where there is no
p
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.
--
Brendan Barnwell
tting 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 Python code less readable in the relativ
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 no
path, and leave a tra
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 leave a
* 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.
--
Brendan Barnwell
"Do not f
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."
--author unknown
___
Python-idea
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 may
f 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.org
To unsubscribe send an emai
/ , 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 leave a trail."
t; 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
___
Python-idea
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 following:
&
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 where the path may lead. Go, ins
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.
--
Brendan Barnwell
"Do not f
1 - 100 of 226 matches
Mail list logo
