Re: [Python-Dev] Another case for frozendict
I find it handy to use named tuple as my database mapping type. It allows you
to perform this behavior seamlessly.
-Mark
> On Jul 13, 2014, at 7:04, "Jason R. Coombs" wrote:
>
> I repeatedly run into situations where a frozendict would be useful, and
> every time I do, I go searching and find the (unfortunately rejected)
> PEP-416. I’d just like to share another case where having a frozendict in the
> stdlib would be useful to me.
>
> I was interacting with a database and had a list of results from 206 queries:
>
> >>> res = [db.cases.remove({'_id': doc['_id']}) for doc in fives]
> >>> len(res)
> 206
>
> I can see that the results are the same for the first two queries.
>
> >>> res[0]
> {'n': 1, 'err': None, 'ok': 1.0}
> >>> res[1]
> {'n': 1, 'err': None, 'ok': 1.0}
>
> So I’d like to test to see if that’s the case, so I try to construct a ‘set’
> on the results, which in theory would give me a list of unique results:
>
> >>> set(res)
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: unhashable type: 'dict'
>
> I can’t do that because dict is unhashable. That’s reasonable, and if I had a
> frozen dict, I could easily work around this limitation and accomplish what I
> need.
>
> >>> set(map(frozendict, res))
> Traceback (most recent call last):
> File "", line 1, in
> NameError: name 'frozendict' is not defined
>
> PEP-416 mentions a MappingProxyType, but that’s no help.
>
> >>> res_ex = list(map(types.MappingProxyType, res))
> >>> set(res_ex)
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: unhashable type: 'mappingproxy'
>
> I can achieve what I need by constructing a set on the ‘items’ of the dict.
>
> >>> set(tuple(doc.items()) for doc in res)
> {(('n', 1), ('err', None), ('ok', 1.0))}
>
> But that syntax would be nicer if the result had the same representation as
> the input (mapping instead of tuple of pairs). A frozendict would have
> readily enabled the desirable behavior.
>
> Although hashability is mentioned in the PEP under constraints, there are
> many use-cases that fall out of the ability to hash a dict, such as the one
> described above, which are not mentioned at all in use-cases for the PEP.
>
> If there’s ever any interest in reviving that PEP, I’m in favor of its
> implementation.
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/wizzat%40gmail.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] Python 2.x and 3.x use survey, 2014 edition
I disagree. I know there's a huge focus on The Big Libraries (and wholesale migration is all but impossible without them), but the long tail of libraries is still incredibly important. It's like saying that migrating the top 10 Perl libraries to Perl 6 would allow people to completely ignore all of CPAN. It just doesn't make sense. -Mark On Thu, Dec 11, 2014 at 6:47 AM, Giampaolo Rodola' wrote: > > > On Wed, Dec 10, 2014 at 5:59 PM, Bruno Cauet wrote: > >> Hi all, >> Last year a survey was conducted on python 2 and 3 usage. >> Here is the 2014 edition, slightly updated (from 9 to 11 questions). >> It should not take you more than 1 minute to fill. I would be pleased if >> you took that time. >> >> Here's the url: http://goo.gl/forms/tDTcm8UzB3 >> I'll publish the results around the end of the year. >> >> Last year results: https://wiki.python.org/moin/2.x-vs-3.x-survey >> >> Thank you >> Bruno >> >> ___ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com >> > > I still think the only *real* obstacle remains the lack of important > packages such as twisted, gevent and pika which haven't been ported yet. > With those ones ported switching to Python 3 *right now* is not only > possible and relatively easy, but also convenient. > > > -- > Giampaolo - http://grodola.blogspot.com > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/wizzat%40gmail.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] Python 2.x and 3.x use survey, 2014 edition
So, I'm more than aware of how to write Python 2/3 compatible code. I've ported 10-20 libraries to Python 3 and write Python 2/3 compatible code at work. I'm also aware of how much writing 2/3 compatible code makes me hate Python as a language. It'll be a happy day when one of the two languages dies so that I never have to write code like that again. However, my point was that just because the core libraries by usage are *starting* to roll out Python 3 support doesn't mean that things are "easy" or "convenient" yet. There are too many libraries in the long tail which fulfill semi-common purposes and haven't been moved over yet. Yeah, sure, they haven't been updated in years... but neither has the language they're built on. I suppose what I'm saying is that the long tail of libraries is far more valuable than it seems the Python3 zealots are giving it credit for. Please don't claim it's "easy" to move over just because merely most of the top 20 libraries have been moved over. :-/ -Mark On Thu, Dec 11, 2014 at 12:14 PM, Dan Stromberg wrote: > On Thu, Dec 11, 2014 at 11:35 AM, Mark Roberts wrote: > > I disagree. I know there's a huge focus on The Big Libraries (and > wholesale > > migration is all but impossible without them), but the long tail of > > libraries is still incredibly important. It's like saying that migrating > the > > top 10 Perl libraries to Perl 6 would allow people to completely ignore > all > > of CPAN. It just doesn't make sense. > > Things in the Python 2.x vs 3.x world aren't that bad. > > See: > https://python3wos.appspot.com/ and > https://wiki.python.org/moin/PortingPythonToPy3k > http://stromberg.dnsalias.org/~strombrg/Intro-to-Python/ (writing code > to run on 2.x and 3.x) > > I believe just about everything I've written over the last few years > either ran on 2.x and 3.x unmodified, or ran on 3.x alone. If you go > the former route, you don't need to wait for your libraries to be > updated. > > I usually run pylint twice for my projects (after each change, prior > to checkin), once with a 2.x interpreter, and once with a 3.x > interpreter (using > http://stromberg.dnsalias.org/svn/this-pylint/trunk/this-pylint) , but > I gather pylint has the option of running on a 2.x interpreter and > warning about anything that wouldn't work on 3.x. > ___ 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] Python 2.x and 3.x use survey, 2014 edition
On Mon, Dec 15, 2014 at 11:30 AM, Chris Barker wrote: > Are you primarily writing packages for others to use? if so, then yes. But > I wonder how many people are in that camp? Don't most of us spend most of > our time writing our own purpose-built code? > > That might be a nice thing to see in a survey, actually. > So, I'm the guy that used the "hate" word in relation to writing 2/3 compliant code. And really, as a library maintainer/writer I do hate writing 2/3 compatible code. Having 4 future imports in every file and being forced to use a compatibility shim to do something as simple as iterating across a dictionary is somewhere between sad and infuriating - and that's just the beginning of the madness. From there we get into identifier related problems with their own compatibility shims - like str(), unicode(), bytes(), int(), and long(). Writing 2/3 compatible Python feels more like torture than fun. Even the python-future.org FAQ mentions how un-fun writing 2/3 compatible Python is. The whole situation is made worse because I *KNOW* that Python 3 is a better language than Python 2, but that it doesn't *MATTER* because Python 2 is what people are - and will be - using for the foreseeable future. It's impractical to drop library support for Python 2 when all of your users use Python 2, and bringing the topic up yields a response that amounts to: "WELL, Python 3 is the future! It has been out for SEVEN YEARS! You know Python 2 won't be updated ever again! Almost every library has been updated to Python 3 and you're just behind the times! And, you'll have to switch EVENTUALLY anyway! If you'd just stop writing Python 2 libraries and focus on pure Python 3 then you wouldn't have to write legacy code! PEOPLE LIKE YOU are why the split is going to be there until at least 2020!". And then my head explodes from the hostility of the "core Python community". Perhaps no individual response is quite so blunt, but the community (taken as a whole) feels outright toxic on this topic to me. Consider some statistics from Pypi: - 13359 Python 2.7 packages - 7140 Python 3.x packages - 2732 Python 3.4 packages - 4024 Python 2.7/3.x compatible packages - 2281 2.7/3.4 compatible modules - 9335 Python 2.7 without ANY Python 3 support - 11078 Python 2.7 without Python 3.4 support - 451 modules 3.4 only packages - 3116 Python 3.x only packages - 1004 Python 3.x modules without (tagged) Python 3.4 support Looking at the numbers, I just cannot fathom how we as a community can react this way. The top 50 projects (!!) still prevent a lot of people from switching to Python 3, but the long tail of library likely an even bigger blocker. I also don't understand how we can claim people should start ALL new projects in Python 3 - and be indignant when they don't!. We haven't successfully converted the top 50 projects after SEVEN YEARS, and the long tail without 3.x support is still getting longer. Claims that we have something approaching library parity seem... hilarious, at best? I suppose what I'm saying is that there's lots of claims that the conversion to Python 3 is inevitable, but I'm not convinced about that. I'd posit that another outcome is the slow death of Python as a language. I would suggest adding some "community health" metrics around the Python 2/3 split, as well as a question about whether someone considers themselves primarily a library author, application developer, or both. I'd also ask how many people have started a new application in another language instead of Python 3 because of the split. -Mark ___ 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] Python 2.x and 3.x use survey, 2014 edition
On Tue, Dec 16, 2014 at 2:45 AM, Antoine Pitrou wrote:
>
> Iterating accross a dictionary doesn't need compatibility shims. It's
> dead simple in all Python versions:
>
> $ python2
> Python 2.7.8 (default, Oct 20 2014, 15:05:19)
> [GCC 4.9.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> d = {'a': 1}
> >>> for k in d: print(k)
> ...
> a
>
> $ python3
> Python 3.4.2 (default, Oct 8 2014, 13:08:17)
> [GCC 4.9.1] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> d = {'a': 1}
> >>> for k in d: print(k)
> ...
> a
>
> Besides, using iteritems() and friends is generally a premature
> optimization, unless you know you'll have very large containers.
> Creating a list is cheap.
>
It seems to me that every time I hear this, the author is basically
admitting that Python is a toy language not meant for "serious computing"
(where serious is defined in extremely modest terms). The advice is also
very contradictory to literally every talk on performant Python that I've
seen at PyCon or PyData or ... well, anywhere. And really, doesn't it
strike you as incredibly presumptuous to call the *DEFAULT BEHAVIOR* of
Python 3 a "premature optimization"? Isn't the whole reason that the
default behavior switch was made is because creating lists willy nilly all
over the place really *ISN'T* cheap? This isn't the first time someone has
tried to run this line past me, but it's the first time I've been fed up
enough with the topic to call it complete BS on the spot. Please help me
stop the community at large from saying this, because it really isn't true
at all.
-Mark
___
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] Python 2.x and 3.x use survey, 2014 edition
Perhaps you are correct, and I will attempt to remain more constructive on
the topic (despite it being an *incredibly* frustrating experience).
However, my point remains: this is a patently false thing that is being
parroted throughout the Python community, and it's outright insulting to be
told my complaints about writing 2/3 compatible code are invalid on the
basis of "premature optimization".
-Mark
On Tue, Dec 16, 2014 at 10:57 AM, Brett Cannon wrote:
>
> Mark, your tone is no longer constructive and is hurting your case in
> arguing for anything. Please take it down a notch.
>
> On Tue Dec 16 2014 at 1:48:59 PM Mark Roberts wrote:
>
>> On Tue, Dec 16, 2014 at 2:45 AM, Antoine Pitrou
>> wrote:
>>>
>>> Iterating accross a dictionary doesn't need compatibility shims. It's
>>> dead simple in all Python versions:
>>>
>>> $ python2
>>> Python 2.7.8 (default, Oct 20 2014, 15:05:19)
>>> [GCC 4.9.1] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> d = {'a': 1}
>>> >>> for k in d: print(k)
>>> ...
>>> a
>>>
>>> $ python3
>>> Python 3.4.2 (default, Oct 8 2014, 13:08:17)
>>> [GCC 4.9.1] on linux
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> d = {'a': 1}
>>> >>> for k in d: print(k)
>>> ...
>>> a
>>>
>>> Besides, using iteritems() and friends is generally a premature
>>> optimization, unless you know you'll have very large containers.
>>> Creating a list is cheap.
>>>
>>
>> It seems to me that every time I hear this, the author is basically
>> admitting that Python is a toy language not meant for "serious computing"
>> (where serious is defined in extremely modest terms). The advice is also
>> very contradictory to literally every talk on performant Python that I've
>> seen at PyCon or PyData or ... well, anywhere. And really, doesn't it
>> strike you as incredibly presumptuous to call the *DEFAULT BEHAVIOR* of
>> Python 3 a "premature optimization"? Isn't the whole reason that the
>> default behavior switch was made is because creating lists willy nilly all
>> over the place really *ISN'T* cheap? This isn't the first time someone has
>> tried to run this line past me, but it's the first time I've been fed up
>> enough with the topic to call it complete BS on the spot. Please help me
>> stop the community at large from saying this, because it really isn't true
>> at all.
>>
>> -Mark
>> ___
>> Python-Dev mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
>> brett%40python.org
>>
>
___
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] subclassing builtin data structures
> On Feb 12, 2015, at 18:40, Chris Angelico wrote: > > On Fri, Feb 13, 2015 at 12:46 PM, MRAB wrote: > class BaseInt: >> ... def __init__(self, value): >> ... self._value = value >> ... def __add__(self, other): >> ... return type(self)(self._value + other) > >> On Fri, Feb 13, 2015 at 11:55 AM, Guido van Rossum wrote: >> ... there is no reason (in general) why >> the signature of a subclass constructor should match the base class >> constructor, and it often doesn't. > > You're requiring that any subclass of BaseInt be instantiable with one > argument, namely its value. That's requiring that the signature of the > subclass constructor match the base class constructor. > > ChrisA > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/wizzat%40gmail.com No, it seems like he's asking that the type return a new object of the same type instead of one of the superclass. In effect, making the Date class call type(self)(*args) instead of datetime.date(*args). He seems completely willing to accept the consequences of changing the constructor (namely that he will have to override all the methods that call the constructor). It seems like good object oriented design to me. -Mark ___ 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] Language Summit Follow-Up
On Thu, May 29, 2014 at 9:30 AM, Terry Reedy wrote: > On 5/28/2014 6:26 PM, Glyph Lefkowitz wrote: > > I hope it's >> not controversial to say that most new Python code is still being >> written against Python 2.7 today; >> > > Given that Python 3 downloads now outnumber Python 2 downloads, I think > 'most' might be an overstatement. But I think it a moot point. How can you determine that Python3 downloads actually outnumber Python2 downloads? It seems that looking at Windows downloads (as I saw in a thread earlier this month) is fallacious at absolute best. Linux and OSX both ship with Python2, and most downloads happen via individual package management tools. Even including Python3.4 as a default Python3 doesn't mean that it's the default Python on the system. >From my perspective as an engineer and library maintainer: Pypi seems to indicate an overwhelming number of Python2 usage, and so do the job requisitions that I've seen. Furthermore, even Python based libraries for cutting edge technologies are still written in Python2 and later converted to Python3. I just don't understand how we (as a community) can make the assertion that most "new Python" is written in Python 3. What I'd really like to see is a Python 2.8 that makes sufficient changes to Python 2 that writing libraries which cross the boundary between 2 and 3 is relatively easy instead of a painful nightmarish chore. Because when push comes to shove, Python 2 support is still infinitely more important than Python 3. -Mark ___ 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] PyPy3 2.3.1 released
That's fantastic! Great job - that's a lot of work :) -Mark > On Jun 20, 2014, at 13:32, Philip Jenvey wrote: > > = > PyPy3 2.3.1 - Fulcrum > = > > We're pleased to announce the first stable release of PyPy3. PyPy3 > targets Python 3 (3.2.5) compatibility. > > We would like to thank all of the people who donated_ to the `py3k proposal`_ > for supporting the work that went into this. > > You can download the PyPy3 2.3.1 release here: > >http://pypy.org/download.html#pypy3-2-3-1 > > Highlights > == > > * The first stable release of PyPy3: support for Python 3! > > * The stdlib has been updated to Python 3.2.5 > > * Additional support for the u'unicode' syntax (`PEP 414`_) from Python 3.3 > > * Updates from the default branch, such as incremental GC and various JIT > improvements > > * Resolved some notable JIT performance regressions from PyPy2: > > - Re-enabled the previously disabled collection (list/dict/set) strategies > > - Resolved performance of iteration over range objects > > - Resolved handling of Python 3's exception __context__ unnecessarily forcing > frame object overhead > > .. _`PEP 414`: http://legacy.python.org/dev/peps/pep-0414/ > > What is PyPy? > == > > PyPy is a very compliant Python interpreter, almost a drop-in replacement for > CPython 2.7.6 or 3.2.5. It's fast due to its integrated tracing JIT compiler. > > This release supports x86 machines running Linux 32/64, Mac OS X 64, Windows, > and OpenBSD, > as well as newer ARM hardware (ARMv6 or ARMv7, with VFPv3) running Linux. > > While we support 32 bit python on Windows, work on the native Windows 64 > bit python is still stalling, we would welcome a volunteer > to `handle that`_. > > .. _`handle that`: > http://doc.pypy.org/en/latest/windows.html#what-is-missing-for-a-full-64-bit-translation > > How to use PyPy? > = > > We suggest using PyPy from a `virtualenv`_. Once you have a virtualenv > installed, you can follow instructions from `pypy documentation`_ on how > to proceed. This document also covers other `installation schemes`_. > > .. _donated: > http://morepypy.blogspot.com/2012/01/py3k-and-numpy-first-stage-thanks-to.html > .. _`py3k proposal`: http://pypy.org/py3donate.html > .. _`pypy documentation`: > http://doc.pypy.org/en/latest/getting-started.html#installing-using-virtualenv > .. _`virtualenv`: http://www.virtualenv.org/en/latest/ > .. _`installation schemes`: > http://doc.pypy.org/en/latest/getting-started.html#installing-pypy > > > Cheers, > the PyPy team > > -- > Philip Jenvey > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/wizzat%40gmail.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] The "lazy strings" patch
Hmm, I have not viewed the patch in question, but I'm curious why we wouldn't want to include such a patch if it were transparent to the user (Python based or otherwise). Especially if it increased performance without sacrificing maintainability or elegance. Further considering the common usage of strings in usual programming, I fail to see why an implementation like this would not be desirable? If there's a widely recognized argument against this, a link will likely sate my curiosity. Thanks, Mark > ---Original Message--- > From: Josiah Carlson <[EMAIL PROTECTED]> > Subject: Re: [Python-Dev] The "lazy strings" patch > Sent: 21 Oct '06 22:02 > > > Larry Hastings <[EMAIL PROTECTED]> wrote: > > > > I've significantly enhanced my string-concatenation patch, to the point > > where that name is no longer accurate. So I've redubbed it the "lazy > > strings" patch. > [snip] > > Honestly, I don't believe that pure strings should be this complicated. > The implementation of the standard string and unicode type should be as > simple as possible. The current string and unicode implementations are, > in my opinion, as simple as possible given Python's needs. > > As such, I don't see a need to go mucking about with the standard string > implementation to make it "lazy" so as to increase performance, reduce > memory consumption, etc.. However, having written a somewhat "lazy" > string slicing/etc operation class I called a "string view", whose > discussion and implementation can be found in the py3k list, I do > believe that having a related type, perhaps with the tree-based > implementation you have written, or a simple pointer + length variant > like I have written, would be useful to have available to Python. > > I also believe that it smells like a Py3k feature, which suggests that > you should toss the whole string reliance and switch to unicode, as str > and unicode become bytes and text in Py3k, with bytes being mutable. > > > - Josiah > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/mark%40pandapocket.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
