[Ben Hoyt]
> I was emailing someone today about implementing something (for PEP
> 471, as it happens) and wanted to link to the Zen of Python [1] and
> note a particular clause (in this case "If the implementation is hard
> to explain, it's a bad idea."). However, there are no clause numbers,
> so
[nha pham ]
> Statement_1: With an array of size N or less than N, we need at most log2(N)
> comparisons to find a value
> (or a position, incase the search miss), using the binary search algorithm.
>
> proof: This statement is trivia, and I believe, someone outthere already
> proved it.
Sorry for
[nha pham ]
> Thank you very much. I am very happy that I got a reply from Tim Peter.
My pleasure to speak with you too :-)
> You are correct, my mistake.
>
> The python code should be:
> for i in range(low+1,high): //because we already add
> data[low]
> x = data[i]
>
OK - here's what the current binsort does, ignoring that it skips an
already-sorted prefix (if any), and creating a new list instead of
modifying in-place:
def oldsort(a):
from bisect import bisect_right as br
assert a
result = [a[0]]
for i in range(1, len(a)):
[Tim]
>> 1. Merge "2 at a time" instead of just 1. That is, first "sort" the
>> next 2 elements to be merged (1 compare and a possible swap). Then
>> binary search to find where the smaller belongs, and a shorter binary
>> search to find where the larger belongs. Then shift both into place.
[Ar
[Neil Schemenauer ]
> Python objects that participate in cyclic GC (things like lists, dicts,
> sets but not strings, ints and floats) have extra memory overhead. I
> think it is possible to mostly eliminate this overhead. Also, while
> the GC is running, this GC state is mutated, which destroys
[Tim]
>> In that case, it's because Python
>> _does_ mutate the objects' refcount members under the covers, and so
>> the OS ends up making fresh copies of the memory anyway.
[Greg Ewing ]
> Has anyone ever considered addressing that by moving the
> refcounts out of the objects and keeping them so
[Richard Hinerfeld ]
> Compiling Python-3.6.3 on Linux fails two tests: test_math and test_cmatg
Precisely which version of Linux? The same failure has already been
reported on OpenBSD here:
https://bugs.python.org/issue31630
___
Python-Dev mailing
Note that Matthew Barnett's `regex` module already supports \G, and a
great many other features that weren't around 15 years ago ;-) either:
https://pypi.python.org/pypi/regex/
I haven't followed this in detail. I'm just surprised once per year
that it hasn't been folded into the core ;-)
[
[Peter Ludemann]
> Does it matter whether the dict order after pop/delete is explicitly
> specified, or just specified that it's deterministic?
Any behavior whatsoever becomes essential after it becomes known ;-)
For example, dicts as currently ordered easily support LRU (least
recently used) pur
[Eric Snow ]
> Does that include preserving order after deletion?
Given that we're blessing current behavior:
- At any moment, iteration order is from oldest to newest. So, "yes"
to your question.
- While iteration starts with the oldest, .popitem() returns the
youngest. This is analogous to h
[Guido]
> as_integer_ratio() seems mostly cute (it has Tim Peters all
> over it),
Nope! I had nothing to do with it. I would have been -0.5 on adding
it had I been aware at the time.
- I expect the audience is tiny.
- While, ya, _I_ have uses for it, I had a utility function
[David Mertz ]
> ...
> I can see no sane reason why anyone would ever call float.is_integer()
> actually. That should always be spelled math.isclose(x, int(x)) because
> IEEE-754. Attractive nuisance is probably too generous, I'd simply call the
> method a bug.
Sometimes it's necessary to know, an
[Tim Peters]
>> ...
>> >>> (-math.inf) ** 3.1
>> inf
[David Mertz]
> Weird. I take it that's what IEEE-754 says. NaN would sure be more intuitive
> here since inf+inf-j is not in the domain of Reals. Well, technically
> neither is inf, but at least it'
[Tim. on as_integer_ratio()]
>> - I expect the audience is tiny.
[Alexander Belopolsky]
> The datetime module would benefit from having as_integer_ratio()
> supported by more types. It's been hard to resist requests to allow
> Decimal in timedelta constructors and/or arithmetics
I don't see the
[Tim]
>> At heart, the Fraction() constructor is _all about_ creating integer
>> ratios, so is the most natural place to put knowledge of how to do so.
>> A protocol for allowing new numeric types to get converted to Fraction
>> would be more generally useful than just a weird method only datetime
[Guido]
> So let's make as_integer_ratio() the standard protocol for "how to make a
> Fraction out of a number that doesn't implement numbers.Rational". We
> already have two examples of this (float and Decimal) and perhaps numpy or
> the sometimes proposed fixed-width decimal type can benefit from
[Tim]
>> An obvious way to extend it is for Fraction() to look for a special
>> method too, say "_as_integer_ratio()".
[Greg Ewing]
> Why not __as_integer_ratio__?
Because. at this point, that would be beating a dead horse ;-)
___
Python-Dev mailing lis
[David Mertz]
> I've been using and teaching python for close to 20 years and I never
> noticed that x.is_integer() exists until this thread.
Except it was impossible to notice across most of those years, because
it didn't exist across most of those years ;-)
> I would say the "one obvious way"
wing that guidance has repeatedly proved to be a
boon to those writing numerical methods. And, yes, also a pain in the
ass ;-)
--- nothing new below ---
On Wed, Mar 21, 2018 at 3:49 PM, David Mertz wrote:
> On Wed, Mar 21, 2018 at 3:02 PM, Tim Peters wrote:
>>
>> [David Mertz]
[David Mertz ]
>> For example, this can be true (even without reaching inf):
>>
>> >>> x.is_integer()
>> True
>> >>> (math.sqrt(x**2)).is_integer()
>> False
[Mark Dickinson ]
> If you have a moment to share it, I'd be interested to know what value of
> `x` you used to achieve this, and what syste
[Devin Jeanpierre ]
> PyPy (5.8):
> x = 1e300
> x.is_integer()
> True
> math.sqrt(x**2).is_integer()
> False
> x**2
> inf
I think you missed that David said "even without reaching inf" (you
did reach inf), and that I said "such that x*x neither overflows nor
underflows". Those
[Chris Barker ]
> ...
> ... "is it the "right" thing to do in most cases, when deployed by folks
> that haven't thought deeply about floating point.
Gimme a break ;-) Even people who _believe_ they've thought about
floating point still litter the bug tracker with
>>> .1 + .2
0.30004
[Tim]
>> from trig functions doing argument reduction as if pi were represented
>> with infinite precision,
[Greg Ewing ]
> That sounds like an interesting trick! Can you provide
> pointers to any literature describing how it's done?
>
> Not doubting it's possible, just curious.
As I recall, when
[Kirill Balunov ]
> I apologize that I get into the discussion. Obviously in some situations it
> will be useful to check that a floating-point number is integral, but from
> the examples given it is clear that they are very rare. Why the variant with
> the inclusion of this functionality into the
[Kirill Balunov ]
> ...
> In spite of the fact that the pronouncement has
> already been made, there may still be an opportunity to influence this
> decision.
That's not really how this works. Guido has been doing this for
decades, and when he Pronounces he's done with it :-)
> I do not thi
[Serhiy Storchaka ]
> ...
> This is not new. The optimizer already changes semantic.
> Non-optimized "if a and True:" would call bool(a) twice, but optimized code
> calls it only once.
I have a hard time imaging how that could have come to be, but if it's
true I'd say the unoptimized code was plai
[Tim]
> I have a hard time imaging how that could have come to be, but if it's
> true I'd say the unoptimized code was plain wrong. The dumbest
> possible way to implement `f() and g()` is also the correct ;-) way:
>
> result = f()
> if not bool(result):
> result = g()
Heh - that's entirely w
[Tim]
> Same top-level point, though: [for evaluating `f() and g()`]:
>
> result = f()
> if bool(result):
> result = g()
Ah, I think I see your point now. In the _context_ of `if f() and
g()`, the dumbest possible code generation would do the above, and
then go on to do
if bool(result):
[Tim Delaney ]
> ...
> If I'm not mistaken, #3 would result in the optimiser changing str.format()
> into an f-string in-place. Is this correct? We're not talking here about
> people manually changing the code from str.format() to f-strings, right?
All correct. It's a magical transformation from
[Steven D'Aprano ]
> ...
> Is there a down-side to 2b? It sounds like something you might end up
> doing at a later date regardless of what you do now.
There are always downsides ;-)
As Serhiy noted later, the idea that "it's faster" is an educated
guess - you can't know before it's implemented.
[MRAB [
> A thread on python-ideas is talking about the prefixes of string literals,
> and the regex used in IDLE.
>
> Line 25 of Lib\idlelib\colorizer.py is:
>
> stringprefix = r"(?i:\br|u|f|fr|rf|b|br|rb)?"
>
> which looks slightly wrong to me.
>
> The \b will apply only to the first choice.
I'll channel that Guido would be happiest if this rule were followed:
Given an assignment statement using "=", the meaning is the same if
"=" is replaced with ":=".
In particular, the expression at the far right is evaluated once, and
- in case of chained assignments - is applied in turn to each
[Tim]
>> I'll channel that Guido would be happiest if this rule were followed:
>>
>> Given an assignment statement using "=", the meaning is the same if
>> "=" is replaced with ":=".
[Chris]
> That's broadly the intention. At the moment, there are two exceptions:
>
> 1) Augmented assignment isn't
[Guido, makes peace with `identifier := expression`]
> ...
> I am fine with this, it certainly seems the easiest to implement, with the
> fewest corner cases, and the easiest restriction to explain.
>
> (I was thinking there would be a use case for basic tuple unpacking, like
> seen a lot in for-lo
[Paul Moore]
>> the next question will likely be "so why does = exist at all?"
[Greg Ewing ]
> And if we decide to make ':=' the official assigment operator and
> deprectate '=', the next question will be "Why do we have '=='
> instead of '='?"
Which would be a fine question! In Python's very ea
[Tim]
>> And, for some reason, I find this even worse:
>>
>> while ((x, y) := func_returning_tuple())[1] is not None:
>> ...
>>
>> The rub there: I gave `y` a name but can't use it in the test?!
>>
>> And those are the same kinds of headaches I saw over & over in my own
>> "fancier" co
[Guido, about
g(items[idx] := idx := f())
]
> Does the PEP currently propose to *allow* that horrible example? I thought
> Tim Peters successfully pleaded to *only* allow a single "NAME := ".
I was "successful" only in that the two of us agreed that would be far
[Chris Angelico ]
> I don't see much value in restricting the assignment target to names
> only, but if that's what it takes, it can be restricted, at least
> initially.
I believe this point was made most clearly before by Terry Reedy, but
it bears repeating :-) This is from the PEP's motivation:
[Tim]
>> And I'll take this opportunity to repeat the key point for me: I
>> tried hard, but never found a single case based on staring at real
>> code where allowing _fancier_ (than "plain name") targets would be a
>> real improvement. In every case I thought it _might_ help, it turned
>> out th
[Matthew Woodcraft ]
> I would like to suggest one more motivating example for "Capturing
> condition values": multiple regex matches with 'elif'.
>
> if match := re.search(pat1, text):
> print("Found one:", match.group(0))
> elif match := re.search(pat2, text):
> print("Found two:", match.
[Christoph Groth ]
> Tim, thanks for this clear analysis. Here's the best use case of more
> general assignment expressions that I can come up with (from real code
> I'm currently working on):
>
> class Basis:
> def __init__(self, parent, periods=()):
> self._parent = parent
>
[Tim]
>> I expected that, given that expressions "naturally nest", chained
>> targets could still be specified:
>>
>> a := b := c:= 5
>>
>> but since they're all plain names there's no way to tell whether the
>> bindings occur "left to right" or "right to left" short of staring at
>> the genera
[Christoph Groth ]
>> > Still, it seems weird to have two different ways of binding names in
>> > the language where one would be sufficient (i.e. the old one would
>> > remain only for backwards compatibility). From the point of view of
>> > someone who's new to the language that's two things to
[Matthew Woodcraft]
>>> Well, that's a reason to make the example a bit more realistic, then.
>>>
>>> Say:
>>>
>>> if match := re.search(pat1, text):
>>> do_something_with(match.group(0))
>>> elif match := re.search(pat2, text):
>>> do_something_else_with(match.group(0), match.group(1))
>>>
[Guido]
> In reality there often are other conditions being applied to the match for
> which `if expr as name` is inadequate. The simplest would be something like
>
> if ...:
>
> elif (m := re.match('(.*):(.*)', line)) and m.group(1) == m.group(2):
>
>
> And the match() call may not
[Tim]
>> Which this alternative expresses directly:
>>
>> if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
>> return g
>>
>> That's so Pythonic I could cry ;-)
[Antoine]
> It looks like C to me. That won't make me cry (I write C++ code daily
> these days), but it's certainly not the same
[Sven R. Kunze ]
> What about
>
> diff = x - x_base
> if diff and gcd(diff, n) > 1:
> return gcd(diff, n)
>
> # or
>
> if (x - x_base) and gcd(x - x_base, n) > 1:
> return gcd(x - x_base, n)
>
>
> and have the interpreter handle the optimization, or apply an lru_cache? ;-)
Surely you're jo
[Tim]
>> Surely you're joking. This is math.gcd(), which is expensive for
>> multi-thousand bit integers, and the interpreter knows nothing about
>> it. Adding a cache of _any_ kind (LRU or otherwise) would make it
>> even slower.
[Sven R. Kunze ]
> Alright, if that problem is just about perform
[Ethan Furman ]
> So I really like being able to make the assignment in the expression, but I
> have a really hard time parsing it with the name first.
>
> ...
>
> On the other hand, if it were using the "as" keyword:
>
> if (x - xbase as diff) and (gcd(diff, n) as g) > 1:
> return g
>
> I woul
[Tim]
>> if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
>> return g
[Greg Ewing ]
> My problem with this is -- how do you read such code out loud?
In the message in which I first gave that example:
if the diff isn't 0 and gcd(diff, n) > 1, return the gcd.
That's how I _thought_
[Steve Holden ]
>> ...
>> The assignment expression seems like a vary natural way to introduce
>> variables of limited (controlled?) scope, [...]
[Antoine Pitrou ]
> AFAIU, the scope isn't limited to the "if" block, it's a regular local
> variable. I might have misread.
You're right about the cu
[Antoine]
>>> - does it make Python easier to learn and teach?
[Tim]
>> By whom? Almost no addition has ever made a language easier to learn
>> for raw beginners: every addition is something they eventually need
>> to learn. We could make Python easier to learn for beginners by
>> throwing out
[Antoine Pitrou ]
> ...
> Having to break things out over multiple lines is a fact of life, if
> only for readability when implementing (and maintaining!) non-trivial
> processing routines. It's a good thing to be used to it, and to learn to
> choose good names for intermediate variables.
Well, th
[Stephen J. Turnbull[
>> Neologisms are usually written in the other order:
>> "dead on arrival (DOA, for short)." ;-)
[Greg Ewing ]
> Maybe we can make use of that?
>
>if (x - x_base) (diff) and gcd(diff, n) (g) > 1:
>
> That doesn't work, because the (...) look like function
> calls. But wha
[Antoine]
> ...
> Yes... I think most will agree that Python is generally easy to take up
> for people coming from C++ etc., so my "easier to learn and teach" was
> mostly about non-programmers.
[Tim]
>> even for raw beginners the semantics are the tiniest part of what
>> they need to learn anyway
[Chris Angelico ]
> Hopefully you have seen, or soon will see, the latest posting of the
> PEP, in which assignment targets are restricted to simple names. :)
I haven't yet, but look forward to it! You have the patience of a
saint to endure all this - I would have given up 6 years ago ;-)
> Tho
[Victor Stinner]
...
> Tim Peter gaves the following example. "LONG" version:
>
> diff = x - x_base
> if diff:
> g = gcd(diff, n)
> if g > 1:
>return g
>
> versus the "SHORT" version:
>
> if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
>return g
>
> == Write ==
>
> If your
[Tim]
>> Binding expressions are debugger-friendly in that they _don't_ just
>> vanish without a trace. It's their purpose to _capture_ the values of
>> the expressions they name. Indeed, you may want to add them all over
>> the place inside expressions, never intending to use the names, just
>>
[Guido]
>> You don't seem to grasp the usability improvements this will give.
>> I hear you but at this point appeals to Python's "Zen" don't help you.
[Łukasz Langa ]
> This reads dismissive to me. I did read the PEP and followed the discussion on
> python-dev. I referred to PEP 20 because it dis
[Tim]
>> To my eyes, this is genuinely harder to follow, despite its relative brevity:
>>
>> while total != (total := total + term):
[Antoine]
> Does it even work? Perhaps if the goal is to stop when total is NaN,
> but otherwise?
I don't follow you. You snipped all the text explaining
[Tim]
To my eyes, this is genuinely harder to follow, despite its relative
brevity:
while total != (total := total + term):
[Antoine]
>>> Does it even work? Perhaps if the goal is to stop when total is NaN,
>>> but otherwise?
[Chris]
>> Yes, it does, because the firs
[Ryan Gonzalez ]
> I have to say I'm not overly thrilled with PEP 572...it's almost odd,
> because if you asked me back when I first joined this list when I was 13, I
> would've no doubt said *YES*. But, since then, I've gone across many
> projects and languages, and fundamentally *I have never fel
[Raymond Hettinger ]
> After re-reading all the proposed code samples, I believe that
> adopting the PEP will make the language harder to teach to people
> who are not already software engineers.
Can you elaborate on that? I've used dozens of languages over the
decades, most of which did have som
[Tim]
>> One language feature conspicuous by absence in newbie
>> confusions was, consistently, assignment expressions. Read any book
>> or tutorial for such a language, and you'll find very little space
>> devoted to them too.
[Łukasz Langa ]
> Well, you have an entire code style built around th
[Raymond Hettinger ]
>>> After re-reading all the proposed code samples, I believe that
>>> adopting the PEP will make the language harder to teach to people
>>> who are not already software engineers.
[Tim]
>> Can you elaborate on that?
[Raymond]
> Just distinguishing between =, :=, and == will
[Guido]
> Maybe the order for d[k] = v should also be reconsidered?
There's certainly code in the wild relying on the order "v, then d,
then k", because that's just how assignment statements have always
worked (dicts or not). I'd rather change the dict comprehension code,
because I think the anal
[Kirill Balunov ]
> Not sure, but if additional motivating examples are required, there is a
> common pattern for dynamic attribute lookup (snippet from `copy.py`):
>
> reductor = dispatch_table.get(cls)
> if reductor:
> rv = reductor(x)
> else:
> reductor = getattr(x, "
[Kirill Balunov]
> Not sure, but if additional motivating examples are required, there is a
> common pattern for dynamic attribute lookup (snippet from `copy.py`):
>
> reductor = dispatch_table.get(cls)
> if reductor:
> rv = reductor(x)
> else:
> reductor = getattr(x, "_
[Tim]
>> So, to match your sarcasm, here's mine: try using a feature for what
>> it's good at instead of for what it's bad at ;-)
[Lukasz Langa ]
> Yes, this is the fundamental wisdom. Judging which is which is left as an
> exercise to the programmer.
>
> With this, I'm leaving the discussion.
[Mike Miller]
>> - How are other modern languages solving this issue?
[Greg Ewing ]
> In all the languages I can think of that allow assignments in
> expressions, there is only one assignment operator -- a stand
> alone assignment is just a bare assignment expression.
Pretty much so, but I do
[Larry Hastings ]
>>> I hate to be pedantic--there's enough of that going on in this thread--but I
>>> can't agree with the word "simplifed" above. I agree that the code using
>>> binding expressions is shorter. But considering that emit the two code
>>> examples implement the exact same algorith
[Zero Piraeus]
>> Since it now looks like it really *does* have a decent chance, and
>> maybe another -1 has a small chance of tipping the balance: my
>> reaction to the proposal is also emotional. Visceral, in fact, to the
>> extent that I'd aim to read and write less Python if it became
>> common
[Lukasz]
>> > And that *is* a thing that you will have to explain to newbies when
>> > they encounter it for the first time.
[Tim]
>> Sure. That doesn't frighten me, though. It's easy to explain what it
>> does - although it may be hard to explain when it's _desirable_ to use
>> it.
[Chris Bar
[Chris Angelico ]
> ...
> I don't understand why people bring up all these arguments that have
> absolutely nothing to do with the proposal at hand. None of this has
> in any way changed.
That's easy: any time there's a long thread to which Guido has
contributed at least twice, it will be seen as
Wes, sorry, but I really don't follow what you're saying. For example,
[Wes Turner ]
> Do not do this:
>
> x = 2
> if (x == 3) or (x := 3):
>print(x)
>
> What do we call that mistake?
It displays 3 - while it appears to be silly code, there's nothing
about it that's undefined. So I fail to
[Tres Seaver ]
> FWIW, Ned Batchelder's 'coverage.py' does a good job with branch coverage.
> I haven't seen anything in this discussion which indicates that binding
> expressions will change that at all.
I don't think you missed anything relevant either ;-) Binding
operators are exactly as irrel
[Raymond Hettinger ]
> Thanks Antoine, this is an important point that I hope doesn't get lost.
> In a language with exceptions, assignment expressions are less needful.
> Also, the pattern of having of having mutating methods return None
> further limits the utility.
It doesn't diminish the utili
[Matěj Cepl ]
> It absolutely impossible to remove Tkinter IMHO (it has been
> part of stdlib since like forever and people expect it there;
> its removal would be betrayal on the level of switching = to
> :=), I have my doubts about IDLE though. I know, the same
> argument applies, but really, doe
[Steven D'Aprano ]
> ...
> If we could look forward to 2028, when we're running Python 3.14 or so
> (4.7 if you prefer), how many fantastic language features that we cannot
> bear to give up would we be missing out on?
This, for just one:
k = 6 if >!{myobj.meth(arg)[2]} elsenone 7 elsenan 8 e
[Chris Angelico ...
> With current semantics, you can easily prove that a list comp is
> implemented with a function by looking at how it interacts with other
> scopes (mainly class scope), but Tim's proposal may change that.
Absolutely not. I haven't considered for a nanosecond that anything
_e
Sorry about approving this message (I'm a python-dev list moderator)!
There will be a few more like it.
Looking closer, it appears to be another variation of pure-nuisance
spam that's been flooding all sorts of python.org lists. You've been
spared many hundreds of those here, but since this one a
[ Tim, about the most version of the docs at
https://docs.python.org/dev/reference/expressions.html#displays-for-lists-sets-and-dictionaries
]
>> I say "pretty much" because, for whatever reason(s), it seems to be
>> trying hard _not_ to use the word "function". But I can't guess what
>> "the
[Nathaniel Smith ]
> ...
> As far as git is concerned, the main repo on github, your fork on
> github, and your local repo are 3 independent repositories, equally
> valid. The relationships between them are purely a matter of
> convention.
Thanks for that! It instantly cleared up several mysterie
-- at least Nick and Greg seem
to
> be +0 or better for (a) but -1 for (b). IIRC (b) originated with Tim. But
his
> essay on the topic, included as Appendix A
> (
https://www.python.org/dev/peps/pep-0572/#appendix-a-tim-peters-s-findings)
> does not even mention comprehensions.
I was wr
>
> [Tim]
>>
> . First, the original example I gave would be approximately as well
>> addressed by allowing to declare intended scopes in magically synthesized
>> functions; like (say)
>>
>> p = None # to establish the intended scope of `p`
>> while any( # split across lines just for readability
[Nick Coghlan]>
> actually made those semantics available as an explicit
> "parentlocal NAME" declaration ...:
> >
> > def _list_comp(_outermost_iter):
> > parentlocal item
> > _result = []
> > for x in _outermost_iter:
> > item = x
> > _result
[Nick Coghlan]
> However, PEP 572 in its current form takes the position "parent local
> scoping is sufficiently useful to make it a required pre-requisite for
> adding assignment expressions, but not useful enough to expose as a
> new scope declaration primitive",
>
Of course the PEP doesn't tak
[ISAAC J SCHWABACHER ]
> ...
> I disagree with the view Tim had of time zones when he wrote that comment
> (and that code). It sounds like he views US/Eastern and US/Central as time
> zones (which they are), but thinks of the various America/Indiana zones as
> switching back and forth between them,
[Tim]
> Sure. But, honestly, who cares? Riyadh Solar Time was so
> off-the-wall that even the Saudis gave up on it 25 years ago (after a
> miserable 3-year experiment with it). "Practicality beats purity".
Heh. It's even sillier than that - the Saudis never used "Riyadh
Solar Time", and it's b
[Lennart Regebro ]
> And I would want to remind everyone again that this is not a question
> of the problem being impossible. It's just really complex to get right
> in all cases, and that always having the UTC timestamp around gets rid
> of most of that complexity.
Could you please be explicit ab
[Tim]
>> The formulas only produced approximations, and then
>> rounded to 5-second boundaries because the tz data format didn't have
>> enough bits.
[ISAAC J SCHWABACHER ]
> Little known fact: if you have a sub-minute-resolution UTC offset when a
> leap second hits, it rips open a hole in the spa
[Lennart Regebro ]
>>> And I would want to remind everyone again that this is not a question
>>> of the problem being impossible. It's just really complex to get right
>>> in all cases, and that always having the UTC timestamp around gets rid
>>> of most of that complexity.
[Tim]
>> Could you plea
[ISAAC J SCHWABACHER ]
>>> ...
>>> I think the right perspective is that a time zone *is* the function that its
>>> `fromutc()` method implements,
[Tim]
>> Fine by me ;-)
[Isaac]
> My issue is that you're computing `fromutc()`, which is a function, in
> terms of `dst()` and `utcoffset()`, which a
[Tim]
>> However, the _body_ of the PEP said nothing whatsoever about altering
>> arithmetic. The body of the PEP sounds like it's mainly just
>> proposing to fold the pytz package into the core. Perhaps doing
>> _just_ that much would get this project unstuck? Hope springs eternal :-)
[Lennart
[Paul Moore ]
> I think the current naive semantics are useful and should not be
> discarded lightly. At an absolute minimum, there should be a clear,
> documented way to get the current semantics under any changed
> implementation.
Realistically, default arithmetic behavior can't change in Python
[Tim]
>> The Python docs also are quite clear about that all arithmetic within
>> a single timezone is "naive". That was intentional. The _intended_
>> way to do "aware" arithmetic was always to convert to UTC, do the
>> arithmetic, then convert back.
[Lennart]
> We can't explicitly implement in
[Paul Moore ]
>>
>> As an example, consider an alarm clock. I want it to go off at 7am
>> each morning. I'd feel completely justified in writing
>> tomorrows_alarm = todays_alarm + timedelta(days=1).
[Lennart Regebro ]
> That's a calendar operation made with a timedelta.
It's an instance of
[Ronald Oussoren ]
> IMHO “+ 1 days” and “+ 24 hours” are two different things.
> Date arithmetic is full of messy things like that.
But it's a fact that they _are_ the same in naive time, which Python's
datetime single-timezone arithmetic implements:
- A minute is exactly 60 seconds.
- An hour i
>>> The "days" attribute here is indeed confusing as it doesn't mean 1 day,
>>> it means 24 hours.
>> Which, in naive arithmetic, are exactly the same thing.
[Terry Reedy]
> I think using the word 'naive' is both inaccurate and a mistake. The issue
> is civil or legal time versus STEM time
1 - 100 of 1049 matches
Mail list logo
