I know this has come up in the past.
Could the consensus have changed regarding bool's inheritance from int?
This is not intuitive (to me), and recently bit me as a bug:
Python 3.9.1 (default, Dec 13 2020, 11:55:53)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more
>
> -100.
>
> On Mon, Dec 21, 2020, 3:00 AM Paul Bryan wrote:
> > I know this has come up in the past.
> >
> > Could the consensus have changed regarding bool's inheritance from
> > int?
> >
> > This is not intuitive (to me), and rece
common useful pattern.
>
> ntrue = sum(this == that for this, that in items)
>
> -100.
>
> On Mon, Dec 21, 2020, 3:00 AM Paul Bryan wrote:
> > I know this has come up in the past.
> >
> > Could the consensus have changed regarding bool's inheritance from
I'm interested in knowing when (id(x), x) would be preferable over
(type(x), x).
On Mon, 2020-12-21 at 17:52 +, David Mertz wrote:
> On Mon, Dec 21, 2020 at 5:27 PM Christopher Barker
> wrote:
> > Surely what you're looking for is some kind of typed hash table?
> >
> > Maybe, maybe not. My i
Perhaps this would be a good opportunity to start looking at
typing.Annotated[...] as a mechanism for parameter documentation?
Something like:
def request(
method: Annotated[str, Doc("The method to perform")],
url: Annotated[str, Doc("The URL to submit request to")],
...
) -> Response:
"""Constructs and sends a request."""
...
On Fri, 2021-01-29 at 20:40 +, Paul Bryan wrote:
> Perhaps this would be a good opportunity to start looking at
> typing.Annotated[...] as a mechanism for parameter documentation?
> Something like:
>
>
t; > doesn't work" ...
> > ) -> Response:
> > """This also is a bit weird"""
> > """Constructs and sends a request"""
> >
> > The weirdest part about that is the doc string for "m
To clarify, the point of __provisional__ would be to enable some
syntactical feature in the language that should not be considered
stable? I'm not sure I see a reason to use this for a new module or
package in stdlib for example; a docstring or perhaps some decorator
like @provisional could indicat
I'm encountering a situation where it would be far cleaner to use
**kwargs (multiple functions taking the same set of parameters); I'd
like to have type hints, and avoid repeating multiple function
definitions, explicitly enumerating all parameters for each function
definition.
Therefore, I'd like
I wonder how that is substantially different than:
from pathlib import Path as p
p() / "foo"
or perhaps more verbosely, but arguably more readable:
from pathlib import Path
Path() / "foo"
Paul
On Tue, 2021-02-16 at 01:07 +, mwmajewsk wrote:
> P.S. the code snippet I mentioned is not rende
I agree, I don't think it justifies a builtin, because it is so simple
to just define your own empty class. That said, it does come in handy,
and I do use it for same reasons others have expressed.
On Thu, 2021-02-18 at 11:50 +1300, Greg Ewing wrote:
> On 18/02/21 3:51 am, Ricky Teachey wrote:
>
I think it's a classic case of dependency hell.
OS packagers are rebundling Python packages as OS packages and
expressing their own OS-package dependency graphs. Then, you sudo pip
install something that has a conflicting dependency, it bypasses OS
packaging, and *boom*.
I find tools like pipx go
Could somone provide a concrete example on a proposed use of such an
asyncio.Barrier?
On Fri, 2021-02-26 at 14:19 -0800, Guido van Rossum wrote:
> On Fri, Feb 26, 2021 at 10:09 AM Yves Duprat
> wrote:
> > I was expecting an explanation about the initial request.
> > Is there an oversight (??) or
Sorry, didn't see Jonathan's example.
On Sat, 2021-02-27 at 01:12 +0000, Paul Bryan wrote:
> Could somone provide a concrete example on a proposed use of such an
> asyncio.Barrier?
>
> On Fri, 2021-02-26 at 14:19 -0800, Guido van Rossum wrote:
> > On Fri, Feb 26,
Since class is a keyword, this is unlikely. Why is type(o) not
insufficient?
On Wed, 2021-03-03 at 22:59 +0100, Hans Ginzel wrote:
> > > > class c: pass
> > > > o = c()
> > > > o.__class__
>
> > > > class(o)
> File "", line 1
> class(o)
> ^
> SyntaxError: invalid syntax
Err, why is it insufficient?
On Wed, 2021-03-03 at 14:03 -0800, Paul Bryan wrote:
> Since class is a keyword, this is unlikely. Why is type(o) not
> insufficient?
>
> On Wed, 2021-03-03 at 22:59 +0100, Hans Ginzel wrote:
> > > > > class c: pass
> > &g
In my experience, a dataclass with more than a few attributes makes
using positional arguments unwieldy and error-prone.
I would think something like @dataclass(kwonly=bool) with default of
False would be reasonably clean to implement and understand.
While I appreciate supporting existing behavi
Given that @dataclass is a decorator, and otherwise you're just
defining a class, some concerns:
1. Such proposed syntax would require a change to the language
specification.
2. It would seem that / and * in a class not decorated with @dataclass
would be of no other utility.
Paul
On Thu, 2021-
It's current convention (and is used by typing module and static type
checkers) that string annotations evaluate to valid Python types.
On Thu, 2021-03-11 at 10:45 -0800, Ethan Furman wrote:
> On 3/10/21 9:47 PM, Eric V. Smith wrote:
>
> > I'm not sure of the best way to achieve this. Using flags
Of course, you could encapsulate your imports inside of functions, that
import only once called. However, there are plenty of cases where that
is not practical.
Probably one of countless examples of performing lazy imports, for
precisely the reason of preventing circular imports:
https://github.co
It would be resolved at the time the value is accessed in the lazy map.
The map then stores the resultant value to avoid attempting to re-
import the module on every access.
On Fri, 2021-03-12 at 08:31 +1100, Chris Angelico wrote:
> On Fri, Mar 12, 2021 at 8:24 AM Paul Bryan wr
If you're proposing something like this, then I think it would be
compatible:
class Hmm:
#
this: int
that: float
#
pos: PosOnly
#
these: str
those: str
#
key: KWOnly
#
some: list
On Thu, 2021-03-11 at 14:06 -0800, Ethan Furman wrote:
> On 3/11/21 10:50 AM, Paul Bryan wrote
o not support the full range of __init__ signatures
you could generate with a normal class, and they are extremely hostile
to subclassing. That is a failing that often forces people to fall bac
k to normal classes in otherwise ideal dataclass use-case situations.
On Thu, Mar 11, 2021 at 10:
It seems your proposal is intended to address an aesthetic concern. Is
there a case where using a leading comma would make something
actually easier or more intuitive to express over the use of trailing
comma?
On Fri, 2021-03-12 at 10:34 +, roland.puntaier--- via Python-ideas
wrote:
> I had po
My inclination would be to cede code formatting to a tool like Black
and focus on function:
https://black.readthedocs.io/en/stable/
On Fri, 2021-03-12 at 15:32 +, Matt Williams wrote:
> Hi,
>
> It's becoming more popular in Python to have interfaces which are
> built around method chaining a
Using your example (thanks, seeing a concrete example is helpful) it
appears you can do it the SQL way in Python too:
x = (1
,2
,3
)
On Fri, 2021-03-12 at 16:35 -0500, Eric V. Smith wrote:
> On 3/12/2021 3:37 PM, Greg Ewing wrote:
> > On 13/03/21 5:02 am, Ned Batchelder wrote:
> > > I think the
+1 to Matt's points here. I get the desire for symmetry with / and * in
params, but I'm not convinced it's useful enough to warrant the
complexity of the approaches being proposes. I think a @dataclass(...,
kwonly=True) would solve > 90% of the issues with dataclass usability
today.
On Sat, 2021-0
With some of the dataclass threads in python-ideas ongoing, I wanted to
add another to the fray.
There's an area where typing.get_type_hints on dataclass and __init__
produce inconsistent results. Example:
@dataclass
class Foo:
x: int = None
>>> typing.get_type_hints(Foo)
{'x': }
>>> typing
I've encountered the same issue, either matching the default values in
the else clause (and hoping they won't later be changed) or having to
revert to building a kwargs dict, and then in multiple `if` statements,
conditionally including arguments.
I've also felt this same pain building dicts with
Haven't seen a reply to this yet, so I'll start the bidding at 2¢.
Generally, I like the idea of using Annotated in this fashion. I'm
currently using it for expressing validation rules and hints about how
parameters are handled in HTTP requests. Handy!
If = field(...) weren't already established,
I think I like it.
Q. Safe to assume this would catch exceptions from both the call to
`open` as well as the call to `open.__enter__`?
Q. What about something even more verbose (descriptive) like`try with
open(...) as cfg:`? 🙂
Paul
On Thu, 2021-04-08 at 15:59 +0100, anthony.flury via Python-i
This sounds more like a Unicode thing than a generic string thing. And,
in Uncode, Greek characters are included in multiple groupings.
Searching for "Theta" to see what we get:
Greek and Coptic:
U+0398 GREEK CAPITAL LETTER THETA
U+03B8 GREEK SMALL LETTER THETA
U+03D1 GREEK THETA SYMBOL
U+03F4 GRE
I agree. It would be great to get something more than what the
simplistic `unicodedata.category(...)` returns; for example, what
Unicode group a character falls in.
On Sat, 2021-04-10 at 00:29 +1000, Chris Angelico wrote:
> On Sat, Apr 10, 2021 at 12:15 AM Paul Bryan wrote:
> >
> &
A recipe to have an idea be marginalized or ignored:
1. Start by denigrating the work of others with pejoratives like
"cranky" and "unpleasant".
2. Do not provide any support to back such a claim, or call out any
specific usability issue.
3. Imply that the content is deficient, without qualificat
On Sun, 2021-05-02 at 23:07 +0400, Abdur-Rahmaan Janhangeer wrote:
> Oh seems like you are a dinosaur needing some carbon dating.
It seems you need to review the Python Community Code of Conduct:
https://www.python.org/psf/conduct/
Please see the sections regarding being respectful and insults,
I think improving the online documentation is a good idea.
How can this effort avoid merely addressing subjective preferences?
Beauty in the eye of the beholder, and all that.
This appears to be the current style guide:
https://devguide.python.org/documenting/
It largely focuses on content. Woul
I've read the proposal, and this thread.
Questions:
1. It seems that I could get close to what you're aiming for by just
using underscores in names, and grouping them together in the class
definition. Is there any advantage to declaring methods in a namespace
beyond indentation and the dot notati
Correction:
4. What would you expect getattr(A.B, "C") to yield?
Paul
On Mon, 2021-05-03 at 12:10 -0700, Paul Bryan wrote:
> I've read the proposal, and this thread.
>
> Questions:
>
> 1. It seems that I could get close to what you're aiming for by jus
Response inline.
On Mon, 2021-05-03 at 23:30 +0100, Matt del Valle wrote:
> @Paul Bryan, I'll try to address your questions one-by-one
>
> > 1. It seems that I could get close to what you're aiming for by
> > just using underscores in names, and grouping them together
+1
On Sun, 2021-05-09 at 16:45 +, Thomas Grainger wrote:
> now that python2.7 is EOL, it might be worth resurrecting this syntax
> as discussed in https://www.python.org/dev/peps/pep-3100/#id13
>
> eg, python 3.11 could support
> ```
> try:
> ...
> except (E1, E2, E3) as e:
> ...
> ``
I like the idea of supporting fractions to maintain more precision in
calculations. I wonder if this should fall outside the scope of a
standard library and be implemented in an external library. I'd lean
toward inclusion in stdlib.
A couple of thoughts, which should result in zero breakage of exi
And I've just learned something. 🙂
On Fri, 2021-05-14 at 11:28 -0300, André Roberge wrote:
>
>
> On Fri, May 14, 2021 at 11:23 AM Paul Bryan wrote:
> > I like the idea of supporting fractions to maintain more precision
> > in calculations. I wonder if this should
On Fri, 2021-05-14 at 15:15 +, Martin Teichmann wrote:
> So, my argument is, this change will benefit many people, and be of
> only a small disadvantage to others. That disadvantage is that yes,
> there will be places where it does not work, so libraries need to get
> fixed. But this is the ca
I'll vote: bad. I don't think non-integer representations of fraction
attributes should be considered valid when expressing as a literal.
On Fri, 2021-05-14 at 14:17 -0400, Ricky Teachey wrote:
> On Fri, May 14, 2021 at 2:09 PM Ricky Teachey
> wrote:
> > On Fri, May 14, 2021 at 1:14 PM André Robe
s/non-integer/non-decimal-integer/
On Fri, 2021-05-14 at 11:23 -0700, Paul Bryan wrote:
> I'll vote: bad. I don't think non-integer representations of fraction
> attributes should be considered valid when expressing as a literal.
>
> On Fri, 2021-05-14 at 14:17 -0400, Ricky
If you're proposing prevention of monkey patching Ellipsis, I think
you'll have to go all-in on all builtins.
For example:
>>> str = int
>>> str
>>> str == int
True
Paul
On Mon, 2021-05-31 at 11:37 -0300, André Roberge wrote:
> In Python `...` is referred to as `Ellipsis` and cannot be assigne
Because ... is still bound to the original Ellipsis. Just as "s" below
will remain bound to the original str.
>>> s = str
>>> str = int
>>> int
>>> s
Paul
On Mon, 2021-05-31 at 16:16 +0100, MRAB wrote:
> On 2021-05-31 15:55, Paul Bryan wr
Fixing typo:
>>> s = str
>>> str = int
>>> str
>>> s
On Mon, 2021-05-31 at 08:31 -0700, Paul Bryan wrote:
> Because ... is still bound to the original Ellipsis. Just as "s"
> below will remain bound to the original str.
>
> >>>
+1
On Tue, 2021-06-01 at 05:46 +1000, Chris Angelico wrote:
> On Tue, Jun 1, 2021 at 5:40 AM David Mertz wrote:
> >
> > I think making 'Ellipsis' a reserved word is too much. The analogy
> > with non-reserved words like `int`, `str`, `map`, `print`, and so
> > on, illustrate this, I think. I.e
On Wed, 2021-06-23 at 21:18 -0700, [email protected] wrote:
> I'm +1 to add a 'context' keyword-argument to
> 'asyncio.create_task()'. It will still be copied. I believe I've
> explained *why* the copy is still necessary in this thread.
+1.
Paul
___
It looks like you're suggesting hard-coding specific language escape
conventions into f-strings?
What if instead you were to allow delegation to some filter function?
Then, it's generic and extensible.
def html(value: Any):
filtered = ... # filter here
return filtered
f'{!!html}...'
P
I like the idea in principle.
Could be as simple the presence of a __deprecated__ attribute on the
class or function being deprecated. A simple decorator could set it.
On Mon, 2021-07-12 at 19:37 +0100, Sergei Lebedev wrote:
> Hi python-ideas,
>
> The subject is by no means new nor unique, and i
I'm with you; since dataclasses were introduced, namedtuple has not see
any use from me, though none of my uses have demanded ultra-high
efficiency either.
I wonder how many users are currently relying on namedtuple __getitem__
semantics though. that's functionality dataclasses do not (currently)
I'm +1 on deprecation decorator, with some way to represent it so that
it can be determined at runtime (e.g. dunder).
On Thu, 2021-07-29 at 20:52 +, Leonardo Freua wrote:
> This is a good example of how using a decorator to express
> depreciation is much better and less polluting the method,
I'm in favour of keyword-only arguments in dataclasses; however
accepting arbitrary **kwargs seems pretty exotic to me. As Eric has
suggested, this seems like a job for some kind of wrapper or decorator.
On Mon, 2021-09-20 at 14:28 +, [email protected] wrote:
> Sorry for the double post
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
__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 __main__():
> > ...
> >
> >
> > Behavior:
> >
> > 1.
ev/2006-March/062951.html
>
> Eric
>
> On 10/1/2021 3:38 PM, Paul Bryan wrote:
>
> >
> > How about the following?
> >
> > def __main__():
> > ...
> > Behavior:
> >
> > 1. Load module as normal.
> > 2. If __name__ is &q
+1. These would be handy for any iterable. It'll works on dict keys and
values; bonus.
On Wed, 2021-10-06 at 15:42 +0100, Alex Waygood wrote:
> > Whether they are added to dict or itertools, there are still nine
> > of
> > them
>
> No, the suggestion was to add two functions to itertools (first(
Is this behavior of list iteration guaranteed by documentation
anywhere? A quick search didn't yield any results for me.
If not, I suggest either:
a) it gets documented so developers can rely on it, or
b) the lack of guarantee is documented so that we can reserve a change
of behavior later.
Paul
I too have used plain strings in Annotated[...] to document fields in
dataclasses.
On Thu, 2021-11-18 at 13:51 -0500, Ricky Teachey wrote:
> On Thu, Nov 18, 2021 at 1:39 PM Thomas Grainger
> wrote:
> > Ricky Teachey wrote:
> > > Could this be a use case for typing.Annotated?
> > > In [6]: from da
According
to https://docs.python.org/3/glossary.html#term-iterator and
https://docs.python.org/3/library/stdtypes.html#typeiter,
iterators must implement the __iter__ method.
On Sun, 2021-11-28 at 22:02 -0500, David Mertz, Ph.D. wrote:
> On Sun, Nov 28, 2021, 8:59 PM Steven D'Aprano
> > To be a
And the second link?
On Mon, 2021-11-29 at 00:11 -0500, David Mertz, Ph.D. wrote:
> On Sun, Nov 28, 2021, 11:43 PM Paul Bryan wrote:
> > According to https://docs.python.org/3/glossary.html#term-iterator
> > and https://docs.python.org/3/library/stdtypes.html#typeiter,
>
; the documentation already reflects this.
4. If you believe the documentation is in error or the requirement
should be relaxed, then further discussion is probably warranted.
On Mon, 2021-11-29 at 00:22 -0500, David Mertz, Ph.D. wrote:
> On Mon, Nov 29, 2021, 12:16 AM Paul Bryan wrote:
> > And t
I propose there is already a viable option in typing.Annotated.
Example:
@dataclass
class InventoryItem:
"""Class for keeping track of an item in inventory."""
name: Annotated[str, "Short name of the item."]
unit_price: Annotated[float, "Price per unit in dollar."]
...
I've
ar to require changes to the interpreter.
On Wed, 2021-12-08 at 13:04 -0500, Ricky Teachey wrote:
> On Wed, Dec 8, 2021 at 12:46 PM Paul Bryan wrote:
> > I propose there is already a viable option in typing.Annotated.
> > Example:
> >
> > @dataclass
> > cla
On Thu, 2021-12-09 at 12:32 +1100, Steven D'Aprano wrote:
> On Wed, Dec 08, 2021 at 09:45:35AM -0800, Paul Bryan wrote:
>
> > I propose there is already a viable option in typing.Annotated.
> > Example:
> >
> > @dataclass
> > class InventoryItem:
> &g
ion that those strings don't "go
anywhere" (i.e. they're not in help documentation, they're not
introspectable.)
> On 2021-12-08 13:25:55, Ricky Teachey wrote:
> > On Wed, Dec 8, 2021 at 1:20 PM Paul Bryan wrote:
> > > I believe a Annotated[..., str] could
I think that because Sphinx could interpret strings below attributes
for documentation, that perhaps we should go in that direction in
Python proper.
Personally, I find this more readable:
class C:
x: Annotated[str, "Doc string"]
y: Annotated[int, "Doc string"]
over:
class C:
x:
On Sat, 2021-12-11 at 17:02 -0800, Christopher Barker wrote:
> It [Annotated] has a number of possible unspecified uses, but
> fundamentally, it's about the adding information to the type, not to
> the attribute -- e.g. not really intended for docstrings.
Ah, good point. I've conflated the two be
On Sun, 2021-12-12 at 12:23 -0800, Christopher Barker wrote:
> As for Typing.Annotated: it has one advantage in that typing tools
> currently (presumably) already accommodate extracting the type
> information from it -- see what typing.get_type_hints() does.
Confirmed. I have tooling today using
On Mon, 2021-12-13 at 09:57 +1100, Steven D'Aprano wrote:
> On Sun, Dec 12, 2021 at 12:48:36PM -0800, Paul Bryan wrote:
>
> > But what's being annotated, the type or the attribute?
>
> That's easy to test:
>
>
> > > > class A:
> ...
On Mon, 2021-12-13 at 11:22 +1100, Steven D'Aprano wrote:
> On Sun, Dec 12, 2021 at 03:38:23PM -0800, Paul Bryan wrote:
>
> > OK, so it's not the type, except it kind of is.
>
> Except it isn't annotating the type, it is annotating the attribute.
>
>
If we proceed with using `Annotated`, I suggest it be the last string
in the metadata. Using your example:
spam: Annotated[
int,
Positive,
GreaterThan[1],
"Doc string goes here..."
Union[Odd|Literal[2]],
Prime,
Wibble,
Wobble,
] = 2
In other words, strings would be reserved to spe
Interesting. Some apparent downsides:
- doesn't apply to class attributes
- objects with `__slots__` can't dynamically add attributes
On Wed, 2021-12-15 at 11:13 +1100, Steven D'Aprano wrote:
> Hmmm, well it seems that we already have support for class attribute
> docstrings, since Python 3.8.
+1
"x-" prefix indicates ad hoc (unofficial), not deprecated.
I agree, an official MIME type should be preferred over an unofficial
one.
On Tue, 2022-01-18 at 16:26 +, [email protected] wrote:
> mimetypes are parsed from the file /etc/mime.types
>
> cat /etc/mime.types | grep javascript
>
+1
On Wed, 2022-01-19 at 07:20 +, Ben Rudiak-Gould wrote:
> My preferred syntax for a frozenset literal would be something like
>
> {1, 2, 3}.freeze()
>
> This requires no new syntax, and can be safely optimized at compile
> time (as far as I can tell).
>
> set.freeze would be a new met
I like the idea, quite a bit. Unfortunately, string annotations are
currently reserved for type annotations (particularly for forward
references), so`x: str` and `x: "str"` are currently equivalent. This
would rule-out using string literals in the manner you suggest.
On Sat, 2022-02-05 at 23:21 +0
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@pytho
I meant to ask, why is nan not comparable? Even:
>>> math.nan == math.nan
False
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.py
On Fri, 2020-09-25 at 18:19 +0200, Marco Sulla wrote:
> That I hope it's not the place where this proposal will be sent.
>
> My idea is apparently simple: what if, anytime we create an object,
> instead of deleting it, we send it in a trash bin? If the object is,
> for some reason, recreated, we c
Can you explain why Python should behave differently than other
languages?
Python:
>>> math.inf == 2 * math.inf
True
JavaScript:
> Infinity == 2 * Infinity
true
Wolfram Alpha:
https://www.wolframalpha.com/input/?i=inf+%3D+2+*+inf+%3D+3+*+inf
∞ = 2∞ = 3∞
True
On Sun, 2020-10-11 at 17:39 -0400,
print is now a function, and as such can be passed to something that
expects a callable. We would lose this if it were restored to a
statement. Consequently this would be a breaking change, so I don't see
it happening.
On Tue, 2020-10-20 at 01:21 +0200, J. Pic wrote:
> +1 because print is a debugg
Yeah, I should have done that instead of replying without context. 🤦
On Tue, 2020-10-20 at 17:43 +1100, Chris Angelico wrote:
> On Tue, Oct 20, 2020 at 3:47 PM Paul Bryan wrote:
> >
> > print is now a function, and as such can be passed to something
> > that expects a ca
pbryan@dynamo:~$ python3
Python 3.8.6 (default, Sep 30 2020, 04:00:38)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import annotations
>>> Any
Traceback (most recent call last):
File "", line 1, in
NameError: name 'Any' is not
ot defined
>>>
On Mon, 2020-11-30 at 06:10 +, Steve Barnes wrote:
> Any only works as an annotation:
>
> In [3]: def fn(*argv: Any) -> Any:
> ...: return argv[0]
> ...:
>
>
> From: Paul Bryan
> Sent: 30 November 2020 05:55
> To: Inada
s the Any type available for use
> during **annotations** i.e. if you follow the below with:
> In [6]: from typing import Any
>
> In [7]: get_type_hints(fn)
> Out[7]: {'argv': typing.Any, 'return': typing.Any}
>
> So the Any is out of scope for typing unless it is
I'm seeing the need to strip annotations from type hints after they've
been fetched using get_type_hints(..., include_extras=True). There's a
convenient function, typing._strip_annotations,which does exactly that.
Why not make it public?
___
Python-ideas
With PEP 563 behavior going mainstream in Python 3.10, I see some
ramifications, especially for runtime validation of type hints:
1. PEP 563 is changing the scope of evaluation of type hints, and in
some cases it is not feasible to move that scope to the annotated
object's globals. (I appreciate t
cache built into ForwardRef, but it
> appears to be ineffective because a new ForwardRef instance is
> created each time when get_type_hints() encounters a string value.
> Maybe the ForwardRef instance should be stored back into
> `__annotations__`?
>
> On Thu, Dec 10, 2020 a
Very strong +1.
On Wed, 2022-03-02 at 02:28 +0100, Svein Seldal wrote:
> I'm sorry for reposting, but this message got stuck in moderation
> approval for 5 days so I figured I should try again.
>
>
> I'd like to propose extending the for statement to include
> conditionals
> akin to comprehens
1. It aligns with existing syntax in list comprehensions and generator
expressions.
2. In probably majority of cases it would be more readable to me;
"iterate over iterable for items meeting condition:".
3. Could it be easier to optimize an explicit filter expression to
improve iteration performanc
I wonder if applying regular expressions would sufficiently address
your use case.
On Mon, 2022-03-28 at 14:13 +0200, StrikerOmega wrote:
> Hello everyone,
>
> When I am coding in Python I often encounter situations where I have
> a string like this one.
>
> sample="""
> fruit:apple
> tree:[Appl
+1. I would suggest `fromtimestamp` also accept an optional timezone
argument.
On Sun, 2022-06-19 at 11:47 -0700, Lucas Wiman wrote:
> Since "today" depends on the time zone, it should be an optional
> argument to date.today(). The interface should be the same as
> datetime.now(tz=None), with date
What type hint will be exposed for the __init__ parameter? Clearly,
it's not a `str` type in your example; you're passing it an `int` value
in your example. Presumably to overcome this, you'd need yet another
`field` function parameter to provide the type hint for the `__init__`
param?
On Wed, 20
Could the type hint for the __init__ parameter be inferred from the
(proposed) init_fn's own parameter type hint itself?
On Tue, 2022-06-28 at 16:39 +, Steve Jorgensen wrote:
> Dexter Hill wrote:
> > Ah right I see what you mean. In my example I avoided the use of
> > `__init__` and specifical
I think we are saying the same thing. I don't think this would require
another parameter if type checkers are capable of inferring the type
from the parameter to the function to be called on init.
On Wed, 2022-06-29 at 21:26 +, Steve Jorgensen wrote:
> Paul Bryan wrote:
> >
On Tue, 2022-05-31 at 21:08 +, [email protected] wrote:
> On the theme of the addition of pip operators to indicate union, I
> was wondering what people think of using the following shortcuts for
> type hints.
> * type[] be a short-hand for List[type]
I'm at -½ on this idea. Using list[ty
It's unclear to me what `Void` is meant to provide in your example. Is
your hope for a `Void` value to not be passed as a parameter to the
wrapped function?
On Sun, 2022-07-24 at 17:55 +, Крупенков Михаил wrote:
> Hello, I'll give an example:
>
> def func(param="default"):
> ...
>
> def
+0
Questions:
1. What's the use case for partial having __name__?
2. Does this imply it should have __qualname__ as well?
3. What name would be given to (an inherently anonymous) lambda?
Notes:
1. I would prefer __name__ to be more qualifying like its repr (e.g.
partial(foo, "x") → "")
On Mon
1 - 100 of 110 matches
Mail list logo
