.
--
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...@
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."
hon, 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."
--a
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 trail."
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
___
so 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 there is no
path, and l
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 defin
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-ideas mailing list -- p
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
finitional 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 there is no
path, and leave a trail."
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, but we aren
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
___
Python-ideas mailing
. 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."
--auth
sistent 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."
--author unknown
___
;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 -- python-ideas@pyth
y "Yes, I'll join you and work on
a totally new restricted version of Python from scratch just to see what
happens"?
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
__
reezing" them into functions. For me the issue is only about
how function scopes capture variables from enclosing scopes; we don't
need new scopes, we just need new ways to control that capturing behavior.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there
hints, but those are just hints and what happens still
happens. Type hints don't say anything about what happens, only what is
"supposed" to happen.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--auth
On 2020-11-24 16:47, Chris Angelico wrote:
On Wed, Nov 25, 2020 at 10:29 AM Brendan Barnwell wrote:
On 2020-11-24 00:05, Chris Angelico wrote:
>> >
>> >I'm still confused what the point is of a zipapp, if it can't be a proper
point and click GUI thing, and it can'
what can't be done without C
extensions, because most GUI toolkits require C extensions.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
Py
damaging enough, you
also lose the whole scipy stack.
--
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@
On 2020-11-20 20:53, Chris Angelico wrote:
On Sat, Nov 21, 2020 at 3:35 PM Brendan Barnwell wrote:
> So let me ask this: In what circumstances do you think producing
native
>executables IS a bad thing, and in what circumstances do you think it
>ISN'T a bad thing, and why do
bout a Python "app
store". I think that would be even better than a
native-executable-creation library, if we can get it.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
__
xecutables IS a bad thing, and in what circumstances do you think it
ISN'T a bad thing, and why do you think including such functionality in
the stdlib would encourage the former more than the latter?
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where th
or a .pyz archive*won't* have
these problems. Is that of no value?
So are you suggesting that every single app should always be
distributed as source code, run by a separate interpreter that users
install separately?
--
Brendan Barnwell
"Do not follow where the path may lead. Go,
ency-bundling and
native-installing shouldn't be in the stdlib. It would be great if they
were included in some form or fashion.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
__
are valid and are used for instance by pandas, where you
can do things like `mydataframe.loc['some_row':'other_row',
'some_column':'other_column']` .
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
because "that's not
how Python does it". (This is tangential to the idea under discussion
here, though.)
--
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-09-17 12:16, Alex Hall wrote:
On Thu, Sep 17, 2020 at 8:57 PM Brendan Barnwell mailto:brenb...@brenbarn.net>> wrote:
On 2020-09-16 21:52, Dennis Sweeney wrote:
> TL;DR: I propose the following behavior:
>
> >>> s = "She turned me in
de). So it would be like:
>>> pattern = "That {animal} is really {attribute}."
>>> d = pattern.parse("That snake is really powerful.")
>>> d['animal']
'snake'
>>> d['attribute']
'powerful'
This wouldn't let you assign the results into local
hat looks sort of like JSON but technically isn't because it's not
UTF-8, it's on the user to first convert the file to UTF-8 before
bringing JSON into the picture.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
ticular use of `+` seems odd
conceptually on its own, it can still be excellent if it fits in with
the overall scheme of how operators work on that type.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
except is a statement.
This PEP proposes a clean and simple way to handle this common
situation. Just as the if-else ternary operator provides a handy way to
encode "X unless condition A, in which case Y", the except operator
provides a handy way to encode "X unless EXCEPTIONAL con
ConvenientProgrammingLanguage. Alternatively, we
could make a concerted effort to recruit some actual pythons onto the
steering committee so that they have the opportunity to influence the
development of this language in a manner consistent with the needs of
their community.
--
Brendan Barnwell
&qu
. Why does it
matter that it looks like a tilde?
--
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@
wouldn't look
exactly like it does in R, but it could function pretty similarly.
--
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 m
nd of model specification with Python
expressions, so I don't think I'm in favor of this proposal as it is.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
ighlighted, syntax errors aren't caught until you eval
it, etc. You can't use eval for the case I described because there
isn't any Python object like the unevaluated expression that I called
`expr`.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where th
worst perhaps having to parenthesize the dependent-variable
expression (in case our alternative "depends" operator had the wrong
precedence). But without deferred evaluation, the tilde operator gains
little, at least in terms of providing model-evaluation expressions like
those i
Just over six years ago I wrote an answer about this on StackOverflow
(https://stackoverflow.com/questions/14132789/relative-imports-for-the-billionth-time/14132912#14132912)
that continues to get upvotes and comments of the form "wow why isn't
this explained in the documentation" a
rable" or "the
data must be numbers". The only case of practical relevance is the
specific case of the single value NaN, so just put a specific note in
the docs to specifically warn people about that specific value.
--
Brendan Barnwell
"Do not follow where the path may lead. Go
it
def foo():
# custom delay
@wait(2)
def foo():
. . . you do this:
# default delay
@wait()
def foo():
# custom delay
@wait(2)
def foo():
-- Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail.&qu
y esoteric. The best policy is
for every file-opening operation to occur as part of a context manager,
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
On 2019-11-03 01:21, Steven D'Aprano wrote:
On Sun, Nov 03, 2019 at 12:23:02AM -0700, Brendan Barnwell wrote:
For the record, I have always thought that str.join should call str
on all its arguments. The fact that it doesn't is really annoying.
Given:
values = ["
hangeable if we want to change it, and I don't see what's so strange
about updating it to handle new developments like Path objects.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and l
name from a trusted
package. As I said, though, it's unlikely, and just a *potential*
issue.
There's nothing new about that either, though. Any imported module can
already monkeypatch a stdlib module to add such typo-names and map them
to malicious functions.
--
Brendan Barnwell
"Do not f
uire_compatibility_with", which
is more compatible (har har) with the idea that multiple calls coalesce
into their minimum. Likewise set_python_min_compat_version might be
better as "prohibit_compatibility_with" or something.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, ins
ects. Getting items is a basic
potential interface capability of objects and that alone is enough is
enough justification for adding an ABC for it.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a tra
reiterate here: what is your "idea"?
You just keep posting about the features of PysoniQ without explaining
why you've even brought it up on this list. What action are you
intending anyone here to take? Are you planning for PysoniQ to be
incorporated into core Python?
--
Brendan
e
possible to write a pure-Python wrapper around the existing C itertools
(renaming that existing C module to _itertools or whatever), and add the
recipes as pure Python in the wrapper but without a C implementation?
Or would that not be accepted?
--
Brendan Barnwell
"Do not follow whe
into itertools?
--
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 py
On 2019-08-02 06:37, Rhodri James wrote:
On 02/08/2019 06:26, Brendan Barnwell wrote:
It is massively more discoverable, for one simple reason:
autocomplete.
In teaching people to program, I often use Jupyter notebook, which
has great autocomplete functionality that can also bring up
t of people in text
form without actually being usable (or discoverable via autocomplete).
The way the "recipes" are presented in the existing docs clearly
indicates that they are widely useful as-is, and they already have to be
maintained as text, so why not just put them in for r
when they
shouldn't. I don't think there's any need to change the language to
make star imports easier or more convenient; if anything we should be
trying to move away from their use.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and
t it seems the real problem here is the lack of a real way
to determine if an available version is a real release or a
prerelease/beta. Is it not possible to change that, so that it is
possible for the launcher to quickly and easily determine the highest
release version available?
--
Brendan Ba
easoning about code
where any assignment to a local variable can call arbitrary code under
the hood.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
;not" in lambda expressions
What you describe is already possible, you just have to use the "is
not" operator, just as you would in any other expression.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and l
of tabs). So I just basically ignore PEP
8 and follow my own style, which happens to overlap in some respects
with PEP 8 and diverge from it in others.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and l
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. Go, instead, where there is no
path, an
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
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
ger 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 iterable (not just a list).
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
pa
table 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 documented.
--
Brendan Barnwell
"Do not follow where t
ings 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
__
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
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 operation, ever; it is more
likely
--- that is, None is not special enough to warrant the
creation of multiple new operators solely to compare things against this
specific value.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_
s actually
common enough for me to care about --- but it's still not common enough
to warrant the creation of a new operator, let alone multiple new operators.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
to cause bugs later on. Eventually it has to actually matter
whether something is None or not, and these operators just kick that can
down the road. In terms of their abstract meaning, they are not
remotely close to as common or useful as operators like & and |.
--
Brenda
That's what the OP is trying to do. You were just asked if there were
any disadvantages or costs. Are there or not? If so, what are they?
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
__
functions therein is fine. If anything, I think
the name "re" is too short and cryptic and should be made longer!
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a tra
etimes the sub-object may want to hold state if it is
going to be passed around and used later, rather than just having a
method called and being thrown away immediately.) But I think it's
clear that in both cases the namespacing is also nice.
--
Brendan Barnwell
"Do not follow where the path m
d
group related functionality without having to worry about using up all
the short or "good" names at the top level. I'm not sure I agree with
the specific proposal here for allowing regex operations on strings, but
if we do do it, this would be a good way to do it.
--
Brendan Barnwel
trying to cobble together an understanding of what the actual behavior is.
--
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 li
seen
advocating for this kind of leaking seems to me like it is much more
logically consistent with allowing all comprehension variables to leak
than it is with the current behavior, in which they don't leak.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where t
in the past, though.) But I don't really see how your
solution of magically making kwargs appear and disappear is a good
solution to that problem.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a tr
s: what are the languages that people specifically
believe are superior to other languages *in design*? (Even better would
be what are the languages that actually ARE superior, in some reasonably
nonsubjective, definable, way, but we have even less data on that.)
--
Brendan Barnwell
"Do
.
--
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
https://mail.python.org/mailman/listinfo/python-
nitely
pushes me even more towards disliking the assignment-expression
proposals and preferring a more specific change to the syntax of
particular constructs (if, while, maybe comprehensions) --- or no change
at all.
--
Brendan Barnwell
"Do not follow where the path may lead. Go,
, that's not sufficient. Part of what
I'm saying is that on LATER readings it's faster to see the overall
expression first, because you don't have to plow through the definitions
of the givens.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where ther
explode
due to the attractiveness of the reserved words. That is, many
libraries would start defining things named "and", "or", "with", "is",
"in", etc., because the names are so nice and short and are useful in so
many situations. So there'd be
dia.org/wiki/Compound_interest#Mathematics_of_interest_rate_on_loans).
If we have to use the word "given" even though the word mathematicians
would use in that position is "where", that's not such a big deal.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where ther
On 2018-05-11 11:08, Brendan Barnwell wrote:
. . . and it's true the latter is a bit more verbose in that case for
little extra benefit. But when the locally-defined value is used within
a more complicated expression (like the quadratic formula example), I
think readability goes down
ent components. If we just have "Eddie McEquals, president
of the International Association of Assignment Expression advocates,
delivered a speech yesterday at the organization's convention", the
inline appositive is not so disruptive. But the more complex the inline
definitions become
al sense IN ADDITION
TO having practical utility, and fit together into a unified whole.
Personally my feeling on this whole thread is that these changes, if
implemented are likely to decrease the average readability of Python
code, and I don't see the benefits as being worth the added complexity.
and returns the missing value, so be it. That's not a big deal.
--
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@
ence for claims
about whether things "really are" distracting, readable, unreadable,
intuitive, etc.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
putting the
expression first has some advantages, but they just don't seem as
important to me as they apparently do to you.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_
= (-b + sqrt(D)))/2, (-b - sqrt(D))/2
If the new feature encourages people to do something like your example
(or my earlier examples with the D definition inline in the expression
for x1), then I'd consider that another mark against it.
--
Brendan Barnwell
"Do not follow where the path may
st don't see how this proposal provides any way to
make things like the quadratic formula example above MORE readable.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
nk of code is being documented.
If the documentation for accumulate doesn't give the information that
people using it need to know, that's a documentation bug for sure, but
it doesn't mean we should stop using functions.
--
Brendan Barnwell
"Do not follow where the path may lead. Go,
that many of the combinations you list differ
only in case, which to my mind adds no extra cognitive load whatsoever.)
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
ugins available on the default import path.
For what it's worth, I have been bitten by the problem a few times,
although it's not very common. I think it's worth considering the
proposal, but not sure if any change is justified given that the issue
is fairly obscure.
--
Brendan Barnwell
&qu
omething, None):".
But you could have "while (do_something() as x) is not _sentinel". Not
sure how proponents and opponents would react to that. Limiting the
SLNB to the beginning of block-level statements seems perverse in a way,
but also might cut down on gratuitous overuse mixed
occur makes the overall construct LESS readable for me, not more, so I'm
-1 on the current proposal.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_
quot;as"
syntax, I think the ONLY way to assign to an SLNB should be with the
"as" syntax. You shouldn't be able to assign to an SLNB with regular
assignment syntax, even if you created an SNLB with the same name as the
LHS within the RHS.
--
Brendan Barnwell
"Do not follow
better to make Python faster instead! :-) But I think it's an
important corollary to the above. Python's excellence in developer-time
"speed" is a sort of latent force multiplier that makes execution-time
improvements all the more powerful.
--
Brendan Barnwell
"Do not follow whe
to a stable base (some
kind of collection) that can be re-iterated; sometimes it isn't. But
that doesn't change the iteration protocol. The interpreter is not free
to do what it likes behind the scenes; an implementation that did not
call __iter__ in the above case would be errroneous. __iter
e something that isn't affected
(i.e., a re-iterable). It does seem that in some cases you may want the
iterator to be exhausted, and in others not, but I don't think it's a
good idea to try to "hide" the unpacking by limiting the number of
iterations. The important difference is between any
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-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailma
101 - 200 of 226 matches
Mail list logo
