On Sun, May 12, 2019 at 1:30 PM David Mertz wrote:
>
> I'll try to find a concrete one tomorrow. I did this recently, but I might
> have factored it away somehow. The real life code has lots of extraneous
> parts that need to be removed or simplified though. Both because they aren't
> FLOSS, an
I'll try to find a concrete one tomorrow. I did this recently, but I might
have factored it away somehow. The real life code has lots of extraneous
parts that need to be removed or simplified though. Both because they
aren't FLOSS, and because the details would muddy things. "Trimmed from
real" won
> On May 11, 2019, at 11:12 PM, Christopher Barker wrote:
>
>> On Sat, May 11, 2019 at 3:26 PM Eric V. Smith wrote:
>
>> It’s a design goal of dataclasses to not be iterable.
>>
>> https://www.python.org/dev/peps/pep-0557/#why-not-just-use-namedtuple
>
> you would know, but that reference t
On Sun, May 12, 2019 at 1:16 PM David Mertz wrote:
>
> Ok, sure. But what if different seen_enough() conditions are in the two inner
> loops? By "break to outer" ... I mean, don't get any more 'main' from
> 'stuff'. I meant to dig through some real code, but forgot because I was
> writing code
Ok, sure. But what if different seen_enough() conditions are in the two
inner loops? By "break to outer" ... I mean, don't get any more 'main' from
'stuff'. I meant to dig through some real code, but forgot because I was
writing code for work. This example on my tablet is the general pattern I
ofte
On Sat, May 11, 2019 at 3:26 PM Eric V. Smith wrote:
> It’s a design goal of dataclasses to not be iterable.
>
> https://www.python.org/dev/peps/pep-0557/#why-not-just-use-namedtuple
>
you would know, but that reference talks about why they are not the same as
NamedTuple.
if dataclasses *were*i
I remembered, there is a "labeled break" in Perl.
https://perldoc.perl.org/functions/last.html
On Sun, May 12, 2019 at 10:50 AM Chris Angelico wrote:
> On Sun, May 12, 2019 at 12:43 PM David Mertz wrote:
> >
> > Terry reminds me of a common case I encounter that cannot be transformed
> into a l
On Sun, May 12, 2019 at 12:43 PM David Mertz wrote:
>
> Terry reminds me of a common case I encounter that cannot be transformed into
> a loop over itertools.product(). E.g.
>
> for main in stuff:
> if thing_about(main):
> for detail in more_stuff(stuff, main):
> if seen_e
Terry reminds me of a common case I encounter that cannot be transformed
into a loop over itertools.product(). E.g.
for main in stuff:
if thing_about(main):
for detail in more_stuff(stuff, main):
if seen_enough(detail):
# break to outer somehow
else:
On Sun, May 12, 2019 at 10:14 AM Ricky Teachey wrote:
>
> Using iter() for the sole purpose of being able to shoehorn your user class
> into being dict-cast-able is, IMO, an abuse of iter.
>
> If your class makes logical sense as an iterable of key/value pairs, then for
> petesake, just use the
Using iter() for the sole purpose of being able to shoehorn your user class
into being dict-cast-able is, IMO, an abuse of iter.
If your class makes logical sense as an iterable of key/value pairs, then
for petesake, just use the mapping protocol (implement getitem and keys).
iter() is for constru
On 5/11/2019 1:20 PM, haael wrote:
Python allows for breaking out from a loop through 'break' and
'continue' keywords. It would be nice if it was possible to break many
loop levels using one command.
I propose two constructions for that:
break
break break
break break break
...
continue
bre
On Sat, May 11, 2019 at 1:22 PM haael wrote:
> Python allows for breaking out from a loop through 'break' and
> 'continue' keywords. It would be nice if it was possible to break many
> loop levels using one command.
I'm surprised no one has yet mentioned splitting off the loops into a
function an
> On May 11, 2019, at 4:51 PM, Christopher Barker wrote:
>
>> On Sat, May 11, 2019 at 1:38 PM Brendan Barnwell
>> wrote:
>
>> > protocol for something different -- I can't image what that would be.
>> > Sure, on the general case, maybe, but for a class that has a "natural"
>> > use case for d
On Sun, May 12, 2019 at 3:45 AM Christopher Barker
wrote:
>
> judicious use of the for loop "else" may help here, too -- I know I often
forget it's there.
yeah, I often do this when I want to break twice but this method only
supports breaking twice at once but this doesn't support break once
and
judicious use of the for loop "else" may help here, too -- I know I often
forget it's there.
-CHB
On Sat, May 11, 2019 at 2:26 PM Adrien Ricocotam
wrote:
>
>
> > On 11 May 2019, at 23:20, David Mertz wrote:
> >
> > I don't love the 'break break' syntax idea. But I find myself wanting to
> bre
OK, so some more exploration:
Other may already know this, but it seems that the dict constructor
essentially checks if the passed in object is a Mapping ABC:
if it is, it iterates on teh keys and used __getitem__ to get the values.
if it is not, it iterates over key, value pairs.
So if you wan
> On 11 May 2019, at 23:20, David Mertz wrote:
>
> I don't love the 'break break' syntax idea. But I find myself wanting to
> break out of nested loops quite often. Very rarely could this be transformed
> to an 'itertools.permutation' de-nesting, albeit perhaps more often than I
> actually
I don't love the 'break break' syntax idea. But I find myself wanting to
break out of nested loops quite often. Very rarely could this be
transformed to an 'itertools.permutation' de-nesting, albeit perhaps more
often than I actually do that.
My usual kludge is a sentinel 'break_outer' variable th
On Sat, May 11, 2019 at 1:38 PM Brendan Barnwell
wrote:
> > protocol for something different -- I can't image what that would be.
> > Sure, on the general case, maybe, but for a class that has a "natural"
> > use case for dictifying, how else would you want to iterate over it??
>
> One ex
On 2019-05-11 12:50, Christopher Barker wrote:
On Sat, May 11, 2019 at 4:06 AM Jeff
> I'd much rather have some kind of explicit wrapping or cast into
their Python type: I had imagined the wrapped object would identify and
behave as exactly that Python type (or ABC), however, it would be a
*pro
On Sat, May 11, 2019 at 4:06 AM Jeff
> I'd much rather have some kind of explicit wrapping or cast into their
Python type: I had imagined the wrapped object would identify and behave as
exactly that Python type (or ABC), however, it would be a *proxy* to the
original.
The ABCs are already defined
On Sat, 11 May 2019 at 18:22, haael wrote:
> Breaking out from many loops at once is a common practice
Do you have evidence for this? In my experience, it's very rare
(although I concede it would be *occasionally* convenient).
In most cases where I'd consider breaking out of multiple levels of
n
Dear Haael
With python you can write
for i, j in something ():
# loop body
This would cover both your examples.
For the first, use itertools.product. For the second, write a custom
iterator.
--
Jonathan
On Sat, 11 May 2019, 18:22 haael, wrote:
>
> Python allows for breaking out
Python allows for breaking out from a loop through 'break' and
'continue' keywords. It would be nice if it was possible to break many
loop levels using one command.
I propose two constructions for that:
break
break break
break break break
...
continue
break continue
break break continue
..
On 11/05/2019 02:46, Christopher Barker wrote:
Though yeah, that’s the key question— how often is this useful???
I have wanted something similar to this in Jython. Java supplies a
battery of containers (with different performance and concurrency
characteristics) and we monkepatch onto them th
26 matches
Mail list logo
