Re: [Python-Dev] Status on PEP-431 Timezones

[Ronald Oussoren]

> On 28 Jul 2015, at 03:13, Tres Seaver  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 07/27/2015 06:11 PM, Ronald Oussoren wrote:
> 
>> Treating time as UTC with conversions at the application edge might
>> be "cleaner" in some sense, but can make code harder to read for 
>> application domain experts.
>> 
>> It might be nice to have time zone aware datetime objects with the 
>> right(TM) semantics, but those can and should not replace the naive 
>> objects we know and love.
> 
> Interesting.  My experience is exactly the opposite:  the datetimes which
> "application domain experts" cared about *always* needed to be non-naive
> (zone captured explicitly or from the user's machine and converted to
> UTC/GMT for storage).  As with encoded bytes, allowing a naive instance
> inside the borders the system was always a time-bomb bug (stuff would
> blow up at a point far removed from which it was introduced).
> 
> The instances which could have safely been naive were all
> logging-related, where the zone was implied by the system's timezone
> (nearly always UTC).  I guess the difference is that I'm usually writing
> apps whose users can't be presumed to be in any one timezone.  Even in
> those cases, having the logged datetimes be incomparable to user-facing
> ones would make them less useful.

I usually write application used by local users where the timezone is completely
irrelevant, including DST.  Stuff needs to be done at (say) 8PM, ands that’s
8PM local time. Switching to and from UTC just adds complications. 

I’m lucky enough that most datetime calculations happen within one work week
and therefore never have to cross DST transitions.  For longer periods I usually
only care about dates, and almost never about the number of seconds between
two datetime instances.   That makes the naive datetime from the stdlib a 
very convenient programming model.

And I’m in a country that’s small enough to have only one timezone.

IMHO Unicode is different in that regard, there the application logic can 
clearly
be expressed as text and the encoding to/from bytes can safely be hidden in
the I/O layer. Often the users I deal with can follow the application logic 
w.r.t.
text handling, but have no idea about encodings (but do care about accented
characters). With some luck they can provide a sample file that allows me to 
deduce the encoding that should be used, and most applications are moving 
to UTF-8.

BTW. Note that I’m not saying that a timezone aware datetime is bad, just
that they are not always necessary.

Ronald
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[R. David Murray]

On Wed, 29 Jul 2015 06:26:44 +0200, Lennart Regebro  wrote:
> On Tue, Jul 28, 2015 at 10:26 PM, Tim Peters  wrote:
> >> I have yet to see a use case for that.
> >
> > Of course you have.  When you address them, you usually dismiss them
> > as "calendar operations" (IIRC).
> 
> Those are not usecases for this broken behaviour.
> 
> I agree there is a usecase for where you want to add one day to an 8am
> datetime, and get 8am the next day. Calling them "date operations" or
> "calendar operations" is not dismissing them. I got into this whole
> mess because I implemented calendars. That use case is the main
> usecase for those operations.
> 
> But that usecase is easily handled in several ways. Already today in
> how datetime works, you have two solutions: The first is to use a time
> zone naive datetime. This is what most people who want to ignore time
> zones should use. The other is to separate the datetime into date and
> time objects and add a day to the date object.

I said I was done commenting, and this is supposed to move to the
datetime-sig, but this "lack of use cases" keeps coming up, so I'm going
to make one more comment, repeating something I said earlier.

What *I* want aware datetimes to do is give me the correct timezone
label when I format them, given the date and time information they hold.
The naive arithmetic is perfect, the conversion between timezones is
fine, the only thing missing from my point of view is a timezone
database such that if I tell a datetime it is in zone X, it will print
the correct offset and/or timezone label when I format it as a string.

That's my use case; and it is, I would venture to guess, *the* most
common use case that datetime does not currently support, and I was very
disappointed to find that pytz didn't support it either (except via
'normalize' calls, but why should I have to call normalize every
time I do datetime arithmetic?  It should just *do* it.)

Anything more would be gravy from my point of view.

Now, maybe tzinfo can't actually support this, but I haven't heard Tim
say that it can't.  Since the datetime is always passed to tzinfo,
I think it can.

--David

PS: annoying story: I scheduled an event six months in advance on my
tablet's calendar, and it scheduled it using what was my *current* GMT
offset (it calls it a time zone) even though it knew what date I was
scheduling it on.  Which meant the alarm in my calendar was off by an
hour.  I hope they have fixed this bug.  I relay this because it is
exactly the same problem I find to be present in pytz.  If the calendar
had been using aware datetimes and naive arithmetic as I describe above,
the alarm would not have been off by an hour.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?

[Wes Turner]

On Jul 28, 2015 10:41 PM, "Stephen J. Turnbull"  wrote:
>
> Ben Finney writes:
>
>  > I've made a clear distinction between the need to *be able to*
>  > justify a change, versus arbitrary demands to do so by arbitrary
>  > members.
>  >
>  > The latter is what you're arguing against, and of course I agree. I've
>  > never advocated that.
>
> Sure, but the former, when stated as a rule rather than induced from
> past cases, is also an unacceptably high bar.  It's unnecessarily
> high, because this is open source.  No mistake is irrecoverable, even
> if it happens in a public release.  One can always keep using the last
> release one liked.  Or maintain a local fork.  Or switch to a
> different language.  Or  live with the misfeature.
>
> The other face is that it's impossibly high.  Some decisions can't be
> justified rationally, because the theory isn't developed until later,
> typically based on experience with an intuitively-approved feature.
> In the end, some decisions really do come down to somebody's "gut
> feeling".
>
> As I've already said, in the case of "assret" I *personally* think the
> demands of accountability were higher than the mere repetition of
> "it's a minor design decision" could satisfy.  Nevertheless, I
> wouldn't try to enunciate a rule.

* sorry, I haven't the context for this: would -m compileall or an AST
preprocess help catch speling mistakes as well as syntax highlighting?
* If the constraints are ill-defined, there are not enough tests; "Fearless
Refactoring"

>
> Steve
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?

[Ethan Furman]

On 07/29/2015 09:18 AM, Wes Turner wrote:


sorry, I haven't the context for this


tl;dr -- Mock objects now protect against accidentally accessing wrong assert methods by raising an attribute error;  this is different than past behavior in that any attribute that didn't exist 
simply returned a new Mock.  Besides guarding against incorrect "assert*" attributes, it also guards against "assret*" attributes.



For the complete history:

  https://mail.python.org/pipermail/python-dev/2015-July/140720.html

Please keep in mind that this has been discussed enough.

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Benchmark Results for Python Default 2015-07-24

[Catalin G . Manciu]

Brett Cannon  python.org> writes:

> 
> 
> Should we discuss of these are the benchmarks we want daily reports on 
(you can see what the benchmark suite has at 
https://hg.python.org/benchmarks/file/2979f5ce6a0c/perf.py#l2243 )? I 
personally would prefer dropping pybench and replacing it with a startup 
measurement.
> 
> On Fri, Jul 24, 2015, 07:23 Nick Coghlan  gmail.com> wrote:
> 
> On 24 July 2015 at 23:55, Serhiy Storchaka  gmail.com> 
wrote:
> > On 24.07.15 15:34, lp_benchmark_robot wrote:
> >> The community's feedback is very important for us. For any questions,
> >> comments or suggestions you can also contact us on our mailing list
> >> lp  lists.01.org. You can also check our website: 
https://www.01.org/lp
> >
> > It is cool! Thank you, it whats we need.
> Indeed!
> > But perhaps it would be better to post these reports on
> > python-checkins  python.org instead of Python-Dev list, with Reply-
To set to
> > python-dev  python.org.
> Aye, python-checkins is a better option for automated daily posts.
> Cheers,
> Nick.
> --
> Nick Coghlan   |   ncoghlan  gmail.com   |   Brisbane, Australia
> ___
> Python-Dev mailing listPython-Dev  
python.orghttps://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-
dev/brett%40python.org
> 
> 
> 
> 
> 
> Should we discuss of these are the benchmarks we want daily 
reports on (you can see what the benchmark suite has at https://hg.python.org/benchmarks/file/2979f5ce6a0c/perf.py#l2243";>http
s://hg.python.org/benchmarks/file/2979f5ce6a0c/perf.py#l2243 )? I 
personally would prefer dropping pybench and replacing it with a startup 
measurement.
> 
> On Fri, Jul 24, 2015, 07:23 Nick Coghlan ncoghlan  gmail.com> wrote:

> 
> On 24 July 2015 at 23:55, Serhiy Storchaka 
storchaka  
gmail.com> wrote:
> > On 24.07.15 15:34, lp_benchmark_robot wrote:
> >> The community's feedback is very important for us. For any 
questions,
> >> comments or suggestions you can also contact us on our mailing 
list
> >> mailto:lp  lists.01.org" target="_blank">lp  
lists.01.org. You can also check our website: https://www.01.org/lp"; rel="noreferrer" 
target="_blank">https://www.01.org/lp
> >
> > It is cool! Thank you, it whats we need.
> Indeed!
> > But perhaps it would be better to post these reports on
> > mailto:python-checkins  python.org" 
target="_blank">python-checkins  python.org instead of Python-Dev 
list, with Reply-To set to
> > mailto:python-dev  python.org" target="_blank">python-
dev  python.org.
> Aye, python-checkins is a better option for automated daily posts.
> Cheers,
> Nick.
> --
> Nick Coghlan   |   mailto:ncoghlan  
gmail.com" target="_blank">ncoghlan  gmail.com   |  
 Brisbane, Australia
> ___
> Python-Dev mailing listmailto:Python-Dev  python.org" 
target="_blank">Python-Dev  python.orghttps://mail.python.org/mailman/listinfo/python-dev"; rel="noreferrer" 
target="_blank">https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-
dev/brett%40python.org" rel="noreferrer" 
target="_blank">https://mail.python.org/mailman/options/python-
dev/brett%40python.org
> 
> 
> 
> 


Thank you for your feedback! We value the community’s input and we would 
like to provide the most relevant results in our automatic measurements. 
Regarding the startup benchmarks, could you tell us which one you think is 
the most useful to be included in the daily report ("normal_startup", 
"startup_nosite")?

Regards !
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Benchmark Results for Python Default 2015-07-24

[Brett Cannon]

On Wed, Jul 29, 2015 at 9:40 AM Catalin G. Manciu <
catalin.gabriel.man...@intel.com>
[SNIP -- stuff came back as visible HTML; hopefully I didn't miss something]

>
>
> Thank you for your feedback! We value the community’s input and we would
> like to provide the most relevant results in our automatic measurements.
> Regarding the startup benchmarks, could you tell us which one you think is
> the most useful to be included in the daily report ("normal_startup",
> "startup_nosite")?
>

I personally think normal_startup is best as that's how people probably
typically launch Python.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?

[Robert Collins]

On 29 July 2015 at 02:17, Ben Finney  wrote:
> Paul Moore  writes:
>
>> On 28 July 2015 at 13:35, Ben Finney  wrote:
>> > People can, do, and probably must make many decisions through
>> > non-rational processes. I don't propose to change that.
>>
>> Good.
>>
>> > Choices can be made that, when challenged, lack compelling rational
>> > justification. I do propose that such a challenge should be taken as a
>> > healthy desire to improve Python, not a personal attack.
>>
>> While that is fine, you appear unwilling to accept the possibility
>> that people may not have the time/energy to develop a detailed
>> rational justification for a change that they have made, and demanding
>> that they do so when they are offering the time they do give on a
>> volunteer basis, is what I claim is unacceptable.
>
> I've said many times now that's not what I'm advocating.
>
> I've made a clear distinction between the need to *be able to* justify a
> change, versus arbitrary demands to do so by arbitrary members.
>
> The latter is what you're arguing against, and of course I agree. I've
> never advocated that.

I'm arguing against the former. Being able to survive a crowd sourced
grilling on any arbitrary change would be quite the chilling effect,
and its a level of backpressure that the committers who engaged in
this discussion have rejected. Some have rejected contributing *at
all* as a result of the discussion. Others, like me, are telling you
that you're wrong, that we don't accept that we can be called up for
any odd commit and asked to justify it to anyone.

There is a social contract around our commits - and it does permit
enquiry and discussion, but not with the degree of heat or antagonism
that was present in this thread.

AND

Not by uninformed folk: If you're going to second guess the onus is on
you to educate yourself about the issue first. This particular one,
for instance, requires going back through the history of mock right to
its founding in 2007, and walking forward through the merge into the
stdlib in Python 3,3 (because its popular) and finally the realisation
that large chunks of peoples code were silently not testing what was
desired and the fixing of that. Discussing the thing we discussed *in
that context* is a very different discussion to what we had, where
every second message was someone misunderstanding what the issue is
and chiming in to say that this is surprising and unPythonic and
against the Zen and oh my.

>> The issue is not one of your motives in asking for explanations - it's
>> the implication that you are entitled to require others to *provide*
>> those explanations, to whatever level of detail *you* require.
>
> Hopefully this repetition is enough: I do not claim any such entitlement.

If you don't claim such entitlement, who does? Whose entitlement are
you arguing for? If its Guido's, I think we can stop arguing - sure,
he is entitled to ask for a lot, but I don't want to argue about what
entitlements someone else has: they can argue on their own.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[Lennart Regebro]
\>>> I have yet to see a use case for that.

[Tim]
>> Of course you have.  When you address them, you usually dismiss them
>> as "calendar operations" (IIRC).

'[Lennart]

> Those are not usecases for this broken behaviour.
>
> I agree there is a usecase for where you want to add one day to an 8am
> datetime, and get 8am the next day. Calling them "date operations" or
> "calendar operations" is not dismissing them. I got into this whole
> mess because I implemented calendars. That use case is the main
> usecase for those operations.
>
> But that usecase is easily handled in several ways. Already today in
> how datetime works, you have two solutions: The first is to use a time
> zone naive datetime. This is what most people who want to ignore time
> zones should use. The other is to separate the datetime into date and
> time objects and add a day to the date object.
>
> But most importantly, there are better ways to solve this that
> datetime today doesn't support at all:
>
> 1. You can use something like dateutil.rrule for repeating events.
> (works today, but requires a third-party module).
> 2. timedelta could not incorrectly pretend that one day is always 24
> hours, but actually handle days separately, and always increase the
> days when a day is given. (This would however mean we no longer can
> support fractional days).
> 3. There could be a datetelta() object that makes operations on dates,
> leaving hours, minuts, seconds and microseconds alone, or something
> like Lubridates Perod and Delta objects, where a Period() essentially
> operates on wall time, and a Duration() operates on real time.
>
> So that's not the usecase I'm asking for. I am specifically asking for
> a usecase where I want an object that is timezone aware, but ignores
> the timezone for everything other than conversion to other timezones.
> Because that's what datetime implements. That's what I want a usecase
> for. "I want the same time next day" is not such a usecase.
>
> And I don't want that use case for you to convince me that we
> shouldn't change datetime. You say it breaks too much. OK, if you say
> so. I don't know.
> I want to know if that use case actually exists, because I don't think it 
> does.
>
>> But it doesn't matter whether you _call_ them "calendar operations",
>> or anything else.  What they're called doesn't change any of the
>> high-order bits:  they are use cases, they already work, they have
>> worked that way for a dozen years (an eternity in "computer time"),
>> they were always intended to work that way, and the docs have always
>> said they work that way.
>
> They only work like that because people have adapted to how datetime
> does things. If datetime had done this properly from the start, it
> would have worked even better.
>
>> I do think you're missing my fundamental objection:  no matter what
>> intended and documented thing datetime (or any other module) has done
>> all along, and regardless of whether I loved it or hated it, I'd be
>> just as annoying about insisting we cannot intentionally break
>> existing code
>
> I stopped arguying for changing datetime two days ago. I've also
> mentioned that several times.
>
>> using that thing in non-trivial ways without a
>> justification so compelling that I can't recall a case of it ever
>> happening.
>
> Well, I've seen several of those on Stackoverflow.
>
> //Lennart
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com