Re: All permutations from 2 lists
For completeness, the itertools solution (which returns an iterator) is
>>> os = ["Linux","Windows"]
>>> region = ["us-east-1", "us-east-2"]
>>> import itertools
>>> itertools.product(os,region)
>>> list(itertools.product(os,region))
[('Linux', 'us-east-1'), ('Linux', 'us-east-2'), ('Windows', 'us-east-1'),
('Windows', 'us-east-2')]
There are probably use cases where you want the iterator and others where you
want the list comprehension. I think the itertools looks nice and it's easier
to generalize it to N=3,4,5,... lists than writing out `for a in list1 for b in
list2 for c in list3` etc -- also, you can do things like
itertools.product(*list_of_lists) to get the product if you have a variable
number of lists. Not exactly sure about speed comparison but my instinct is
that a double/triple list comprehension is going to be slower than letting
itertools do its magic.
On Tue, 01 Mar 2022 18:20:16 -0600 <2qdxy4rzwzuui...@potatochowder.com>
wrote
> On 2022-03-01 at 19:12:10 -0500,
> Larry Martell wrote:
>
> > If I have 2 lists, e.g.:
> >
> > os = ["Linux","Windows"]
> > region = ["us-east-1", "us-east-2"]
> >
> > How can I get a list of tuples with all possible permutations?
> >
> > So for this example I'd want:
> >
> > [("Linux", "us-east-1"), ("Linux", "us-east-2"), ("Windows",
> > "us-east-1"), "Windows", "us-east-2')]
> >
> > The lists can be different lengths or can be 0 length. Tried a few
> > different things with itertools but have not got just what I need.
>
> [(o, r) for o in os for r in region]
>
> Feel free to import itertools, but it's not really necessary. ;-)
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: All permutations from 2 lists
I sent this 17hrs ago but I guess it just went through. Apologies for the
redundant comments... On Tue, 01 Mar 2022 18:57:02 -0600
om+pyt...@omajoshi.com wrote For completeness, the itertools solution
(which returns an iterator) is
>>> os = ["Linux","Windows"]
>>> region = ["us-east-1", "us-east-2"]
>>> import itertools
>>> itertools.product(os,region)
>>> list(itertools.product(os,region))
[('Linux', 'us-east-1'), ('Linux', 'us-east-2'), ('Windows', 'us-east-1'),
('Windows', 'us-east-2')]
There are probably use cases where you want the iterator and others where you
want the list comprehension. I think the itertools looks nice and it's easier
to generalize it to N=3,4,5,... lists than writing out `for a in list1 for b in
list2 for c in list3` etc -- also, you can do things like
itertools.product(*list_of_lists) to get the product if you have a variable
number of lists. Not exactly sure about speed comparison but my instinct is
that a double/triple list comprehension is going to be slower than letting
itertools do its magic.
On Tue, 01 Mar 2022 18:20:16 -0600 <2qdxy4rzwzuui...@potatochowder.com>
wrote
> On 2022-03-01 at 19:12:10 -0500,
> Larry Martell wrote:
>
> > If I have 2 lists, e.g.:
> >
> > os = ["Linux","Windows"]
> > region = ["us-east-1", "us-east-2"]
> >
> > How can I get a list of tuples with all possible permutations?
> >
> > So for this example I'd want:
> >
> > [("Linux", "us-east-1"), ("Linux", "us-east-2"), ("Windows",
> > "us-east-1"), "Windows", "us-east-2')]
> >
> > The lists can be different lengths or can be 0 length. Tried a few
> > different things with itertools but have not got just what I need.
>
> [(o, r) for o in os for r in region]
>
> Feel free to import itertools, but it's not really necessary. ;-)
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: All permutations from 2 lists
Something like this?itertools.product(x or ("",) for x in perm_elems)Out of
curiousity, how might one adapt this if x is not a list but an iterator,
without doing `itertools.product(list(x) or ("",) for x in perm_elems)`?
On Wed, 02 Mar 2022 09:25:42 -0600 antoon.par...@vub.be wrote
Op 2/03/2022 om 15:58 schreef Larry Martell:
> On Wed, Mar 2, 2022 at 9:37 AM Antoon Pardon wrote:
>>
> If one list is empty I want just the other list. What I am doing is
> building a list to pass to a mongodb query. If region is empty then I
> want to query for just the items in the os list. I guess I can test
> for the lists being empty, but I'd like a solution that handles that
> as down the road there could be more than just 2 lists.
How about the following: Keep a list of your lists you want to permute
over.
Like the following:
permutation_elements = [["Linux","Windows"],["us-east-1", "us-east-2"]]
permutation = itertools.product(*permutation_elements)
If you don't include the empty list, you will get more or less what you
seem to want.
>>> But I need to deal with that case.
>> What does that mean? How does using the above method to produce the
>> permutations
>> you want, prevent you from dealing with an empty list however you want when
>> you
>> encounter them? Just don't add them to the permutation_elements.
> I need to know what items are in which position. If sometimes the
> regions are in one index and sometimes in another will not work for
> me.
I am starting to suspect you didn't think this through. What you are telling
here
contradicts what you told earlier that if either list was empty, you just wanted
the other list. Because then you wouldn't know what items were in that list.
The only solution I can see now is that if a list is empty, you either add
[None] or
[""] to the permutation_elements (whatever suits you better) and then use
itertools.product
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
I'm not sure if anyone has mentioned it on this thread, but with respect to
your comment about adding either on.empty or a decorator, the Django template
syntax uses
{% for x in iterator %}
{{ x }}
{% empty %}
Empty
{% endfor %}
and this seems to work quite well and be incredibly intuitive, at least for
Django html templates.
On Fri, 04 Mar 2022 13:45:21 -0600 Avi Gross via Python-list
wrote
> {NOTE, after some diversion, this long message does revert a bit to the
> topic.}
>
> Ah, Chris, the games we played when we were young and relatively immature!
>
> Has anyone else played with embedding "escape sequences" or other gimmicks
> in unexpected places like filenames so that on the right terminals, such as
> the VT100, it displayed oddly or was hard to open or delete as what showed
> was not quite the underlying representation?
>
> The main reason for the restrictions in olden days was cost. Everything was
> so costly including storage/memory and CPU time. Clearly it is a lot easier
> to have fixed-length filenames that fit into say 16 bytes, or storing
> multiple flags about file permissions as single bits, even if it meant lots
> of bit-twiddling or using masks to retrieve their values. We think nothing
> of creating structures that have many others embedded in them as attributes
> or function calls that allow a hundred optional arguments so that the
> function spends much of the time used just figuring out what was set before
> doing whatever calculation is required to fulfill the request.
>
> I was reading a novel recently (Jack Reacher Series) where the main
> character is noticing how much technology has changed as they have been
> ignoring it for a decade or so. Everything seems to be coming up faster. My
> view was that if something seems ten times as fast as it was, it also
> probably is doing a hundred or ten thousand times as much to get that
> result. The real speed changes are often counterbalanced by expecting to do
> more. A web page served may display a screen of text but to transmit it may
> include not just lots of padding in the HTML, but have all kinds of code
> such as in Java or JavaScript or lots of back and forth with the server to
> keep something like a graph displayed being refreshed ...
>
> So back to filenames, the concept of having to search for long filenames
> that may not even be stored sequentially in large blocks that can be read
> (ahead) efficiently, may have seemed to be so illogical as not to be
> considered. So given that the shorter ones were not allowed to have embedded
> spaces, it made sense to treat them like tokens that could be broken up at
> whitespace. As mentioned, languages (or other programs) would often parse a
> command line and create something like this for the main program in C with
> suitable version in Python and other languages:
>
>main(int argc, char *argv[])
>
> The code variations on the above do suppose that something has already
> parsed the command line that invoked them and partitioned it properly into
> individual strings placed in an array of such strings and also returned how
> many arguments it saw. Users invoking the program needed to be careful such
> as using double quotes around anything with embedded spaces, where allowed.
>
> But like many paradigms, there can be a shift. Consider the fact that
> languages like Python are constantly parsing things like names. Can you
> create a variable name like "me first" with an embedded space or even other
> symbols normally reserved such as parentheses? Most languages do not like
> such things. It makes it hard to parse if not quoted in some unique way. Yet
> languages like R happily allow such constructs if placed in back quotes
> (grave accents?) as in `me & you` as a variable name or the name of a
> function. Of course, you then never use the darn name without the extra
> quotes.
>
> Similarly, when you make an object like a DataFrame, can you include spaces
> and other things in the names of columns (or sometimes rows)? If so, is
> there only access some ways and not others?
>
> The answer often is not simple. As Chris repeatedly highlights, making a
> language consistent as you play with features can be VERY hard and sometimes
> not quite possible without relaxing some rules or making exceptions.
> Sometimes the answer varies. In base R a data.frame can be given a column
> name like "me + you" which it then stores as "me...you" leading to odd
> results. But it happily returns that result if you ask for mydf$me using
> auto-completion. Spell it out fully and it won't find it! A later package
> added on makes modified data.frame objects called tibbles which do not
> autocomplete but do completely store and let you access the name so mydf$me
> fails and mydf$"me + you" or mydf
On Fri, 04 Mar 2022 13:45:21 -0600 Avi Gross via Pyt
