On May 15, 2020, at 21:35, Steven D'Aprano wrote:
>
> On Fri, May 15, 2020 at 05:44:59PM -0700, Andrew Barnert wrote:
>
>> Once you go with a separate view-creating function (or type), do we even
>> need the dunder?
>
> Possibly not. But the beauty of a protocol is that it can work even if
On May 15, 2020, at 21:25, Steven D'Aprano wrote:
>
> On Fri, May 15, 2020 at 01:00:09PM -0700, Christopher Barker wrote:
>
>> I know you winked there, but frankly, there isn't a clear most Pythonic API
>> here. Surely you do'nt think PYhton should have no methods?
>
> That's not what I said.
On May 15, 2020, at 18:21, Christopher Barker wrote:
>
> Hmm, more thought needed.
Speaking of “more thought needed”, I took a first pass over cleaning up my
quick slice view class and adding the slicer class, and found some
bikesheddable options. I think in most cases the best answer is
On May 15, 2020, at 18:21, Christopher Barker wrote:
>
>> On Fri, May 15, 2020 at 5:45 PM Andrew Barnert wrote:
>
>> On May 15, 2020, at 13:03, Christopher Barker wrote:
>> >
>> > Taking all that into account, if we want to add "something" to Sequence
>> > behavior (in this case a
On May 14, 2020, at 20:01, Stephen J. Turnbull
wrote:
>
> Executive summary:
>
> AFAICT, my guess at what's going on in the C tokenizer was exactly
> right. It greedily consumes as many non-operator, non-whitespace
> characters as possible, then validates.
Well, it like like it’s not
On May 15, 2020, at 13:03, Christopher Barker wrote:
>
> Taking all that into account, if we want to add "something" to Sequence
> behavior (in this case a sequence_view object), then adding a dunder is
> really the only option -- you'd need a really compelling reason to add a
> Sequence
On May 15, 2020, at 03:50, Steven D'Aprano wrote:
>
> On Thu, May 14, 2020 at 09:47:36AM -0700, Andrew Barnert wrote:
>>> On May 14, 2020, at 03:01, Steven D'Aprano wrote:
>>>
>> Which is exactly why Christopher said from the start of this thread,
>> and everyone else has agreed at every
On May 14, 2020, at 20:17, Stephen J. Turnbull
wrote:
>
> Andrew Barnert writes:
>
>> Students often want to know why this doesn’t work:
>> with open("file") as f:
>> for line in file:
>> do_stuff(line)
>> for line in file:
>> do_other_stuff(line)
>
> Sure.
On May 14, 2020, at 11:53, Ricky Teachey wrote:
>
>> So that means a view() function (with maybe a different name) -- however,
>> that brings up the issue of where to put it. I'm not sure that it warrants
>> being in builtins, but where does it belong? Maybe the collections module?
>> And I
On May 14, 2020, at 10:45, Rhodri James wrote:
>
> On 14/05/2020 17:47, Andrew Barnert via Python-ideas wrote:
>> Which is exactly why Christopher said from the start of this thread,
>> and everyone else has agreed at every step of the way, that we can’t
>> cha
On May 14, 2020, at 03:35, Steven D'Aprano wrote:
>
> On Sun, May 10, 2020 at 09:36:14PM -0700, Andrew Barnert via Python-ideas
> wrote:
>
>
>>> for i in itertools.seq_view(a_list)[::2]:
>>>...
>>>
>>> I still think I pr
On May 14, 2020, at 03:01, Steven D'Aprano wrote:
>
> On Mon, May 11, 2020 at 10:41:06AM -0700, Andrew Barnert via Python-ideas
> wrote:
>
>> I think in general people will expect that a slice view on a sequence
>> acts like “some kind of sequence”, not like the same
On May 13, 2020, at 20:49, Christopher Barker wrote:
>
> OK, now for:
>
>> On Wed, May 13, 2020 at 7:50 PM Andrew Barnert wrote:
>
>> But that’s the wrong generalization. Because sets also work the same way,
>> and they aren’t Sequences. Nor are dict views, or many of the other kinds of
>>
> On May 13, 2020, at 20:32, Christopher Barker wrote:
>
>>> On Wed, May 13, 2020 at 7:50 PM Andrew Barnert wrote:
>> On May 13, 2020, at 12:40, Christopher Barker wrote:
>>
Back to the Sequence View idea, I need to write this up properly, but I'm
thinking something like:
>>>
>>>
On May 13, 2020, at 12:40, Christopher Barker wrote:
I hope you don’t mind, but I’m going to take your reply out of order to get the
most important stuff first, in case anyone else is still reading. :)
>> Back to the Sequence View idea, I need to write this up properly, but I'm
>> thinking
On May 13, 2020, at 05:31, Richard Damon wrote:
>
> On 5/13/20 2:22 AM, Stephen J. Turnbull wrote:
>> MRAB writes:
>>>
>>> This isn't a parsing problem as such. I am not an expert on the
>>> parser, but what's going is something like this: the parser
>>> (tokenizer) sees the character "=" and
On May 12, 2020, at 23:29, Stephen J. Turnbull
wrote:
>
> Andrew Barnert writes:
>>> On May 10, 2020, at 22:36, Stephen J. Turnbull
>>> wrote:
>>>
>>> Andrew Barnert via Python-ideas writes:
>>>
>>>> A lot of people get this
On May 12, 2020, at 01:32, Barry Scott wrote:
>
>
>> On 11 May 2020, at 23:24, Andrew Barnert wrote:
>>
>>> On May 11, 2020, at 13:31, Barry Scott wrote:
>>>
>>> macOS and Unix version (I only use Unicode input so avoid the random bytes
>>> problems):
>>
>> But that doesn’t avoid the
On May 11, 2020, at 13:31, Barry Scott wrote:
>
> macOS and Unix version (I only use Unicode input so avoid the random bytes
> problems):
But that doesn’t avoid the problem. If someone gives you a character whose
encoding on the target filesystem includes a null or pathsep byte, your
> On May 11, 2020, at 14:18, Steve Jorgensen wrote:
>
> Andrew Barnert wrote:
>>> On May 11, 2020, at 00:40, Steve Jorgensen ste...@stevej.name wrote:
>>> Proposal:
>>> Add a new function (possibly os.path.sanitizepart) to sanitize a value for
>>> use as a single component of a path. In the
On May 11, 2020, at 12:54, Wes Turner wrote:
>
>
> What does sanitizepart do with newlines \n \r \r\n in filenames? Are these
> control characters?
>>> unicodedata.category('\n')
Cc
___
Python-ideas mailing list -- python-ideas@python.org
On May 11, 2020, at 12:59, Barry Scott wrote:
>
>
>> On 11 May 2020, at 18:09, Andrew Barnert via Python-ideas
>> wrote:
>>
>> More generally, what’s the use case for %-encoding filenames like this? Are
>> people expecting it to interact transpar
On May 11, 2020, at 10:57, Alex Hall wrote:
>
>
>> On Mon, May 11, 2020 at 12:50 AM Christopher Barker
>> wrote:
>
>
>> Though it is heading in a different direction that where Andrew was
>> proposing, that this would be about making and using views on sequences,
>> which really
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
On May 10, 2020, at 21:51, Christopher Barker wrote:
>
>
> On Sun, May 10, 2020 at 9:36 PM Andrew Barnert wrote:
>
>> However, there is one potential problem with the property I hadn’t thought
>> of until just now: I think people will understand that mylist.view[2:] is
>> not mutable, but
On May 11, 2020, at 00:40, Steve Jorgensen wrote:
>
> Proposal:
>
> Add a new function (possibly `os.path.sanitizepart`) to sanitize a value for
> use as a single component of a path. In the default case, the value must also
> not be a reference to the current or parent directory ("." or
On May 10, 2020, at 15:39, Christopher Barker wrote:
>
>
>> On Sun, May 10, 2020 at 12:48 PM Andrew Barnert wrote:
>
>> Is there any way you can fix the reply quoting on your mail client, or
>> manually work around it?
>
> I'm trying -- sorry I've missed a few. It seems more and more
On May 10, 2020, at 14:33, Christopher Barker wrote:
>
> Having a "tabnanny-like" function / module in the stdlib would be nice,
> though I'd think a stand alone module in PyPi would be almost as good, and a
> good way to see if it gains traction.
Good point.
Plus, it might well turn out
On May 10, 2020, at 00:11, Steve Barnes wrote:
>
> What can be done?
I think there’s another option (in addition to improving SyntaxError, not
instead of it):
Add a defancier module to the stdlib. It has functions that take some text and
turn smart quotes into plain ASCII quotes, dashes and
On May 10, 2020, at 03:47, Ned Batchelder wrote:
>
> On 5/10/20 3:09 AM, Steve Barnes wrote:
>> Change the error message “SyntaxError: invalid character in identifier” to
>> include which character and it’s Unicode value so that it becomes
>> “SyntaxError: invalid character 0x201c “ in
On May 10, 2020, at 11:09, Christopher Barker wrote:
Is there any way you can fix the reply quoting on your mail client, or manually
work around it? I keep reading paragraphs and saying “why is he saying the same
thing I said” only to realize that you’re not, that’s just a quote from me that
On May 10, 2020, at 02:42, Alex Hall wrote:
>
> - Handling negative indices for sequences (is there any reason we don't have
> that now?)
Presumably partly just to keep it minimal and simple. Itertools is all about
transforming iterables into other iterables in as generic a way as possible.
On May 9, 2020, at 17:35, Steve Jorgensen wrote:
>
> I believe the Python standard library should include a means of sanitizing a
> filesystem entry, and this should not be something requiring a 3rd party
> package.
>
> One of reasons I think this should be in the standard lib is because
On May 9, 2020, at 19:43, Christopher Barker wrote:
>
> On Sat, May 9, 2020 at 1:03 PM Andrew Barnert wrote:
> > https://github.com/PythonCHB/islice-pep/blob/master/pep-xxx-islice.rst
>
> I haven’t read the whole thing yet, but one thing immediately jumped out at
> me:
>
> > and methods on
On May 9, 2020, at 13:24, Dominik Vilsmeier wrote:
>
>
>> On 09.05.20 22:16, Andrew Barnert wrote:
>>>
>> There’s an obvious use for the .all, but do you ever have a use for the
>> elementwise itself? When do you need to iterate all the individual
>> comparisons? (In numpy, an array of
On May 9, 2020, at 02:58, Dominik Vilsmeier wrote:
>
>
> Initially I assumed that the reason for this new functionality was
> concerned with cases where the types of two objects are not precisely
> known and hence instead of converting them to a common type such as
> list, a direct elementwise
On May 9, 2020, at 12:38, Christopher Barker wrote:
>
> https://github.com/PythonCHB/islice-pep/blob/master/pep-xxx-islice.rst
I haven’t read the whole thing yet, but one thing immediately jumped out at me:
> and methods on containers, such as dict.keys return iterators in Python 3,
No they
On May 9, 2020, at 02:12, Ram Rachum wrote:
>
>
> Here's an idea I've had. How about instead of this:
>
> itertools.islice(iterable, 7, 20)
>
> We'll just have:
>
> itertools.islice(iterable)[7:20]
I’ve actually built this.[1] From my experience, it feels clever at first, but
it can get
On May 9, 2020, at 03:46, Chris Angelico wrote:
>
> But ultimately, a generator function is very similar to a class with a
> __next__ method. When you call it, you get back a state object that
> you can ping for the next value. That's really all that matters.
Well, it’s very similar to a class
> 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 g
On May 8, 2020, at 20:36, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com>
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
On May 4, 2020, at 10:44, Steve Barnes wrote:
> And "equal" doesn't say what it's equal.
>
> What we need is a word that means "same length", much as "shorter" and
> "longer" are about length.
>
> There's "coextensive", but that'll probably get a -1.
If “equal” is bad, “coextensive” is much
On May 8, 2020, at 15:44, Steven D'Aprano wrote:
>
> On Fri, May 08, 2020 at 10:46:45PM +0300, Serhiy Storchaka wrote:
>
>> I propose to add the METH_GENERAL flag, which is applicable to methods
>> as METH_CLASS and METH_STATIC (and is mutually incompatible with them).
>> If it is set, the
On May 6, 2020, at 05:22, Richard Damon wrote:
>
> In my mind, tuples and lists seem very different concepts, that just
> happen to work similarly at a low level (and because of that, are
> sometimes 'misused' as each other because it happens to 'work').
I think this thread has gotten off
On May 4, 2020, at 17:26, Steven D'Aprano wrote:
>
> Proposal:
>
> We should have a mechanism that collects the current function or
> method's parameters into a dict, similar to the way locals() returns all
> local variables.
>
> This mechanism could be a new function,or it could even be a
On May 5, 2020, at 12:50, Christopher Barker wrote:
>
> Another key point is that if you want zip_longest() functionality, you simply
> can not get it with the builtin zip() -- you are forced to look elsewhere.
> Whereas most code that might want "strict" behavior will still work, albeit
>
On May 1, 2020, at 09:51, Tom Forbes wrote:
>
>> You’ve written an exactly equIvalent to the double-checked locking for
>> singletons examples that broke Java 1.4 and C++03 and led to us having once
>> functions in the first place.
>> … but what about on Jython, or PyPy-STM, or a future
On May 1, 2020, at 15:35, Steven D'Aprano wrote:
>
> but if it is all functions, then I think you have no choice but to
> either live with it or shift languages, because the syntax for functions
> is too deeply baked into Python to change now.
Actually, I’m pretty sure Python could add infix
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 if ".
> On May 1, 2020, at 14:34, Christopher Barker wrote:
>
> But it seems clear that "doing a big revamp if all the Exceptions and adding
> alot more subclasses" is not supported. Which doesn't means that a few more
> expansions wouldn't be excepted.
>
> So folks that like this idea may be best
On May 1, 2020, at 11:19, Brandt Bucher wrote:
>
> I have pushed a first draft of PEP 618:
>
> https://www.python.org/dev/peps/pep-0618
The document says “… with nobody challenging the use of the word ‘strict’”, but
people did challenge it, and even more people just called it “equal” instead
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):
>
> Yucky.
I think
On May 1, 2020, at 09:24, Christopher Barker wrote:
>
> Maybe it's too late for this, but I would love it if ".errno or similar" were
> more standardized. As it is, every exception may have it's own way to find
> out more about exactly what caused it, and often you are left with parsing
> the
On May 1, 2020, at 08:08, Christopher Barker wrote:
>
> Also please keep in mind that the members of this list, and the python-dev
> list, are not representative of most Python users. Certainly not beginners
> but also many (most?) fairly active, but more "casual" users.
>
> Folks on this
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
On Apr 30, 2020, at 07:58, Christopher Barker wrote:
>
>> I think that the issue of searchability and signature are pretty
>> compelling reasons for such a simple feature to be part of the
>> function name.
>
> I would absolutely agree with that if all three function were in the same
>
On Apr 29, 2020, at 11:15, Tom Forbes wrote:
>
>> Thread 2 wakes up with the lock, calls the function, fills the cache, and
>> releases the lock.
>
> What exactly would the issue be with this:
>
> ```
> import functools
> from threading import Lock
>
> def once(func):
>sentinel =
On Apr 29, 2020, at 12:03, Christopher Barker wrote:
>
>
> Isn't much demand for a *generic* linked list. It would probably be a good
> recipe though -- so users could have a starting point for their custom
> version.
I think what would be really handy would be a HOWTO on linked lists that
On Apr 29, 2020, at 07:08, Barry Scott wrote:
>
>
>> On 28 Apr 2020, at 16:12, Rhodri James wrote:
>>
>>> On 28/04/2020 15:46, Brandt Bucher wrote:
>>> Thanks for weighing in, everybody.
>>> Over the course of the last week, it has become surprisingly clear that
>>> this change is
On Apr 29, 2020, at 08:33, Christopher Barker wrote:
>
> I've wondered about Linked Lists for a while, but while there are many
> versions on PyPi, I can't find one that seems to be mature and maintained.
> Which seems to indicate that there isn't much demand for them.
I think there’s lots of
On Apr 28, 2020, at 16:25, Steven D'Aprano wrote:
>
> On Tue, Apr 28, 2020 at 11:45:49AM -0700, Raymond Hettinger wrote:
>
>> It seems like you would get just about everything you want with one line:
>>
>> once = lru_cache(maxsize=None)
>
> But is it thread-safe?
You can add thread
On Apr 28, 2020, at 12:02, Alex Hall wrote:
>
> Some libraries implement a 'lazy object' which forwards all operations to a
> wrapped object, which gets lazily initialised once:
>
> https://github.com/ionelmc/python-lazy-object-proxy
>
On Apr 28, 2020, at 09:18, Chris Angelico wrote:
>
> I suggest forking CPython and implementing the feature.
I’d suggest trying MacroPy first. There’s no way to get the desired syntax with
macros, but at least at first glance it seems like you should be able to get
the desired semantics with
On Apr 26, 2020, at 10:41, Guido van Rossum wrote:
>
>
> Since the function has no parameters and is pre-computed, why force all users
> to *call* it? The @once decorator could just return the value of calling the
> function:
>
> def once(func):
> return func()
>
> @once
> def pwd():
>
On Apr 27, 2020, at 20:48, Soni L. wrote
>
>> Here are four ways of doing this today:
…
>> So, why do we need another way to do something that’s probably pretty
>> uncommon and can already be done pretty easily? Especially if that new way
>> isn’t more readable or more powerful?
>
> the
On Apr 27, 2020, at 17:01, Soni L. wrote:
>
>>> On 2020-04-27 8:37 p.m., Andrew Barnert wrote:
>>> On Apr 27, 2020, at 14:38, Soni L. wrote:
>> [snipping a long unanswered reply]
>>> The explicit case for zip is if you *don't* want it to consume anything
>>> after the stop.
>> Sure, but *when
On Apr 27, 2020, at 16:35, Soni L. wrote:
>
> the point of posting here is that someone else may have a similar existing
> use-case
Similar to *what*? It can’t be similar to your use case if you don’t have a use
case for it to be similar to.
If you really can’t imagine why something might
On Apr 27, 2020, at 14:38, Soni L. wrote:
[snipping a long unanswered reply]
> The explicit case for zip is if you *don't* want it to consume anything after
> the stop.
Sure, but *when do you want that*? What’s an example of code you want to write
that would be more readable, or easier to
On Apr 27, 2020, at 13:41, Christopher Barker wrote:
>
> SIDE NOTE: this is reminding me that there have been calls in the past for an
> optional __len__ protocol for iterators that are not proper sequences, but DO
> know their length -- maybe one more place to use that if it existed.
But
On Apr 27, 2020, at 12:49, Soni L. wrote:
>
> I wanna propose making generators even weirder!
Why? Most people would consider that a negative, not a positive. Even if you
demonstrate some useful functionality with realistic examples that benefit from
it, all you’ve done here is set the bar
On Apr 26, 2020, at 21:23, David Mertz wrote:
>
>
>> On Sun, Apr 26, 2020 at 11:56 PM Christopher Barker
>> wrote:
>> > If I have two or more "sequences" there are basically two cases of that.
>>
>> so you need to write different code, depending on which case? that seems not
>> very
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 can’t
On Apr 26, 2020, at 14:36, Daniel Moisset wrote:
>
> This idea is something I could have used many times. I agree with many people
> here that the strict=True API is at least "unusual" in Python. I was thinking
> of 2 different API approaches that could be used for this and I think no one
>
On Apr 26, 2020, at 10:49, Eric Fahlgren wrote:
>
>> On Sun, Apr 26, 2020 at 9:46 AM Alex Hall wrote:
>> It's not clear to me why people prefer an extra function which would be
>> exactly equivalent to lru_cache in the expected use case (i.e. decorating a
>> function without arguments). It
On Apr 25, 2020, at 09:40, Christopher Barker wrote:
>
> - The main exception to this may be when one of them is infinite, but how
> common is that, really? Remember that when zip was first created (py2) it was
> a list builder, not an iterator, and Python itself was much less
>
On Apr 24, 2020, at 11:07, Brandt Bucher wrote:
>
> 1. Likely the most common case, for me, is when I have some data and want to
> iterate over both it and a calculated pairing:
>
x = ["a", "b", "c", "d"]
y = iter_apply_some_transformation(x)
for a, b in zip(x, y):
> ... ...
> On Apr 24, 2020, at 08:46, Soni L. wrote:
>
> it's not my own use case for once. the PEP clearly lists a use-case. we
> should support that use-case.
So your use case is the rationale from a PEP written because Barry “can’t
resist” and rejected as a joke in record time, for which a better
> 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 is
On Apr 22, 2020, at 15:04, pyt...@roganartu.com wrote:
>
> The natural extension to this filtering idea are convenience args that set
> two const values (eg: `--filter x --filter y` being equivalent to
> `--filter-x-y`), but there is no `extend_const` action to enable this.
>
> While this is
> 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 exception yo
On Apr 21, 2020, at 19:35, Steven D'Aprano wrote:
>
> On Mon, Apr 20, 2020 at 07:47:51PM -0700, Andrew Barnert wrote:
>
counter = itertools.count()
yield from zip(counter, itertools.chain(headers, [''], body, [''])
lines = next(counter)
>>>
>>> That gives you one more than the
On Apr 22, 2020, at 01:52, Serhiy Storchaka wrote:
>
> 22.04.20 11:20, Antoine Pitrou пише:
>> Ideally, that's what it would do. Whether it's desirable to transition
>> to that behaviour is an open question.
>> But, as far as I'm concerned, the number of times where I took
>> advantage of
On Apr 21, 2020, at 01:36, Serhiy Storchaka wrote:
>
>except ValueError: # assuming that’s the exception you want?
For what it’s worth, more_itertools.zip_equal raises an UnequalIterablesError,
which is a subclass of ValueError.
I’m not sure whether having a special error class is worth
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
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 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 somethi
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 far
On Apr 20, 2020, at 16:46, Christopher Barker wrote:
> On Mon, Apr 20, 2020 at 3:13 PM Andrew Barnert wrote:
> > Sure, it’s a declarative format, it’s just that often it’s intended to be
> > understood as representing an object graph.
>
> I"m not sure the point here -- I was not getting onto
Alex Hall wrote:
> Surely no exception is raised because zip is lazy?
Ack, you're right. The same problem would come up wherever you actually _use_
the zip, of course, but it's harder to demonstrate and reason about.
So change that toy example to `zipped = list(zip(x, y, strict=True))`.
On Apr 20, 2020, at 13:49, Ram Rachum wrote:
>
> Good point. It would have to be dependent on position. In other words, you
> would never pass an iterator into zip with any expectation that it would be
> in a usable condition by the time it's done.
>
> Actually, I can't think of any current
On Apr 20, 2020, at 13:42, Christopher Barker wrote:
>
> On Mon, Apr 20, 2020 at 12:17 PM Andrew Barnert wrote:
>>
>> A lot of JSON is designed to be consumed by JavaScript, where there is no
>> real line (there is no dict type; objects have both dict-style and dot-style
>> access). So in
On Apr 20, 2020, at 10:42, Ram Rachum wrote:
>
> Here's something that would have saved me some debugging yesterday:
>
> >>> zipped = zip(x, y, z, strict=True)
>
> I suggest that `strict=True` would ensure that all the iterables have been
> exhausted, raising an exception otherwise.
One
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
On Apr 20, 2020, at 11:25, Brandt Bucher wrote:
>
> I disagree. In my own personal experience, ~80% of the time when I use `zip`
> there is an assumption that all of the iterables are the same length.
Sure, but I think cases where you want that assumption _checked_ are a lot less
common.
On Apr 20, 2020, at 11:01, Christopher Barker wrote:
>
> The JSON - related example is a good one -- JSON maps well to "data" in
> Python, dicts and lists of numbers and strings. If you find yourself
> converting a bunch of variable names to/from JSON, you probably should be
> simply using a
On Apr 20, 2020, at 10:42, Ram Rachum wrote:
>
> Here's something that would have saved me some debugging yesterday:
>
> >>> zipped = zip(x, y, z, strict=True)
>
> I suggest that `strict=True` would ensure that all the iterables have been
> exhausted, raising an exception otherwise.
On Apr 20, 2020, at 01:06, M.-A. Lemburg wrote:
>
> The current version already strikes me as way too complex.
> It's by far the most complex piece of grammar we have in Python:
>
> funcdef: 'def' NAME parameters ['->' test] ':' [TYPE_COMMENT]
> func_body_suite
But nobody’s proposing changing
On Apr 20, 2020, at 08:41, J. Pic wrote:
>
>
> Currently, list.append(x) mutates the list and returns None.
Yes, which is consistent with the vast majority of mutating methods in Python.
It would be pretty weird to make lst.append(x) return x, while lst.extend(xs)
still returns None, not to
On Apr 18, 2020, at 05:16, Alex Hall wrote:
>
> Is there anything else similar in the language? Obviously there are cases
> where the same text has different meanings in different contexts, but I don't
> think you can ever refactor an expression (or text that looks like an
> expression) into
On Apr 17, 2020, at 23:18, Steven D'Aprano wrote:
>
>
> Keyword Unpacking Shortcut
> --
>
> Inside function calls, the syntax
>
> **{identifier [, ...]}
>
> expands to a set of `identifier=identifier` argument bindings.
>
> This will be legal anywhere inside a
1 - 100 of 745 matches
Mail list logo
