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

[Ronie Martinez]

Hi Serhiy,

__setstate__() made it possible to specify the starting point.

Using this method and combining it with binning (if the items does not have
any pattern) worked well!

Thanks for the suggestion.

Cheers!

Best Regards,
Ronie

On Fri, Oct 26, 2018 at 10:31 AM Ronie Martinez 
wrote:

> Hi Serhiy,
>
> I missed the 31st on days range. Thanks for spotting it. I do verify if
> the datetime tuple is correct by passing them to datetime() and raising
> exception later on on the code (see
> https://github.com/Code-ReaQtor/DocCron/blob/1.0.0/doccron/job.py#L180)
>
> Datetime and timedeltas can solve the problem if there is a "pattern" but
> this is not an efficient way.
>
> For example, if there are steps on all the categories or the items have no
> pattern:
>
> datetime_odometer = itertools.product(
> range(2018, 10_000, 5),  # year with steps
> range(1, 13, 3),  # month with steps
> range(1, 32, 4),  # days with steps
> [0, 5, 6, 10, 13, 24],  # hours without steps
> range(0, 60, 6),  # minutes with steps
> range(0, 60, 2)  # seconds with steps
> )
>
>
> Datetime and timedelta will create a lot of overhead and is not the best
> solution. I still believe itertools.product() is the fastest and best
> solution.
>
> Let me read the code for __setstate__ first. Thanks for spotting this!
>
> Best Regards,
> Ronie Martinez
>
>
> On Thu, Oct 25, 2018 at 6:22 PM Serhiy Storchaka 
> wrote:
>
>> 25.10.18 09:31, Ronie Martinez пише:
>> > 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)# seconds
>> > )
>> >
>> >  datetime_of_interest = (2050,6,15,10,5,0)
>> >
>> >  for iin datetime_odometer:
>> >  if i == datetime_of_interest:# target start time
>> >  break
>> >
>> >
>> > if __name__ =='__main__':
>> >  start = time.time()
>> >  main()
>> >  duration = time.time() - start
>> >  print(duration,'seconds')# 91.9426908493042 seconds
>> >
>> >
>> > It took 92 seconds to get to the target start time. It does not only
>> > apply to datetimes but for other purposes that uses "odometer-like"
>> > patterns.
>> >
>> > I don't have any propose solution for now, but I guess adding this
>> > feature within itertools will come in handy.
>>
>> Thank you for clarification. Now I understand your idea.
>>
>> For datetimes it is better to use the datetime classes:
>>
>> def iterdatetimes():
>>  delta = timedelta(microseconds=1)
>>  dt = datetime(2050,6,15,10,5,0)
>>  while True:
>>  yield dt
>>  dt += delta
>>
>> Note that in your example you missed 31th days, but iterate 29th and
>> 30th February.
>>
>> See also the calendar module which provides date range iterators
>> (although not with microsecond precision).
>>
>> Currently for general "odometer-like" patterns you can use the
>> undocumented __setstate__ method of itertools.product. But this is on
>> your own risk.
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ronie Martinez]

Hi Serhiy,

I missed the 31st on days range. Thanks for spotting it. I do verify if the
datetime tuple is correct by passing them to datetime() and raising
exception later on on the code (see
https://github.com/Code-ReaQtor/DocCron/blob/1.0.0/doccron/job.py#L180)

Datetime and timedeltas can solve the problem if there is a "pattern" but
this is not an efficient way.

For example, if there are steps on all the categories or the items have no
pattern:

datetime_odometer = itertools.product(
range(2018, 10_000, 5),  # year with steps
range(1, 13, 3),  # month with steps
range(1, 32, 4),  # days with steps
[0, 5, 6, 10, 13, 24],  # hours without steps
range(0, 60, 6),  # minutes with steps
range(0, 60, 2)  # seconds with steps
)


Datetime and timedelta will create a lot of overhead and is not the best
solution. I still believe itertools.product() is the fastest and best
solution.

Let me read the code for __setstate__ first. Thanks for spotting this!

Best Regards,
Ronie Martinez


On Thu, Oct 25, 2018 at 6:22 PM Serhiy Storchaka 
wrote:

> 25.10.18 09:31, Ronie Martinez пише:
> > 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)# seconds
> > )
> >
> >  datetime_of_interest = (2050,6,15,10,5,0)
> >
> >  for iin datetime_odometer:
> >  if i == datetime_of_interest:# target start time
> >  break
> >
> >
> > if __name__ =='__main__':
> >  start = time.time()
> >  main()
> >  duration = time.time() - start
> >  print(duration,'seconds')# 91.9426908493042 seconds
> >
> >
> > It took 92 seconds to get to the target start time. It does not only
> > apply to datetimes but for other purposes that uses "odometer-like"
> > patterns.
> >
> > I don't have any propose solution for now, but I guess adding this
> > feature within itertools will come in handy.
>
> Thank you for clarification. Now I understand your idea.
>
> For datetimes it is better to use the datetime classes:
>
> def iterdatetimes():
>  delta = timedelta(microseconds=1)
>  dt = datetime(2050,6,15,10,5,0)
>  while True:
>  yield dt
>  dt += delta
>
> Note that in your example you missed 31th days, but iterate 29th and
> 30th February.
>
> See also the calendar module which provides date range iterators
> (although not with microsecond precision).
>
> Currently for general "odometer-like" patterns you can use the
> undocumented __setstate__ method of itertools.product. But this is on
> your own risk.
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ronie Martinez]

Hi Steve,

I tried this when writing DocCron but
it will not work correctly.

Suppose we have minutes with range 0-59 and seconds with range 0-59 but
starting at, say, 5:

When the seconds value reaches 59, on the next iteration the minute value
should increase by 1 (or back to zero) but it will not work that way since
the next rotation will be at 4 transitioning to 5.

So the correct solution is not modifying any of the arrangements.

Best Regards,
Ronie





On Thu, Oct 25, 2018 at 7:31 PM Steven D'Aprano  wrote:

> On Thu, Oct 25, 2018 at 02:31:05PM +0800, Ronie Martinez wrote:
>
> > 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
> > )
>
> When you talked about datetime, I thought you meant actual datetime
> objects. The above is buggy: it ignores the 31st day of January, etc,
> but includes February 29 and 30 every year.
>
>
> > datetime_of_interest = (2050, 6, 15, 10, 5, 0)
> >
> > for i in datetime_odometer:
> > if i == datetime_of_interest: # target start time
> > break
>
> In the most general case, there is no way to jump into the middle of an
> arbitrary iterator, except to start at the beginning and compute the
> values until you see the one that you want. Arbitrary iterators compute
> their values on request, and there is no way to jump ahead except by
> inspecting each value in turn, skipping the ones you don't want.
>
> So unless I have missed something, I think what you are asking for is
> impossible except for special cases like lists.
>
> But in *this* case, modelling an odometer, that special case works:
>
> def rotate(iterable, position):
> L = list(iterable)
> return L[position:] + L[:position]
>
> Which gives us this:
>
> py> months = rotate(range(1, 13), 5)
> py> months
> [6, 7, 8, 9, 10, 11, 12, 1, 2, 3, 4, 5]
>
> Now pass that to itertools.product.
>
> In other words, I think that the right solution here is to construct
> your iterables to start at the position you want, rather than expect
> product() to jump into the middle of the sequence. (Which may not be
> possible.)
>
>
>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Nathaniel Smith]

On Thu, Oct 25, 2018, 14:44 Marko Ristin-Kaufmann 
wrote:

>
> Nathaniel Smith wrote:
>
>> In your position, I wouldn't be talking to the core devs; I'd be
>> writing blog posts to proselytize the advantages of contracts, working
>> with popular projects that are interested in adopting them, writing
>> case studies, going to meetups, submitting talks to pycons, that sort
>> of thing. If you want contracts to become a widely-used thing, you
>> have to convince people to use them. The core team doesn't have a
>> magic wand that can short-circuit that process.
>>
>
> I thought python-ideas is an open list to generally discuss ideas, not the
> core dev list (isn't that python-dev)? That's why I wrote here (after being
> forwarded from python-dev list).
>
> I agree that these efforts you mention would be worthwhile. Implementation
> of a (prototype) library and participating in the discussions on this mail
> list are the maximum effort I can put up at the moment. Maybe in 2019 I
> could manage to go to the local Python summit.
>

Python-ideas is for ideas for changing the python language or standard
library. And the subthread I was replying to was about adding contracts
support to the stdlib, so you're in the right place for that discussion. I
was trying to explain why trying to add contract support to the stdlib
doesn't make much sense right now. And if you switch your focus to trying
to recruit users and collaborators, like I recommend, then python-ideas
isn't the best place to do that. Most of your potential users aren't here!

-n

>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] name2type mapping

[Guido van Rossum]

On Thu, Oct 25, 2018 at 1:35 PM Steven D'Aprano  wrote:

> On Thu, Oct 25, 2018 at 10:04:05PM +0200, Thomas Güttler Lists wrote:
> > I created a first draft of the name2type mapping which was discussed
> > here some days ago:
>
> Since this is not a language feature, please take the discussion to a
> more appropriate forum such as this:
>
> https://mail.python.org/mailman/listinfo/code-quality
>

Honestly I think you're a little quick to request this discussion be taken
away from python-ideas. Since the feature is intended to be closely
integrated with static type checking (PEPs 484, 526, 544, 561) it may be
PEP-worthy.

As a compromise, perhaps some discussion can take place in the issue
tracker of the repo (https://github.com/guettli/python-name2type-mapping)
Thomas created? If someone with PEP experience is interested they can guide
Thomas into drafting a PEP.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Problems (and solutions?) in writing decorators

[Greg Ewing]

Jonathan Fine wrote:

I also find writing decorators a bit
hard. It seems to be something I have to learn anew each time I do it.
Particularly for the pattern

@deco(arg1, arg2) def fn(arg3, arg4):

> # function body


Perhaps doing something with partial might help here. Anyone here interested
in exploring this?



I can't think of a way that partial would help. But would
you find it easier if you could do something like this?

class deco(Decorator):

def __init__(self, arg1, arg2):
self.arg1 = arg1
self.arg2 = arg2

def invoke(self, func, arg3, arg4):
# function body

Implementation:

class Decorator:

def __call__(self, func):
self._wrapped_function = func
return self._wrapper

def _wrapper(self, *args, **kwds):
return self.invoke(self._wrapped_function, *args, **kwds)

--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Marko Ristin-Kaufmann]

Hi,

Stephen J. Turnbull wrote:

> You can't weaken the
> contracts for iparent.recontract as far as I can see in a decorator-
> based contract library


Of course you can weaken the contracts for iparent.recontract with a
decorator-based contract library. From my first message:

> The features include:
> ...
>
* inheritance of the contracts (with strengthening/weakening)
> ...
>

Please also have a look at the readme on
https://github.com/Parquery/icontract/, Section "Inheritance".

Chris Barker wrote:

> However, I'm not sure it's anywhere near time to actually do that --
> before we get there, there needs to be a pretty good community of folks
> using icontract (or maybe something else?) and ideally some interest from a
> core developer or two.


I absolutely agree. In my first message I wrote:

> Before we organize a collective to write a proposal to standardize the
> library, I would suggest that a couple of other interested teams adopt
> icontract, apply it to their code bases and report their experiences on
> this mail list. I hope that 2-3 reports would be insightful enough to
> either convince other people that contracts in python are worth
> standardizing (and highlight missing features yet to be implemented) or
> provide solid material to discard the endeavor at the current moment.
>

and in my second message (before yours), I wrote:

> My conclusion is at this point is that the best course of action would be
> that other teams pick up a contract library (now that there is at least
> icontract library with a full feature set for design-by-contract akin to
> Eiffel and other languages), and present us how they use contracts and what
> problems they were facing (*e.g., *were there any problems with the
> toggling granularity? readability? maintainability?). Then we decide how to
> proceed.
>

Stefane Fermigier wrote:

> 1) Just as with with PEP 484, we could distinguish between contract
> specification and checking. To achieve some of the goals that you state, we
> need to standardise the way people would state contracts in their code (and
> provide a small implementation in the stdlib, similar to the typing
> module), but how these contracts are verified (at runtime or statically) or
> leveraged in the documentation are left to third party projects (similar to
> mypy & al).
>

This is a great idea -- though I'm not sure how it could be implemented
other than already specifying the implementation (i.e. how the contracts
are verified). If you have some time, could you elaborate a bit how this
might work? I'm suffering from tunnel vision at this point after
implementing the library.


> 2) Building momentum is paramount. First, since there are many contracts
> libraries out there, some dating more than 15 years (ex: PyDBC), we'd need
> to build consensus between the people who wrote and use these libraries.
> And of course, get feedback from people who use this approach on
> significant projects. I'm willing to try your library on one of my projects.
>

Thanks, I'm looking forward to hearing your experience!

I contacted the authors of dpcontracts, but there is still no clear plan of
action how to merge icontract and dpcontracts (see
https://github.com/deadpixi/contracts/issues/15). Other libraries seem
either unmaintained or not applicable except for single-argument checks and
involve custom syntax (like https://pypi.org/project/PyContracts/; I only
played a bit with PyContracts, so it would be great if anybody could tell
their experience with it in a larger code base).

We found that all the present libraries were far from usable for a larger
code base (so we rolled out our own). To the best of our knowledge, none
could deal with inheritance properly (weakening/strengthening) and you
always had to write out the condition along the lambda function (unless the
code was parsed from the documentation which increases the import time
significantly even if you want to disable some of the contracts). As others
already mentioned in the previous discussion, part of the reason for not
adopting DbC was the lack of tools. I'm not saying that icontract should be
that standard tool -- not at all! We need to first find out what such
standard tool would need to fulfill*. *Assuming that we don't make language
changes, what would we like the standard contract library to look like?
What features should it have? What is too much of a niche to be left out?


> 3) Having contracts for most of the stdlib would be a worthy goal (for
> contracts users) but, as noted by some, would come with some speed issues.
> And of course, would represent a multi-year effort. Hopefully your project
> (i.e. standardising a library, but not "contracting" the stdlib) would
> still be valuable if this never happen.
>

I agree.

Nathaniel Smith wrote:

> In your position, I wouldn't be talking to the core devs; I'd be
> writing blog posts to proselytize the advantages of contracts, working
> with popular projects that are interested in 

Re: [Python-ideas] Return for assignment blocks

[Greg Ewing]

Calvin Spealman wrote:
You know what, I /can't/ think of other good examples than slightly 
improved decorators. So, maybe its not that great an idea if it can't be 
applied to at least a few more use cases.


The class version might be useful for things like namedtuple
that dynamically create classes. But that's even rarer than
decorators.

--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] name2type mapping

[Steven D'Aprano]

On Thu, Oct 25, 2018 at 10:04:05PM +0200, Thomas Güttler Lists wrote:
> I created a first draft of the name2type mapping which was discussed 
> here some days ago:

Since this is not a language feature, please take the discussion to a 
more appropriate forum such as this:

https://mail.python.org/mailman/listinfo/code-quality


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Return for assignment blocks

[Steven D'Aprano]

On Thu, Oct 25, 2018 at 08:44:44AM -0400, Calvin Spealman wrote:
> On Wed, Oct 24, 2018 at 4:41 PM Steven D'Aprano  wrote:
[...]
> > I *think* you are proposing the following syntax. Am I right?
> >
> >
> > return def (func):
> > # body of func
> >
> > which is equivalent to:
> >
> > def func:
> > # body of func
> > return func
[...]
> > Aside from saving one line, what is the purpose of this?
> >
> 
> The point is not saving a line or typing, but saving a thought. Expressing
> the intent of the factory function more clearly.

I don't find that it expresses the intent clearly. Perhaps because I 
have read, and written, many factory functions that post-process the 
inner function in some fashion, to me creating the inner function is 
just one step out of possibly many steps, no more special than the 
others and not deserving of any special syntax.

To give a toy example, adding an extra attribute to the function:

def factory(argument):
def inner():
...
inner.spam = "spam"
return inner


Another common pattern for me is changing the name of the inner 
function. Most of the time wraps() does this, but if the factory doesn't 
wrap another function, I frequently change the inner function name 
manually:

 inner.__name__ = some_name() or "default"

Admittedly even for me, the pattern of returning the function 
immediately after it is created (usually after being decorated by 
functools.wraps) is very *common*, but I don't find it *special* enough 
to justify dedicated syntax.


> Decorators don't do more than "saving one line", either.

I didn't say they did.


> But the biggest reason I'd like something like this is that it solves a
> *specific* version of the multi-line anonymous function that comes up over
> and over and over again, and maybe by chipping away at those use-cases we
> can stop seeing *that* debate over and over and over again. :-)

I don't see the connection.

"def" will still be a statement, not an expression, so you can't put it 
in expressions with or without a leading "return" statement:

x = [spam, eggs, return def func(): block, aardvark]

nor can you put it in a lambda. So I don't see why this would help with
the anonymous code block requests.


> So, no, it doesn't save a lot of typing, but I'm never interested in that.
> I don't spend a lot of time typing code, I spend it reading code, and
> something like this would certainly help there, imho.

I don't think it will "certainly" help. I think you're projecting your own 
opinion onto others. I don't find it very readable, and neither have 
some others who commented. When I read a function def, I read it as 
short for "define", an imperative command. "return def(ine)" doesn't 
read like English to me.

I also see return, expect an expression, and instead find a statement, 
so I find it jarring.

If *everything was an expression* in Python, perhaps I would agree with 
you, but then we wouldn't need special syntax because we could already 
write "return def ...". 

But given that we do have the statement vs expression dichotomy in 
Python, making def a special case but only in return statements causes 
an exception in my brain when I read it :-)


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] name2type mapping

[Thomas Güttler Lists]

I created a first draft of the name2type mapping which was discussed 
here some days ago:



https://github.com/guettli/python-name2type-mapping/blob/master/README.rst


Feedback is welcome.


Regards,

  Thomas Güttler


--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Problems (and solutions?) in writing decorators

[Jonathan Fine]

Was: Return for assignment blocks

Anders Hovmöller wrote:

> Personally I often just copy paste an existing decorator and then tweak it 
> instead of writing from scratch because it's too confusing and error prone to 
> do that.

Thank you, Anders, for your honesty. I also find writing decorators a
bit hard. It seems to be something I have to learn anew each time I do
it. Particularly for the pattern

@deco(arg1, arg2)
def fn(arg3, arg4):
# function body

Perhaps doing something with partial might help here. Anyone here
interested in exploring this?

-- 
Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Return for assignment blocks

[Guido van Rossum]

On Thu, Oct 25, 2018 at 7:41 AM Calvin Spealman  wrote:

>
> On Thu, Oct 25, 2018 at 9:28 AM Anders Hovmöller 
> wrote:
>
>> [Calvin]
>> > The point is not saving a line or typing, but saving a thought.
>> Expressing the intent of the factory function more clearly.
>>
> [...]

> You know what, I *can't* think of other good examples than slightly
> improved decorators. So, maybe its not that great an idea if it can't be
> applied to at least a few more use cases.
>

I appreciate that you're saving a thought, and I think it isn't a bad idea.
It is indeed a very common pattern in decorators. But it would be a bit of
a one-trick pony, since there aren't many *other* situations where it's
useful. Compared to decorators themselves (which also, as was pointed out,
do so much more than "saving a line") the use case is just much narrower.
So unless we find more use cases, or until we can convince ourselves that
we can use `def (args): block` in all expression contexts, I guess it'll
have to remain an idea. Thank you though! It was a fascinating one.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Return for assignment blocks

[Calvin Spealman]

On Thu, Oct 25, 2018 at 9:28 AM Anders Hovmöller 
wrote:

>
> > The point is not saving a line or typing, but saving a thought.
> Expressing the intent of the factory function more clearly.
>
> Could you give some other usage examples?
>
> To me it seems like a nicer and less confusing way to create decorators is
> warranted but could then be more specialized and this much nicer. We
> wouldn't necessarily get to that future point by adding super tiny
> improvements to what we have, but instead take a step back and rethink what
> the syntax could be. Personally I often just copy paste an existing
> decorator and then tweak it instead of writing from scratch because it's
> too confusing and error prone to do that.
>

You know what, I *can't* think of other good examples than slightly
improved decorators. So, maybe its not that great an idea if it can't be
applied to at least a few more use cases.

/ Anders
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Return for assignment blocks

[Anders Hovmöller]

> The point is not saving a line or typing, but saving a thought. Expressing 
> the intent of the factory function more clearly.

Could you give some other usage examples? 

To me it seems like a nicer and less confusing way to create decorators is 
warranted but could then be more specialized and this much nicer. We wouldn't 
necessarily get to that future point by adding super tiny improvements to what 
we have, but instead take a step back and rethink what the syntax could be. 
Personally I often just copy paste an existing decorator and then tweak it 
instead of writing from scratch because it's too confusing and error prone to 
do that. 

/ Anders
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Return for assignment blocks

[Calvin Spealman]

On Wed, Oct 24, 2018 at 4:41 PM Steven D'Aprano  wrote:

> 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, I propose a combined return-def structure, and optionally also
> > allowing a return-class version. Omitting the name would be allowable, as
> > well.
> >
> > This would only apply to a `def` or `class` statement made as the last
> part
> > of the function body, of course.
> >
> > def ignore_exc(exc_type):
> > return def (func):
> > @wraps(func)
> > return def (*args, **kwargs):
> > try:
> > return func(*args, **kwargs)
> > except exc_type:
> > pass
>
> Your example is too complex for me this early in the morning -- I can't
> tell what it actually *does*, as it is obscured by what looks like a
> bunch of irrelevent code.
>
> I *think* you are proposing the following syntax. Am I right?
>
>
> return def (func):
> # body of func
>
> which is equivalent to:
>
> def func:
> # body of func
> return func
>
> And similar for classes:
>
> return class (K):
> # body of K
>
> being equivalent to:
>
> class K:
> # body of K
> return K
>
>
> Is it intentional that your example function takes no arguments? If the
> function did, where would the parameter list go in your syntax?
>
> Aside from saving one line, what is the purpose of this?
>

The point is not saving a line or typing, but saving a thought. Expressing
the intent of the factory function more clearly.

Decorators don't do more than "saving one line", either.

But the biggest reason I'd like something like this is that it solves a
*specific* version of the multi-line anonymous function that comes up over
and over and over again, and maybe by chipping away at those use-cases we
can stop seeing *that* debate over and over and over again. :-)

So, no, it doesn't save a lot of typing, but I'm never interested in that.
I don't spend a lot of time typing code, I spend it reading code, and
something like this would certainly help there, imho.


> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Return for assignment blocks

[Rhodri James]

On 25/10/2018 02:15, Virendra Tripathi wrote:

In addition to what GVR wrote, a generator function would have to have its
own syntax - backward compatibility would be another issue.


No it wouldn't.  This is about returning the function/generator/class 
itself, not its results.


I still don't think it's worth it, mind you.


On Wed, Oct 24, 2018 at 2:31 PM Greg Ewing 
wrote:


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.

--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

On Thu, Oct 25, 2018 at 02:31:05PM +0800, Ronie Martinez wrote:

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

When you talked about datetime, I thought you meant actual datetime 
objects. The above is buggy: it ignores the 31st day of January, etc, 
but includes February 29 and 30 every year.


> datetime_of_interest = (2050, 6, 15, 10, 5, 0)
> 
> for i in datetime_odometer:
> if i == datetime_of_interest: # target start time
> break

In the most general case, there is no way to jump into the middle of an 
arbitrary iterator, except to start at the beginning and compute the 
values until you see the one that you want. Arbitrary iterators compute 
their values on request, and there is no way to jump ahead except by 
inspecting each value in turn, skipping the ones you don't want.

So unless I have missed something, I think what you are asking for is 
impossible except for special cases like lists.

But in *this* case, modelling an odometer, that special case works:

def rotate(iterable, position):
L = list(iterable)
return L[position:] + L[:position]

Which gives us this:

py> months = rotate(range(1, 13), 5)
py> months
[6, 7, 8, 9, 10, 11, 12, 1, 2, 3, 4, 5]

Now pass that to itertools.product.

In other words, I think that the right solution here is to construct 
your iterables to start at the position you want, rather than expect 
product() to jump into the middle of the sequence. (Which may not be 
possible.)



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Serhiy Storchaka]

25.10.18 09:31, Ronie Martinez пише:

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)# seconds
)

 datetime_of_interest = (2050,6,15,10,5,0)

 for iin datetime_odometer:
 if i == datetime_of_interest:# target start time
 break



if __name__ =='__main__':
 start = time.time()
 main()
 duration = time.time() - start
 print(duration,'seconds')# 91.9426908493042 seconds


It took 92 seconds to get to the target start time. It does not only 
apply to datetimes but for other purposes that uses "odometer-like" 
patterns.


I don't have any propose solution for now, but I guess adding this 
feature within itertools will come in handy.


Thank you for clarification. Now I understand your idea.

For datetimes it is better to use the datetime classes:

def iterdatetimes():
delta = timedelta(microseconds=1)
dt = datetime(2050,6,15,10,5,0)
while True:
yield dt
dt += delta

Note that in your example you missed 31th days, but iterate 29th and 
30th February.


See also the calendar module which provides date range iterators 
(although not with microsecond precision).


Currently for general "odometer-like" patterns you can use the 
undocumented __setstate__ method of itertools.product. But this is on 
your own risk.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stéfane Fermigier]

A few thoughts:

1) Just as with with PEP 484, we could distinguish between contract
specification and checking. To achieve some of the goals that you state, we
need to standardise the way people would state contracts in their code (and
provide a small implementation in the stdlib, similar to the typing
module), but how these contracts are verified (at runtime or statically) or
leveraged in the documentation are left to third party projects (similar to
mypy & al).

2) Building momentum is paramount. First, since there are many contracts
libraries out there, some dating more than 15 years (ex: PyDBC), we'd need
to build consensus between the people who wrote and use these libraries.
And of course, get feedback from people who use this approach on
significant projects. I'm willing to try your library on one of my projects.

3) Having contracts for most of the stdlib would be a worthy goal (for
contracts users) but, as noted by some, would come with some speed issues.
And of course, would represent a multi-year effort. Hopefully your project
(i.e. standardising a library, but not "contracting" the stdlib) would
still be valuable if this never happen.

4) Interaction between contracts and typing is an open question.

  S.


On Wed, Oct 24, 2018 at 9:40 AM Marko Ristin-Kaufmann <
marko.ris...@gmail.com> 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
> Python (e.g., see [1, 2, 3, 4]).
>
> *Features*
> The functionality of icontract library is basically on par with Eiffel,
> Cobra and other languages supporting contracts except for loop invariants
> and less readable syntax.
>
> The features include:
> * "require", "ensure" and "invariant" decorators to define the contracts
> * "snapshot" decorator to capture the values prior to the function
> invocation to allow postconditions to verify the state transitions
> * inheritance of the contracts (with strengthening/weakening)
> * tracing of the argument values on contract violation
> * informative violation messages automatically parsed from the code of the
> condition function
> * The user can specify custom errors to be raised on a specific contract
> violation
> * individual toggling of the contracts
> * linter to check the contract arguments
> * sphinx extension to render the contracts automatically in the
> documentation (including a sophisticated matching of logical implications)
>
> We covered all the use cases we could find in our code base (at Parquery
> AG) such as:
> * functions
> * instance methods
> * class and static methods
> * property getters, setters and deleters
> * slot wrappers
>
> *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
> inherit from. See [5] for more details.
>
> * We need to inspect the source code of the condition and error lambdas to
> generate the violation message and infer the error type in the
> documentation, respectively. inspect.getsource(.) is broken on lambdas
> defined in decorators in Python 3.5.2+ (see [6]). We circumvented this bug
> by using inspect.findsource(.), inspect.getsourcefile(.) and examining the
> local source code of the lambda by searching for other decorators above and
> other decorators and a function or class definition below. The decorator
> code is parsed and then we match the condition and error arguments in the
> AST of the decorator. This is brittle as it prevents us from having partial
> definitions of contract functions or from sharing the contracts among
> functions.
>
> Here is a short code snippet to demonstrate where the current
> implementation fails:
> import icontract
>
> require_x_positive = icontract.require(
> lambda x: x > 0, error=lambda: ValueError("x must be positive"))
>
> @require_x_positive
> def some_func(x: int) -> None:
> pass
>
> However, we haven't faced a situation in the code base where we would do
> something like the above, so I am unsure whether this is a big issue. As
> long as decorators are directly applied to functions and classes,
> everything worked fine on our code base.
>
>
> *Our Experience*
> We have been using icontract in our team for our production code base
> (~100K LOC) as well as for a couple of open source projects (each <10K LOC)
> since August 1st 2018 (~ 3 months).
>
> In contrast to points raised during the discussions in [1, 2, 3, 4], we
> did not have issues with readability and modifying contracts. Thus far, we
> have not encountered problems with variable renames and major code
> refactorings. We use Pycharm, so it remains open whether this also applies
> to development environments such as emacs and vim.
>
> We confirm that contracts help us improve the documentation, keep the
>