Steven D'Aprano wrote:
> On Wed, Dec 09, 2020 at 12:05:17PM -, Mathew Elman wrote:
> > Steven D'Aprano wrote:
> > On Tue, Dec 08, 2020 at 11:46:59AM -, Mathew
> > Elman wrote:
> > I would like to propose adding lazy types for
> > casting
> > builtins in a
> > lazy fashion. e.g. lazy_tuple
08.12.20 22:14, M.-A. Lemburg пише:
> On 08.12.2020 20:47, Gregory Szorc wrote:
>> Anyway, I was encouraged by Brett Cannon to email this list to assess the
>> appetite for introducing a backwards incompatible change to this behavior. So
>> here's my strawman/hardline proposal:
>>
>> 1. 3.10 introd
On 10.12.2020 14:18, Serhiy Storchaka wrote:
> 08.12.20 22:14, M.-A. Lemburg пише:
>> On 08.12.2020 20:47, Gregory Szorc wrote:
>>> Anyway, I was encouraged by Brett Cannon to email this list to assess the
>>> appetite for introducing a backwards incompatible change to this behavior.
>>> So
>>> he
09.12.20 22:39, Steven D'Aprano пише:
> On Wed, Dec 09, 2020 at 01:56:01PM +0200, Serhiy Storchaka wrote:
>
>> Thank you for good explanation of the problem.
>
> I'm sorry Serhiy, I disagree that this has been a "good explanation of
> the problem".
>
> Gregory has not identified any actual bugs
On Thu, Dec 10, 2020 at 03:46:37PM +0200, Serhiy Storchaka wrote:
> Maybe it is just me, because I read the original issue. But Gregory's
> message looks to me well organized and answering questions that were
> asked before and possible new questions.
>
> Here is an example. File "foo/__init__.py
On 12/9/2020 10:39 AM, Chris Angelico wrote:
On Thu, Dec 10, 2020 at 12:38 AM sam bland wrote:
In response to the additional work required to convert the new python dataclass
using the json encoder I propose an __encode__ method that will be included in
the default dataclass attributes. This
On 12/10/2020 10:08 AM, Eric V. Smith wrote:
The dataclass metadata feature was added for this type of use, or at
least experimenting with it:
...
I realize this isn't helpful in general, where a dataclass is a member
of another object hierarchy. But it could be leveraged by a
json.JSONEnc
On Thu, Dec 10, 2020 at 5:47 AM Serhiy Storchaka
wrote:
> 09.12.20 22:39, Steven D'Aprano пише:
> > On Wed, Dec 09, 2020 at 01:56:01PM +0200, Serhiy Storchaka wrote:
> >
> >> Thank you for good explanation of the problem.
> >
> > I'm sorry Serhiy, I disagree that this has been a "good explanation
All I have to add is that I am appalled that people actually write `from
foo import __init__`, and I am sorry that we left this hole open when
implementing packages. I don't know what's the best way forward now that
the cat is out of the bag, but deprecation seems a reasonable thing to do.
As for
On Thu, 10 Dec 2020 at 17:48, Gregory Szorc wrote:
> So one can make the argument that this one-off behavior of PathFinder
> undermines the ability to easily distribute Python applications and that in
> turn undermines the value of Python in the larger ecosystem. My opinion is
> the harm infli
10.12.20 16:40, Steven D'Aprano пише:
> On Thu, Dec 10, 2020 at 03:46:37PM +0200, Serhiy Storchaka wrote:
>
>> Maybe it is just me, because I read the original issue. But Gregory's
>> message looks to me well organized and answering questions that were
>> asked before and possible new questions.
>
I do not want to make type-checker a part of CPython, I just what options that
will allow to run python with first some type-checker ...
For example, you would be able to set default python module for type-checking
and if there is not module set for type checking, verify if `mypy` installed
and
On Thu, Dec 10, 2020 at 10:57:32AM -0800, Guido van Rossum wrote:
> All I have to add is that I am appalled that people actually write `from
> foo import __init__`
I too would be appalled if that was what people are doing, but it isn't.
Looking at the code samples in the wild:
https://github.co
December 10, 2020 4:18 PM, redrad...@gmail.com wrote:
> I do not want to make type-checker a part of CPython, I just what options
> that will allow to run
> python with first some type-checker ...
> For example, you would be able to set default python module for type-checking
> and if there is n
I would think this is something that should live in the type checker rather
than cpython. They could have an argument to run cpython after doing the
check.
On Sun, Dec 6, 2020, 05:23 wrote:
> It would be nice to have "Typed Python" mode that will look like this:
>
> ```bash
> #!/usr/bin/env bas
On Thu, Dec 10, 2020 at 1:22 PM Steven D'Aprano wrote:
> On Thu, Dec 10, 2020 at 10:57:32AM -0800, Guido van Rossum wrote:
>
> > All I have to add is that I am appalled that people actually write `from
> > foo import __init__`
>
> I too would be appalled if that was what people are doing, but it
No, it is not good design choose, because then all type-checker will have
different optional and it will be a mess ...
It should be done in one place like python
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to pyt
It is also about convenience
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.or
On 12/10/20 2:08 PM, redrad...@gmail.com wrote:
It is also about convenience
It takes a stronger argument than convenience to get something added to the
stdlib.
--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send
On Thu, Dec 10, 2020 at 17:12 wrote:
> No, it is not good design choose, because then all type-checker will have
> different optional and it will be a mess ...
> It should be done in one place like python
I think the nature of open source is that all the tools have different
options and it is a
On Wed, Dec 9, 2020 at 7:54 PM wrote:
> I agree that itertools shouldn't be a collection of vaguely useful
> functions. I proposed that one because I have needed this one many times,
Could you give an actual use case? I haven't been able to imagine one.
-CHB
> often used str.join instead w
Here is an example of how I use it to build an arbitrary long SQL request
without having to pay for long intermediate strings, both in computation on
memory.
from itertools import chain #, join
def join(sep, iterable):
notfirst=False
for i in iterable:
if notf
On Fri, Dec 11, 2020 at 2:46 PM wrote:
>
> Here is an example of how I use it to build an arbitrary long SQL request
> without having to pay for long intermediate strings, both in computation on
> memory.
>
> from itertools import chain #, join
> def join(sep, iterable):
> notfir
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
That looks like a two-line convenience function using no private APIs, so
you can easily include that in your own toolbox if you need it.
If your concern is that get_type_hints() is too slow, submit a PR that
makes it faster. There's a cache built into ForwardRef, but it appears to
be ineffective
Agree that implementation I propose is trivial.
I'm not sure what the benefit of overwriting a string literal in
__annotations__ with the ForwardRef would be when it can be overwritten
with the already evaluated value, hence why I was proposing the latter.
On Thu, 2020-12-10 at 23:00 -0800, Guido
I'm a bit confused here.
there have been multiple discussions on this list about having a magic
methods (maybe __json__) that could be called by the json module (or any
other) -- so that objects could define for themselves how to be encoded as
JSON.
Is this the same idea? in which case, if you do
27 matches
Mail list logo
