[Python-ideas] Re: Curious : Why staticmethod if classmethods can do everything a static method can?
On Sun, Sep 13, 2020 at 12:32:54AM -0400, Random832 wrote: > This isn't what I was suggesting - I meant something like this: > > class instancemethod: > def __init__(self, wrapped): > self.wrapped = wrapped > def __get__(self, obj, objtype): > if obj is None: return self.wrapped > else: return MethodType(self.wrapped, obj) > > this wouldn't be useful for functions, but would give other callables > the same functionality as functions, automatically creating the bound > method object, e.g.: > > class D: > def __init__(self, obj, *args): ... > > class C: > foo = instancemethod(D) You want a method which does absolutely nothing at all but delegate to a class constructor or callable object (but not a function), with no docstring and no pre-processing of arguments or post-processing of the result. Seems like an awfully small niche for this to be in the stdlib. But having said that, I might have a use for that too. Except... I would need a docstring. And pre- and post-processing. Hmmm. *shrug* Seems to me that this might be useful in theory, but in practice we might never use it, preferring this instead: class C: def foo(self, *args): """Doc string.""" return D(self, *args) with appropriate pre- and post-processing as needed. Interesting suggestion though, I may have to play around with it. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QKAA54IV2WDEEWN354PK3JPSPIAMRGD2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Curious : Why staticmethod if classmethods can do everything a static method can?
On Sat, Sep 12, 2020, at 23:14, Steven D'Aprano wrote: > We already have an instancemethod, it's just spelled differently: > > py> from types import MethodType > > > And while it is not useful as a decorator, it is *really* useful for > adding methods to an individual instance rather than the class: This isn't what I was suggesting - I meant something like this: class instancemethod: def __init__(self, wrapped): self.wrapped = wrapped def __get__(self, obj, objtype): if obj is None: return self.wrapped else: return MethodType(self.wrapped, obj) this wouldn't be useful for functions, but would give other callables the same functionality as functions, automatically creating the bound method object, e.g.: class D: def __init__(self, obj, *args): ... class C: foo = instancemethod(D) obj = C() obj.foo(...) # D(obj, ...) Same for other types of callables such as functools.partial objects etc. > So an instancemethod decorator would be a waste of time, but the > instancemethod type, spelled types.MethodType, is very useful. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CYBMRSMOQOKSYELNW7AZ36WL3W23RD5Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
Indeed the usual definition of isnan reads: def isnan(x): return x != x ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CPDLKMXMX74MIA5QFGJK2ZH6LLKB52Q3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Curious : Why staticmethod if classmethods can do everything a static method can?
On Sat, Sep 12, 2020 at 07:25:30PM -0400, Eric V. Smith wrote:
> On 9/12/2020 7:13 PM, Random832 wrote:
> >On Fri, Sep 11, 2020, at 19:57, Cameron Simpson wrote:
> >>The default (an instance method) requires "self" to perform.
> >Of course, this is only the default if the method is a function object. If
> >it is a different callable class, the default is effectively staticmethod.
> >
> >Perhaps there should be an @instancemethod?
>
> What would that let us do that we can't currently achieve?
We already have an instancemethod, it's just spelled differently:
py> from types import MethodType
And while it is not useful as a decorator, it is *really* useful for
adding methods to an individual instance rather than the class:
py> class K:
... pass
...
py> obj = K()
py> obj.method = lambda self, x: (self, x)
py> obj.method('arg') # Fails
Traceback (most recent call last):
File "", line 1, in
TypeError: () missing 1 required positional argument: 'x'
But this works:
py> obj.method = MethodType(lambda self, x: (self, x), obj)
py> obj.method('arg')
(<__main__.K object at 0x7f67a4e051d0>, 'arg')
So an instancemethod decorator would be a waste of time, but the
instancemethod type, spelled types.MethodType, is very useful.
--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/D24PW37YSIHV2XHNHARQLM4EMHH6GQKD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On Sat, Sep 12, 2020 at 02:09:11PM -1000, David Mertz wrote: > On Sat, Sep 12, 2020, 2:02 PM Steven D'Aprano wrote: > > > In general though, Python doesn't support generating the full range of > > NANs with payloads directly. > > > I've researched this a little bit for discussion in a book I'm writing, and > I have not been able to identify ANY widely used programming language or > tool that does anything meaningful with the NaN payloads. > > It's possible I've missed something, but certainly not the top 20 languages > are libraries that might come to mind. Alas, NAN payloads have been under-utilized. It has been a vicious circle: programming languages have, in general, not supported setting the payload, or any consistent meaning for them, so people don't use the feature, so programming languages don't support it, so people don't use it, and so on... But back in the early 1990s, when IEEE-754 was brand new, one of the first platforms to support it was Apple's SANE (Standard Apple Numerics Environment), and they not only supported NAN payloads, but defined standard meanings for them. So Apple's maths libraries would parse strings like "NAN(123)" (by memory) and return the NAN with payload 123. Printing NANs would display the payload. And you could use the payload information to help debug what failed, e.g. NANSQRT = 1 # invalid square root NANADD = 2 # invalid addition, e.g. INF + (-INF) But when Apple moved their SANE maths libraries out of software and into the Motorola floating point chip, that was all lost. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WHKXWQSSPIG2ZGLXCNFVOKB35KFIAWGM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On Sat, Sep 12, 2020 at 05:37:23PM -0700, Christopher Barker wrote: > On Sat, Sep 12, 2020 at 5:05 PM Steven D'Aprano wrote: > > IEEE-754 requires that float literals overflow to infinity. > > sure, which means that, e.g. 1e100 * 1e300 would overflow to Inf. > > But that doesn't say anything about interpreting a literal. I don't if C > libs necessarily parse: Sorry, I didn't explain correctly. What I attempted, but failed, to say is that the standard requires that if the float literal cannot be represented as a numeric value because it would overflow, then it should be interpreted as an infinity. So `1e300` can be represented as a double precision float, so that's what you get, but `1e1000` cannot be, it overflows, so you get infinity instead. This doesn't mean that the standard requires the parser to read the mantissa and exponent separately and actually perform a multiplication and power. I expect that the standard will require *correctly rounded* results. So for example, this literal rounds down to the largest possible finite float: py> 1.7976931348623158e+308 1.7976931348623157e+308 but this literal rounds up to infinity: py> 1.7976931348623159e+308 inf because the closest representable binary number to 1.79...159e+308 would overflow the available bits. > So that's what I'm wondering -- is there a standard that says the a > too-large literal should overflow, and therefgor create and inf, rather > than being an error. Yep, that's what I'm saying :-) Or at least tried to say. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WSNITPXWL2J2EZK35VU4EBRONDDXQDJY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On 9/12/20 8:48 PM, Paul Bryan wrote: > I meant to ask, why is nan not comparable? Even: > > >>> math.nan == math.nan > False It's the IEEE definition of nan, a nan will compare unequal to ALL values, even another nan. It is also neither greater than or less than any value. -- Richard Damon ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MPNZG6PXMDDLLCLMPL5R53JLPSMG2FGE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
I meant to ask, why is nan not comparable? Even: >>> math.nan == math.nan False ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/AIKVPIUWFZW5HY5LYWYMOKSFFLH3ZFV7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On Sun, 2020-09-13 at 10:01 +1000, Steven D'Aprano wrote: > If you have an INF, then you can generate a NAN with `INF - INF`. >>> math.inf - math.inf nan >>> (math.inf - math.inf) == math.nan False ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BGW7ZX6RUKF2C4K7HPAVLWRIOYDIRKIQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On Sat, Sep 12, 2020 at 5:05 PM Steven D'Aprano wrote: > On Sat, Sep 12, 2020 at 12:56:25PM -0700, Christopher Barker wrote: > > > Is there any guarantee in Python or the C spec, or the IEEE spec that, > e.g.: > > 1e1 > > would create an Inf value, rather than an error of some sort? > > IEEE-754 requires that float literals overflow to infinity. > sure, which means that, e.g. 1e100 * 1e300 would overflow to Inf. But that doesn't say anything about interpreting a literal. I don't if C libs necessarily parse: xxEyy and then do xx * 10**yy, which would be an overflow, or if they do something more direct, in which case, they *could* note that the value is not representable and raise an error. So that's what I'm wondering -- is there a standard that says the a too-large literal should overflow, and therefgor create and inf, rather than being an error. by the way, this behavior is not consistent with python, which will give an error, rather than returning inf when the same operation overflows: In [22]: math.pow(10, 1000) --- OverflowError Traceback (most recent call last) in > 1 math.pow(10, 1000) OverflowError: math range error So in Python, at least, interpreting the literal is not the same as computing the pow(). -CHB > I don't have a source for this (I cannot find a copy of the IEEE-754 > standard except behind paywalls) but I have a very strong memory of > either Tim Peters and Mark Dickinson stating this, and I believe them. > (If either of them are reading this, please confirm or deny.) > > > > And there's still NaN -- any way to get that with a literal? > > If you have an INF, then you can generate a NAN with `INF - INF`. > > In general though, Python doesn't support generating the full range of > NANs with payloads directly. > > > > -- > Steve > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/LX5XVAN3FZCXBBHVKU6MGKWXZAS63Y2D/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HIGHOUUIA7G4CL5EO43TMYXX56QR5ZTV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
I probably should have added "user exposed" or something to my comment. Those extra bits certainly seem to offer compiler optimization possibilities, as apparently SpiderMonkey does with WASM. I can easily *imagine* a library like NumPy or PyTorch deciding to expose something useful with those 52 unused mantissa bits. But that's some future version, if ever. On Sat, Sep 12, 2020, 2:16 PM Cade Brown wrote: > As per tagged nans, check for JavaScript tagged NaN optimization. > Essentially, the tag of the NaN (i.e. the mantissa) is interpreted as a > pointer. Obviously, this is a very advanced use case, probably not worth > Python guaranteeing such behavior. > Here is one article: > https://brionv.com/log/2018/05/17/javascript-engine-internals-nan-boxing/ > > On Sat, Sep 12, 2020, 8:10 PM David Mertz wrote: > >> On Sat, Sep 12, 2020, 2:02 PM Steven D'Aprano >> wrote: >> >>> In general though, Python doesn't support generating the full range of >>> NANs with payloads directly. >> >> >> I've researched this a little bit for discussion in a book I'm writing, >> and I have not been able to identify ANY widely used programming language >> or tool that does anything meaningful with the NaN payloads. >> >> It's possible I've missed something, but certainly not the top 20 >> languages are libraries that might come to mind. >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/FZ7QGRV5IRV2WFX6YFDO7KR5C2Y5BJHG/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DL62J56XOFI6Z4SJ23NYF5VQGMDHK2KU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
As per tagged nans, check for JavaScript tagged NaN optimization. Essentially, the tag of the NaN (i.e. the mantissa) is interpreted as a pointer. Obviously, this is a very advanced use case, probably not worth Python guaranteeing such behavior. Here is one article: https://brionv.com/log/2018/05/17/javascript-engine-internals-nan-boxing/ On Sat, Sep 12, 2020, 8:10 PM David Mertz wrote: > On Sat, Sep 12, 2020, 2:02 PM Steven D'Aprano wrote: > >> In general though, Python doesn't support generating the full range of >> NANs with payloads directly. > > > I've researched this a little bit for discussion in a book I'm writing, > and I have not been able to identify ANY widely used programming language > or tool that does anything meaningful with the NaN payloads. > > It's possible I've missed something, but certainly not the top 20 > languages are libraries that might come to mind. > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/FZ7QGRV5IRV2WFX6YFDO7KR5C2Y5BJHG/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HEWH35252NLRDWWFU3TFAH7FWCPR4FJZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On Sat, Sep 12, 2020, 2:02 PM Steven D'Aprano wrote: > In general though, Python doesn't support generating the full range of > NANs with payloads directly. I've researched this a little bit for discussion in a book I'm writing, and I have not been able to identify ANY widely used programming language or tool that does anything meaningful with the NaN payloads. It's possible I've missed something, but certainly not the top 20 languages are libraries that might come to mind. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FZ7QGRV5IRV2WFX6YFDO7KR5C2Y5BJHG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On Sat, Sep 12, 2020 at 12:56:25PM -0700, Christopher Barker wrote: > Is there any guarantee in Python or the C spec, or the IEEE spec that, e.g.: > > 1e1 > > would create an Inf value, rather than an error of some sort? IEEE-754 requires that float literals overflow to infinity. I don't have a source for this (I cannot find a copy of the IEEE-754 standard except behind paywalls) but I have a very strong memory of either Tim Peters and Mark Dickinson stating this, and I believe them. (If either of them are reading this, please confirm or deny.) > And there's still NaN -- any way to get that with a literal? If you have an INF, then you can generate a NAN with `INF - INF`. In general though, Python doesn't support generating the full range of NANs with payloads directly. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LX5XVAN3FZCXBBHVKU6MGKWXZAS63Y2D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Curious : Why staticmethod if classmethods can do everything a static method can?
On 9/12/2020 7:13 PM, Random832 wrote: On Fri, Sep 11, 2020, at 19:57, Cameron Simpson wrote: The default (an instance method) requires "self" to perform. Of course, this is only the default if the method is a function object. If it is a different callable class, the default is effectively staticmethod. Perhaps there should be an @instancemethod? What would that let us do that we can't currently achieve? Eric ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/Z27KHJZZTVMJFCBGO5Z6VJRAJHZYZ2YD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Curious : Why staticmethod if classmethods can do everything a static method can?
On Fri, Sep 11, 2020, at 19:57, Cameron Simpson wrote: > The default (an instance method) requires "self" to perform. Of course, this is only the default if the method is a function object. If it is a different callable class, the default is effectively staticmethod. Perhaps there should be an @instancemethod? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5ZMYQ33BPI2VNWADQIBSGD4NVLXI4SQF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
not really relevant anyway, but the issue with using a really large literal
to get Infinity is not that some possible future system could hold really
huge numbers, but whether a too-large-for-the-implimentation literal get
evaluated as Inf at all.
Is there any guarantee in Python or the C spec, or the IEEE spec that, e.g.:
1e1
would create an Inf value, rather than an error of some sort?
It apparently works in all cases anyone in this thread has tried (and me
too), but is it guaranteed anywhere?
And there's still NaN -- any way to get that with a literal?
-CHB
On Sat, Sep 12, 2020 at 10:34 AM Steven D'Aprano
wrote:
> On Sat, Sep 12, 2020 at 11:06:35AM -0400, Cade Brown wrote:
> > If, in the future, Python used a library such as MPFR and made all
> floats a
> > given precision (say, by giving a flag to the interpreter "python
> > -prec2048"), it would never be enough to make infinity because it only
> has
> > the limitation of a 64 bit exponent.
>
> Nobody is recommending that the best way to create an infinity is by
> writing 1e1000 or whatever other out of range number you choose.
> We're not using Python 2.4 anymore, and the correct ways to create an
> infiniy float is one of:
>
> float('inf')
> from math import inf
>
> (Or rather, most of us aren't using Python 2.4 anymore. For my sins, I
> am still maintaining code that is expected to run back to 2.4. Yay.)
>
> Using something like 1e1000 (or choose a larger exponent) is a fall back
> for when nothing else works, and if that trick doesn't work either, then
> you have no hope for it, you are running on some weird machine without
> IEEE-754 semantics and there probably isn't an infinity at all.
>
> In my own code I have something like this:
>
>
> try:
> from math import inf
> except ImportError:
> try:
> inf = float('inf')
> except ValueError:
> # Could be Windows in 2.4 or 2.5?
> try:
> inf = float('1.#INF')
> except ValueError:
> # Desperate times require desperate measures.
> try:
> inf = 1e1000
> assert inf > 0 and inf == 2*inf
> except (OverflowError, AssertionError):
> # Just give up, there is no infinity available.
> pass
>
>
> Fortunately, I don't have to support some hypothetical future Python
> with 2048 bit non-IEEE-754 floats, but if I did, I'm sure that the
> import from math would work and the rest of the nested blocks would
> never be called.
>
>
> > This is just an example of course, probably won't happen, but when I read
> > "1e1000" or such a number it doesn't strike me as infinite (although a
> > particular version of IEEE floating point may consider it that), it
> strikes
> > me as a lazy programmer who thinks it's bigger than any other number he's
> > processing.
>
> Well, I guess the code above makes me a lazy programmer.
>
>
> --
> Steve
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/NH7O6ABMAZBTA7WOGS4NMTW3C65EYBC6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/JKZD3SZYFJHF35KQBLA5MKFVFJCYBMGR/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf
On Sat, Sep 12, 2020 at 1:40 AM Serhiy Storchaka wrote: > Second, the resulting function would have monstrous interface. open() > takes 8 arguments, well, maybe not -- this would not need to support the entire open() interface: * No one is suggesting getting rid of the current load() function, so if you need to do something less common, you can always open the file yourself. * Many of the options to open() should be always the same when reading/writing json. In fact, that's (IMHO) the most compelling reason to have this built in -- the defaults may be not ideal for JSON, and other specs may be downright wrong. Here they are all eight parameters. mode='r' : this should be either 'r' or 'w' depending on loading or saving, I don't think there's any other (certainly not common) use case for any other mode. buffering=-1 : This seems very reasonable to put in control of the JSON encoder/decoder encoding=None: this is the important one -- json is always UTF-8 yes? errors=None: This also is good ot be in control of the JSON encoder/decoding newline=None: also in control of the encoder closefd=True: I think this is irrelevant to this use case. opener=None: Also does not need to be supported If I have this right, then none of the optional arguments to open() would need to be passed through. > they should be combined. And thank that open() does not accept arbitrary > var-keyword arguments as json.load(), resolving this conflict would be > impossible. > see above -- there is no conflict to resolve. > Third, this combination is not so common as you think. agreed -- but still fairly common. And most of the use cases that aren't file-on-disk are strings anyway. I know I use file-on-disk most of the time I use .load()/dump(), even if I use .loads()/dumps() more frequently. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VVBF7PRFOZTDBBANGQZBBDSQH5BCJMTR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf
On Sat, Sep 12, 2020 at 5:29 AM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > See Naoki Inada's post for why this might be a good idea even though > it's a three-line function. It's not open and shut (for one thing, on > most modern systems the system default encoding is already UTF-8), Actually that fact is the most compelling reason to do this -- since many (most) development systems use UTF-* by default then if you leave the encoding out, your code will work most of the time, pass tests, pass test on the CI, etc, and then barf when it's run on an unusual system. I have to say that I"m not at all sure that I've remembered to set the encoding in my code that reads/writes JSON from files. Time to go check. In fact, I'm getting bytes/str errors in JSON related parts of code I'm porting to py3 right now. This is probably related. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/J2MSDYPNMAWVP5EA6L3LZY6TQNIVNOFP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Curious : Why staticmethod if classmethods can do everything a static method can?
On 9/11/20 7:35 PM, Christopher Barker wrote: - > But the real question is why staticmethod at all? > > And the answer is that there is very little use for staticmethod in > Python [...] On 9/11/20 7:28 PM, Greg Ewing wrote: - > IMO, static methods are a kludge only needed in languages that make > classes do double duty as modules, and also can't have class methods > because classes aren't first-class objects. - I have a base class that holds the logic for converting from one data system to another. The module that holds this base class also imports several utility functions from other places. The subclasses that hold the unique code occasionally have to overwrite/extend some of the base class methods, which means also needing to import the utility functions (the subclasses live in different files). Rather than having to keep track of the various utility methods, including adding more imports if the base class uses more with new functionality, I just get_fis_table = staticmethod(fisData) get_xid_records = staticmethod(get_xid_records) and then the subclasses can do blah = self.get_xid_records(...) without worrying where `get_xid_records` came from. Without `staticmethod` I would have to have a thin wrapper around those utility methods -- obviously not insurmountable, but annoying; and I really like that Python is not usually annoying. -- ~Ethan~ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/B7Q64WDU6EN235SWQX44CJ36XBUSJ3DH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On Sat, Sep 12, 2020 at 11:06:35AM -0400, Cade Brown wrote:
> If, in the future, Python used a library such as MPFR and made all floats a
> given precision (say, by giving a flag to the interpreter "python
> -prec2048"), it would never be enough to make infinity because it only has
> the limitation of a 64 bit exponent.
Nobody is recommending that the best way to create an infinity is by
writing 1e1000 or whatever other out of range number you choose.
We're not using Python 2.4 anymore, and the correct ways to create an
infiniy float is one of:
float('inf')
from math import inf
(Or rather, most of us aren't using Python 2.4 anymore. For my sins, I
am still maintaining code that is expected to run back to 2.4. Yay.)
Using something like 1e1000 (or choose a larger exponent) is a fall back
for when nothing else works, and if that trick doesn't work either, then
you have no hope for it, you are running on some weird machine without
IEEE-754 semantics and there probably isn't an infinity at all.
In my own code I have something like this:
try:
from math import inf
except ImportError:
try:
inf = float('inf')
except ValueError:
# Could be Windows in 2.4 or 2.5?
try:
inf = float('1.#INF')
except ValueError:
# Desperate times require desperate measures.
try:
inf = 1e1000
assert inf > 0 and inf == 2*inf
except (OverflowError, AssertionError):
# Just give up, there is no infinity available.
pass
Fortunately, I don't have to support some hypothetical future Python
with 2048 bit non-IEEE-754 floats, but if I did, I'm sure that the
import from math would work and the rest of the nested blocks would
never be called.
> This is just an example of course, probably won't happen, but when I read
> "1e1000" or such a number it doesn't strike me as infinite (although a
> particular version of IEEE floating point may consider it that), it strikes
> me as a lazy programmer who thinks it's bigger than any other number he's
> processing.
Well, I guess the code above makes me a lazy programmer.
--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/NH7O6ABMAZBTA7WOGS4NMTW3C65EYBC6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf
On 9/12/2020 12:05 PM, Greg Ewing wrote: > On 12/09/20 8:36 pm, Serhiy Storchaka wrote: >> it is not hard to write your >> own helper with interface and defaults that suit you. It will take less >> time than writing a letter in a mailing list. > > Obviously what's needed is an IDE feature such that whenever > you write a 3-line function that you haven't used before, it > automatically posts a request to python-ideas asking for it > to be added to the stdlib. Think of all the time it would > save! > Nah, don't stop there. All you need is an IDE feature that creates and merges a pull request. Just think how easy that would make it for Python to be everything to everyone. --Edwin ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RLHGTI3QNMYTSGUP5TRSTVKJL45PJZXI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf
On 12/09/20 8:36 pm, Serhiy Storchaka wrote: it is not hard to write your own helper with interface and defaults that suit you. It will take less time than writing a letter in a mailing list. Obviously what's needed is an IDE feature such that whenever you write a 3-line function that you haven't used before, it automatically posts a request to python-ideas asking for it to be added to the stdlib. Think of all the time it would save! -- Greg ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SAEDTBGJK6O5QNX4TTLIUH2AH34MXUMW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Curious : Why staticmethod if classmethods can do everything a static method can?
On 2020-09-12 at 14:07:57 +1000, Cameron Simpson wrote: > Dan, I should preface this by saying I don't substantially disagree > with you, I just work differently and want to show how and why. > The beauty here is that you have the same pattern of > classname.transcribe_value(value) to use whatever binary format you > want. And that's a static method because it doesn't need a class or > instance for context - it just transcribes the data. > > IMO, m.f has less cognitive load than m.X.f, at their definitions > > and at call sites. Full disclosure: I consider most of Object > > Oriented Programming to be extraneous cognitive noise. > > Whereas I use OOP a lot. Hugely. Maybe what I needed early on was a good example of a large, well designed OO piece of software to use as a role model. But the large non-OO systems seemed to be much better (in any number of ways, and please don't mistake me for implying that all non-OO systems are good) than the large OO ones. My habits and opinions are certainly shaped from my experience. Namespaces are one honking great idea. I¹ have modules, you¹ have classes. We¹ build software. Vive la différence! :-) > > In other languages (*cough* Java *cough*), there are no functions > > outside of classes, and static methods fill that role. > > Aye. I agree that is an example where static methods exist for > language definition reasons instead of functionality. OTOH, the > language design is deliberately like that to force encapsulation as a > universal approach, which has its own benefits in terms of side effect > limitation and code grouping, so there's an ulterior purpose there. Encapsulation is a good thing, OO or otherwise. Unless, of course, the code is behind an HTTP server and I can't see it from the outside. ¹ in the generic sense of the pronoun -- “Whoever undertakes to set himself up as a judge of Truth and Knowledge is shipwrecked by the laughter of the gods.” – Albert Einstein Dan Sommers, http://www.tombstonezero.net/dan ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/AGAZ6OEKE2TSNEMSMNCSCSS3EA5G3HIQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
If, in the future, Python used a library such as MPFR and made all floats a given precision (say, by giving a flag to the interpreter "python -prec2048"), it would never be enough to make infinity because it only has the limitation of a 64 bit exponent. This is just an example of course, probably won't happen, but when I read "1e1000" or such a number it doesn't strike me as infinite (although a particular version of IEEE floating point may consider it that), it strikes me as a lazy programmer who thinks it's bigger than any other number he's processing. I've added this case to my PEP .rst file and why it's not a good solution Thanks, Cade On Sat, Sep 12, 2020, 8:25 AM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Guido van Rossum writes: > > > I don't actually understand why Stephen made this claim about > > arithmetic operations, > > Stephen is often mistaken about computers (among many topics). That's > why he mostly posts on -ideas, and mostly throws drafts away rather > than post them. :-) > > I would not claim that evaluating a literal such as 1e1000 is not an > arithmetic operation, I just "forgot" that these examples exist > (mostly in a context of trying to get NaN with math.asin(2) and got > ValueError instead ;-/ ). > > I still stand by the argument that since some common ways of producing > true infinities (rather than overflows) and NaNs such as 1.0/0.0 and > 0.0/0.0 end up as Exceptions rather than float values, inf and nan > have rather small usefulness in Python with only builtins, especially > nan. "from math import inf" has to be the least annoying thing about > working with infinities and overflows in Python (which, to be fair, is > quite annoying in any context, on computers or on paper). > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/22TKQDJV4PNMOK5KUAX74QHX3KP74XCT/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PBFPTMQ3M4TWI6PFR7DNBD5QH2JOCUQW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf
The Nomadic Coder writes: > This came out personal frustration, as I use this 3 line function > very, very often, and the whole community does. I don't deny your experience, but mine differs. Most JSON I get as single objects arrives as strings (eg as an attribute on an HTTP response object), not in files or file-like objects. Most JSON I get from file-like objects comes as streams of objects, rather than as single objects, which means that to use the json module I have to do something a little more complicated (sometimes quite a bit more complicated) than a 3-line function. The issue of handling such streams has come up in the past. > Still learning-to-navigate what's accepted here and what's not :) On this list, you can ask as long as you don't get pissy about not receiving. See Naoki Inada's post for why this might be a good idea even though it's a three-line function. It's not open and shut (for one thing, on most modern systems the system default encoding is already UTF-8), but it definitely is food for thought. Also Serhiy's post on issues specific to working with files and json. So this is a richer learning experience than you might have thought! ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MX3ANN4ZJGVT4CCTN6UWR4XLAGJFEWFU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
Guido van Rossum writes: > I don't actually understand why Stephen made this claim about > arithmetic operations, Stephen is often mistaken about computers (among many topics). That's why he mostly posts on -ideas, and mostly throws drafts away rather than post them. :-) I would not claim that evaluating a literal such as 1e1000 is not an arithmetic operation, I just "forgot" that these examples exist (mostly in a context of trying to get NaN with math.asin(2) and got ValueError instead ;-/ ). I still stand by the argument that since some common ways of producing true infinities (rather than overflows) and NaNs such as 1.0/0.0 and 0.0/0.0 end up as Exceptions rather than float values, inf and nan have rather small usefulness in Python with only builtins, especially nan. "from math import inf" has to be the least annoying thing about working with infinities and overflows in Python (which, to be fair, is quite annoying in any context, on computers or on paper). ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/22TKQDJV4PNMOK5KUAX74QHX3KP74XCT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: 'Infinity' constant in Python
On Fri, Sep 11, 2020 at 11:19:05AM -1000, David Mertz wrote: > On Fri, Sep 11, 2020 at 10:19 AM Guido van Rossum wrote: > > > While one may argue that writing `1e1000` is not an "arithmetic > > operation", certainly it's certainly not "casting strings to floats", and > > it's the simeplest way of producing `inf` in a pinch (in theory it's not > > portable, but I think "in a pinch" means you don't care about that). I think that the only reason that could fail to produce inf is if your C doubles aren't IEEE-754 binary64. Are there any such platforms that are capable of building CPython but don't support IEEE-754? Or has anyone tried building CPython using, for example, posits instead? > For 128-bit versions of Python you'd need 1e4933. For 256-bit, 1e78914. > But those work fine on 32-bit or 64-bit also. Are there any Pythons with 128-bit or 256-bit floats? I've just tried Jython and IronPython, and got: >>> sys.float_info.max_10_exp 308L for both of them, which matches CPython. Micropython doesn't seem to support sys.float_info, but testing suggests that the floats are 64 bit too: # Micropython 1.9, Python version 3.4 >>> 1e309 inf If anyone is seriously worried about their Python supporting more than 64 bit floats, you can use 1e8 which should give inf on any system supporting IEEE-754 no matter what size floats you have. What it will do on a posit or other non-IEEE-754 machine, I have no idea :-) -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/O5X5GEE3NMIHTGV46ES2MNXPRGUTOH6C/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf
11.09.20 23:28, The Nomadic Coder пише:
> Hi All,
>
> This is the first time I'm posting to this mailing group, so forgive me if
> I'm making any mistakes.
>
> So one of the most common ways to load json, is via a file. This is used
> extensively in data science and the lines. We often write something like :-
>
> with open(filename.json, "r") as f:
> my_dict = json.load(f)
>
> or
> my_dict = json.load(open("filename.json", "r"))
>
> Since this is so common, why doesn't python have something like :-
> json.loadf("filename.json")
>
> Is there an obvious issue by defining this in the cpython? I don't whipping
> up a PR if it gains traction.
Similar ideas were already proposed and rejected multiple times.
First, there is a principle "not every three-line function needs to be a
built-in". Every new function increases maintenance cost and cognitive
burden. You can think that it is small, but there are thousands of such
"useful" helpers. It is easier to learn how to combine simple builtin
blocks than remember names and arguments for all combinations.
Second, the resulting function would have monstrous interface. open()
takes 8 arguments, and json.load() can take at least 8 arguments, and
they should be combined. And thank that open() does not accept arbitrary
var-keyword arguments as json.load(), resolving this conflict would be
impossible.
Third, this combination is not so common as you think. On my current
work JSON is used everywhere, but in most cases it is received from
internet or load from database. If loading from a file is the most
common ways to load JSON in your program, it is not hard to write your
own helper with interface and defaults that suit you. It will take less
time than writing a letter in a mailing list.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/HWBBABAIXB6IUOP2SOXHPMVZXXRZRKMM/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf
12.09.20 01:57, Guido van Rossum пише: > What happened to "not every three-line function needs to be a built-in"? > This is *literally* a three-line function. And I know the proposal is > not to make it a builtin, but still... ISTM down here lies the path to PHP. Oh, I am very glad that this principle has not yet been forgotten. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XU7NM4XF7CRSIE7NUJM3FZ6CD7E36N4X/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Curious : Why staticmethod if classmethods can do everything a static method can?
Dan, I should preface this by saying I don't substantially disagree with you, I just work differently and want to show how and why. On 11Sep2020 21:24, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote: >On 2020-09-12 at 09:57:10 +1000, >Cameron Simpson wrote: >> So, consider: >> >> @classmethod >> def func(cls, foo): >> print(foo) >> >> A linter will warn you that "cls" is unused. With a static method: >> >> @staticmethod >> def func(foo): >> print(foo) >> >> a linter will be happy. >> >> Think of @classmethod and @staticmethod as ways to write "clean" >> functions with no extraneous cognitive noise. > >I concur with all of Cameron's technical details and explanations. > >But no extraneous cognitive noise? Specificly in the sense that the @classmethod example has an unused "cls" parameter. For a three line function this is trivial to ignore, but for a substantial function I'd be devoting annoying brainpower to understanding where it was used, and if it didn't appear, _should_ it be used? Thus noise. With the static method it is instantly clear that no instance or class context is used. >By definition, methods appear inside >a class definition, and then I have to process the @staticmethod >decorator. Effectively, the decorator "cancels" the class method status >of the function. For me, I have to process either the @staticmethod or @classmethod decorators equally - they just have different meanings. But at least they're up the front - I see them and their meaning for the function context is instantly available to me instead of needing to be deduced. >I can accomplish the same thing with clean >module-level function, modulo the specific namespace in which the >function is created. > >So, in a module m: > >class X: >@staticmethod >def f(x): >print(x) > >and > >def f(x): >print(x) > >m.X.f and m.f are interchangeable. Yes, technically. Let me say up front that I write plenty of module elvel plain functions. However I do have plenty of use cases for @staticmethod in class definitions. They tend to be class utility functions, either for some common function used in the class methods, _or_ a common method meant to be available for outside use - particularly for a common pattern for outside use. Here's an example of the former: @staticmethod def pick_value(float_value, string_value, structured_value): ''' Chose amongst the values available. ''' if float_value is None: if string_value is None: return structured_value return string_value return float_value @property def value(self): ''' Return the value for this `Tag`. ''' return self.pick_value( self.float_value, self.string_value, self.structured_value ) This is from a tag library of mine, where the tags live in a database and there are three fields: a float, a string and a JSON blob. Only one will be nonNULL. This supports a remarkable flexibility in tagging things. It is common in the class to pick amongst them, thus the static method. It is also not unreasonable to work with such a choice outside the class (so it might not be a private method/function). On review, I've actually got relatively few examples of the latter category - methods for use outside the class - they are almost entirely @classmethods. The few which are static methods live in the class for purposes of conceptual hierarchy. My commonest example is the transcription method from a binary structure module I have. Data structures each have a class which implements them, and all subclass a base class. This gets me a common API for parsing the structure and also for writing it back out. When implementing a particular structure one always has a choice between implementing one of two "transcribe" methods. For a simple thing with a single "value" (eg an int) you'd implement "transcribe_value(value)", a static method. For something more complex you implement "transcribe()", a class or instance method depending. In the abstract base class each method calls the other - the subclass must provide a concrete implementation of one method. Anyway, back to the static method: if is pretty common to want to write out a value using the transcription from a class, example: value = 9 bs = BSUInt.transcribe_value(value) without going to any hassle of instantiating an instance of BSUInt - we just want to convert from the Python type to bytes. There's a similar example for parsing. The beauty here is that you have the same pattern of classname.transcribe_value(value) to use whatever binary format you want. And that's a static method because it doesn't need a class or instance for context - it just transcribes the data. >IMO, m.f has less cognitive load >than m.X.f, at their definitions and at call sites. Full disclosure: I >consider most of
