On Sat, Oct 2, 2021 at 3:15 PM Jonathan Crall wrote:
>
> That's effectively every module I write. I don't think that's uncommon or bad
> practice.
>
Interesting. Why is that?
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscri
That's effectively every module I write. I don't think that's uncommon or
bad practice.
On Sat, Oct 2, 2021, 12:05 AM Chris Angelico wrote:
> On Sat, Oct 2, 2021 at 2:01 PM Jonathan Crall wrote:
> >
> > @Steven D'Aprano Yes my original post is somewhat pithy and has some
> harsh words for decor
A correction to my reply: int('1234567890' * 100) will not raise an overflow
error, multiplying 1.0 with it raises the error. str.isfloat would still flag
the string as an int and then it is upto the application code to deal with the
overflow error.
__
On Sat, Oct 2, 2021 at 2:01 PM Jonathan Crall wrote:
>
> @Steven D'Aprano Yes my original post is somewhat pithy and has some harsh
> words for decorators. Like many I have some opinions about code. Don't take
> them too seriously if they disagree with your experience, but I do hold my
> opinio
@Steven D'Aprano Yes my original post is somewhat
pithy and has some harsh words for decorators. Like many I have some
opinions about code. Don't take them too seriously if they disagree with
your experience, but I do hold my opinions for reasons, and I will explain
some of them, but I don't want
Having such a method in the core helps avoid writing the function repeatedly.
(This would especially help beginners.)
My version is suited to the core language as a string method. parse_value as
given by Dennis Sweeney is suited to user code.
___
Python
On Sat, Oct 2, 2021 at 1:00 PM Nick Parlante wrote:
>
> I have also often wondered if there could be something more turn-key for that
> bit at the bottom.
>
> Here is a suggestion I'll throw into the ring:
>
> sys.run_main()
>
> It goes at the bottom of the file, and basically just lets the progr
I have also often wondered if there could be something more turn-key for
that bit at the bottom.
Here is a suggestion I'll throw into the ring:
sys.run_main()
It goes at the bottom of the file, and basically just lets the programmer
express what they want to happen. Easy to explain. The appropri
There is no need of a three_way_flag - just use a conditional expression
instead of an if-elif-else block,
str.isfloat uses the int() and float() functions, so, in your example, if float
returns inf we can still return True (or maybe return None in this case too).
If int() raises overflow error
On Sat, Oct 2, 2021 at 12:19 PM Debashish Palit wrote:
>
> The method need not take care of every variation. Currently there is no
> method to check for a float in a string even without formatting. str.numeric
> or str.decimal don't work. str.isfloat would test unformatted strings for
> floats
The method need not take care of every variation. Currently there is no method
to check for a float in a string even without formatting. str.numeric or
str.decimal don't work. str.isfloat would test unformatted strings for floats
or ints just like the functions int() and float() convert strings
On Fri, Oct 01, 2021 at 08:56:39AM -, dpali...@outlook.com wrote:
> It would be nice to have a string method that checks for a float.
> Currently there is no support for this, either built-in or in the
> standard library. There is a thread, dating back to Dec 2020, that
> proposes a trivial
On Fri, Oct 01, 2021 at 03:35:26PM -0400, Jonathan Crall wrote:
> My motivation for writing this suggestion is in an attempt to stop a common
> anti-pattern, where instead of defining a `main` function (or a function by
> any other name) an simply calling that by adding the above two lines, a lot
On Fri, Oct 1, 2021 at 12:14 PM Ricky Teachey wrote:
>
>
> that being the case, i think it should probably stay where it is.
>
Exactly:-)
-CHB
>
>
> --
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Develop
I don't know how common it is to want to distinguish between string
representations of integers and those of floats. It seems like a function that
could have a million little variations: What if my boss says that now my input
integers can have commas? Or have extra space added? Or if integer-val
Yes, it seems like having special handling of `def __main__` is an
extension in the spirit of `package/__main__.py `.
On Fri, Oct 1, 2021 at 3:43 PM Thomas Grainger wrote:
> FYI you can already use package/__main__.py which is runnable with `python
> -m package` and you don't need the `if __name
For sure. I think there can be room for improvement in modules though.
On Fri, 2021-10-01 at 20:43 +0100, Thomas Grainger wrote:
> FYI you can already use package/__main__.py which is runnable with
> `python -m package` and you don't need the `if __name__ ==
> "__main__":`
> https://docs.python.or
FYI you can already use package/__main__.py which is runnable with `python
-m package` and you don't need the `if __name__ == "__main__":`
https://docs.python.org/3.10/library/__main__.html#main-py-in-python-packages
On Fri, 1 Oct 2021, 20:39 Paul Bryan, wrote:
> How about the following?
>
> def
That would also make a lot of sense. That way has fewer characters without
sacrificing clarity, which is a +1 in my book.
On Fri, Oct 1, 2021 at 3:38 PM Paul Bryan wrote:
> How about the following?
>
> def __main__():
>
> ...
>
>
> Behavior:
>
> 1. Load module as normal.
> 2. If __name__ is
How about the following?
def __main__():
...
Behavior:
1. Load module as normal.
2. If __name__ is "__main__" or module is named in python -m, call
__main__ function.
Paul
On Fri, 2021-10-01 at 15:35 -0400, Jonathan Crall wrote:
> I was curious if / what sort of proposals have been consid
I was curious if / what sort of proposals have been considered for
simplifying the pattern:
```
def main():
...
if __name__ == "__main__":
main()
```
I imagine this topic must have come up before, so I'd be interested in any
relevant history.
But unless I'm missing something, it seems
On Fri, Oct 1, 2021 at 2:52 PM Christopher Barker
wrote:
> On Fri, Oct 1, 2021 at 8:05 AM Paul Moore wrote:
>
>> Having to take the runtime cost of an import to do a development-time
>> static analysis of the code, sort of is, though...
>
>
> Perhaps so — though I’d think that could be addressed
On Fri, Oct 1, 2021 at 8:05 AM Paul Moore wrote:
> Having to take the runtime cost of an import to do a development-time
> static analysis of the code, sort of is, though...
Perhaps so — though I’d think that could be addressed in a more
comprehensive way. Thus can’t be the only runtime overhea
On Fri, 1 Oct 2021 at 15:50, Christopher Barker wrote:
>
> The fact that the built in “any” is not a type is not an implementation
> detail. any() and typing.Any are completely different things/concepts. They
> just happen to be spelled the same.
Agreed.
> I don’t think it’s a bad thing that o
The fact that the built in “any” is not a type is not an implementation
detail. any() and typing.Any are completely different things/concepts. They
just happen to be spelled the same.
I don’t think it’s a bad thing that objects that are specifically about
Type Hinting can be found in the typing m
On Fri, Oct 1, 2021 at 9:49 AM Matt del Valle wrote:
> I had no idea that type[Something] was already a thing, and this makes me
> so happy! :)
>
> It's true that `any` would have to converted to be either:
>
> 1) an object implementing __call__ and __getitem__
> 2) a type implementing __new__ an
I had no idea that type[Something] was already a thing, and this makes me
so happy! :)
It's true that `any` would have to converted to be either:
1) an object implementing __call__ and __getitem__
2) a type implementing __new__ and __class_getitem__
3) some special-cased type implemented in the i
On Fri, Oct 1, 2021 at 8:02 AM Matt del Valle wrote:
> In the spirit of 3.9 allowing builtin collections like `list`, `dict`,
> `tuple`, and `set` to be subscripted for type-hinting to remove the need
> for importing their equivalents from `typing`, I'd like to propose the same
> thing for a few
FYI type[Something] is already valid as it was implemented in PEP 585 and is
prefered over typing.Type[Something].
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.
It would be nice to have a string method that checks for a float. Currently
there is no support for this, either built-in or in the standard library. There
is a thread, dating back to Dec 2020, that proposes a trivial implementation
for str.isfloat . I was thinking of a method that did more.
Co
> Being too terse is worse than being too verbose
This is my view as well. I would not want to see python go Perl-shaped.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.
In the spirit of 3.9 allowing builtin collections like `list`, `dict`,
`tuple`, and `set` to be subscripted for type-hinting to remove the need
for importing their equivalents from `typing`, I'd like to propose the same
thing for a few other builtin objects, namely:
`type` (for use instead of`typi
On 2021-10-01 8:26 a.m., Steven D'Aprano wrote:
> On Thu, Sep 30, 2021 at 01:25:42PM -0300, Soni L. wrote:
>
> > def foo():
> > raise Bar
> > def baz() with Bar:
> > foo()
> > baz()
> >
> > would make a RuntimeError, because foo raised a Bar and the VM sees that
> > B
On Fri, Oct 01, 2021 at 06:43:40AM -0300, Soni L. wrote:
> Look for the clarification post we posted as a reply to the original post.
Who is "we"? If you are posting this in collaboration with other people,
it would be polite to introduce them.
--
Steve
___
On Thu, Sep 30, 2021 at 01:25:42PM -0300, Soni L. wrote:
> def foo():
> raise Bar
> def baz() with Bar:
> foo()
> baz()
>
> would make a RuntimeError, because foo raised a Bar and the VM sees that
> Bar is in baz's with.
So the syntax "with SomeException" in a functio
On 2021-10-01 2:04 a.m., Steven D'Aprano wrote:
> Let's get to the fundamental problem with this. It is DWIM magic, and
> you haven't (as far as I have seen) yet specified how we are supposed to
> use it or predict how it is supposed to work.
>
> Here is your syntax again:
>
> > > def a_pot
`yield from (,)` produced different byte code when I tried it, so I think it's
a tad slower
Also yield from doesn't work in async generators
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@pyth
37 matches
Mail list logo
