Re: [Python-ideas] Revisiting Immutable Mappings

[Serhiy Storchaka]

11.10.18 07:20, João Santos пише:
One important difference between MappingProxyType and a "proper" 
frozendict, as analog to frozenset, is that MappingProxyType doesn't 
have any method to return mutated versions of itself.


MappingProxyType.copy()?

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Revisiting Immutable Mappings

[Anders Hovmöller]

In tri.struct we have a class Frozen 
https://github.com/TriOptima/tri.struct/blob/master/lib/tri/struct/__init__.py 
that can be used to freeze stuff. I think something like this would be even 
better in the standard library, especially now with data classes! If we had 
this frozendict would just be:

class frozendict(dict, Frozen):
pass

/ Anders

> On 10 Oct 2018, at 19:04, Philip Martin  wrote:
> 
> Hi, I first want to thank everyone in the community for the contributions 
> over the years. I know the idea of a frozendict has been proposed before and 
> rejected. I have a use case for a frozendict implementation that to my 
> knowledge was not discussed during previous debates. My reasoning for a 
> frozendict class stems from patterns I typically see arise when performing 
> ETL or data integrations and conversions. I generally have used 
> MappingProxyType as a way to set default mapping to a function or to set an 
> empty mapping to a function. I've created a gist with an example use case:
> 
> https://gist.github.com/pmart123/493edf84d9aa61691ca7321325ebb6ab
> 
> I've included an example of what code typically looks like when using 
> MappingProxyType and what it could look like with a frozendict 
> implementation. I believe this use case may also be under-reported in open 
> source code as it often crops up when integrating third-party data sources, 
> which at times can't be open sourced due to licensing issues. I would love to 
> hear if anyone has used MappingProxyType in a similar manner, or if this use 
> case could help warrant a frozendict in the standard library.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Revisiting Immutable Mappings

[João Santos]

One important difference between MappingProxyType and a "proper"
frozendict, as analog to frozenset, is that MappingProxyType doesn't have
any method to return mutated versions of itself.

On Thu, 11 Oct 2018 at 01:24, Steven D'Aprano  wrote:

> Hi Philiip, and welcome,
>
> On Wed, Oct 10, 2018 at 12:04:48PM -0500, Philip Martin wrote:
>
> > I generally have used MappingProxyType as a way to set default mapping
> > to a function or to set an empty mapping to a function.
>
> > I've created a gist with an example use case:
> >
> > https://gist.github.com/pmart123/493edf84d9aa61691ca7321325ebb6ab
>
> Please try to keep the discussion in one place (i.e. here), for the
> benefit of the archives and for those who have email access but not
> unrestricted web access.
>
> Can you explain (in English) your use-case, and why MappingProxyType
> isn't suitable? If it *is* suitable, how does your proposal differ?
>
> If the only proposal is to rename types.MappingProxyType to a builtin
> "frozendict", that's one thing; if the proposal is something else, you
> should explain what.
>
>
> > I've included an example of what code typically looks like when using
> > MappingProxyType and what it could look like with a
> > frozendict implementation.
>
> Wouldn't that be just:
>
> from types import MappingProxyType as frozendict
> d = frozendict({'spam': 1, 'eggs': 2})
>
> versus:
>
> d = frozendict({'spam': 1, 'eggs': 2})
>
> Apart from the initial import, how would they be different? You want a
> frozendict; the existing MappingProxyType provides a frozendict (with a
> surprising name, but never mind...). Wouldn't you use them exactly the
> same way? They both (I presume) offer precisely the same read-only
> access to the mapping interface.
>
>
>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Revisiting Immutable Mappings

[Philip Martin]

That is interesting. From my recollection, when OrderedDict was
reimplemented in C, there was advice on the thread to not implement it as a
subclass of dict.

https://bugs.python.org/issue16991

I'm far from the right person to comment on the exact reasons, but perhaps
frozenset being decoupled from set gives precedence for a frozendict not
subclassing dict? The methods clear, pop, popitem, update and setdefault
would not be necessary.


On Wed, Oct 10, 2018 at 9:28 PM Chris Angelico  wrote:

> On Thu, Oct 11, 2018 at 1:02 PM Cameron Simpson  wrote:
> >
> > On 10Oct2018 20:25, Philip Martin  wrote:
> > >Steven, that's a great idea, and I would be 100% up for your suggestion
> to
> > >have types.MappingProxyType renamed to frozendict.
> >
> > I'm not for the rename, myself. Though I'd not be against a frozendict
> > factory in builtins, a tiny shim for MappingProxyType.
> >
> > >However, the differences
> > >in the behavior of MappingProxyType's constructor versus dict's would
> make
> > >the API's behavior confusing IMO. For example, MappingProxyType(x=5,
> y=10)
> > >throws a TypeError. I don't think most people would expect this.
> >
> > Well, if it were called frozendict, indeed not. It should act like dict.
> >
> > So:
> >
> >   def frozendict(**kw):
> >   return MappingProxyType(kw)
> >
> > You could make an argument for that (or a slightly heftier version
> > accepting the various things dict accepts). Or... you could just keep
> > such a thing in your personal kit as a trivial way to spell
> > "frozendict". One could argue for the above as a nice example to live in
> > the docs perhaps.
> >
> > But not everything needs a special name.
> >
>
> Point of note: A mapping proxy is NOT immutable; it is merely read-only.
>
> >>> from types import MappingProxyType
> >>> d = {'a':1, 'b':2}
> >>> p = MappingProxyType(d)
> >>> p
> mappingproxy({'a': 1, 'b': 2})
> >>> d['a'] = 3
> >>> p
> mappingproxy({'a': 3, 'b': 2})
>
> A frozendict type, if it's meant to parallel frozenset, ought to be
> hashable (subject to the hashability of its members, of course), but
> you can't just take MPT and toss in a __hash__ method. No idea how
> important that use-case is, but Michael Selik mentioned "want[ing] to
> use a dict as a dict key about once or twice a year", which MPT is not
> able to do.
>
> Interestingly, frozenset isn't a subclass of set. I was going to say
> that a frozendict ought to be a dict, but maybe that isn't so
> important. Which might make a simple pure-Python frozendict actually
> pretty easy.
>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Revisiting Immutable Mappings

[Philip Martin]

Cameron,

That's a good suggestion. Ultimately, if there are not enough various use
cases for a frozendict class, I think we could add something like this as
an example recipe similar to the recipe section in itertools. I would be
hesitant to add a quick shim to the standard library as I can't think of
another instance where a developer calls a function expecting a specific
class, and receives a different class. I'm happy to draft up some
documentation if we decide to take this route because there aren't enough
use cases. It would be great though to hear what other use cases developers
have for a frozendict to ultimately decide whether this is the case.

On Wed, Oct 10, 2018 at 9:01 PM Cameron Simpson  wrote:

> On 10Oct2018 20:25, Philip Martin  wrote:
> >Steven, that's a great idea, and I would be 100% up for your suggestion to
> >have types.MappingProxyType renamed to frozendict.
>
> I'm not for the rename, myself. Though I'd not be against a frozendict
> factory in builtins, a tiny shim for MappingProxyType.
>
> >However, the differences
> >in the behavior of MappingProxyType's constructor versus dict's would make
> >the API's behavior confusing IMO. For example, MappingProxyType(x=5, y=10)
> >throws a TypeError. I don't think most people would expect this.
>
> Well, if it were called frozendict, indeed not. It should act like dict.
>
> So:
>
>   def frozendict(**kw):
>   return MappingProxyType(kw)
>
> You could make an argument for that (or a slightly heftier version
> accepting the various things dict accepts). Or... you could just keep
> such a thing in your personal kit as a trivial way to spell
> "frozendict". One could argue for the above as a nice example to live in
> the docs perhaps.
>
> But not everything needs a special name.
>
> Cheers,
> Cameron Simpson 
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Revisiting Immutable Mappings

[Chris Angelico]

On Thu, Oct 11, 2018 at 1:02 PM Cameron Simpson  wrote:
>
> On 10Oct2018 20:25, Philip Martin  wrote:
> >Steven, that's a great idea, and I would be 100% up for your suggestion to
> >have types.MappingProxyType renamed to frozendict.
>
> I'm not for the rename, myself. Though I'd not be against a frozendict
> factory in builtins, a tiny shim for MappingProxyType.
>
> >However, the differences
> >in the behavior of MappingProxyType's constructor versus dict's would make
> >the API's behavior confusing IMO. For example, MappingProxyType(x=5, y=10)
> >throws a TypeError. I don't think most people would expect this.
>
> Well, if it were called frozendict, indeed not. It should act like dict.
>
> So:
>
>   def frozendict(**kw):
>   return MappingProxyType(kw)
>
> You could make an argument for that (or a slightly heftier version
> accepting the various things dict accepts). Or... you could just keep
> such a thing in your personal kit as a trivial way to spell
> "frozendict". One could argue for the above as a nice example to live in
> the docs perhaps.
>
> But not everything needs a special name.
>

Point of note: A mapping proxy is NOT immutable; it is merely read-only.

>>> from types import MappingProxyType
>>> d = {'a':1, 'b':2}
>>> p = MappingProxyType(d)
>>> p
mappingproxy({'a': 1, 'b': 2})
>>> d['a'] = 3
>>> p
mappingproxy({'a': 3, 'b': 2})

A frozendict type, if it's meant to parallel frozenset, ought to be
hashable (subject to the hashability of its members, of course), but
you can't just take MPT and toss in a __hash__ method. No idea how
important that use-case is, but Michael Selik mentioned "want[ing] to
use a dict as a dict key about once or twice a year", which MPT is not
able to do.

Interestingly, frozenset isn't a subclass of set. I was going to say
that a frozendict ought to be a dict, but maybe that isn't so
important. Which might make a simple pure-Python frozendict actually
pretty easy.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Revisiting Immutable Mappings

[Cameron Simpson]

On 10Oct2018 20:25, Philip Martin  wrote:

Steven, that's a great idea, and I would be 100% up for your suggestion to
have types.MappingProxyType renamed to frozendict.


I'm not for the rename, myself. Though I'd not be against a frozendict 
factory in builtins, a tiny shim for MappingProxyType.



However, the differences
in the behavior of MappingProxyType's constructor versus dict's would make
the API's behavior confusing IMO. For example, MappingProxyType(x=5, y=10)
throws a TypeError. I don't think most people would expect this.


Well, if it were called frozendict, indeed not. It should act like dict.

So:

 def frozendict(**kw):
 return MappingProxyType(kw)

You could make an argument for that (or a slightly heftier version 
accepting the various things dict accepts). Or... you could just keep 
such a thing in your personal kit as a trivial way to spell 
"frozendict". One could argue for the above as a nice example to live in 
the docs perhaps.


But not everything needs a special name.

Cheers,
Cameron Simpson 
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Revisiting Immutable Mappings

[Philip Martin]

It would help over using a regular dict as a default argument to a function
by preventing accidental mutation of the default or constant mapping. This
is a quickly contrived example of the convert_price function now having a
side effect by changing the translation_map.

from unicodedata import normalize
prices = [{'croissant': 1}, {'coffee': 3}]
translation_map = {'apple': 'pomme',  'coffee': 'café'}
def normalize_text(s):
return normalize('NFD', s).encode('ascii', 'ignore').decode("utf-8")

def usd_to_eur(v):
return v / 1.2

def passthrough(v):
return v

def convert_price(record, convert_map=translation_map):
# remove accents for price mapping. Oops!
for key, value in convert_map.items():
convert_map[key] = normalize_text(value)

record = {
convert_map[k]: usd_to_eur(v) for k, v in record.items()
}
return record

On Wed, Oct 10, 2018 at 6:24 PM Steven D'Aprano  wrote:

> Hi Philiip, and welcome,
>
> On Wed, Oct 10, 2018 at 12:04:48PM -0500, Philip Martin wrote:
>
> > I generally have used MappingProxyType as a way to set default mapping
> > to a function or to set an empty mapping to a function.
>
> > I've created a gist with an example use case:
> >
> > https://gist.github.com/pmart123/493edf84d9aa61691ca7321325ebb6ab
>
> Please try to keep the discussion in one place (i.e. here), for the
> benefit of the archives and for those who have email access but not
> unrestricted web access.
>
> Can you explain (in English) your use-case, and why MappingProxyType
> isn't suitable? If it *is* suitable, how does your proposal differ?
>
> If the only proposal is to rename types.MappingProxyType to a builtin
> "frozendict", that's one thing; if the proposal is something else, you
> should explain what.
>
>
> > I've included an example of what code typically looks like when using
> > MappingProxyType and what it could look like with a
> > frozendict implementation.
>
> Wouldn't that be just:
>
> from types import MappingProxyType as frozendict
> d = frozendict({'spam': 1, 'eggs': 2})
>
> versus:
>
> d = frozendict({'spam': 1, 'eggs': 2})
>
> Apart from the initial import, how would they be different? You want a
> frozendict; the existing MappingProxyType provides a frozendict (with a
> surprising name, but never mind...). Wouldn't you use them exactly the
> same way? They both (I presume) offer precisely the same read-only
> access to the mapping interface.
>
>
>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Revisiting Immutable Mappings

[Philip Martin]

Steven, that's a great idea, and I would be 100% up for your suggestion to
have types.MappingProxyType renamed to frozendict. However, the differences
in the behavior of MappingProxyType's constructor versus dict's would make
the API's behavior confusing IMO. For example, MappingProxyType(x=5, y=10)
throws a TypeError. I don't think most people would expect this.

MappingProxyType to me though does seem to be a non-obvious name compared
to say frozenset as you have mentioned. Plus, it's included in a module
that I would say is very low level alongside functions like prepare_class,
new_class, etc.



On Wed, Oct 10, 2018 at 6:24 PM Steven D'Aprano  wrote:

> Hi Philiip, and welcome,
>
> On Wed, Oct 10, 2018 at 12:04:48PM -0500, Philip Martin wrote:
>
> > I generally have used MappingProxyType as a way to set default mapping
> > to a function or to set an empty mapping to a function.
>
> > I've created a gist with an example use case:
> >
> > https://gist.github.com/pmart123/493edf84d9aa61691ca7321325ebb6ab
>
> Please try to keep the discussion in one place (i.e. here), for the
> benefit of the archives and for those who have email access but not
> unrestricted web access.
>
> Can you explain (in English) your use-case, and why MappingProxyType
> isn't suitable? If it *is* suitable, how does your proposal differ?
>
> If the only proposal is to rename types.MappingProxyType to a builtin
> "frozendict", that's one thing; if the proposal is something else, you
> should explain what.
>
>
> > I've included an example of what code typically looks like when using
> > MappingProxyType and what it could look like with a
> > frozendict implementation.
>
> Wouldn't that be just:
>
> from types import MappingProxyType as frozendict
> d = frozendict({'spam': 1, 'eggs': 2})
>
> versus:
>
> d = frozendict({'spam': 1, 'eggs': 2})
>
> Apart from the initial import, how would they be different? You want a
> frozendict; the existing MappingProxyType provides a frozendict (with a
> surprising name, but never mind...). Wouldn't you use them exactly the
> same way? They both (I presume) offer precisely the same read-only
> access to the mapping interface.
>
>
>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Revisiting Immutable Mappings

[Steven D'Aprano]

Hi Philiip, and welcome,

On Wed, Oct 10, 2018 at 12:04:48PM -0500, Philip Martin wrote:

> I generally have used MappingProxyType as a way to set default mapping 
> to a function or to set an empty mapping to a function.

> I've created a gist with an example use case:
> 
> https://gist.github.com/pmart123/493edf84d9aa61691ca7321325ebb6ab

Please try to keep the discussion in one place (i.e. here), for the 
benefit of the archives and for those who have email access but not 
unrestricted web access.

Can you explain (in English) your use-case, and why MappingProxyType 
isn't suitable? If it *is* suitable, how does your proposal differ?

If the only proposal is to rename types.MappingProxyType to a builtin 
"frozendict", that's one thing; if the proposal is something else, you 
should explain what.


> I've included an example of what code typically looks like when using
> MappingProxyType and what it could look like with a
> frozendict implementation.

Wouldn't that be just:

from types import MappingProxyType as frozendict
d = frozendict({'spam': 1, 'eggs': 2})

versus:

d = frozendict({'spam': 1, 'eggs': 2})

Apart from the initial import, how would they be different? You want a 
frozendict; the existing MappingProxyType provides a frozendict (with a 
surprising name, but never mind...). Wouldn't you use them exactly the 
same way? They both (I presume) offer precisely the same read-only 
access to the mapping interface.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Revisiting Immutable Mappings

[Michael Selik]

How does a frozendict help in that example? It's not obvious to me.

Despite not understanding that example, I'm +1 for having a frozendict. I
don't think it'll increase cognitive load much, as it'll sit right next to
frozenset when someone reads the builtins in alphabetical order. In my own
experience, I want to use a dict as a dict key about once or twice a year.
It'd be nice to have a quick way to convert to a frozendict.

On Wed, Oct 10, 2018 at 10:05 AM Philip Martin 
wrote:

> Hi, I first want to thank everyone in the community for the contributions
> over the years. I know the idea of a frozendict has been proposed before
> and rejected. I have a use case for a frozendict implementation that to my
> knowledge was not discussed during previous debates. My reasoning for a
> frozendict class stems from patterns I typically see arise when performing
> ETL or data integrations and conversions. I generally have used
> MappingProxyType as a way to set default mapping to a function or to set an
> empty mapping to a function. I've created a gist with an example use case:
>
> https://gist.github.com/pmart123/493edf84d9aa61691ca7321325ebb6ab
>
> I've included an example of what code typically looks like when using
> MappingProxyType and what it could look like with a
> frozendict implementation. I believe this use case may also be
> under-reported in open source code as it often crops up when integrating
> third-party data sources, which at times can't be open sourced due to
> licensing issues. I would love to hear if anyone has used MappingProxyType
> in a similar manner, or if this use case could help warrant a frozendict in
> the standard library.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] async unittest.TestCase

[Serhiy Storchaka]

10.10.18 20:19, Yury Selivanov пише:

Thanks for proposing this.  Yes, it makes sense to have
unittest.AsyncTestCase in 3.8.  AFAIK Lisa Roach (copied) was working
on that (as well as on async Mock object), but I'm not sure what's the
status of her work.  I suggest to search for an open issue for this on
bugs.python.org; if there's none, please create one.  And let's make
this happen.


https://bugs.python.org/issue32972
https://bugs.python.org/issue26467

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] async unittest.TestCase

[Yury Selivanov]

Thanks for proposing this.  Yes, it makes sense to have
unittest.AsyncTestCase in 3.8.  AFAIK Lisa Roach (copied) was working
on that (as well as on async Mock object), but I'm not sure what's the
status of her work.  I suggest to search for an open issue for this on
bugs.python.org; if there's none, please create one.  And let's make
this happen.

Yury
On Wed, Oct 10, 2018 at 7:11 AM David Shawley  wrote:
>
> Hi everyone and good morning to some of you,
>
> Since asyncio and the async/await syntax are both part of Python, I think
> that we should extend TestCase to support it.  The simplest solution that
> I can think of is to create unittest.AsyncTestCase sub-class with the
> following extensions:
>
>  - create a new event loop and install it in AsyncTestCase.run
>  - make it possible for setUp, tearDown, and test methods to be async
>by calling asyncio.iscoroutinefunction
>
> I wrote my own in a local test before noticing that Martin Richard had
> already written and published asynctest [1].  Since then I found the
> following projects as well:
>
>  - https://github.com/kwarunek/aiounittest
>  - https://github.com/pytest-dev/pytest-asyncio
>
> I think that the community as a whole would benefit from basic support in
> unittest for async/await test "user methods".  I am personally fond of the
> approach of extending unittest.TestCase in asynctest [2] over some of the
> other approaches.
>
> Is this something that we want in our Standard Library?
>
> - dave
> --
> [1]: https://github.com/Martiusweb/asynctest
> [2]: https://github.com/Martiusweb/asynctest/blob/master/asynctest/case.py
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
 Yury
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Paul Romer, 2018 Economics Nobel Laureate, uses Python and Jupyter

[Jonathan Fine]

Geoffrey Spear wrote:

> Is there an idea for Python hidden somewhere in this message?

Thank you, Geoffrey, for pointing this out. I'd have done better to
prefixed the title with OFF-TOPIC. That would have been more polite.

To answer your question: Django created a new community of Python
users. As did, for example, NumPy, Raspberry Pi, SciPy and other
worthy examples, such as PyData.

Python, in part because of the shared experience we have on this list,
has made many good decisions that work well across the board. I think
we're pragmatic, and concerned about our users. Paul Romer's Nobel
Prize draws attention to an emerging new community.

I don't mean economics. I mean scholarly publishing. See:

https://paulromer.net/jupyter-mathematica-and-the-future-of-the-research-paper/
https://www.nature.com/articles/d41586-018-01322-9 # Future of online publishing

By the way, back in the 1980s TeX and LaTeX were the future of STEM
publishing. I think Jupyter is well placed to be 'the Django of STEM
publishing', or if you prefer 'the LaTeX of the 2020s'. Things change.

The relevance to this list? Off-topic, but I hope adding to our shared
relevant background knowledge.

I will try to remember the OFF-TOPIC in future.

-- 
Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Revisiting Immutable Mappings

[Philip Martin]

Hi, I first want to thank everyone in the community for the contributions
over the years. I know the idea of a frozendict has been proposed before
and rejected. I have a use case for a frozendict implementation that to my
knowledge was not discussed during previous debates. My reasoning for a
frozendict class stems from patterns I typically see arise when performing
ETL or data integrations and conversions. I generally have used
MappingProxyType as a way to set default mapping to a function or to set an
empty mapping to a function. I've created a gist with an example use case:

https://gist.github.com/pmart123/493edf84d9aa61691ca7321325ebb6ab

I've included an example of what code typically looks like when using
MappingProxyType and what it could look like with a
frozendict implementation. I believe this use case may also be
under-reported in open source code as it often crops up when integrating
third-party data sources, which at times can't be open sourced due to
licensing issues. I would love to hear if anyone has used MappingProxyType
in a similar manner, or if this use case could help warrant a frozendict in
the standard library.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Paul Romer, 2018 Economics Nobel Laureate, uses Python and Jupyter

[Geoffrey Spear]

On Wed, Oct 10, 2018 at 11:29 AM Jonathan Fine  wrote:

> Terry Reedy wrote (to comp.lang.python)
>
> >
> https://paulromer.net/jupyter-mathematica-and-the-future-of-the-research-paper/
> > Jupyter, Mathematica, and the Future of the Research Paper
> > Paul Romer, new Nobel prize winner in economics, for research on how
> > ideas interact with economic growth, explained last April why he has
> > switched from Mathematica to Jupyter.
>
> Well done, Terry, for spotting this. I hope you don't mind, I've
> changed the subject to give Paul Romer star billing. I think he
> deserves it.
>
> Here's some URLs on Romer and Python.
>
>
> https://qz.com/1417145/economics-nobel-laureate-paul-romer-is-a-python-programming-convert/
>
> https://developers.slashdot.org/story/18/10/09/0042240/economics-nobel-laureate-paul-romer-is-a-python-programming-convert
>
> https://www.reddit.com/r/Python/comments/9mhxq2/this_years_nobel_prize_in_economics_was_awarded/
>
> https://news.ycombinator.com/item?id=18173812=hvper.com_source=hvper.com_medium=website
>
> https://www.wsj.com/articles/nobel-in-economics-goes-to-american-pair-1538992672
>
> And some related URLs
>
> https://www.nature.com/articles/d41586-018-01322-9 # Future of online
> publishing
> https://pypi.org/project/nobel/ # Python interface to Nobel Prize API!
>
> https://jfine2358.github.io/slides/2018-nature-jupyter-altair-vega-binder.html
>
> And some Python code:
>
> >>> import nobel
> >>> api = nobel.Api()
> >>> api.prizes.filter(year=2018,
> category='economics')[0].laureates[1].surname
> u'Romer'
>
>
>
Is there an idea for Python hidden somewhere in this message?
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Paul Romer, 2018 Economics Nobel Laureate, uses Python and Jupyter

[Jonathan Fine]

Terry Reedy wrote (to comp.lang.python)

> https://paulromer.net/jupyter-mathematica-and-the-future-of-the-research-paper/
> Jupyter, Mathematica, and the Future of the Research Paper
> Paul Romer, new Nobel prize winner in economics, for research on how
> ideas interact with economic growth, explained last April why he has
> switched from Mathematica to Jupyter.

Well done, Terry, for spotting this. I hope you don't mind, I've
changed the subject to give Paul Romer star billing. I think he
deserves it.

Here's some URLs on Romer and Python.

https://qz.com/1417145/economics-nobel-laureate-paul-romer-is-a-python-programming-convert/
https://developers.slashdot.org/story/18/10/09/0042240/economics-nobel-laureate-paul-romer-is-a-python-programming-convert
https://www.reddit.com/r/Python/comments/9mhxq2/this_years_nobel_prize_in_economics_was_awarded/
https://news.ycombinator.com/item?id=18173812=hvper.com_source=hvper.com_medium=website
https://www.wsj.com/articles/nobel-in-economics-goes-to-american-pair-1538992672

And some related URLs

https://www.nature.com/articles/d41586-018-01322-9 # Future of online publishing
https://pypi.org/project/nobel/ # Python interface to Nobel Prize API!
https://jfine2358.github.io/slides/2018-nature-jupyter-altair-vega-binder.html

And some Python code:

>>> import nobel
>>> api = nobel.Api()
>>> api.prizes.filter(year=2018, category='economics')[0].laureates[1].surname
u'Romer'

-- 
Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] async unittest.TestCase

[David Shawley]

Hi everyone and good morning to some of you,

Since asyncio and the async/await syntax are both part of Python, I think
that we should extend TestCase to support it.  The simplest solution that
I can think of is to create unittest.AsyncTestCase sub-class with the
following extensions:

 - create a new event loop and install it in AsyncTestCase.run
 - make it possible for setUp, tearDown, and test methods to be async
   by calling asyncio.iscoroutinefunction

I wrote my own in a local test before noticing that Martin Richard had
already written and published asynctest [1].  Since then I found the
following projects as well:

 - https://github.com/kwarunek/aiounittest 

 - https://github.com/pytest-dev/pytest-asyncio 


I think that the community as a whole would benefit from basic support in
unittest for async/await test "user methods".  I am personally fond of the
approach of extending unittest.TestCase in asynctest [2] over some of the
other approaches.

Is this something that we want in our Standard Library?

- dave
--
[1]: https://github.com/Martiusweb/asynctest 

[2]: https://github.com/Martiusweb/asynctest/blob/master/asynctest/case.py 
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] add a time decorator to timeit.py

[Anders Hovmöller]

> On 7 Oct 2018, at 22:44, Guido van Rossum  wrote:
> 
> So someone ought to submit a PR that adds (brief) documentation for this, 
> with reference to this thread.

I was trying to write this documentation when I noticed that the docs already 
mention this! "The stmt and setup parameters can also take objects that are 
callable without arguments." Maybe we should reword this? Obviously many people 
here have looked at the docs and not spotted it.

I'll post a PR with lambda examples under "Basic Examples", I think this should 
make people take notice of this feature.

/ Anders

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/