[Python-ideas] Re: Developer messages on install (pip, poetry, etc.)

[Ronie Martinez]

Hi Ned,

That is a very different issue as the ads are similar to what we see when
browsing. These ads are commonly provided by 3rd party ad networks and not
directly related to the package maintainer.

As for this proposal, think of it as links, messages, or announcements
specific to the package/library.

We install these packages using pip, poetry, etc. but we don't see anything
in the terminal that gives them credit for their work.

Regards,
Ronie

On Mon, Mar 23, 2020 at 9:59 PM Ned Batchelder 
wrote:

> On 3/23/20 1:01 AM, Ronie Martinez wrote:
>
> Good day!
>
> I have been developing in Node for a few months now for non-Python
> projects (legacy project) and I found a NPM feature which could be helpful
> to developers of Python libraries.
>
> When you install a NPM package, some show a message from the author after
> installation (see example below).
>
> --
>
> Thank you for using core-js ( https://github.com/zloirock/core-js ) for
> polyfilling JavaScript standard library!
>
>
> The project needs your help! Please consider supporting of core-js on Open
> Collective or Patreon:
>
> > https://opencollective.com/core-js
>
> > https://www.patreon.com/zloirock
>
>
> Also, the author of core-js ( https://github.com/zloirock ) is looking
> for a good job -)
> --
>
> Is it possible to adopt this? My proposal is to add an entry in the
> package metadata which I believe is safer and easier to implement compared
> to running a post-installation script. It is up for developers of package
> managers (pip, poetry, etc.) to actually print these on the terminal.
>
> I appreciate comments and feedback.
>
> Isn't this the same feature that caused a backlash and a ban?
> https://www.zdnet.com/article/npm-bans-terminal-ads/  I'm not an npm
> user, so maybe I'm conflating two different things.
>
> --Ned.
> ___
> 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.org/archives/list/python-ideas@python.org/message/XT5IY37CLA3LLEC7ZDW26LBQHHYIHVAK/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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.org/archives/list/python-ideas@python.org/message/SMWHTMXMRBQQS2IHONYCM66BTEVLZIWX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Developer messages on install (pip, poetry, etc.)

[Ronie Martinez]

Good day!

I have been developing in Node for a few months now for non-Python projects
(legacy project) and I found a NPM feature which could be helpful to
developers of Python libraries.

When you install a NPM package, some show a message from the author after
installation (see example below).

--

Thank you for using core-js ( https://github.com/zloirock/core-js ) for
polyfilling JavaScript standard library!


The project needs your help! Please consider supporting of core-js on Open
Collective or Patreon:

> https://opencollective.com/core-js

> https://www.patreon.com/zloirock


Also, the author of core-js ( https://github.com/zloirock ) is looking for
a good job -)
--

Is it possible to adopt this? My proposal is to add an entry in the package
metadata which I believe is safer and easier to implement compared to
running a post-installation script. It is up for developers of package
managers (pip, poetry, etc.) to actually print these on the terminal.

I appreciate comments and feedback.

Regards,
Ronie
___
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.org/archives/list/python-ideas@python.org/message/CEAVGLCMAHQGV2S5MOZMDUU2NRI2FH55/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Improve of threading.Timer

[Ronie Martinez]

Event scheduler library already exists and can be "tweaked" to become
periodic. - https://docs.python.org/3/library/sched.html

Best Regards,
Ronie

On Sun, Jun 9, 2019, 2:35 AM  wrote:

> Hi,
>
> I recently needed to run a function every half a second and the first
> option was threading.Timer, but it just tick once.
> Based on https://stackoverflow.com/a/48741004 I derived a class from
> Timer to run endlessly, but there are two things I do not like:
> - The function, args and kwargs attributes of Timer are just the same as
> the _target, _args and _kwargs from Thread.
> - It feels better that Timer can "tick" a given number of times.
>
> So I changed Timer to be more inline with the Thread class and make it
> possible to run the function more than once:
>
> class Timer(Thread):
> FOREVER = Ellipsis
>
> def __init__(self, interval, function, args=None, kwargs=None,
>  name=None, *, ticks=1, daemon=None):
> # Keep compatibility with the old Timer, where the default
> # args and kwargs where mutable.
> if args is None:
> args = []
> if kwargs is None:
> kwargs = {}
>
> Thread.__init__(self, target=function,
> args=args, kwargs=kwargs,
> name=name, daemon=daemon)
> self.interval = interval
> self.ticks = ticks
> self.finished = Event()
>
> def cancel(self):
> """Stop the timer if it hasn't finished yet."""
> self.finished.set()
>
> def run(self):
> try:
> while not self.finished.wait(self.interval):
> if self._target and not self.finished.is_set():
> self._target(*self._args, **self._kwargs)
>
> if self.ticks is self.FOREVER:
> continue
>
> self.ticks -= 1
> if self.ticks <= 0:
> break
> finally:
> # Remove the reference to the function for the same
> # reason it is done in Thread.run
> del self._target
> # However, for backwards compatibility do not remove
> # _args and _kwargs as is done in Thread.run
> # del self._args, self._kwargs
>
> self.finished.set()
>
> def join(self, timeout=None):
> # If the timer was set to repeat endlessly
> # it will never join if it is not cancelled before.
> if self.ticks is self.FOREVER:
> self.cancel()
> super().join(timeout=timeout)
>
> @property
> def function(self):
> return getattr(self, '_target', None)
>
> @function.setter
> def function(self, value):
> self._target = value
>
> @property
> def args(self):
> return self._args
>
> @args.setter
> def args(self, value):
> self._args = value
>
> @property
> def kwargs(self):
> return self._kwargs
>
> @kwargs.setter
> def kwargs(self, value):
> self._kwargs = value
>
> The default option for ticks is to run once, just like the current Timer.
>
> With this version it is possible to do things like:
> >>> t = Timer(10.0, f, ticks=3)
> >>> t.start()
> # Will run f three times, with 10 seconds between each call.
>
> >>> t = Timer(10.0, f, ticks=Timer.FOREVER, daemon=True)
> >>> t.start()
> # Will run f every 10 seconds until the end of the program
> # It also stops the thread if the program is interrupted.
>
> >>> t = Timer(10.0, f, ticks=..., daemon=True)
> >>> t.start()
> # Same as above, but I like the usage of Ellipsis here :)
>
>
> Other option is to leave Timer as it is and create a new class, so it is
> not necessary to keep the compatibility with the function, args and kwargs
> attributes:
>
> class Ticker(Thread):
> FOREVER = Ellipsis
>
> def __init__(self, interval, target=None, args=(), kwargs=None,
>  group=None, name=None, *, ticks=1, daemon=None):
> super().__init__(group=group, target=target,
> args=args, kwargs=kwargs,
> name=name, daemon=daemon)
> self.interval = interval
> self.ticks = ticks
> self.finished = Event()
>
> def cancel(self):
> """Stop the timer if it hasn't finished yet."""
> self.finished.set()
>
> def evaluate(self):
> if self._target and not self.finished.is_set():
> self._target(*self._args, **self._kwargs)
>
> def run(self):
> try:
> while not self.finished.wait(self.interval):
> self.evaluate()
>
> if self.ticks is self.FOREVER:
> continue
>
> self.ticks -= 1
> if self.ticks <= 0:
> break
> finally:
> # Remove the reference to the function for the same
> # reason it is done in Thread.run
> del self._target, self._args, self._k

Re: [Python-ideas] Break multiple loop levels

[Ronie Martinez]

What if labels are placed in comments beside the loops, like how type is,
at least, being used by analyzers?

for x in range(100):  # label: outer
for y in range(3):   # label: inner


On Sun, May 12, 2019 at 5:45 PM Steven D'Aprano  wrote:

> On Sun, May 12, 2019 at 11:16:21AM +0200, Oleg Broytman wrote:
> > On Sun, May 12, 2019 at 01:36:28AM -0700, Elias Tarhini <
> elt...@gmail.com> wrote:
> > > If I may propose `break n` as a replacement for the original message's
> > > `break break ... break`, where n>0 is the number of contiguous loops to
> > > break out of and `break 1` is synonymous with `break`. Seems easier on
> my
> > > eyes/noggin than counting out the individual `break` statements.
> >
> >This is very much error-prone because on any refactoring (increasing
> > or decreasing the number of loop levels) one must increase/decrease all
> > numbers in internal loops.
> >
> >Labels are at least stable.
>
> Indeed.
>
> Go has labels for loops:
>
> Label:
> for { ...
>   break Label
> }
>
> as does Rust:
>
> 'label: while condition:
>{
> ...
> break label
> }
>
> We can't use the same syntax in Python, but we might write it like this:
>
> @label while condition:
> block
> break label
>
> and similar with for loops:
>
> @outer for x in range(100):
> @inner for y in range(3):
> if x == y == 1: break  # like ``break inner``
> if x == y == 2: break outer
> print(x, y)
> # break inner jumps to here
> # break outer jumps to here
>
>
> --
> Steven
> ___
> 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] Break multiple loop levels

[Ronie Martinez]

I remembered, there is a "labeled break" in Perl.
https://perldoc.perl.org/functions/last.html

On Sun, May 12, 2019 at 10:50 AM Chris Angelico  wrote:

> On Sun, May 12, 2019 at 12:43 PM David Mertz  wrote:
> >
> > Terry reminds me of a common case I encounter that cannot be transformed
> into a loop over itertools.product(). E.g.
> >
> > for main in stuff:
> > if thing_about(main):
> > for detail in more_stuff(stuff, main):
> > if seen_enough(detail):
> > # break to outer somehow
> > else:
> > for detail in different_stuff():
> > if seen_enough(detail):
> > # break to outer somehow
> >
>
> For that kind of loop, there's a different problem, which is the
> duplication. So I would start by rewriting that as:
>
> for main in stuff:
> if thing_about(main):
> details = more_stuff(stuff, main)
> else:
> details = different_stuff()
> for detail in details:
> if seen_enough(detail):
> ...
>
> I'm not sure what you mean by "break to outer somehow", though, so I
> don't know what you're actually needing here. Concrete examples would
> help.
>
> ChrisA
> ___
> 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/

[Python-ideas] Proposal: Using % sign for percentage

[Ronie Martinez]

Good day!

As Python focuses on readability, why not use % sign for actual percentages?

For example:
```
rate = 0.1058  # float
rate = 10.58%  # percent, similar to above

```

It does not interfere with modulo operator as modulo follows a different
format:
```
a = x % y
```

This looks like a small feature but it will surely set Python a level
higher in terms of readability.

Thanks a lot!
___
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] Add list.join() please

[Ronie Martinez]

If there is a more Pythonic way of joining lists, tuples, sets, etc., it is
by using a keyword and not a method. For example, using a keyword, say
*joins*:

'-' joins ['list', 'of', 'strings']
>

This is more readable than using the method join() since you can read this
as "dash joins a list of strings". Although, the current method of joining
lists is almost similar to this, the current method is somewhat "confusing"
for beginners or for people who came from other languages.

BTW, this is just what comes in my mind and not supported by Python.

On Tue, Jan 29, 2019 at 1:22 PM Brendan Barnwell 
wrote:

> On 2019-01-28 18:22, David Mertz wrote:
> > On Mon, Jan 28, 2019 at 8:44 PM Jamesie Pic  > > wrote:
> >
> > ['cancel', name].join('_')
> >
> >
> > This is a frequent suggestion.  It is also one that makes no sense
> > whatsoever if you think about Python's semantics.  What would you expect
> > to happen with this line:
> >
> > ['foo', b'foo', 37, re.compile('foo')].join('_')
> >
> >   List are not restricted to containing only strings (or things that are
> > string-like enough that they might play well with joining).  Growing a
> > method that pertains only to that specialized sort of list breaks the
> > mental model of Python.  Moreover, there is no way to TELL if a
> > particular list is a "list of strings" other than checking each item
> > inside it (unlike in many languages).
>
> That problem already exists with str.join though.  It's just
> currently
> spelled this way:
>
> ','.join(['foo', b'foo', 37, re.compile('foo')])
>
> . . . and the result is an error.  I don't see how it's
> semantically
> any less sensible to call list.join on a list of non-string things than
> it is to pass a list of non-string things to str.join.
>
> Personally what I find is perverse is that .join is a method of
> strings
> but does NOT call str() on the items to be joined.  The cases where I
> would have been surprised or bitten by something accidentally being
> converted to a string are massively outweighed by the cases where I want
> everything to be converted into a string, because, dangit, I'm joining
> them into a bigger string.
>
> I agree that a list method would be nice, but we then have to
> think
> about should we add similar methods to all iterable types, since
> str.join can take any iterable (not just a list).
>
> --
> Brendan Barnwell
> "Do not follow where the path may lead.  Go, instead, where there is no
> path, and leave a trail."
> --author unknown
> ___
> 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,

__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 <https://github.com/Code-ReaQtor/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] Set starting point for itertools.product()

[Ronie Martinez]

Hi another Steve,

Your code will not work! You are skipping the other values below it. When,
let's say, the minute value reaches 59, the next iterator should return 0.
In your code, it will not. It will start with 5. That is not how an
odometer wheel works.

Best Regards,
Ronie

On Thu, Oct 25, 2018 at 2:59 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> 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
>  > )
>  >
>  > datetime_of_interest = (2050, 6, 15, 10, 5, 0)
>  >
>  > for i in datetime_odometer:
>  > if i == datetime_of_interest: # target start time
>  > break
>
> I don't understand the issue.  Doesn't
>
> def make_odometer(year, month, day, hour, minute, second):
> return itertools.product(
> range(year, 10_000),
> range(month, 13),
> range(day, 31),
> range(hour, 24),
> range(minute, 60),
> range(second, 61)# leap seconds!
> )
>
> def main():
> datetime_of_interest = (2050, 6, 15, 10, 5, 0)
>
> datetime_odometer = make_odometer(*datetime_of_interest)
>
> do what you want?  If you have a task where that *doesn't* do what's
> needed, eg, where the "odometer wheels" are an iterated function
> system, I don't see any way to avoid the problem.  If you have some
> range-like object that doesn't support starting values, you need to
> fix that or there's nothing that could be done about it in itertools.
>
> (Yet Another) Steve
>
> --
> Associate Professor  Division of Policy and Planning Science
> http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information
> Email: turnb...@sk.tsukuba.ac.jp   University of Tsukuba
> Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
>
___
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,

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

Regards,
Ronie

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

> 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()
> > <https://docs.python.org/3.6/library/itertools.html#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/microseconds), you need to skip a lot of items.
>
> I don't understand what you mean by "skip a lot of items" or why this
> applies to datetime tuples.
>
> Can you give a SHORT and SIMPLE example, showing both the existing
> solution and your proposed solution?
>
>
>
> --
> 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/

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

[Ronie Martinez]

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/microseconds), you need to skip a lot of items.

There are several methods I have tried as an alternative but
itertools.product() is the fastest:
- datetime and timedelta
- naive looping

This is where I applied it but the issue at seconds resolution is still a
bottleneck:
https://github.com/Code-ReaQtor/DocCron/blob/1.0.0/doccron/job.py#L171

Setting the starting point might come in handy if we want to skip several
data.
What do you think?

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