I think a datetime.range object could be useful.
Perhaps someone can write one and then see if the core devs would accept it
in the stdlib.
It would be na interesting exercise in any case :-)
-CHB
On Tue, Feb 8, 2022 at 10:38 PM Aman Pandey
wrote:
> I get your point. I checked the code which
I get your point. I checked the code which is in C and implement the
solution which was something similar to yours.
Should we have some function like that in the datetime module that can
generate date, and time as well between two ranges?
This looks like a feature to me that can be helpful.
On 2/8/22 2:08 PM, Abdur-Rahmaan Janhangeer wrote:
> It might be true that the days of batteries included are over,
They are not. Batteries are still included in Python, and more advanced versions of built-in batteries are available
elsewhere.
--
~Ethan~
On Wed, Feb 09, 2022 at 02:08:47AM +0400, Abdur-Rahmaan Janhangeer wrote:
> Proposing this on -ideas as i no longer understand what
> the original thread is about.
You can ask questions on Python-Dev, the people there won't bite, and
may even be more friendly than here *wink*
--
Steve
Greetings list,
Here is a nobody proposing something to be picked
up by more skilled people.
The urllib deprecation thread is scary for many reasons.
I cannot just ignore it as it affects me as a noob user.
The security issues makes one think if we continue shipping
something that always has
On Wed, 9 Feb 2022 at 01:00, Aman Pandey wrote:
>
> I wanted to generate all the dates between two date ranges for which I was
> using count function in the itertools and to my surprise count function
> doesn't support datetime operation.
>
> For example
> >import datetime
> >from itertools
Very nice ideas. The plus and minus signs are much better than :: and :::. I am
glad people are working on that. [+T: (str, int)] would be similar to
TypeVar(“T”, str, int, covariant=True).
Abdulla
Sent from my iPhone
> On 8 Feb 2022, at 6:49 PM, Abdulla Al Kathiri
> wrote:
>
> Thank you
On Tue, 8 Feb 2022 at 14:00, Aman Pandey wrote:
>
> I wanted to generate all the dates between two date ranges for which I was
> using count function in the itertools and to my surprise count function
> doesn't support datetime operation.
>
> For example
> >import datetime
> >from itertools
Thank you Stephan. Very fair points you brought. I will make sure to check the
typing-sig.
Sent from my iPhone
> On 8 Feb 2022, at 6:00 PM, James H-B wrote:
>
> I really like the idea as a whole presented here. I have a few concerns here
> though:
> 1. The support for constraints overlaps
I wanted to generate all the dates between two date ranges for which I was
using count function in the itertools and to my surprise count function
doesn't support datetime operation.
For example
>import datetime
>from itertools import count
>count(datetime.date.today(), datetime.timedelta(1))
I really like the idea as a whole presented here. I have a few concerns here
though:
1. The support for constraints overlaps with union which is undesireable, Jelle
has previously suggested using TypeVar in (constraint1, constraint2, ...) which
I think is much nicer.
2. The syntax for defining
Consider the following config file:
[section]
some_var = 1
[other_section]
other_var = ${section:some_var}
My idea would be to have an optional additional argument to perform some
implied arithmetic e.g.
[other_section]
other_var = ${section:some_var:int} + 1
Thoughts?
Paul
Abdulla Al Kathiri writes:
> I thought this is called python-ideas,
It is, and if that's all you know, this is the *right* place to bring
this kind of idea. I'm sorry, I should have been more clear about
this.
> meaning it’s ok to bring ideas even if they are ugly or stupid.
What I was
On Tue, Feb 8, 2022 at 5:50 AM Paul Moore wrote:
> On Tue, 8 Feb 2022 at 00:09, Neil Girdhar wrote:
> >
> > Currently, some type checkers rightly complain that a method is
> decorated with abc.abstractmethod when the class's type does not inherit
> from ABCMeta. Adding a metaclass is a fairly
On Tue, 8 Feb 2022 at 00:09, Neil Girdhar wrote:
>
> Currently, some type checkers rightly complain that a method is decorated
> with abc.abstractmethod when the class's type does not inherit from ABCMeta.
> Adding a metaclass is a fairly heavy dependency since you're forced to poison
> all
*Your audience is really in the Typing SIG. Happy hunting!Steve*
Until I read that line I thought I was reading Typing-SIG
I was saying cool for once I found a discussion I completely follow,
but dear me, it turned out to be -ideas. Btw every time I read discussions
on Typing-SIG I'm like:
>
>> class Indexable[T_co::](Protocol[T_co]):
>>def __getitem__(self, n: int) -> T_co: …
>
> This is completely new syntax: between the class name and what it
> subclasses, you have a subscript-like syntax.
>
> This is new semantics for subclassing, I think, unless you want
> Indexable to
Personally, I very much like this approach, although I'd definitely prefer
<> brackets instead, like in other languages.
We could possibly think of it as being syntactic sugar for the current
TypeVar approach, and have it translated into TypeVars at runtime.
However, if we'd define it that way,
On Tue, 8 Feb 2022 at 18:59, Abdulla Al Kathiri
wrote:
>
> I thought this is called python-ideas, meaning it’s ok to bring ideas even if
> they are ugly or stupid. No need to introduce it in Python if it’s too much
> but it might induce discussions.
>
Yes, it's absolutely okay to bring ideas
19 matches
Mail list logo
