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 a
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: b
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
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
a
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]'
>
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 them
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 l
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 f
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 (no
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
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 change
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
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 -- [email protected]
To unsubscribe send an em
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 t
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?
___
Python-ide
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 :)
__
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 re
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 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 w
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 has
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 -- python-ideas@python
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 cons
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 stil
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 a
On Fri, Sep 11, 2020 at 7:27 PM <[email protected]> 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
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 <[email protected]> wrote:
>On 2020-09-12 at 09:57:10 +1000,
>Cameron Simpson wrote:
>> So, consider:
>>
>> @cl
31 matches
Mail list logo
