Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On 4/21/2014 1:39 AM, Nick Coghlan wrote: OK, I've now updated the PEP to better described the *problem* (rather than skipping ahead to proposing a specific solution - exactly what I was asking people *not* to do at the language summit!), Looks great. I think the analysis should be part of a dict section of the porting how-to. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
Hi Nick, On 21 April 2014 07:39, Nick Coghlan wrote: > Notably, I recommend that hybrid code avoid calling mapping iteration > methods directly, and instead rely on builtin functions where possible, > and some additional helper functions for cases that would be a simple > combination of a builtin and a mapping method in pure Python 3 code, but > need to be handled slightly differently to get the exact same semantics in > Python 2. How about explicitly noting that in Python 2, a large fraction of usages of the iterkeys(), itervalues() and iteritems() methods (that's more than 99% in my experience, but I might be biased) should just be written as keys(), values() and items() in the first place, with no measurable difference of performance or memory usage? I would recommend to anyone with a large Python 2 code base to simply do a textual search-and-replace and see if any test breaks. If not, problem solved. A bientôt, Armin. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On 04/20/2014 10:39 PM, Nick Coghlan wrote: Lists as mutable snapshots -- [...] The semantic equivalent of these operations in Python 3 are ``list(d.keys())``, ``list(d.values())`` and ``list(d.iteritems())``. Last item should be ``list(d.items())``. Iterator objects [...] In Python 3, direct iteration over mappings works the same way as it does in Python 2. There are no method based equivalents - the semantic equivalents of ``d.itervalues()`` and ``d.iteritems()`` in Python 3 are ``iter(d.values())`` and ``iter(d.iteritems())``. ``iter(d.items())``. Thanks again, Nick. -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
> -Original Message- > From: Python-Dev [mailto:python-dev- > [email protected]] On Behalf Of Steven > D'Aprano > If this is a cunning plan to make Nick's suggestion sound better by suggesting > an even worse alternative, it's working :-) You got me. However, I also admit to having learned something today from the PEP. That 2to3 actually replaces d.iteritems() with iter(d.items()). In all my porting experience this conservative approach is redundant for my use cases which is usally just immediate iteration, so I have successfully replaced d.iteritems() with d.items() without issue. For polyglot code, with rare exceptions simply using d.items() in both places is good enough, since IMHO the ill effects of creating temporary list objects is somewhat overstated. The PEP however explicitly wants to do it "correctly" because testing is often limited. So I withdraw my suggestion :) K ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
Hi Guys, please don't do it! We don't need this legacy really. On 21 April 2014 08:41, Armin Rigo wrote: > Hi Nick, > > On 21 April 2014 07:39, Nick Coghlan wrote: > > Notably, I recommend that hybrid code avoid calling mapping iteration > > methods directly, and instead rely on builtin functions where possible, > > and some additional helper functions for cases that would be a simple > > combination of a builtin and a mapping method in pure Python 3 code, but > > need to be handled slightly differently to get the exact same semantics > in > > Python 2. > > How about explicitly noting that in Python 2, a large fraction of > usages of the iterkeys(), itervalues() and iteritems() methods (that's > more than 99% in my experience, but I might be biased) should just be > written as keys(), values() and items() in the first place, with no > measurable difference of performance or memory usage? I would > recommend to anyone with a large Python 2 code base to simply do a > textual search-and-replace and see if any test breaks. If not, > problem solved. > > Couldn't agree more with Armin. -- http://lucasbardella.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
> -Original Message- > From: Python-Dev [mailto:python-dev- > [email protected]] On Behalf Of Armin Rigo > Sent: 21. apríl 2014 07:42 > To: Nick Coghlan > Cc: Python-Dev > Subject: Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() > methods > > How about explicitly noting that in Python 2, a large fraction of usages of > the > iterkeys(), itervalues() and iteritems() methods (that's more than 99% in my > experience, but I might be biased) should just be written as keys(), values() > and items() in the first place, with no measurable difference of performance > or memory usage? I would recommend to anyone with a large Python 2 > code base to simply do a textual search-and-replace and see if any test > breaks. If not, problem solved. +1 K ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Open Source Organizational Culture
Hi, I would like to request your participation in a survey on Open Source Organizational Culture, which will provide valuable insight into how Open Source projects are run, how their participants act, how they might change going forward, and how particular Open Source projects compare with one another and with traditional business cultures. The survey will take 10-15 minutes to complete. http://bit.ly/osocas2014 Why? The survey will be used as part of my thesis on Open Source Organizational Culture at BI Norwegian Business School (www.bi.no/en, or www.bi.edu), but in true Open Source spirit the raw - but anonymized - results will be open for all. So, your Open Source project will be able to massage and dissect the results any way you wish, and see how you compare with other projects out there. Up until now, most research in Open Source culture has been based on mining mailing lists to find out how people act, who they interact with, and how projects organize themselves. In this research we would rather ask the participants directly about how a project is managed and what should change for the project to be spectacularly successful. When? - The survey is open now through May 1st. Where? -- The bit.ly address brings you to the following survey https://osocas.2014.sgizmo.com/s3/ Remember that you can save your progress at any time and come back to the survey at a later point when you have time to finish it. Who are you? My name is Marius Storm-Olsen, and I am currently working on a thesis on Open Source Organizational Culture. I've been an active part of Open Source for years, most notably on the Qt and Git projects. Although I have my own experiences to draw on in the thesis, they do not qualify for the Open Source community at large, hence the survey. How to help? If you want to help, feel free to forward this email to any Open Source project you would want to participate the survey. Once you have send the invitation, please either send me an email with the name of the project, or update the table shown on https://github.com/mstormo/OSOCAS/wiki I do hope you can participate, and thank you for your consideration! Best regards, Marius Storm-Olsen ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open Source Organizational Culture
On 4/21/2014 9:31 PM, Marius Storm-Olsen wrote: > Hi, > > I would like to request your participation in a survey on > Open Source Organizational Culture, > which will provide valuable insight into how Open Source projects are > run, how their participants act, how they might change going forward, > and how particular Open Source projects compare with one another and > with traditional business cultures. The survey will take 10-15 > minutes to complete. > > http://bit.ly/osocas2014 ... > The bit.ly address brings you to the following survey > > https://osocas.2014.sgizmo.com/s3/ Turns out the osocas.2014.sgizmo.com survey subdomain gives an SSL warning for the *.sgizmo.com certificate. *face palm* Feel free to use http://bit.ly/OSOCAS2014 instead, which will redirect to the non-subdomain version https://www.surveygizmo.com/s3/1587798/osocas-2014 Sorry for the inconvenience, and thanks to ChrisA for pointing out the issue! Sincerely, Marius Storm-Olsen -- ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] List vs Tuple / Homogeneous vs Heterogeneous / Mutable vs Immutable
On Apr 18, 2014, at 1:21 AM, Jeff Allen wrote:
> The "think of tuples like a struct in C" explanation immediately reminded me
> that ...
>
> On 16/04/2014 21:42, Taavi Burns wrote (in his excellent notes from the
> language summit):
>> The demographics have changed. How do
>> we change the docs and ecosystem to avoid the assumption that Python
>> programmers already know how to program in C?
In teaching Python, I find that analogs to other languages are helpful
in explaining Python even if a person doesn't know the other language.
sorted(set(open(somefile)))
is like:
cat somefile | sort | uniq # different algorithm, same outcome
or:
SELECT DISTINCT line FROM somelines ORDER BY line;
In particular, it is effective to say that tuples are used like structs in
other languages
or like records in database tables.
I don't think we should go down the road of removing all the similes and
metaphors
from the docs. While children don't usually benefit from them, adults face
different
learning challenges. Usually, their biggest learning hurdle is figuring-out
what is
and what is not a valid comparison to other things they already know.
One problem I have seen with the usual list vs tuple explanations is that
they seem to suggest that the list-are-for-looping and tuples-are-like-records
notions are baked into the implementation of lists and tuples.
In fact, the distinction is extrinsic to their implementations. It is only
important
because the rest of the language tends to treat them differently. For example,
you could store ['raymond', 'red'] as a list or as a tuple ('raymond', 'red'),
but you
wouldn't be punished until later when you tried:
'I think %s likes %s' % container # str.__mod__ treats lists and
tuples differently
Likewise, there seems to be wide-spread confusion about make makes an
object immutable. People seem to miss that ints, tuples, None and str are
immutable only because they lack any mutating methods,
Raymond
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
