I'd like to suggest what I think would be a simple addition to `def` and
`class` blocks. I don't know if calling those "Assignment Blocks" is
accurate, but I just mean to refer to block syntaxes that assign to a name.
Anyway, I propose a combined return-def structure, and optionally also
allowing
Hi Chris,
For the sake of those of us who REALLY don't feel like diving back
> into the extensive threads on this subject, can you please summarize
> the benefits of having this in the stdlib rather than as a third-party
> library?
>
Certainly. We need a standard approach to contracts as opposed
On Wed, Oct 24, 2018 at 9:08 PM Marko Ristin-Kaufmann
wrote:
>
> Hi Chris,
>
>> For the sake of those of us who REALLY don't feel like diving back
>> into the extensive threads on this subject, can you please summarize
>> the benefits of having this in the stdlib rather than as a third-party
>>
My idea is not "assignment blocks" those already exist. `def` and `class`
blocks are both syntaxes that assign to some name. I'm just using the term
to refer to them as a group.
The proposal is just being able to return them. These two examples become
equivalent:
def ignore_exc(exc_type):
> Roadblocks
> During the development, the following roadblocks were encountered:
>
> * We wanted to include the contracts in the output of help(). Unfortunately,
> help() renders the __doc__ of the class and not of the instance. For
> functions, this is the class "function" which you can not
On 10/24/2018 5:30 AM, Anders Hovmöller wrote:
Well that seems super unfortunate. You can opt out of the auto generate
constructor and do it yourself:
@dataclass(init=False)
class Foo:
foo: str
bar: str = None
baz: str
def __init__(self, *, foo, bar = None,
Would you mind providing a bit more details about your proposal?
What exactly are those "Assignment Blocks" supposed to do?
If I understand your proposal correctly you want this:
def my_func():
return def():
print("abc")
to be the same as this:
def my_func():
def
On 24/10/2018 15:04, Calvin Spealman wrote:
My idea is not "assignment blocks" those already exist. `def` and `class`
blocks are both syntaxes that assign to some name. I'm just using the term
to refer to them as a group.
The proposal is just being able to return them. These two examples become
Hi Chris,
If not, all your proposed benefits can be achieved at the level of a
> single project, by just saying "we're going to use THIS contracts
> library", unless I'm misunderstanding something here.
>
I think we are having a big disconnect in the discussion. Please apologize
for my
On Wed, Oct 24, 2018 at 09:18:14AM -0400, Calvin Spealman wrote:
> I'd like to suggest what I think would be a simple addition to `def` and
> `class` blocks. I don't know if calling those "Assignment Blocks" is
> accurate, but I just mean to refer to block syntaxes that assign to a name.
> Anyway,
On Wed, Oct 24, 2018 at 12:57 AM, Chris Angelico wrote:
> For the sake of those of us who REALLY don't feel like diving back
> into the extensive threads on this subject, can you please summarize
> the benefits of having this in the stdlib rather than as a third-party
> library?
>
I'm not
In addition to what GVR wrote, a generator function would have to have its
own syntax - backward compatibility would be another issue.
Virendra Tripathi
Santa Clara, CA
415-910-4955
trip...@gmail.com
On Wed, Oct 24, 2018 at 2:31 PM Greg Ewing
wrote:
> Calvin Spealman wrote:
>
> > def
Well that seems super unfortunate. You can opt out of the auto generate
constructor and do it yourself:
@dataclass(init=False)
class Foo:
foo: str
bar: str = None
baz: str
def __init__(self, *, foo, bar = None, baz):
self.foo = foo
self.bar = bar
I'm rewriting an existing python program using a 3rd party async library
to standard asyncio. That library allows one to check if a timer created
with:
timer = loop.call_later(delay, callback)
is active, i.e. not cancelled and the scheduled callback not executed yet.
I'm missing that
P.S. Here is the link to the github repo:
https://github.com/Parquery/icontract
On Wed, 24 Oct 2018 at 09:40, Marko Ristin-Kaufmann
wrote:
> Hi,
> I would like to give you a short report on the development of icontract
> library following the discussion about the introduction of contracts into
Hi,
I would like to give you a short report on the development of icontract
library following the discussion about the introduction of contracts into
Python (e.g., see [1, 2, 3, 4]).
*Features*
The functionality of icontract library is basically on par with Eiffel,
Cobra and other languages
On Wed, Oct 24, 2018 at 6:41 PM Marko Ristin-Kaufmann
wrote:
> Next Steps?
> I personally doubt that we are enough people to form a party to push for a
> change in the language. A standardized library seems to me like a realizable
> compromise given the state of the discussion on this mail
17 matches
Mail list logo
