[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]
On Sun, Aug 23, 2020 at 6:42 PM Todd wrote: > I think it is worth directly discussing the availability of slices in PEP > 472-style keyword indices, > +1 on slices in all indexing. But thus brings up a broader question: Why not allow slice syntax as an expression everywhere? Everywhere I’ve tried, it’s a syntax error now, but is there any technical reason that it couldn’t be used pretty much anywhere? -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/EF7RSFKMOOVMKQKSI3ZGORHQN7L5V2AC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: basic matrix object
Oscar Benjamin writes: > On Mon, 17 Aug 2020 at 07:14, Stephen J. Turnbull > wrote: > > SymPy. > > > > Except that in this conversation, "linear algebra" is likely neither > > restricted to linearity nor so much algebraic as computational, so > > SymPy likely won't do. :-/ > SymPy is exactly what I would recommend for the OP use case of high > school students doing basic linear algebra (although perhaps as > maintainer I would say that...). SymPy's matrix class doesn't have the > complicated broadcasting rules of numpy's ndarray and uses exact > calculations rather than floating point (or limited precision > integers). I'm not sure why it would be considered unsuitable for > this. I didn't say it was unsuitable for high school students. It is, that's why I suggested it. My point was that most of the folks in this conversation don't really want linear algebra, they want fewer comprehensions and 'for' statements and maybe numerical stability (although Ricky's boring friction example doesn't need any special care for stability). Take broadcasting. It is really convenient, for example in computing central moments: vector = [ ... ]# known non-empty mean = sum(vector) / len(vector) variance = ((vector - mean) @ (vector - mean)) / len(vector) I'm not sure you want to allow that in a linear algebra class (although it's a mild and straightforward generalization of scalar multiplication, so maybe a little deemphasis on the "linear"?) > Here's a demonstration: Very nice! > If your high-school students are okay with using Python then I would > certainly recommend SymPy for this kind of calculation. Sure. I just think they should write their own programs for four functions (3 binary operations and inversion, or 2 binary operations and both inversions) first. Once they've got that it's not obvious to me that at that level they need SymPy. (Although it's easy to imagine that in a class of junior high students the ones getting into it will run into numerical instability issues pretty quick, and of course anybody can mess up on conformance.) > On the other hand adding something like this to the stdlib is a very > slippery slope. SymPy's matrices package has 30k lines of code and > counting even though it leverages much of the rest of the sympy > codebase to do the calculations it does. There are a lot of different > features you can add once you have a matrix class. Thank you for pointing that out! Steve ___ 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/22BQLC42M4HXYVWLS6LNIALM5HMHK2L5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] PEP 472 - slices in keyword indices, d[x=1:3]
I think it is worth directly discussing the availability of slices in PEP 472-style keyword indices, since we seem to have mostly converged on a dunder method signature. This is an issue that has been alluded to regarding keyword-based (labelled) indices but not directly addressed. The basic syntax would be something like d[x=1:3]. I am strongly in favor of having slices. The main motivating factor for me, labelled dimensions in xarray, would be much, much less useful without support for slices. In fact, as PEP 472 currently mentions, the big benefit of indexing over method calls is that indexing supports slice syntax while method calls don't. In a more general sense, I feel not allowing slices would create an artificial distinction between labelled and positional indices that I don't think is justified. They would work the same, except for slices where labelled indices behave differently. It would be a strange gotcha. So I think any revision to PEP 472 or new PEP should directly and explicitly support the use of slices. ___ 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/TOABKD7A5X653BTTU3MZICWURNGPMY47/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)
On Sun, Aug 23, 2020 at 03:47:59PM +0100, Stefano Borini wrote:
> I am currently in the process of scouting the whole set of threads and
> rewrite PEP-472, somehow.
> but just as a 2 cents to the discussion, the initial idea was focused
> on one thing only: give names to axes.
That is one of the motivating use-cases, but "axis name" is not the only
use-case for this. Right now I would give my left arm for the ability to
write `matrix[row, column, base=1]` to support standard mathematical
notation which starts indexes at 1 rather than 0.
> Given the asymmetry, and the need for backward compat, would it make a
> possible solution to have __getitem__() accept one additional argument
> "names" containing a tuple with the names?
>
> e.g. if you call a[1,2] __getitem__(index, names) will receive
> index=(1,2), names=(None, None)
> if you call a[foo=1, bar=2] __getitem__ will receive index=(1,2),
> names=("foo", "bar")
> if you call a[1, bar=2] __getitem__ will receive index=(1,2),
> names=(None, "bar")
Advantages over the other suggestions already made: none.
Disadvantages: everything.
(1) Fragile. You mentioned backwards compatibility, so presumably a
single, non-comma separated argument won't receive a name argument at
all:
a[index]
=> a.__getitem__(index)
rather than receiving a "names=None" or "names=()" argument.
That will at least allow code that never uses a comma in the subscript
to work unchanged, but it will break as soon as somebody includes a
comma without a protective set of parentheses:
a[(2,3,4)]
=> a.__getitem__((2, 3, 4))
a[2,3,4]
=> a.__getitem__((2, 3, 4), names=(None, None, None)
So the first version is backwards compatible but the semantically
identical second version breaks.
(2) Not actually backwards compatible. Every `__getitem__` will need to
have a new "names" parameter added or it will break even if no keywords
are used. (See point 1 above.)
(3) We already have two models for matching up arguments to formal
parameters: there is the standard model that uses named parameters and
matches arguments to the named parameter, used everywhere in functions
and methods; and there is the slightly odd, but long established,
convention for subscripts that collects comma-separated positional
arguments into a tuple before matching them to a single named parameter.
This proposal adds a third way to do it: split the parameter names into
a separate positional argument.
(4) This will require the method to do the work of matching up names
with values:
- eliminate values which are paired up with None (positional only);
- match up remaining values with the provided names;
- deal with duplicate names (raise a TypeError);
- deal with missing names (raise a TypeError or provide a default);
- deal with unexpected names (raise a TypeError).
We get this for free with normal parameter passing, the interpreter
handles it all for us. This proposal will require everyone to do it for
themselves.
I once had to emulate keyword-only arguments in Python 2, for a project
that required identical signatures in both 2 and 3. So I wrote the
methods to accept `**kwargs` and parsed it by hand. It really made me
appreciate how much work the interpreter does for us, and how easy it
makes argument passing.
If I had to do this by hand every single time I wanted to support
keyword arguments, I wouldn't support keyword arguments :-)
(5) Being able to see the parameters in the method signature line is
important. It is (partially) self-documenting, it shows default values,
and allows type-hints. There are lots of introspection tools that
operate on the signatures of functions and methods. We lose all of that
with this.
> Now, I personally don't like this solution
Then why suggest it?
Can we just eliminate this from contention right now, without a six week
debate about ways to tweak it so that it's ever so marginally less
awful? You're the PEP author, you don't have to propose this as part of
your PEP if you don't like it. Anyone who thinks they want this can
write a competing PEP :-)
[...]
> But I would like to raise another question. Is there another language
> out there that provides the same feature? I am not aware of any.
It quite astonishes me that the majority of programming languages don't
even supported named keyword arguments in function calls, so I would not
be surprised if there are none that support named arguments to
subscripting.
--
Steven
___
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/CKWE3U3PS2DZSHSPZ5XBOBGL3K2YMV3D/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Enhancement: Adding support for private and name mangled type hints in dataclasses module
I have a proposal for an addition to the dataclasses module that I think would make it easier to use private and name mangled variables. One of the benefits of the dataclass decorator is that it helps lessen the amount of code when you just need a simple constructor. A common pattern in python that isn't addressed by the current implementation is the pattern ```python class MyClass: def __init__(self, a: str, b: str): self._a = a self.__b = b ``` right now the only straightforward way of doing this with a dataclass is ```python @dataclass class MyClass: a: InitVar[str] b: InitVar[str] def __post_init__(self, a, b): self._a = a self.__b = b ``` My proposal would be to add two types to the dataclasses module, one called PrivateVar and one called MangledVar. These would add The above pattern (without the post_init ) using the syntax, ```python @dataclass class MyClass: a: PrivateVar[str] b: MangledVar[str] ``` I've already looked into what would need to be added to dataclasses to implement these and it's just a few lines of code since the class implementation would be very similar to InitVar. Is this something that other see the possibility of being added to python? (Also, I know name mangling isn't super common but I think it may as well be added alongside a private variable implementation)) ___ 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/4JN76TMBGA3YDN5445OR2S7OT32JH2XO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Deferred, coalescing, and other very recent reference counting optimization
Python's cyclic GC collector uses exact reference count. See https://devguide.python.org/garbage_collector/ for detail. On Mon, Aug 24, 2020 at 12:29 AM Raihan Rasheed Apurbo wrote: > > In CPython we have reference counting. My question is can we optimize current > RC using strategies like Deferred RC and Coalescing? If no then where would I > face problem if I try to implement these sorts of strategies? > > These strategies all depend on the concept that we don't need the exact value > of reference count all the time. So far in my observation, we only need exact > value before running a cycle collector. If we can manage to make sure that > we have exact value before entering the cycle collector then in my opinion we > can add these optimizations strategies to some extent. Is there something > that I am missing? Or It is quite possible? If not possible please tell me > the factors I should consider. > > Thanks in advance. > ___ > 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/G2BCHK766Z6ABFEF5KOKC27W4VBNNVSE/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Inada Naoki ___ 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/2Y64LLWFGPUGLOCAC42NPBFSYZGOYWLY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)
On Sun, Aug 23, 2020 at 10:48 AM Stefano Borini
wrote:
> When you have a getitem operation, you are acting on a set of axes.
> e.g. a[4,5,6] acts on three axes. The first axis index is 4, the
> second is 5 and the third is 6.
> These axes currently are anonymous, but the whole idea is that a name
> could be assigned to them.
>
> Which is kind of asymmetric with the whole args/kwargs structure of a
> function. In a function, your "axes" (which are your arguments)
> _always_ have a name. Not so in getitem operations:
> naming axes is optional. There's no such thing as optionally named
> function arguments.
>
> Given the asymmetry, and the need for backward compat, would it make a
> possible solution to have __getitem__() accept one additional argument
> "names" containing a tuple with the names?
>
> e.g. if you call a[1,2] __getitem__(index, names) will receive
> index=(1,2), names=(None, None)
> if you call a[foo=1, bar=2] __getitem__ will receive index=(1,2),
> names=("foo", "bar")
> if you call a[1, bar=2] __getitem__ will receive index=(1,2),
> names=(None, "bar")
>
> Now, I personally don't like this solution, especially because now
> passing names depend if it was declared in the signature to begin
> with, but I am just throwing also this idea in the mix. Apologies if
> it was already passed by someone else.
>
> My point is that the core of the issue is to name axes (with loose
> definition of what axes are. In the case of generic types, they are
> the degrees of freedom of the type).
> How these names are then handled (and recognised) _could_ be put in
> the hands of the user (in other words, python will say "here are the
> names, I have no idea if they mean something or not. it's your duty to
> find out, if you care about it")
>
It's a way of handling it I for one haven't seen suggested yet. I don't
think I like it either.
I suppose a trouble with the basis of this is the assumption that most
users will be using what's inside a [ ] to define axes. Maybe this is
correct. But it could easily be that the most popular usage of providing
these named indices will be more akin to named arguments.
Indeed, nearly all of the discussion (that I've seen at least) has seemed
to presuppose that adding the ability to provide these named indices is
really going to be more akin to a function call.
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
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/WUIMDQPLUHAF3XPJWSSVB5VBHHJQQNHT/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: basic matrix object
On Mon, 17 Aug 2020 at 07:14, Stephen J. Turnbull
wrote:
>
> Christopher Barker writes:
>
> > Anyway, I would like to see a nice linear algebra lib -- but not 'cause I'd
> > use it, only because I find it interesting.
>
> SymPy.
>
> Except that in this conversation, "linear algebra" is likely neither
> restricted to linearity nor so much algebraic as computational, so
> SymPy likely won't do. :-/
SymPy is exactly what I would recommend for the OP use case of high
school students doing basic linear algebra (although perhaps as
maintainer I would say that...). SymPy's matrix class doesn't have the
complicated broadcasting rules of numpy's ndarray and uses exact
calculations rather than floating point (or limited precision
integers). I'm not sure why it would be considered unsuitable for
this.
Here's a demonstration:
>>> from sympy import Matrix
>>> M = Matrix([[1, 2], [3, 4]])
>>> M
Matrix([
[1, 2],
[3, 4]])
>>> M * M
Matrix([
[ 7, 10],
[15, 22]])
>>> 3 * M
Matrix([
[3, 6],
[9, 12]])
>>> M ** -1
Matrix([
[ -2,1],
[3/2, -1/2]])
>>> M.rank()
2
>>> M.det()
-2
>>> M.eigenvals()
{5/2 - sqrt(33)/2: 1, 5/2 + sqrt(33)/2: 1}
There are no funny broadcasting rules. You can multiply two matrices
with * (or @) and if the shapes are compatible in the standard
mathematical rules of matrix multiplication then you will get the
matrix product. You can also multiply a matrix and a scalar as you
would in an equation. No other kind of multiplication is permitted.
You can add two matrices iff they have the same shape. Using ** gives
matrix powers so M**2 or M**-1 are as you would expect when seeing
superscripts in a mathematical equation.
If you don't put floats in the matrix then all of the calculations
will be exact with no overflow and no rounding error. The only thing
to be careful of is Python's division so 1/2 should be sympy's
Rational(1, 2).
If you enter the above in a jupyter notebook (after calling sympy's
init_printing()) then the matrices will all display nicely using
latex->Mathjax under the hood. The same also works in a Qt console
e.g. you can see a nice mathematical display when using a "sympy
console" in the spyder editor.
Of course as the matrices get larger then sympy will be noticeably
slower than numpy. Even the algorithms for computing the eigenvalues
symbolically can breakdown for matrices larger than 4x4 so there are
good reasons why numerical libraries are more commonly used in many
areas. Simple calculations are still faster than the blink of an eye
though and I'm sure some of the high-school students would benefit
from being able to do calculations with things like sqrt(2) or symbols
like x, y, z at some point.
If your high-school students are okay with using Python then I would
certainly recommend SymPy for this kind of calculation.
On the other hand adding something like this to the stdlib is a very
slippery slope. SymPy's matrices package has 30k lines of code and
counting even though it leverages much of the rest of the sympy
codebase to do the calculations it does. There are a lot of different
features you can add once you have a matrix class.
Oscar
___
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/CUELRJNK23FNXT3T3MDLGBMWWLSYJRMM/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Deferred, coalescing, and other very recent reference counting optimization
In CPython we have reference counting. My question is can we optimize current RC using strategies like Deferred RC and Coalescing? If no then where would I face problem if I try to implement these sorts of strategies? These strategies all depend on the concept that we don't need the exact value of reference count all the time. So far in my observation, we only need exact value before running a cycle collector. If we can manage to make sure that we have exact value before entering the cycle collector then in my opinion we can add these optimizations strategies to some extent. Is there something that I am missing? Or It is quite possible? If not possible please tell me the factors I should consider. Thanks in advance. ___ 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/G2BCHK766Z6ABFEF5KOKC27W4VBNNVSE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)
On Sat, 8 Aug 2020 at 05:12, Ricky Teachey wrote:
> The semantic meaning of m[1, 2, a=3, b=2] might be made to mean:
>
> 5.m.__getx__(1, 2, a=3, b=4)
>
> ...which would in turn call, by default:
>
> m.__getitem__((1, 2), a=3, b=4)
I am currently in the process of scouting the whole set of threads and
rewrite PEP-472, somehow.
but just as a 2 cents to the discussion, the initial idea was focused
on one thing only: give names to axes.
When you have a getitem operation, you are acting on a set of axes.
e.g. a[4,5,6] acts on three axes. The first axis index is 4, the
second is 5 and the third is 6.
These axes currently are anonymous, but the whole idea is that a name
could be assigned to them.
Which is kind of asymmetric with the whole args/kwargs structure of a
function. In a function, your "axes" (which are your arguments)
_always_ have a name. Not so in getitem operations:
naming axes is optional. There's no such thing as optionally named
function arguments.
Given the asymmetry, and the need for backward compat, would it make a
possible solution to have __getitem__() accept one additional argument
"names" containing a tuple with the names?
e.g. if you call a[1,2] __getitem__(index, names) will receive
index=(1,2), names=(None, None)
if you call a[foo=1, bar=2] __getitem__ will receive index=(1,2),
names=("foo", "bar")
if you call a[1, bar=2] __getitem__ will receive index=(1,2),
names=(None, "bar")
Now, I personally don't like this solution, especially because now
passing names depend if it was declared in the signature to begin
with, but I am just throwing also this idea in the mix. Apologies if
it was already passed by someone else.
My point is that the core of the issue is to name axes (with loose
definition of what axes are. In the case of generic types, they are
the degrees of freedom of the type).
How these names are then handled (and recognised) _could_ be put in
the hands of the user (in other words, python will say "here are the
names, I have no idea if they mean something or not. it's your duty to
find out, if you care about it")
But I would like to raise another question. Is there another language
out there that provides the same feature? I am not aware of any.
--
Kind regards,
Stefano Borini
___
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/QUXRDOLBUNJGSTTCWA2Y5WBGSGM457D7/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add parse_duration to datetime - a golang like fucntion to parse duration
On Sat, 22 Aug 2020 at 13:08, Oz wrote:
>
> Hi Everyone,
>
> I really like how go parses durations:
>
> ```
> hours, _ := time.ParseDuration("10h")
> complex, _ := time.ParseDuration("1h10m10s")
> micro, _ := time.ParseDuration("1µs")
> // The package also accepts the incorrect but common prefix u for
> micro.
> micro2, _ := time.ParseDuration("1us")
> ```
>
> Consider the example in
> https://docs.python.org/3/library/datetime.html#timedelta-objects:
> ```
> >>> from datetime import timedelta
> >>> delta = timedelta(
> ... days=50,
> ... seconds=27,
> ... microseconds=10,
> ... milliseconds=29000,
> ... minutes=5,
> ... hours=8,
> ... weeks=2
> ... )
> ```
> With a go like parsing it would be:
> ```
> >>> datetime.parse_duration("2w50d8h5m27s10ms2000us")
> ```
In the context you present, it looks like the expected use case is
almost exclusively parsing constant strings representing fixed
timedeltas. In that context, it seems to me that we have:
pros:
more compact (not everyone would view this as a "pro", but let's
go with it).
cons:
overhead of string parsing at runtime
more potential errors (mistype w as q, for example)
new syntax to remember (do the parts need to be in a particular
order, are spaces allowed, is it us or μs, etc?)
Overall, I don't think this is particularly beneficial, personally.
If on the other hand you're expecting to parse *non-constant* strings,
you're typically talking about user-entered data. In which case, it
seems like you're inventing a new, fairly limited, notation for time
intervals, with the expectation that it would be used in places like
config files, or maybe even direct user input. So the proposal depends
heavily on whether the notation is something people would want. And in
that case, I think it's unlikely. I'd be much more supportive if this
were a well-known standard format for intervals. It appears that ISO
8601 defines such a format - see
https://en.wikipedia.org/wiki/ISO_8601#Durations. Maybe the Go
notation is somehow better, but there's no immediate reason I can see
to assume that.
And for human input, you'd want something a lot more flexible. People
typically don't enter things in nice neat formats, and parsers need a
lot of flexibility. That's quite messy, and the stdlib typically isn't
where such parsers are available (parsing of human date input is found
in external libraries like dateutil, the stdlib sticks to more fixed
formats).
To be honest, there doesn't seem to be much around in the way of
parsers for interval data, so it would be nice to see something. But
(a) I'd rather it were on PyPI, so it's not restricted to newer
versions of Python, and (b) the proposed format isn't one I'd want,
personally.
Paul
___
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/4COOYUTWO2VCQV5C6N2YRFZUCPKJG7A3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add parse_duration to datetime - a golang like fucntion to parse duration
On 8/23/20 8:16 AM, Stephen J. Turnbull wrote: > Richard Damon writes: > > > As for holidays, why do holidays matter for time. > > They don't. They matter for durations, because humans regularly do > things like schedule a meeting for "one week from today" and then have > to it because it will fall on a holiday observed by their employer. > Why use units like months and cubits? Because "Man is the measure of > all things." People think in terms of such units, and then are > surprised when computers do "stupid" things with them, like convert > them to intervals measured in seconds that are applied to TAI dates, > and so schedule meetings on a holiday. > > Now, if you aren't thinking like a human, all you need are seconds. > Why mess with such a complicated representation combining weeks and > minutes and microseconds? So the OP is evidently thinking in service > of humans. This protocol *will* be used by humans, and I'll guarantee > you those users will occasionally be surprised and annoyed by the > results. > > Steve But a week from Dec 18th IS Dec 25th, just ask any kid. The business logic of special cases like a regularly scheduled event happening on an inappropriate day falls to a higher level of logic. The definition of what is an appropriate day is well beyond the scope of this sort of class, as it is very domain specific, and even event specific. -- Richard Damon ___ 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/NCQB4NG7DQTM5LCWQLXNFAACNEVBEN5S/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add parse_duration to datetime - a golang like fucntion to parse duration
Richard Damon writes: > As for holidays, why do holidays matter for time. They don't. They matter for durations, because humans regularly do things like schedule a meeting for "one week from today" and then have to it because it will fall on a holiday observed by their employer. Why use units like months and cubits? Because "Man is the measure of all things." People think in terms of such units, and then are surprised when computers do "stupid" things with them, like convert them to intervals measured in seconds that are applied to TAI dates, and so schedule meetings on a holiday. Now, if you aren't thinking like a human, all you need are seconds. Why mess with such a complicated representation combining weeks and minutes and microseconds? So the OP is evidently thinking in service of humans. This protocol *will* be used by humans, and I'll guarantee you those users will occasionally be surprised and annoyed by the results. Steve ___ 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/W6XUBRKYRFM6DHUAZ5MOR7S2QS4T5SY7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add parse_duration to datetime - a golang like fucntion to parse duration
On 8/23/20 7:21 AM, Stephen J. Turnbull wrote: > Richard Damon writes: > > > One issue with allowing Months here is then suddenly an interval > > becomes dependent on when it is, so needs to be keep in a complex > > form, as a month (and year) are variable length time units. > > This is the paradigmatic reason why I don't want this in the stdlib. > There's an irreducible ambiguity between what humans mean by "a month > later" and what timedelta can deal with natively. But if it's going > to be in the standard library, it should be a standard protocol. > > Note that hours have the same problem in jurisdictions that observe > daylight savings time, and minutes have the same problem because of > leap seconds. Weeks have a different problem (or ambiguity): suppose > "1 week later" falls on a holiday? > > So, "consenting adults." The documentation can warn about these > issues. You could also add a flag to accept years and months (and > hours and minutes? ;-). But does something that needs such a flag > belong in the stdlib? You get around leap seconds by just using the right time base, if you use UT1 or TAI then there are no leap seconds, so no problem there. Similarly for Daylight Savings Time, that is only an issue if you are in a frame that changes, if you define you time as a uniform frame (like GMT) then there is no DST to worry about (only when you convert your 'universal time measure' to a 'Local Clock Time' do you need to worry about that. As for holidays, why do holidays matter for time. A week after Dec 18th is Dec 25th, even if much of the world treats that day as differently. Now, if you want to deal with 'Work Weeks' or 'Work Days' then you need something more complicated, just like we had with months. -- Richard Damon ___ 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/M32JGMFHN7CLT3JRZ2YC4URANRKS2GGO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add parse_duration to datetime - a golang like fucntion to parse duration
Richard Damon writes: > One issue with allowing Months here is then suddenly an interval > becomes dependent on when it is, so needs to be keep in a complex > form, as a month (and year) are variable length time units. This is the paradigmatic reason why I don't want this in the stdlib. There's an irreducible ambiguity between what humans mean by "a month later" and what timedelta can deal with natively. But if it's going to be in the standard library, it should be a standard protocol. Note that hours have the same problem in jurisdictions that observe daylight savings time, and minutes have the same problem because of leap seconds. Weeks have a different problem (or ambiguity): suppose "1 week later" falls on a holiday? So, "consenting adults." The documentation can warn about these issues. You could also add a flag to accept years and months (and hours and minutes? ;-). But does something that needs such a flag belong in the stdlib? ___ 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/K6I7QASU6ICNB4HD4MVHS3EBM4LRMBLS/ Code of Conduct: http://python.org/psf/codeofconduct/
