On Fri, Sep 4, 2020, at 12:45, Cade Brown wrote:
> I am positing that Python should contain a constant (similar to True,
> False, None), called Infinity.
What if we created a new syntax [and used it for the repr] that is not
currently a valid identifier?
something like "1.INF"
On Fri, Sep 11, 2020 at 3:09 AM Random832 wrote:
> On Fri, Sep 4, 2020, at 12:45, Cade Brown wrote:
> > I am positing that Python should contain a constant (similar to True,
> > False, None), called Infinity.
>
> What if we created a new syntax [and used it for the repr] that is not
> currently
This syntax seems ugly to me, clunky, and as you said probably breaks
existing code
This, to me, is less clear than current methods of generating an 'inf'
which is the whole reason I proposed it
Thanks,
*Cade Brown*
Research Assistant @ ICL (Innovative Computing Laboratory)
Personal Email:
On Fri, Sep 11, 2020 at 12:09 AM Random832 wrote:
> On Fri, Sep 4, 2020, at 12:45, Cade Brown wrote:
> > I am positing that Python should contain a constant (similar to True,
> > False, None), called Infinity.
>
> What if we created a new syntax [and used it for the repr] that is not
> currently
On Fri, Sep 11, 2020 at 8:58 AM Guido van Rossum wrote:
> What's wrong with 1e1000?
>
As a spelling of "infinity" generically, or just as an example of an
"arithmetic operation"?
On the latter, I didn't use that just because it feels sort of like a
"cheat" rather than an "operation." I.e. my
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:
+1 because the general idea is one of my most commonly used utility
functions. There should also be a similar function for writing to a file,
e.g. json.dumpf if we stick to this naming scheme.
As an alternative, pathlib.Path.read/write_text are pretty cool, maybe we
could have .read/write_json?
Personally prefer it to be in the json module as it just feels more logical.
But that's just a personal choice.
I didn't mention about dumpf as I see a previous thread that became quite
controversial (seems like dumps was a more common usage at that time).
Something I forgot to mention : A
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
On Fri, Sep 11, 2020 at 1:10 PM David Mertz wrote:
> On Fri, Sep 11, 2020 at 8:58 AM Guido van Rossum wrote:
>
>> What's wrong with 1e1000?
>>
>
> As a spelling of "infinity" generically, or just as an example of an
> "arithmetic operation"?
>
> On the latter, I didn't use that just because it
Christopher Barker writes:
> On Fri, Sep 11, 2020 at 12:09 AM Random832 wrote:
> > What if we created a new syntax [and used it for the repr] that is not
> > currently a valid identifier?
> >
> > something like "1.INF"
Not for this please; save it for a case where we need it. I'm against
What's wrong with 1e1000?
On Fri, Sep 11, 2020 at 11:51 AM David Mertz wrote:
> On Fri, Sep 11, 2020 at 6:48 AM Stephen J. Turnbull
>
>> inf and nan only exist in Python the
>>
> language (including builtins) via casting strings to floats (there are
>> no arithmetic operations that produce
On Fri, Sep 11, 2020 at 6:48 AM Stephen J. Turnbull
> inf and nan only exist in Python the
>
language (including builtins) via casting strings to floats (there are
> no arithmetic operations that produce them).
>>> import sys; sys.version
'3.8.3 (default, May 19 2020, 18:47:26) \n[GCC 7.3.0]'
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
On 12/09/20 12:21 pm, Guido van Rossum wrote:
I had heard of this
concept in another language (C++? Smalltalk?)
Probably C++ or Java. Smalltalk doesn't have static methods, only a
form of class method.
IMO, static methods are a kludge only needed in languages that make
classes do double duty
On Fri, Sep 11, 2020 at 7:27 PM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> But no extraneous cognitive noise? 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
On 11Sep2020 23:09, The Nomadic Coder wrote:
>oops, was not aware of "not every three-line function needs to be a built-in"
>
>This came out personal frustration, as I use this 3 line function very,
>very often, and the whole community does. Still learning-to-navigate
>what's accepted here and
On 11Sep2020 22:58, The Nomadic Coder wrote:
>This question is to further my understanding of the internals. It seems to me
>that a classmethod can do everything a staticmethod can, and additionally is
>not limited by inheritance.
>
>Why does python have them as two different constructs?
It
staticmethod is generally used if you don't want an automatically bound
'self'/'cls' parameter when invoking a method on the type.
classmethod just changes WHICH object is used as the "self" parameter.
___
Python-ideas mailing list --
On Fri, Sep 11, 2020 at 4:00 PM The Nomadic Coder
wrote:
> This question is to further my understanding of the internals. It seems to
> me that a classmethod can do everything a staticmethod can, and
> additionally is not limited by inheritance.
>
> Why does python have them as two different
On Fri, Sep 11, 2020 at 4:19 PM David Mertz wrote:
> On Fri, Sep 11, 2020, 12:59 PM Guido van Rossum wrote:
>
>> 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
How about load_from_path or loadp?
I can understand that loadf is a bit misleading, you might think that it loads
from a file-like object, but parses from a file instead.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an
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.
On Fri, Sep 11, 2020 at 3:16 PM Christopher Barker
wrote:
> I"m pretty sure
On Fri, Sep 11, 2020, 12:59 PM Guido van Rossum wrote:
> 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.
>
By the same
On Sat, Sep 12, 2020 at 7:59 AM Guido van Rossum wrote:
>
> What happened to "not every three-line function needs to be a built-in"? This
> is *literally* a three-line function.
This is not only common two line idiom. It creates huge amount of
potential bugs.
```
with open("myfile.json") as f:
On Fri, Sep 11, 2020 at 9:46 AM Stephen J. Turnbull
> itself doesn't seem to be enough to produce inf:
Indeed -- overflow and underflow and divide by zero all all caught and
raise. But you can get it with a simple huge literal:
In [22]: 1e1000
Out[22]: inf
But if there is going to be a
I"m pretty sure this came up recently, and was pretty much rejected.
Another option would be to have json.dump take a file-like-object or a
path-like object -- there's plenty of code out there that does that.
hmm.. maybe that was the version that was rejected.
But I like the idea either way. it
I like the idea of having these functions, but I don't like overloading the
argument to a function with "filename or file-like object" as is common in
libraries like Pandas. I think there are a few places the standard library
does it, but the separation seems better to me.
I don't LOVE the names
This question is to further my understanding of the internals. It seems to me
that a classmethod can do everything a staticmethod can, and additionally is
not limited by inheritance.
Why does python have them as two different constructs?
___
oops, was not aware of "not every three-line function needs to be a built-in"
This came out personal frustration, as I use this 3 line function very, very
often, and the whole community does. Still learning-to-navigate what's accepted
here and what's not :)
30 matches
Mail list logo
