Re: Need max values in list of tuples, based on position

On 11/13/2022 7:37 AM, Pancho wrote: On 11/11/2022 19:56, DFS wrote: Edit: found a solution online: - x = [(11,1,1),(1,41,2),(9,3,12)] maxvals = [0]*len(x[0]) for e in x:  maxvals = [max(w,int(c)) for w,c in zip(maxvals,e)]

Re: Need max values in list of tuples, based on position

On 11/11/2022 19:56, DFS wrote: Edit: found a solution online: - x = [(11,1,1),(1,41,2),(9,3,12)] maxvals = [0]*len(x[0]) for e in x: maxvals = [max(w,int(c)) for w,c in zip(maxvals,e)] print(maxvals) [11,41,12]

Re: Need max values in list of tuples, based on position

On Sat, 12 Nov 2022 13:24:37 -0500, Dennis Lee Bieber declaimed the following: > Granted, this will NOT work with "select *" unless one does the select >*/fetchall first, AND extracts the names from the cursor description -- >then run a loop to create the select max(length(col)), ...

Re: Need max values in list of tuples, based on position

On Fri, 11 Nov 2022 21:20:10 -0500, DFS declaimed the following: >Yeah, I don't know why cursor.description doesn't work with SQLite; all >their columns are basically varchars. > If you read PEP 249 (the general DB-API), everything except column name and data type code are optional. And

Re: Need max values in list of tuples, based on position

ic type checking in addition to the dyunamic typing. > From: Python-list on > behalf of Pancho via Python-list > Date: Friday, November 11, 2022 at 6:28 PM > To: python-list@python.org > Subject: Re: Need max values in list of tuples, based on position > > That was one of the th

Re: Need max values in list of tuples, based on position

Types are available if you want to use them. https://www.pythontutorial.net/python-basics/python-type-hints/ From: Python-list on behalf of Pancho via Python-list Date: Friday, November 11, 2022 at 6:28 PM To: python-list@python.org Subject: Re: Need max values in list of tuples, based

Re: Need max values in list of tuples, based on position

On 11/11/2022 7:04 PM, Dennis Lee Bieber wrote: On Fri, 11 Nov 2022 15:03:49 -0500, DFS declaimed the following: Thanks for looking at it. I'm trying to determine the maximum length of each column result in a SQL query. Normally you can use the 3rd value of the cursor.description object

Re: Need max values in list of tuples, based on position

On Fri, 11 Nov 2022 15:03:49 -0500, DFS declaimed the following: >Thanks for looking at it. I'm trying to determine the maximum length of >each column result in a SQL query. Normally you can use the 3rd value >of the cursor.description object (see the DB-API spec), but apparently >not with

Re: Need max values in list of tuples, based on position

On 11/11/2022 20:58, Thomas Passin wrote: On 11/11/2022 2:22 PM, Pancho via Python-list wrote: On 11/11/2022 18:53, DFS wrote: On 11/11/2022 12:49 PM, Dennis Lee Bieber wrote: On Fri, 11 Nov 2022 02:22:34 -0500, DFS declaimed the following: [(0,11), (1,1),  (2,1),   (0,1) , (1,41), (2,2),

Re: Need max values in list of tuples, based on position

On 11/11/2022 2:22 PM, Pancho wrote: On 11/11/2022 18:53, DFS wrote: On 11/11/2022 12:49 PM, Dennis Lee Bieber wrote: On Fri, 11 Nov 2022 02:22:34 -0500, DFS declaimed the following: [(0,11), (1,1),  (2,1),   (0,1) , (1,41), (2,2),   (0,9) , (1,3),  (2,12)] The set of values in

Re: Need max values in list of tuples, based on position

, and present it in the order of those rows? Your data list does not distinguish the rows from the tuples, so that information must come from somewhere else. Could it sometimes be different from 3? How are we supposed to know? Also, as has already been noted in this thread, the result cannot

Re: Need max values in list of tuples, based on position

On 11/11/2022 2:22 PM, Pancho via Python-list wrote: On 11/11/2022 18:53, DFS wrote: On 11/11/2022 12:49 PM, Dennis Lee Bieber wrote: On Fri, 11 Nov 2022 02:22:34 -0500, DFS declaimed the following: [(0,11), (1,1),  (2,1),   (0,1) , (1,41), (2,2),   (0,9) , (1,3),  (2,12)] The set of

Re: Need max values in list of tuples, based on position

On 11/11/2022 7:50 AM, Stefan Ram wrote: Pancho writes: def build_max_dict( tups): dict = {} for (a,b) in tups: if (a in dict): if (b>dict[a]): dict[a]=b else: dict[a]=b return(sorted(dict.values())) Or, import

Re: Need max values in list of tuples, based on position

On Fri, 11 Nov 2022 02:22:34 -0500, DFS declaimed the following: > >[(0,11), (1,1), (2,1), > (0,1) , (1,41), (2,2), > (0,9) , (1,3), (2,12)] > >The set of values in elements[0] is {0,1,2} > >I want the set of max values in elements[1]: {11,41,12} Do they have to be IN THAT

Re: Need max values in list of tuples, based on position

On 11/11/2022 07:22, DFS wrote: [(0,11), (1,1),  (2,1),  (0,1) , (1,41), (2,2),  (0,9) , (1,3),  (2,12)] The set of values in elements[0] is {0,1,2} I want the set of max values in elements[1]: {11,41,12} def build_max_dict( tups): dict = {} for (a,b) in tups: if (a in

Re: Need max values in list of tuples, based on position

On 11/11/2022 18:53, DFS wrote: On 11/11/2022 12:49 PM, Dennis Lee Bieber wrote: On Fri, 11 Nov 2022 02:22:34 -0500, DFS declaimed the following: [(0,11), (1,1),  (2,1),   (0,1) , (1,41), (2,2),   (0,9) , (1,3),  (2,12)] The set of values in elements[0] is {0,1,2} I want the set of max

Need max values in list of tuples, based on position

[(0,11), (1,1), (2,1), (0,1) , (1,41), (2,2), (0,9) , (1,3), (2,12)] The set of values in elements[0] is {0,1,2} I want the set of max values in elements[1]: {11,41,12} -- https://mail.python.org/mailman/listinfo/python-list

Re: Need max values in list of tuples, based on position

On 11/11/2022 12:49 PM, Dennis Lee Bieber wrote: On Fri, 11 Nov 2022 02:22:34 -0500, DFS declaimed the following: [(0,11), (1,1), (2,1), (0,1) , (1,41), (2,2), (0,9) , (1,3), (2,12)] The set of values in elements[0] is {0,1,2} I want the set of max values in elements[1]: {11,41,12}

[issue517371] Add .count() method to tuples

Change by admin : -- github: None -> 36100 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue430200] corrupt floats in lists & tuples

Change by admin : -- github: None -> 34584 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue506741] ugly floats using str() on tuples,lists

Change by admin : -- github: None -> 35964 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue447478] a = b = c problem with tuples...

Change by admin : -- github: None -> 34888 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue431886] listcomp syntax too confusing (tuples)

Change by admin : -- github: None -> 34602 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46423] CLI: Addition assignment for tuples

Mark Dickinson added the comment: Thanks for the report. This is a long-standing and known behaviour. It's been discussed a good few times before, and (quite apart from potential problems with backwards compatibility) no-one has yet come up with convincing alternative behaviours. See

[issue46423] CLI: Addition assignment for tuples

-- messages: 410861 nosy: ramezaniua priority: normal severity: normal status: open title: CLI: Addition assignment for tuples type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue46423> __

Re: Friday Finking: initialising values and implied tuples

On Tue, Apr 6, 2021 at 5:36 AM Rob Cliffe via Python-list wrote: > > > > On 05/04/2021 18:33, Chris Angelico wrote: > > > > Firstly, anything with any variable at all can involve a lookup, which > > can trigger arbitrary code (so "variables which do not occur on the > > LHS" is not sufficient). >

Re: Friday Finking: initialising values and implied tuples

On 05/04/2021 18:33, Chris Angelico wrote: Firstly, anything with any variable at all can involve a lookup, which can trigger arbitrary code (so "variables which do not occur on the LHS" is not sufficient). Interesting.  I was going to ask: How could you make a variable lookup trigger

Re: Friday Finking: initialising values and implied tuples

0 LOAD_CONST 1 ((1, 2)) > >> 2 UNPACK_SEQUENCE 2 > >> 4 STORE_FAST 0 (x) > >> 6 STORE_FAST 1 (y) > >> 8 LOAD_CONST 0 (None) > &

Re: Friday Finking: initialising values and implied tuples

On 05/04/2021 17:52, Chris Angelico wrote: I don't understand.  What semantic difference could there be between     x = { 1: 2 }    ;    y = [3, 4]   ;   z = (5, 6) and     x, y, z = { 1:2 }, [3, 4], (5, 6) ?  Why is it not safe to convert the latter to the former? But I withdraw "set" from my

Re: Friday Finking: initialising values and implied tuples

)) 2 UNPACK_SEQUENCE 2 4 STORE_FAST 0 (x) 6 STORE_FAST 1 (y) 8 LOAD_CONST 0 (None) 10 RETURN_VALUE Thinking some more about this, this (removing the tuples

Re: Friday Finking: initialising values and implied tuples

LOAD_CONST 1 ((1, 2)) >2 UNPACK_SEQUENCE 2 >4 STORE_FAST 0 (x) >6 STORE_FAST 1 (y) >8 LOAD_CONST 0 (None) > 10 RETURN_VALUE > Thinking som

Re: Friday Finking: initialising values and implied tuples

(It would be kinda nice if the compiler could optimise the tuples away, for those of us who are paranoid about performance.) I think I've read that the compiler is smart-enough to realise that the RHS 'literal-tuples'?'tuple-literals' are being used as a 'mechanism', and thus the inits are in-lined. Ap

Re: Friday Finking: initialising values and implied tuples

On 2021-04-05 at 11:47:53 +1200, dn via Python-list wrote: > Did you spot how various contributors identified when they prefer one > method in a specific situation, but reach for another under differing > circumstances! What? Use cases matter? I'm *shocked*. :-/ Of all the methodologies I

Re: Friday Finking: initialising values and implied tuples

On 5/04/21 11:47 am, dn wrote: I think I've read that the compiler is smart-enough to realise that the RHS 'literal-tuples'?'tuple-literals' are being used as a 'mechanism', and thus the inits are in-lined. It does indeed seem to do this in some cases: >>> def g(i, j, k): ... a, b,

Re: Friday Finking: initialising values and implied tuples

43,  3, 10) >> (x2, y2, z2) = (41, 12,  9) >> (x3, y3, z3) = ( 8,  8, 10) > Agreed, that is even easier to read.  (It would be kinda nice if the > compiler could optimise the tuples away, for those of us who are > paranoid about performance.) I think I've read th

Re: Friday Finking: initialising values and implied tuples

On 03/04/2021 11.25, Marco Ippolito wrote: >> (a) basic linear presentation: >> >> resource = "Oil" >> time = 1 >> crude = 2 >> residue = 3 >> my_list = "long" >> >> (b) using explicit tuples: >> >> ( r

Re: Friday Finking: initialising values and implied tuples

f you must see that structure, then go all in: (x1, y1, z1) = (43, 3, 10) (x2, y2, z2) = (41, 12, 9) (x3, y3, z3) = ( 8, 8, 10) Agreed, that is even easier to read.  (It would be kinda nice if the compiler could optimise the tuples away, for those of us who are paranoid about p

Re: Friday Finking: initialising values and implied tuples

On 2021-04-03 at 02:41:59 +0100, Rob Cliffe via Python-list wrote: >     x1 = 42; y1 =  3;  z1 = 10 >     x2 = 41; y2 = 12; z2 = 9 >     x3 =  8;  y3 =  8;  z3 = 10 > (please imagine it's in a fixed font with everything neatly vertically > aligned). > This has see-at-a-glance STRUCTURE: the

Re: Friday Finking: initialising values and implied tuples

list = "long" In production code I'd almost always go with this one. It's the only option that both keeps the variable and value together and allows me to add an explanatory comment if necessary. > (e) implicit tuples: > > resource, time, crude, residue, my_list = "Oil&qu

Re: Friday Finking: initialising values and implied tuples

On 02/04/2021 23:10, dn via Python-list wrote: (f) the space-saver: resource = "Oil"; time = 1; crude = 2; residue = 3; my_list = "long" IMO This can be OK when the number of items is VERY small (like 2) and not expected to increase (or decrease).  Especially if there are multiple

Re: Friday Finking: initialising values and implied tuples

On 2021-04-02 at 19:25:07 -0300, Marco Ippolito wrote: > > (a) basic linear presentation: > > > > resource = "Oil" > > time = 1 > > crude = 2 > > residue = 3 > > my_list = "long" > > > > (b) using explicit tuples: >

Re: Friday Finking: initialising values and implied tuples

> (a) basic linear presentation: > > resource = "Oil" > time = 1 > crude = 2 > residue = 3 > my_list = "long" > > (b) using explicit tuples: > > ( resource, time, crude, residue, my_list ) = ( "Oil", 1, 2, 3, "long"

Friday Finking: initialising values and implied tuples

various values to a series of objects. Simple? Using tuples can have its advantages, but as their length increases humans have difficulties with the positional nature/relationship. Here are a couple of ways that you may/not have seen, to express the need (and perhaps you could contribute more

[issue43385] heapq fails to sort tuples by datetime correctly

Steven D'Aprano added the comment: Heaps are not sorted lists! It is true that a sorted list is a heap, but heaps are not necessarily sorted. Here is another heap which is not sorted: >>> L = [] >>> for n in (9, 7, 8, 11, 4): ... heapq.heappush(L, n) ... >>> L [4, 7, 8, 11, 9]

[issue43385] heapq fails to sort tuples by datetime correctly

New submission from Michał Kozik : Tuples (datetime, description) all are sorted by the date except one entry (2021-03-09) which is out of order: Expected order: Actual order: 2021-03-04 Event E 2021-03-04 Event E 2021-03-07 Event B 2021-03

[issue43017] Improve error message in the parser when using un-parenthesised tuples in comprehensions

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue43017] Improve error message in the parser when using un-parenthesised tuples in comprehensions

Pablo Galindo Salgado added the comment: New changeset 835f14ff8eec10b3d96f821a1eb46a986e00c690 by Pablo Galindo in branch 'master': bpo-43017: Improve error message for unparenthesised tuples in comprehensions (GH24314) https://github.com/python/cpython/commit

[issue43017] Improve error message in the parser when using un-parenthesised tuples in comprehensions

Andre Roberge added the comment: Such a change would be very useful and appreciated by other users as reported on https://github.com/aroberge/friendly-traceback/issues/167 and asked about on StackOverflow https://stackoverflow.com/questions/60986850/why-does-creating-a-list-of-tuples-using

[issue43017] Improve error message in the parser when using un-parenthesised tuples in comprehensions

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +23133 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24314 ___ Python tracker

[issue43017] Improve error message in the parser when using un-parenthesised tuples in comprehensions

Change by Pablo Galindo Salgado : -- nosy: +lys.nikolaou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43017] Improve error message in the parser when using un-parenthesised tuples in comprehensions

parser when using un-parenthesised tuples in comprehensions ___ Python tracker <https://bugs.python.org/issue43017> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

[issue42669] "except" documentation still suggests nested tuples are allowed

Change by Eric V. Smith : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue42669] "except" documentation still suggests nested tuples are allowed

Eric V. Smith added the comment: New changeset 81f706d2db0f57c4fdd747df6e0a4cffcbc54704 by Miss Islington (bot) in branch '3.8': bpo-42669: Document that `except` rejects nested tuples (GH-23822) (GH-23871) https://github.com/python/cpython/commit/81f706d2db0f57c4fdd747df6e0a4cffcbc54704

[issue42669] "except" documentation still suggests nested tuples are allowed

Eric V. Smith added the comment: New changeset 409ce4a09e4f96ca9b251c19f5819205aae9ae34 by Miss Islington (bot) in branch '3.9': bpo-42669: Document that `except` rejects nested tuples (GH-23822) (GH-23870) https://github.com/python/cpython/commit/409ce4a09e4f96ca9b251c19f5819205aae9ae34

[issue42669] "except" documentation still suggests nested tuples are allowed

Change by miss-islington : -- pull_requests: +22733 pull_request: https://github.com/python/cpython/pull/23871 ___ Python tracker ___

[issue42669] "except" documentation still suggests nested tuples are allowed

Change by miss-islington : -- pull_requests: +22732 pull_request: https://github.com/python/cpython/pull/23870 ___ Python tracker ___

[issue42669] "except" documentation still suggests nested tuples are allowed

miss-islington added the comment: New changeset c95f8bc2700b42f4568886505a819816c9b0ba28 by Colin Watson in branch 'master': bpo-42669: Document that `except` rejects nested tuples (GH-23822) https://github.com/python/cpython/commit/c95f8bc2700b42f4568886505a819816c9b0ba28 -- nosy

[issue42669] "except" documentation still suggests nested tuples are allowed

Change by Colin Watson : -- keywords: +patch pull_requests: +22682 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23822 ___ Python tracker ___

[issue42669] "except" documentation still suggests nested tuples are allowed

r a tuple containing an item compatible with the exception. I think this admits a recursive reading: I certainly read it that way. It should make it clear that nested tuples are not allowed. -- assignee: docs@python components: Documentation messages: 383243 nosy: cjwatson, docs@pyt

[issue33153] interpreter crash when multiplying large tuples

Change by Irit Katriel : -- stage: -> resolved ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33153] interpreter crash when multiplying large tuples

Change by Irit Katriel : -- stage: resolved -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33153] interpreter crash when multiplying large tuples

Irit Katriel added the comment: This is a python 2-only issue. -- nosy: +iritkatriel resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker

Re: Puzzling difference between lists and tuples

On Mon, Sep 21, 2020 at 10:14 PM Serhiy Storchaka wrote: > > 18.09.20 03:55, Chris Angelico пише: > > On Fri, Sep 18, 2020 at 10:53 AM Grant Edwards > > wrote: > >> Yea, the syntax for tuple literals has always been a bit of an ugly > >> spot in Python. If ASCII had only had one more set of

Re: Puzzling difference between lists and tuples

18.09.20 03:55, Chris Angelico пише: > On Fri, Sep 18, 2020 at 10:53 AM Grant Edwards > wrote: >> Yea, the syntax for tuple literals has always been a bit of an ugly >> spot in Python. If ASCII had only had one more set of open/close >> brackets... > > ... then I'd prefer them to be used for

Re: Puzzling difference between lists and tuples

On 20Sep2020 20:33, Avi Gross wrote: >('M','R','A','B') is correct. I appreciate the correction. I did not look to >see the content of what I created, just the type! > a = tuple("first") a >('f', 'i', 'r', 's', 't') type(a) > > >But I thought adding a comma would help and it does

RE: Puzzling difference between lists and tuples

st',) I understand the design choice and can imagine there may be another function that initializes a tuple more directly in some module. Returning to lurking mode ... -Original Message- From: Python-list On Behalf Of MRAB Sent: Sunday, September 20, 2020 7:35 PM To: python-list@python.org Su

Re: Puzzling difference between lists and tuples

On 21/09/20 10:59 am, Avi Gross wrote: a=tuple("first") type(a) That seems more explicit than adding a trailing comma. It doesn't do what you want, though: >>> a = tuple("first") >>> print(a) ('f', 'i', 'r', 's', 't') If you really want to use tuple() to create a 1-tuple without using a

Re: Puzzling difference between lists and tuples

On 2020-09-20 23:59, Avi Gross via Python-list wrote: There is a simple and obvious way to make sure you have a tuple by invoking the keyword/function in making it: a=('first') type(a) a=("first",) type(a) a=tuple("first") type(a) That seems more explicit than adding a trailing

RE: Puzzling difference between lists and tuples

re explicit than adding a trailing comma. It also is a simple way to make an empty tuple but is there any penalty for using the function tuple()? -Original Message- From: Python-list On Behalf Of "???" Sent: Saturday, September 19, 2020 11:39 PM To: python-list@python.or

sorry for typo (Was: Re: Puzzling difference between lists and tuples)

> #+BEGIN_SRC: python > for n in ('first',): > print n > #+BEGIN_SRC The last 'BEGIN_SRC' should be 'END_SRC' so sorry ;;; -- ^고맙습니다 _救濟蒼生_ 감사합니다_^))// -- https://mail.python.org/mailman/listinfo/python-list

Re: Puzzling difference between lists and tuples

William Pearson writes: > ... > for n in ('first'): > print n > > > ... but "f","i","r","s","t" in the second. #+BEGIN_SRC: python for n in ('first',): print n #+BEGIN_SRC Then, that will print 'first'. And please use Python3... Sincerely, Byung-Hee -- ^고맙습니다 _救濟蒼生_ 감사합니다_^))// --

Re: Puzzling difference between lists and tuples

On 19/09/20 6:49 am, Grant Edwards wrote: There must be a few more sets of brackets in Unicode... Quite a lot, actually. The character browser in MacOSX is currently showing me 17, not including the ones that are built up from multiple characters. Some of them could be easily confused with

Re: Puzzling difference between lists and tuples

On 2020-09-18, Chris Angelico wrote: > On Fri, Sep 18, 2020 at 10:53 AM Grant Edwards > wrote: >> >> On 2020-09-17, MRAB wrote: >> >> The only time the parentheses are required for tuple building is when >> >> they would otherwise not be interpreted that way: >> >> >> > They're needed for the

Re: Puzzling difference between lists and tuples

On Fri, Sep 18, 2020 at 10:53 AM Grant Edwards wrote: > > On 2020-09-17, MRAB wrote: > >> The only time the parentheses are required for tuple building is when > >> they would otherwise not be interpreted that way: > >> > > They're needed for the empty tuple, which doesn't have a comma. > > > >>

Re: Puzzling difference between lists and tuples

On 2020-09-17, MRAB wrote: >> The only time the parentheses are required for tuple building is when >> they would otherwise not be interpreted that way: >> > They're needed for the empty tuple, which doesn't have a comma. > >> some_func('first', 'second') # some_func called with two str args

Re: Puzzling difference between lists and tuples

On 9/17/20 10:43 AM, MRAB wrote: On 2020-09-17 17:47, Ethan Furman wrote: The only time the parentheses are required for tuple building is when they would otherwise not be interpreted that way: They're needed for the empty tuple, which doesn't have a comma. Ah, right. Thanks. -- ~Ethan~

Re: Puzzling difference between lists and tuples

On 2020-09-17 17:47, Ethan Furman wrote: On 9/17/20 8:24 AM, William Pearson wrote: I am puzzled by the reason for this difference between lists and tuples. A list of with multiple strings can be reduced to a list with one string with the expected results: for n in ['first']: print n

Re: Puzzling difference between lists and tuples

On 9/17/20 11:24 AM, William Pearson wrote: > I am puzzled by the reason for this difference between lists and tuples. > > A list of with multiple strings can be reduced to a list with one string with > the expected results: > > for n in ['first','second']: > print n

Re: Puzzling difference between lists and tuples

On 9/17/20 8:24 AM, William Pearson wrote: I am puzzled by the reason for this difference between lists and tuples. A list of with multiple strings can be reduced to a list with one string with the expected results: for n in ['first']: print n ['first'] is a list. for n in ('first

Re: Puzzling difference between lists and tuples

On 2020-09-17 at 09:24:57 -0600, William Pearson wrote: > for n in ('first'): That's not a tuple. That's a string. Try it this way: for n in ('first',): # note the trailing comma print n Dan -- https://mail.python.org/mailman/listinfo/python-list

Puzzling difference between lists and tuples

I am puzzled by the reason for this difference between lists and tuples. A list of with multiple strings can be reduced to a list with one string with the expected results: for n in ['first','second']: print n for n in ['first']: print n The first loop prints "first"

[issue14611] inspect.getargs fails on some anonymous tuples

Change by Dong-hee Na : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue14611] inspect.getargs fails on some anonymous tuples

Irit Katriel added the comment: I think this was fixed here: https://github.com/python/cpython/commit/3b23004112aefffa72a3763916d78f12b9e056fe and in any case it's a 2.7-only issue, so can this ticket be closed? -- nosy: +iritkatriel ___ Python

[issue2380] Raise a Py3K warning for catching nested tuples with non-BaseException exceptions

Zachary Ware added the comment: With 2.7 out of support, closing. -- nosy: +zach.ware resolution: -> out of date stage: needs patch -> resolved status: open -> closed ___ Python tracker

[issue40011] Tkinter widget events become tuples

Hênio Tierra Sampaio added the comment: Yes, you guys were right. I solved the problem by writing a new, simpler debugging class. I'm sorry for taking your time! Thank you! -- ___ Python tracker

[issue40011] Tkinter widget events become tuples

Serhiy Storchaka added the comment: The problem is in ExceptionCatcher. It uses builtin function apply() which was outdated even in Python 2.7 and was removed in Python 3 (instead of apply(func, args) you can use func(*args)). So that code always failed, but all exceptions were logged and

[issue40011] Tkinter widget events become tuples

tle: Tkinter widget events are of type Tuple -> Tkinter widget events become tuples ___ Python tracker <https://bugs.python.org/issue40011> ___ ___ Python-bugs-list mail

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On Thu, 19 Mar 2020 at 16:46, Peter J. Holzer wrote: > This is similar to algebraic expressions: Have you ever tried to read a > mathematical paper from before the time the current notation (which we > Long, convoluted > sentences instead of what can now be written as a short formula. ...yes,

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On 2020-03-19 15:17, Musbur wrote: Hello, either it's me or everybody else who's missing the point. I understand the OP's proposal like this: dict[set] == {k: dict[k] for k in set} list[iterable] == [list[i] for i in iterable] Am I right? "Iterable" is too broad because it inclu

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On 19/03/2020 14:47, Peter J. Holzer wrote: On 2020-03-19 14:24:35 +, Rhodri James wrote: On 19/03/2020 13:00, Peter J. Holzer wrote: It's more compact, especially, if "d" isn't a one-character variable, but an expression: fname, lname =

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On Fri, Mar 20, 2020 at 2:46 AM Peter J. Holzer wrote: > > A good language has a small core and extensibility via > > libraries. > > This would actually be a feature of the (standard) library. I think the line kinda blurs here. This would be a feature of a core data type, and in CPython, it

RE: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

For dictionaries it'd even be more useful: d = { 'first_name': 'Frances', 'last_name': 'Allen', 'email': 'fal...@ibm.com' } fname, lname = d[['first_name', 'last_name']] Why not do this? import operator first_last = operator.itemgetter("first_name",

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On Fri, Mar 20, 2020 at 2:37 AM Terry Reedy wrote: > > On 3/18/2020 10:28 PM, Santiago Basulto wrote: > > > For dictionaries it'd even be more useful: > > d = { > > 'first_name': 'Frances', > > 'last_name': 'Allen', > > 'email': 'fal...@ibm.com' > > } > >

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On 2020-03-19 08:05:18 -0700, Dan Stromberg wrote: > On Thu, Mar 19, 2020 at 7:47 AM Peter J. Holzer wrote: > > On 2020-03-19 14:24:35 +, Rhodri James wrote: > > > On 19/03/2020 13:00, Peter J. Holzer wrote: > > > > It's more compact, especially, if "d" isn't a one-character variable, > > > >

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On 03/19/2020 02:09 AM, Terry Reedy wrote: On 3/18/2020 10:28 PM, Santiago Basulto wrote: For dictionaries it'd even be more useful: d = { 'first_name': 'Frances', 'last_name': 'Allen', 'email': 'fal...@ibm.com' } fname, lname = d[['first_name',

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On 3/18/2020 10:28 PM, Santiago Basulto wrote: For dictionaries it'd even be more useful: d = { 'first_name': 'Frances', 'last_name': 'Allen', 'email': 'fal...@ibm.com' } fname, lname = d[['first_name', 'last_name']] Insert ordered dicts make this

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

Hello, either it's me or everybody else who's missing the point. I understand the OP's proposal like this: dict[set] == {k: dict[k] for k in set} list[iterable] == [list[i] for i in iterable] Am I right? -- https://mail.python.org/mailman/listinfo/python-list

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

hink multi indexing > alone would be huge addition. A few examples: > > For lists and tuples: > >>> l = ['a', 'b', 'c'] > >>> l[[0, -1]] > ['a', 'c'] > > For dictionaries it'd even be more useful: > d = { > 'first_nam

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On Thu, Mar 19, 2020 at 7:47 AM Peter J. Holzer wrote: > On 2020-03-19 14:24:35 +, Rhodri James wrote: > > On 19/03/2020 13:00, Peter J. Holzer wrote: > > > It's more compact, especially, if "d" isn't a one-character variable, > > > but an expression: > > > > > > fname, lname = >

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On 2020-03-19 14:24:35 +, Rhodri James wrote: > On 19/03/2020 13:00, Peter J. Holzer wrote: > > It's more compact, especially, if "d" isn't a one-character variable, > > but an expression: > > > > fname, lname = db[people].employee.object.get(pk=1234)[['first_name', > > 'last_name']] >

  1   2   3   4   5   6   7   8   9   10   >