complete new stream system and get the
vast majority of the Python ecosystem to switch over to using it. Which is a
pretty huge ask. (And it still won’t let you just add __iadd__ to StringIO;
it’ll only let you add __iadd__ to that new OutputStringStream.)
_____
e presenting a
dynamic Spam* array terminated by a sentinel value), and iteration still works.___________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/
issingMapping differently from a Mapping? So I think it’s not an ABC because
it’s not a protocol.
Of course you could just make it a pure mixin that isn’t an ABC (and maybe
isn’t in collections.abc), which also solves all of the problems above (except
the optional one with the metaclass, but you
s extra parameters in -- and the
> dataclass' __init__ won't accept extra arguments.
Can’t you just create InitVar attributes for the extra args you want to pass
through in that case?
_______________
Python-ideas mailing list -- [email protected]
t of why
you wrote that script in Python in the first place. And if dataclasses get in
the way of that, it’s a problem, and probably worth fixing.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
effort—just make Y pass everything through, and the couple places you end up
needing to pass down one of those Pandas-y arguments you just do so, and it
works, and that’s fine.
___
Python-ideas mailing list -- [email protected]
To unsubscrib
the general
danger the pickle module already warns about?
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mai
it they could stay as competitors on PyPI forever, while if it turns out that
the extension hooks aren’t sufficient, someone could propose exactly what needs
to be changed to make the extension writable.
_______
Python-ideas mailing list -- python-ideas@pyth
e protocol
(like iteration, construction, and arithmetic), but the fallback from
__getnewargs__ or __getstate__ is just part of some builtin types’
implementations (like attribution and subscription).
_______
Python-ideas mailing list -- python-ideas@py
o decide, more stuff to
remember when you come back to the language after time spent doing other stuff,
more trouble reading code written by other people who internalized a different
subset of the kitchen sink, etc._______
Python-ideas mailing list -- pyt
either one of them…)
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives
way or not. And even if it does,
that hurdle of describing the syntax in a way that people won’t get confused
the way they do when they first learn the feature in C++ might be hard to
overcome. But it’s at least plausible that it could be readable and learnable
enough.
______
place where it gets complicated, but
there may be others I haven’t remembered. I can dig this up if you‘re
interested. Maybe it’s even worth cleaning up and posting to PyPI, or even
proposing for somewhere in the stdlib (collections or functools?).
_______
(And I like the
overall idea in this thread if someone can come up with good enough syntax.)
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org
Mapping…). Whether that counts as an argument for or against any version
of the various proposals in this thread, I’m not sure.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
refactor the {…} in a **{…} if the
call gets too unwieldy; it means calls and other places with ** unpacking
remain consistent; etc.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
http
plemented, taught, and used in the field for years, as part of the
existing call and **unpacking syntax and semantics that already work. The magic
* has few interactions with the rest of call, but changing dict displays has
zero interactions, which is even better than few.
> On Apr 17, 2020, at 01:58, Steven D'Aprano wrote:
>
> On Thu, Apr 16, 2020 at 09:21:05PM -0700, Andrew Barnert via Python-ideas
> wrote:
>
>> But I don’t see why that rules out the “bare colon” form that I and
>> someone else apparently both proposed
inly fluent) speakers
of a LTR-written language (as were the designers of Lisp, most of the C
committee, etc.). If Steve has a problem reading it, I think it’s probably just
him, but of course if I’m wrong I hope (and expect) others will chime in.
_______
P
ing in that case.
I’m not sure how much that parallel means (or even what it would imply if it
did mean a lot). I think I’m still -0.5, and the fact that you can get the same
effect if you’re willing to use CPython frame hacks doesn’t make me either more
or less negative.
___
ot other uses of **unpacking, or
having a mode switch in the middle of call syntax, or anything else proposed so
far.)
___________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.py
n, or should happen,
who cares? Assuming one of the proposals in this set of threads has sufficient
traction, it would be silly to say “Let’s not do this thing that people want
because it would make it harder to do a thing they don’t want”.
___
Python-i
ort of get
the hang of doing, which is not usually what you’re aiming for with a language
feature.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mai
nough,
that may be worth it, but I don’t think the benefits of this proposal reach
that bar.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pyt
exceptions or break any existing parallels at all, so it’s even less of a
cost. But there are plenty of other advantages and disadvantages of each of the
four (and the minor variations on them in this thread); that’s just one factor
of many to weigh.
_______
Py
cala, Haskell), or for bizarre reasons specific to that language (Go), so a
lot of people are likely to misunderstand your syntax as meaning that something
gets the new value of the list.
_______
Python-ideas mailing list -- [email protected]
To unsubsc
urages that reading), which is an extra special
case to learn. Which can still be acceptable (lots of people get away with
thinking of target lists as a special use of tuple displays…); it’s just a
really high bar to clear.
_______
Python-ideas mailing list --
o be added as a flag on the builtin.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.py
indirectly via dict constructor calls—`dict(**, country, year)`,
`dict(country=, year=)`, `dict(**{country, year})`, which isn’t quite as
beautiful, but is still better than repeating yourself if the list of members
or query conditions gets long.
____________
ould be a better design if you were doing Python from
scratch, but I think the established existence of zip_longest pushes us the
other way.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to python-ideas-le...@p
On Apr 20, 2020, at 13:03, Eric V. Smith wrote:
>
> On 4/20/2020 3:39 PM, Andrew Barnert via Python-ideas wrote:
>>
>>
>> As I said, wanting to check does come up sometimes—I know I have written
>> this myself at least once, and I’d be a little surprised if
matter if you zip(y, x, strict=True) instead?
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
ht
to _also_ overcome the cost of being a potential antipattern magnet. For me,
this proposal is right on the border of being worth it (and I’m not sure which
side it falls on), so that could be enough to change the answer, so… good thing
you brought it up.
But I don’t think it eliminates
new
strict=True/zip_strict/zip_equal) is probably not a great tragedy.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archive
y even with `strict=True`"
out loud; maybe that's a mild argument for using a different qualifier like
`equal`, as in more-itertools?)
___________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to python-ideas-le...@pyt
marginal benefit. That’s why I think the whole
proposal is marginal. It’s almost never going to be a huge win—but it may be a
small win in so many places that it adds up to being worth it.
_______
Python-ideas mailing list -- [email protected]
On Apr 20, 2020, at 16:24, M.-A. Lemburg wrote:
>
> On 20.04.2020 19:43, Andrew Barnert via Python-ideas wrote:
>>> On Apr 20, 2020, at 01:06, M.-A. Lemburg wrote:
>>>
>>> The current version already strikes me as way too complex.
>>> It's by f
> On Apr 20, 2020, at 17:22, Steven D'Aprano wrote:
>
> On Mon, Apr 20, 2020 at 03:28:09PM -0700, Andrew Barnert via Python-ideas
> wrote:
>
>> Admittedly, such cases are almost surely not that common, but I
>> actually have some line-numbering code that did so
On Apr 21, 2020, at 01:27, M.-A. Lemburg wrote:
>
> On 21.04.2020 04:25, Andrew Barnert via Python-ideas wrote:
>>> On Apr 20, 2020, at 16:24, M.-A. Lemburg wrote:
>>>
>>> On 20.04.2020 19:43, Andrew Barnert via Python-ideas wrote:
>>>>>
On Apr 21, 2020, at 01:36, Serhiy Storchaka wrote:
>
> 20.04.20 23:33, Andrew Barnert via Python-ideas пише:
>> Should this print 1 or 2 or raise StopIteration or be a don’t-care?
>> Should it matter if you zip(y, x, strict=True) instead?
>
> It should print 2 in bot
th
it.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/m
proselytize for the next one.
If you can convince lots of people that they should care about the choice more
often and get them using the explicit functions, it’ll be a lot harder to argue
that everyone is happy with today’s behavior.
_______
Python-ideas mai
hrough what state the iterables should be left in by this new
zip_strict function, and there is a reasonable answer. Even if your arguments
about this example were correct, they wouldn’t be relevant to the thread,
because the entire purpose of giving the example has been fulfilled.
___
> On Apr 21, 2020, at 16:02, Steven D'Aprano wrote:
>
> On Tue, Apr 21, 2020 at 12:25:06PM -0700, Andrew Barnert via Python-ideas
> wrote:
>>> On Apr 21, 2020, at 01:36, Serhiy Storchaka wrote:
>>> except ValueError: # assuming that’s the excepti
d by extend. And of course you’re adding extend_const. I don’t know if
that’s worth fixing separately, but if not it seems to me it’s probably worth
fixing in your patch.
___________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email
> On Apr 22, 2020, at 14:09, Steven D'Aprano wrote:
>
> On Wed, Apr 22, 2020 at 10:33:24AM -0700, Andrew Barnert via Python-ideas
> wrote:
>
>> If that is your long-term goal, I think you could do it in three steps.
>
> I think the first step is a PEP. This i
even
after you figure it out, it would hardly be any more obvious to other people
who need a noop function where to go digging for it than it was for you.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to python-ide
ved that problem, and now everyone
can stop talking past each other.
(Although the couple of people who suggested wanting to _handle_ the error as a
normal case rather than treating it as a logic error to debug like your
examples still need to give use cases if they want anything different th
until 3.0). If that didn’t actually come up for people even in Python
1.x, nobody would have asked for it in 2.0.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org
nullary function with
lru_cache is to use maxsize=None. If people are leaving the default 128, maybe
the docs need to be improved in some way?
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to python-ideas-le...@
So, that solves
both problems, but it means you have to implement four different builtin types.
(Also, while the C implementation of those types, and constructing them from
the zip type’s methods, seems trivial, I think the pure Python version would
have to be pretty clunky.)
On Apr 26, 2020, at 16:58, Steven D'Aprano wrote:
>
> On Sun, Apr 26, 2020 at 04:13:27PM -0700, Andrew Barnert via Python-ideas
> wrote:
>
>> But if we add methods on zip objects, and then we add a new skip()
>> method in 3.10, how does the backport work? It
ok the same when the distinction between
thinking about sequences and thinking about lazy iterables is irrelevant to the
problem.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
eed to do fancy stuff with iteration, you expect to be
able to transform iterators in ways like this without breaking everything. But
your new feature won’t allow that. It can only be used if you’re directly
iterating on the result of zip. Which seems to imply there probably aren’t any
good use c
sible? Maybe there are people who have tons of real-life examples where they
could use a Sized zip or a Reversible enumerate or a Sequence map, and they
just never thought they could have it so they never tried or asked?
___
Python-ideas mailing list --
sure they mean what
you think they mean. (Although maybe I should have used functions from
more-itertools rather than our own custom functions that do effectively the
same thing but are kind of weird and probably not so well tested and whose
names don’t come up in a web search.)
___
or the guts of the Civ V scripting engine. So the fact that you
can’t search the Dropbox or Firaxis source is not actually a big problem.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
do effectively
>> the same thing but are kind of weird and probably not so well tested and
>> whose names don’t come up in a web search.)
>
> and... well I'm assuming this one just yields the extras at the end of the
> file/iterator?
No, because in this case it’s not
they’re just choosing not to.
Giving them a harder and less discoverable way isn’t going to change that.
Anyone who’s decided it’s not worth using zip_equal instead of zip is not going
to think it’s worth adding an else and a test to the loop around that zip.
n Swift, and if we have to tell them they can’t do it in
Python without learning the deep magic of how variable lookup works, that would
be a major shame. But I can’t think of an answer that doesn’t run into all the
same problems that PEP 562’s competing protocols did.
____
ind of the opposite of fun. :)
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.pyth
t can somehow work for globals and class
attributes (which is probably not solveable), or some brand new language
semantics that aren’t built on what’s already there. The latter sounds like
probably way more work than this feature deserves, but maybe the experience of
Swift argues otherwise.
_
access the value is probably even less
acceptable when unnecessary.
So, I think it makes sense to leave it up to the user (but to explain the issue
in the docs). Or maybe we could add a threading.once (and asyncio.once?) as
well as functools.once?
___________
Pyt
ython-style APIs. And so on.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/pyth
olves half of those problems (as long
as “longest” is one of the options), but it makes others even worse. The
available strings aren’t even discoverable as part of the signature,
auto-complete won’t help at all, and the result is even longer and even more
deemphasizes the important thing.
__
work so well anymore.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/CTSBRBTMALAM
en’t gotten far
enough to get the lock, and there’s no way they can know they don’t need the
lock. And for the next few after that, because unless the system only runs one
thread at a time and synchronizes all of memory every time you switch threads
they may not see the write yet anyway.
___
e
first one, it’ll be just as easy to figure out that zip_equal is what they’re
looking for from the second.
Of course it might be better to rewrite the whole thing to be more
novice-friendly and to describe what zip iterates at a higher level instead of
describing how its __next__ method oper
On Apr 29, 2020, at 22:50, Stephen J. Turnbull
wrote:
> Andrew Barnert via Python-ideas writes:
>
>>> Also -1 on the flag.
>
> Also -1 on the flag, for the same set of reasons.
>
> I have to dissent somewhat from one of the complaints, though:
>
>> auto
, I have to import a module to do any of those things (for the last one,
I even have to install a third-party package first).
Namespaces are a honking great idea, but there is a cost to that idea, and that
cost includes people having to learn import pretty early on.
____
exactly
what should be changed and where.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://m
On May 1, 2020, at 10:27, gbs--- via Python-ideas
wrote:
>
> In cases where it makes sense to do explicit type checking (with ABCs or
> whatever), I really detest the look of the isinstance() function.
>
> if isinstance(thing, Fruit) and not isinstance(thing, Apple):
>
r the actual thing
suggested, but a different thing nobody wanted.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Mess
mplies that you were right
about the best way to get anything done.
___________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Messa
On May 1, 2020, at 16:32, Steven D'Aprano wrote:
>
> On Fri, May 01, 2020 at 12:28:02PM -0700, Andrew Barnert via Python-ideas
> wrote:
>>> On May 1, 2020, at 09:24, Christopher Barker wrote:
>>> Maybe it's too late for this, but I would love it
ust failing to imagine good examples.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://ma
no benefit whatsoever. Why is that acceptable for a
general purpose function?
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/
ount of stuff to learn in builtins just as much as another
function would. And so on. So it’s only worth doing for really special cases,
like open.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to python-ide
two different kinds of functions, because lambda doesn’t produce a
different kind of function).
So, I think this counts as a prior-art/cross-language argument for your
proposal.
___________
Python-ideas mailing list -- [email protected]
To unsubsc
struct—but when it isn’t, it’s usually so obvious
from context that you don’t even have to think about it. It’s confusing a lot
less often than, say, str, and it’s helpful a lot more often.
___________
Python-ideas mailing list -- [email protected]
To un
m consistent at this point, so
Serhiy is just proposing a way to make it a lot easier for C methods to act
like Python ones when you need them to.
And, given that he has some solid use cases, it’s hard to see any problem with
that.
___
Python-ideas m
ated
textbooks. Which is pretty odd.
[4] Or even later, after giving the same spatial boundaries, then the same
temporal boundaries, then the math/logic definition, but I’m lumping those all
together as one sense because they’re coextensive if spacetime Is topological.
:)
___
On May 8, 2020, at 20:36, Dan Sommers <[email protected]>
wrote:
>
> On Fri, 8 May 2020 17:40:31 -0700
> Andrew Barnert via Python-ideas wrote:
>
>> So, the OP is right that (1,2,3)==[1,2,3] would sometimes be handy,
>> the opponents ar
> On May 9, 2020, at 04:30, Alex Hall wrote:
>
>> On Fri, May 8, 2020 at 11:22 PM Andrew Barnert via Python-ideas
>> wrote:
>
>> Trying to make it a flag (which will always be passed a constant value) is a
>> clever way to try to get the
produces—but doing the same thing in raw C would not be a shortcut to
writing a generator class.)
___________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/l
ly
did turn out to be occasionally useful.)___________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/arc
y well be useful on its own.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org
ight place for it. I have a similar
“lexicompare” in my toolbox, but it has extra options that YAGNI. Anyway, even
if I’m remembering right, you probably don’t need to dig up the more-itertools
PR because it’s easy enough to redo from scratch.)
___
Python-id
==y for x,y in zip_longest(self.it, other,
fillvalue=object()))
def __lt__(self, other):
for x, y in zip_longest(self.it, other, fillvalue=_Smallest()):
if x < y: return True
elif x < y: return False
return False
__
I suppose) would actually be harder to Implement, on top of being less
powerful and potentially confusing. And the same is true for slices.
> In short -- not having thought about it deeply at all, but I'm thinking that
> making an SliceIterator very similar to dict_keys and friends would m
able, etc. Even browsers following file: URLs won’t
be able to use these names, and in fact it’ll be pretty confusing that (a) it’s
misleadingly close to URL escaping but not the same, and (b) you have to
%-escape the %-escaped filename to actually get a usable file URL out of it.
___
worth it, and that any form of this proposal would make it even rarer,
but I could be wrong.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman
27;, '6', '7', '8', '9']
You just picked an example where “resettable iterator” and “collection” would
do the same thing. Try the same test with list and it also passes, because list
is a collection. You can only distinguish the two cases by partially using a
acters in other error messages when they
come directly from the user’s input text. For example, if I try to 2+Spám(),
the error message will have á in the string.)
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to pyth
stuff can be
worked around pretty easily, but apparently not that one…)
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
M
stdlib; I suspect
they’re still improving it at a much faster pace than the stdlib could handle.
But maybe the docs should link to it. The only problem is that the obvious
places (like Interface Options section in the Usage docs) are things almost
nobody reads…
_______
t makes it clear. The docs can’t even agree with themselves on
whether it means a generator function or a generator iterator, not to mention
whether normal functions that return a generator iterator are generator
functions (and the recent change to @partial makes that even more fun) and
wheth
ople, adding it to the stdlib will just mean people
don’t search for and find the right one, all the while misleading themselves
into thinking they’re safe when they’re not, which will make the overall
problem worse, not better.
___
Python-ideas maili
because str is the one place we _couldn’t_ provide it even if we wanted to.
But maybe I’m wrong and people won’t have this assumption, or will be easily
cured of it.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an ema
On May 10, 2020, at 22:36, Stephen J. Turnbull
wrote:
>
> Andrew Barnert via Python-ideas writes:
>
>> A lot of people get this confused. I think the problem is that we
>> don’t have a word for “iterable that’s not an iterator”,
>
> I think part of the proble
1101 - 1200 of 1693 matches
Mail list logo
