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

On Sat, Jul 25, 2015 at 7:12 AM, Tim Peters wrote: > [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

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

> The formulas only produced approximations, and then > rounded to 5-second boundaries because the tz data format didn't have > enough bits. Little known fact: if you have a sub-minute-resolution UTC offset when a leap second hits, it rips open a hole in the space-time continuum and you find you

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

> From: Tim Peters > Sent: Saturday, July 25, 2015 00:14 > To: ISAAC J SCHWABACHER > Cc: Alexander Belopolsky; Lennart Regebro; Python-Dev > Subject: Re: [Python-Dev] Status on PEP-431 Timezones > [Tim] > >> The formulas only produced approximations, and then > >> rounded to 5-second boundaries b

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

[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

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

[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

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

[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

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

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. On Sat, Jul 25, 2015 at 3:39 AM, Tim Peters wrote: > [ISA

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

On Fri, Jul 24, 2015 at 9:39 PM, Tim Peters wrote: > > But IIUC what Lennart is complaining about > > I don't, and I wish he would be more explicit about what "the > problem(s)" is(are). > > > is the fact that the DST flag isn't part of and can't be embedded into a > local time, > > so it's impos

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

[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,

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

On 25/07/2015 00:06, ISAAC J SCHWABACHER wrote: I got to "Daylight Saving Time is a red herring," and stopped reading. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Python

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

Well, I was going to stay silent, but math is something I can do without wasting anyone's time or embarrassing myself. I don't think this mail answers Lennart's concerns, but I do want to get it out there to compete with the comment in `datetime.py`. I apologize if the LaTeX density is too high;

[Python-Dev] PyCapsule_Import semantics, relative imports, module names etc.

While porting several existing CPython extension modules that form a package to be 2.7 and 3.x compatible the existing PyObject_* API was replaced with PyCapsule_*. This introduced some issues the existing CPython docs are silent on. I'd like clarification on a few issues and wish to raise some

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

Hi, I don't know if it's related but at EuroPython at saw a new website which can also help: http://pybenchmarks.org/ Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mai

Re: [Python-Dev] PEP 447 (type.__getdescriptor__)

> On 24 Jul 2015, at 17:29, Nick Coghlan wrote: > > On 25 July 2015 at 00:50, Brett Cannon wrote: >> Leave the decorator out like __new__, otherwise people are bound to forget >> it and have a hard time debugging why their code doesn't work. > > I'd actually advocate for keeping this as a meta

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2015-07-17 - 2015-07-24) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open4957 (+10) closed 31511 (+43) total 36468 (+53) Open issues wit

Re: [Python-Dev] PEP 447 (type.__getdescriptor__)

On 25 July 2015 at 00:50, Brett Cannon wrote: > Leave the decorator out like __new__, otherwise people are bound to forget > it and have a hard time debugging why their code doesn't work. I'd actually advocate for keeping this as a metaclass method, rather than making it available to any type ins

Re: [Python-Dev] Building python 2.7.10 for Windows from source

Those files should be under PC folder. Building 3.5 and onwards is a much more pleasant experience, and many of those improvements have been backported for 2.7.11. Cheers, Steve Top-posted from my Windows Phone From: Mark Kelley Sent: ‎

Re: [Python-Dev] PEP 447 (type.__getdescriptor__)

On Fri, Jul 24, 2015, 07:43 Ronald Oussoren wrote: On 24 Jul 2015, at 16:17, Nick Coghlan wrote: On 23 July 2015 at 03:12, Steve Dower wrote: Terry Reedy wrote: On 7/22/2015 3:25 AM, Ronald Oussoren wrote: Hi, Another summer with another EuroPython, which means its time again to try t

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

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:2

Re: [Python-Dev] PEP 447 (type.__getdescriptor__)

> On 24 Jul 2015, at 16:17, Nick Coghlan wrote: > > On 23 July 2015 at 03:12, Steve Dower > wrote: >> Terry Reedy wrote: >>> On 7/22/2015 3:25 AM, Ronald Oussoren wrote: Hi, Another summer with another EuroPython, which means its time again to >

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

On 24 July 2015 at 23:55, Serhiy Storchaka 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 >> l...@lists.01.org. You can also check our website: htt

Re: [Python-Dev] PEP 447 (type.__getdescriptor__)

On 23 July 2015 at 03:12, Steve Dower wrote: > Terry Reedy wrote: >> On 7/22/2015 3:25 AM, Ronald Oussoren wrote: >>> Hi, >>> >>> Another summer with another EuroPython, which means its time again to >>> try to revive PEP 447… >>> >>> I’ve just pushes a minor update to the PEP and would like to ge

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

On 24.07.15 15:34, lp_benchmark_robot wrote: Hi Internals, This is the first message from Intel's language optimization team. We would like to provide the Python internals developer community with a daily service which will monitor latest committed patches performance regressions against well kn

Re: [Python-Dev] Building python 2.7.10 for Windows from source

On Jul 24, 2015 8:30 AM, "Mark Kelley" wrote: > > I have been using Python for some time but it's been a decade since > I've tried to build it from source, back in the 2.4 days. Things seem > to have gotten a little more complicated now. > > I've read through the PCBuild/README file and got most

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

Hi Internals, This is the first message from Intel's language optimization team. We would like to provide the Python internals developer community with a daily service which will monitor latest committed patches performance regressions against well known workloads. Our aim is to run a multitude o

[Python-Dev] [python_default-nightly] Benchmark Results for 3bbd0cbfe836511dd3e05fcc30ffb5bdbfe686ea

Hi Internals, This is the first message from Intel's language optimization team. We would like to provide the Python internals developer community with a daily service which will monitor latest committed patches performance regressions against well known workloads. Our aim is to run a multitude o

[Python-Dev] Building python 2.7.10 for Windows from source

I have been using Python for some time but it's been a decade since I've tried to build it from source, back in the 2.4 days. Things seem to have gotten a little more complicated now. I've read through the PCBuild/README file and got most stuff compiling. I find it a little odd that there are sp

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

On 23 Jul 2015 01:36, "Nikolaus Rath" wrote: > > On Jul 22 2015, Nick Coghlan wrote: > > On 22 July 2015 at 13:23, Nikolaus Rath wrote: > >> If it were up to me, I'd focus all the resources of the PSF on reducing > >> this backlog - be that by hiring some core developers to work full-time > >> o