I'm of the opinion that trying to sandbox an otherwise unaltered
runtime and standard library will run into the same walls as previous
attempts. My sense of this is if the Python community had the appetite
for effective fine-grained access control policies, it would require
embedding enforcement in
For such a thing to be useful, it will ultimately need to percolate up
to users to understand what they are getting themselves into by using
some application. Would this be correct in your view?
Would permissions be attached to individual modules? Packages? Would
they be declarative ahead of time,
It seems to me it would safer to do this in conjunction with
contextvars.ContextVar.
On Wed, Nov 30 2022 at 08:44:50 PM +0100, Benedict Verhegghe
wrote:
A context manager could be used for this. On exit it should delete the
variables created inside it. Someting like this:
class Scope:
de
For my edification, how is copy in pathlib proposed to be implemented?
Just call out to the OS to do the copy? Do the copy by reading and
writing?
On Tue, 2022-10-18 at 19:24 -0400, Todd wrote:
> On Tue, Oct 18, 2022 at 6:26 PM Chris Angelico
> wrote:
> > On Wed, 19 Oct 2022 at 09:17, Todd wrote
+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
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
On Tue, 2022-05-31 at 21:08 +, kevinlu1...@gmail.com 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
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:
> >
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
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
+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
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. 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
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
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
+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
+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 +, mil...@gmail.com wrote:
> mimetypes are parsed from the file /etc/mime.types
>
> cat /etc/mime.types | grep javascript
>
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.
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
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.
>
>
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 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 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
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:
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
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
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
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
; 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
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,
>
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
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
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
+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(
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
__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.
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'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 +, thomas.d.mc...@gmail.com wrote:
> Sorry for the double post
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 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 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
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
On Wed, 2021-06-23 at 21:18 -0700, yselivanov...@gmail.com 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
___
+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
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.
>
> >>>
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
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
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
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
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
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
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
+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:
> ...
> ``
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
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
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
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
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,
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
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:
> >
> &
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 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
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'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
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
+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
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
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
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
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:
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
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
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'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
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-
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
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
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
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,
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
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
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 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'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
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
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
"""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:
>
>
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:
Eric V. Smith wrote:
> See https://bugs.python.org/issue33129. I've not done much with this
> issue, because I'm not crazy about the API, and I'd like to do
> something with positionally-only arguments at the same time. But I
> think in general it's a good idea.
>
The main benefits of this proposal:
- the order of fields (those with defaults, those without) is
irrelevant
- don't need to pedantically add default = None for Optional values
On Sun, 2021-01-24 at 19:46 +0000, Paul Bryan via Python-ideas wrote:
> I've created a helper class in m
I've created a helper class in my own library that enhances the
existing dataclass:
a) __init__ accepts keyword-only arguments,
b) Optional[...] attribute without a specified default value would
default to None in __init__.
I think this could be useful in stdlib. I'm thinking a dataclass
decorato
Reading through the PEP again and some of the discussion, I think I now
better understand the issue.
If we were to undertake a change in for's behavior, unless the
generator is actually explicitly scoped to the for statement (and
doesn't survive outside of the loop, which is not how it works today
d that changing the default
> behavior of for loops would break too much code.
>
> I wonder if the new PEG parser would allow us to decorate for loops
> with context sensitive keywords to override this default behavior
> without requiring code restructuring (adding a with statement).
>
I've now encountered an issue I believe that PEP 533 was intended to
address:
When an asynchronous context manager is created within an asynchronous
generator, if the generator is not iterated fully, the context manager
will not exit until the event loop cancels the task by raising
a CancelledErro
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
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
>
> -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
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
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
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
1 - 100 of 110 matches
Mail list logo
