[Python-ideas] Contracts in python -- a report & next steps

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 suppor

Re: [Python-ideas] Contracts in python -- a report & next steps

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 >

Re: [Python-ideas] Contracts in python -- a report & next steps

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 list.

Re: [Python-ideas] Python 3.7 dataclasses attribute order

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

Re: [Python-ideas] Contracts in python -- a report & next steps

> 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 i

Re: [Python-ideas] Contracts in python -- a report & next steps

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

Re: [Python-ideas] Python 3.7 dataclasses attribute order

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, ba

Re: [Python-ideas] Contracts in python -- a report & next steps

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 >> li

[Python-ideas] Return for assignment blocks

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 a

Re: [Python-ideas] Return for assignment blocks

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 inner_func():

Re: [Python-ideas] Return for assignment blocks

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): ret

Re: [Python-ideas] Return for assignment blocks

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

Re: [Python-ideas] Return for assignment blocks

On Wed, Oct 24, 2018 at 7:55 AM Rhodri James wrote: > 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. > > > >

Re: [Python-ideas] Contracts in python -- a report & next steps

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 vagueness

Re: [Python-ideas] Contracts in python -- a report & next steps

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 (curre

Re: [Python-ideas] Return for assignment blocks

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,

Re: [Python-ideas] Return for assignment blocks

Calvin Spealman wrote: def ignore_exc(exc_type): return def (func): > ... Something very similar has been suggested before, you might like to review the previous discussion. -- Greg ___ Python-ideas mailing list [email protected]

Re: [Python-ideas] Return for assignment blocks

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 [email protected] On Wed, Oct 24, 2018 at 2:31 PM Greg Ewing wrote: > Calvin Spealman wrote: > > > def ignore

Re: [Python-ideas] Contracts in python -- a report & next steps

Chris Barker via Python-ideas writes: > 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 rath

[Python-ideas] Set starting point for itertools.product()

Hi, My idea is to set the starting point for itertools.product() since it becomes very slow if the point of interest is in the middle. For example when working with datetime tuples with seconds resolution (worst case, milli/mic

Re: [Python-ideas] Return for assignment blocks

The idea is okay, but I'm not keen about the syntax, because it doesn't read well as English. Currently "def" can be read as the verb "define", but "return define" doesn't make sense. Maybe it would be better as a pseudo-decorator: @return def f(args): ... But I'm inclined to ag

Re: [Python-ideas] Contracts in python -- a report & next steps

On Wed, Oct 24, 2018 at 11:23 AM, Marko Ristin-Kaufmann wrote: > I imagine that you conceive contracts purely as an approach to a testing to > be applied to a single project. I'm not talking about that. I'm talking > about two packages on pypi, both specifying contracts, each developed by a > sepa

Re: [Python-ideas] Set starting point for itertools.product()

On Thu, Oct 25, 2018 at 11:47:18AM +0800, Ronie Martinez wrote: > Hi, > > My idea is to set the starting point for itertools.product() > > since it becomes very slow if the point of interest is in the middle. For > example when

Re: [Python-ideas] Set starting point for itertools.product()

Hi Steve, Here is an example: import itertools import time def main(): datetime_odometer = itertools.product( range(2018, 10_000), # year range(1, 13), # month range(1, 31), # days range(0, 24), # hours range(0, 60), # minutes range(0, 60

Re: [Python-ideas] Set starting point for itertools.product()

Ronie Martinez writes: > def main(): > datetime_odometer = itertools.product( > range(2018, 10_000), # year > range(1, 13), # month > range(1, 31), # days > range(0, 24), # hours > range(0, 60), # minutes > range(0, 60) # seconds >