Re: [Python-Dev] Not being able to compile: make: *** [Programs/_freeze_importlib] Error 1
On Thu, Apr 16, 2015 at 9:23 PM Facundo Batista facundobati...@gmail.com wrote: On Thu, Apr 16, 2015 at 6:34 PM, R. David Murray rdmur...@bitdance.com wrote: Most likely you just need to run 'make touch' so that it doesn't try to rebuild stuff it doesn't need to (because we check in those particular build artifacts, like the frozen importlib). make touch didn't fix it, but when doing that I noticed this message: Modules/Setup.dist is newer than Modules/Setup; check to make sure you have all the updates you need in your Modules/Setup file. Usually, copying Modules/Setup.dist to Modules/Setup will work. I copied that file, and then make touch, and then the make finished OK!!! Should we update the developer guide with these instructions, or all this is unlikely to happen? It happens on occasion. It definitely wouldn't hurt to add a little note to the UNIX build section of the devguide that this happens on occasion and so to look for it when running configure or make (it's always printed first so it's easy to spot). ___ 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
[Python-Dev] Changing PyModuleDef.m_reload to m_slots
Hello,
PEP 489, Redesigning extension module loading [0], is currently
discussed on import-sig, but one question calls for a wider audience.
As a background, the PyModuleDef structure [1] is currently:
struct PyModuleDef{
PyModuleDef_Base m_base;
const char* m_name;
const char* m_doc;
Py_ssize_t m_size;
PyMethodDef *m_methods;
inquiry m_reload;
traverseproc m_traverse;
inquiry m_clear;
freefunc m_free;
};
... where the m_reload pointer is unused, and must be NULL.
My proposal is to repurpose this pointer to hold an array of slots, in
the style of PEP 384's PyType_Spec [2], which would allow adding
extensions -- both those needed for PEP 489 and future ones.
The result would be:
typedef struct {
int slot;
void *value;
} PyModuleDesc_Slot;
typedef struct PyModuleDef {
PyModuleDef_Base m_base;
const char* m_name;
const char* m_doc;
Py_ssize_t m_size;
PyMethodDef *m_methods;
PyModuleDesc_Slot* m_slots; /* -- change here */
traverseproc m_traverse;
inquiry m_clear;
freefunc m_free;
} PyModuleDef;
The alternative is defining another struct for module definitions, with
a parallel versions of functions to operate on it, and duplication on
the lower level (e.g. a variant of PyModule_GetDef, variants for
PyState_FindModule c with the supporting registry, extra storage in
module objects, two places to look in for GC/deallocation hooks).
The downside is that, strictly speaking, this would break API/ABI,
though in pedantic details.
The field name could conceivably be used to get the NULL or in C99-style
designated initializers, but since NULL is the only valid value, I don't
see a reason for that. It could also be used for zeroing the structure
after allocating a PyModuleDef dynamically.
ABI-wise, this changes a function pointer to a data pointer. To my
knowledge, Python doesn't support a platform where this would matter,
but I admit my knowledge is not complete.
Please share any concerns you might have about this change.
[0] https://www.python.org/dev/peps/pep-0489/
[1] https://docs.python.org/3/c-api/module.html#c.PyModuleDef
[2] https://www.python.org/dev/peps/pep-0384/#type-objects
___
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
[Python-Dev] unittest test discovery and namespace packages
Hello! There's an issue considering test discovery in unittest module. Basically it is about unittest module that doesn't find tests in namespace packages. For more info see issue http://bugs.python.org/issue23882. I'm willing to make a patch for this bug. But I need help to formulate how test discovery should work. Documentation states that all importable modules that match pattern will be loaded. This means that test modules inside namespace packages should be loaded too. But enabling this would change things drastically. For example now, running python -m unittest inside cpython source root does nothing. If we will enable test discovery inside namespace packages then this command will start running the whole python test suite in Lib/test/. So I'm looking for someone's help to clarify how test discovery should work. Thanks, Alex -- Issue in bugtracker - http://bugs.python.org/issue23882 Documentation for discover() method - https://docs.python.org/3.4/library/unittest.html#unittest.TestLoader.discover ___ 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] unittest test discovery and namespace packages
On 17 April 2015 at 19:40, Alex Shkop a.v.sh...@gmail.com wrote: Hello! There's an issue considering test discovery in unittest module. Basically it is about unittest module that doesn't find tests in namespace packages. For more info see issue http://bugs.python.org/issue23882. I'm willing to make a patch for this bug. But I need help to formulate how test discovery should work. Documentation states that all importable modules that match pattern will be loaded. This means that test modules inside namespace packages should be loaded too. But enabling this would change things drastically. For example now, running python -m unittest inside cpython source root does nothing. If we will enable test discovery inside namespace packages then this command will start running the whole python test suite in Lib/test/. I don't think that 'scan the global namespace' makes a sensible default definition. The behaviour of discovery with namespace packages today requires some key to select the namespace - either a locally discovered directory, which happens to be a namespace package, or the name of the package to process. Since discovery is recursive, sub namespace packages should work, but I note there are no explicit tests to this effect. I'm sorry I didn't respond earlier on the tracker, didn't see the issue in my inbox for some reason. Lets discuss there. -Rob -- Robert Collins rbtcoll...@hp.com 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] [python-committers] Do we need to sign Windows files with GnuPG?
On 17.04.2015 19:31, Martin v. Löwis wrote: Am 17.04.15 um 00:46 schrieb M.-A. Lemburg: I had asked the PSF for a StartSSL certificate when the previous certificate expired, and the PSF was not able to provide one. After waiting several weeks for the PSF to provide the certificate, Kurt then kindly went to Verisign. When was that ? I never received such a request. I sent the request to Jesse Noller, Noah Kantrowitz and Kurt Kaiser on 2014-03-17. On 2014-04-15, Jesse indicated that he had given up. I guess that explains why nothing happened. Jesse owned the StartSSL account before I took over in Dec last year. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 17 2015) Python Projects, Coaching and Consulting ... http://www.egenix.com/ mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] [python-committers] Do we need to sign Windows files with GnuPG?
Am 17.04.15 um 00:46 schrieb M.-A. Lemburg: I had asked the PSF for a StartSSL certificate when the previous certificate expired, and the PSF was not able to provide one. After waiting several weeks for the PSF to provide the certificate, Kurt then kindly went to Verisign. When was that ? I never received such a request. I sent the request to Jesse Noller, Noah Kantrowitz and Kurt Kaiser on 2014-03-17. On 2014-04-15, Jesse indicated that he had given up. Regards, Martin ___ 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
[Python-Dev] async/await PEP
Hello, I've just posted a new PEP about adding async/await to python-ideas. Maybe I should have posted it here instead.. Anyways, please take a look. Thanks, Yury ___ 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
[Python-Dev] PEP 484 (Type Hints) -- the next draft is here
The PEP 484 authors (Jukka, Łukasz and I) have a new draft ready. This time we're posting to python-dev. While we don't have all details totally sorted out, it's a lot closer. We have a BDFL-Delegate (Mark Shannon), and we've worked out a variety of issues at PyCon. Our hope remains that we'll get the typing.py module added to CPython 3.5 before beta 1 goes out (May 24). Below is a list of key changes since the draft posted to python-dev on March 20 (for more details see https://github.com/ambv/typehinting/commits/master/pep-0484.txt) and the full text of the PEP. The new draft is also in the peps repo ( https://hg.python.org/peps/file/tip/pep-0484.txt) and will soon be on python.org (https://www.python.org/dev/peps/pep-0484/ -- give it 10-30 minutes). As always, between draft postings the PEP text is updated frequently by the authors in a dedicated GitHub repo (https://github.com/ambv/typehinting), and many detailed discussions are found in the issue tracker there ( https://github.com/ambv/typehinting/issues). The typing.py module also lives in that repo ( https://github.com/ambv/typehinting/tree/master/prototyping). Key changes since 20-Mar-2015 draft -- Generics: - Properly specify generics and type variables. - Add covariant/contravariant flags to TypeVar(). Type specifications: - Define type aliases. - Kill Undefined. - Better specification of `# type:` comments. Specifics: - Add Generator (a generic type describing generator objects) - Document get_type_hints(). Stubs: - Only .pyi is a valid extension for stub files. - Add discussion of third-party stubs (see issue #84). Process: - Mark Shannon is now BDFL-Delegate. - Add section on PEP Development Process, with github links. Other: - Mention the __future__ proposal (a separate PEP to be developed). - Lots of editing; remove some sections that didn't specify anything. Full PEP text -- PEP: 484 Title: Type Hints Version: $Revision$ Last-Modified: $Date$ Author: Guido van Rossum gu...@python.org, Jukka Lehtosalo jukka.lehtos...@iki.fi, Łukasz Langa luk...@langa.pl BDFL-delegate: Mark Shannon Discussions-To: Python-Dev python-dev@python.org Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 29-Sep-2014 Post-History: 16-Jan-2015,20-Mar-2015,17-Apr-2015 Resolution: Abstract This PEP introduces a standard syntax for type hints using annotations (PEP 3107) on function definitions. For example, here is a simple function whose argument and return type are declared in the annotations:: def greeting(name: str) - str: return 'Hello ' + name While these annotations are available at runtime through the usual ``__annotations__`` attribute, *no type checking happens at runtime*. Instead, the proposal assumes the existence of a separate off-line type checker which users can run over their source code voluntarily. Essentially, such a type checker acts as a very powerful linter. The proposal is strongly inspired by mypy [mypy]_. For example, the type sequence of integers can be written as ``Sequence[int]``. The square brackets mean that no new syntax needs to be added to the language. The example here uses a custom class ``Sequence``, imported from a pure-Python module ``typing``. The ``Sequence[int]`` notation works by implementing ``__getitem__()`` in the metaclass. The type system supports unions, generic types, and a special type named ``Any`` which is consistent with (i.e. assignable to and from) all types. This latter feature is taken from the idea of gradual typing. Gradual typing and the full type system are explained in PEP 483. Other approaches from which we have borrowed or to which ours can be compared and contrasted are described in PEP 482. Rationale and Goals === PEP 3107 added support for arbitrary annotations on parts of a function definition. Although no meaning was assigned to annotations then, there has always been an implicit goal to use them for type hinting, which is listed as the first possible use case in said PEP. This PEP aims to provide a standard syntax for type annotations, opening up Python code to easier static analysis and refactoring, potential runtime type checking, and performance optimizations utilizing type information. Of these goals, static analysis is the most important. This includes support for off-line type checkers such as mypy, as well as providing a standard notation that can be used by IDEs for code completion and refactoring. Non-goals - While the proposed typing module will contain some building blocks for runtime type checking -- in particular a useful ``isinstance()`` implementation -- third party packages would have to be developed to implement specific runtime type checking functionality, for example using decorators or metaclasses. Using type hints for performance optimizations is left as an exercise for the reader. It should also be emphasized that
Re: [Python-Dev] Summary of Python tracker Issues
On Fri, 17 Apr 2015 18:08:24 +0200, Python tracker sta...@bugs.python.org wrote: ACTIVITY SUMMARY (2015-04-10 - 2015-04-17) 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: open4792 (-31) closed 30957 (+113) total 35749 (+82) That's a successful sprint week :) Thanks everyone! --David ___ 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
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2015-04-10 - 2015-04-17) 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: open4792 (-31) closed 30957 (+113) total 35749 (+82) Open issues with patches: 2240 Issues opened (60) == #22980: C extension naming doesn't take bitness into account http://bugs.python.org/issue22980 reopened by lemburg #23908: Check path arguments of os functions for null character http://bugs.python.org/issue23908 opened by serhiy.storchaka #23910: C implementation of namedtuple (WIP) http://bugs.python.org/issue23910 opened by ll #23911: Move path-based bootstrap code to a separate frozen file. http://bugs.python.org/issue23911 opened by eric.snow #23914: pickle fails with SystemError http://bugs.python.org/issue23914 opened by alex #23915: traceback set with BaseException.with_traceback() overwritten http://bugs.python.org/issue23915 opened by abathur #23917: please fall back to sequential compilation when concurrent doe http://bugs.python.org/issue23917 opened by doko #23919: [Windows] test_os fails several C-level assertions http://bugs.python.org/issue23919 opened by zach.ware #23920: Should Clinic have nullable or types=NoneType? http://bugs.python.org/issue23920 opened by larry #23921: Standardize documentation whitespace, formatting http://bugs.python.org/issue23921 opened by jedwards #23922: turtle.py and turtledemo use the default tkinter icon http://bugs.python.org/issue23922 opened by Al.Sweigart #23926: skipitem() in getargs.c still supports 'w' and 'w#', and shoul http://bugs.python.org/issue23926 opened by larry #23927: getargs.c skipitem() doesn't skip 'w*' http://bugs.python.org/issue23927 opened by larry #23930: SimpleCookie doesn't parse comma-only separated cookies corre http://bugs.python.org/issue23930 opened by riklaunim #23931: Update DevGuide link in Quickstart Step 1 http://bugs.python.org/issue23931 opened by willingc #23933: Struct module should acept arrays http://bugs.python.org/issue23933 opened by gamaanderson #23934: inspect.signature reporting () for all builtin extension t http://bugs.python.org/issue23934 opened by ncoghlan #23936: Wrong references to deprecated find_module instead of find_spe http://bugs.python.org/issue23936 opened by raulcd #23937: IDLE start maximized http://bugs.python.org/issue23937 opened by zektron42 #23942: Explain naming of the patch files in the bug tracker http://bugs.python.org/issue23942 opened by maciej.szulik #23946: Invalid timestamps reported by os.stat() when Windows FILETIME http://bugs.python.org/issue23946 opened by CristiFati #23947: Add mechanism to import stdlib package bypassing user packages http://bugs.python.org/issue23947 opened by steve.dower #23948: Deprecate os.kill() on Windows http://bugs.python.org/issue23948 opened by jpe #23949: Number of elements display in error message is wrong while unp http://bugs.python.org/issue23949 opened by ulaganathanm...@gmail.com #23950: Odd behavior with file and filename attributes in cgi.Fiel http://bugs.python.org/issue23950 opened by deadpixi #23951: Update devguide style to use a similar theme as Docs http://bugs.python.org/issue23951 opened by willingc #23952: Document the 'maxlen' member of the cgi module http://bugs.python.org/issue23952 opened by deadpixi #23953: test_mmap uses cruel and unusual amounts of disk space http://bugs.python.org/issue23953 opened by larry #23954: Pressing enter/return or clicking IDLE's autocomplete does not http://bugs.python.org/issue23954 opened by Al.Sweigart #23955: Add python.ini file for embedded/applocal installs http://bugs.python.org/issue23955 opened by steve.dower #23958: compile warnings in libffi http://bugs.python.org/issue23958 opened by steveha #23959: Update imaplib to support RFC3501 http://bugs.python.org/issue23959 opened by maciej.szulik #23960: PyErr_SetImportError doesn't clean up on some errors http://bugs.python.org/issue23960 opened by blackfawn #23961: IDLE autocomplete window does not automatically close when sel http://bugs.python.org/issue23961 opened by Al.Sweigart #23962: Incorrect TimeoutError referenced in concurrent.futures docume http://bugs.python.org/issue23962 opened by ryder.lewis #23963: Windows build error using original openssl source http://bugs.python.org/issue23963 opened by anselm.kruis #23964: Update README documentation for IDLE tests. http://bugs.python.org/issue23964 opened by Al.Sweigart #23965: test_ssl failure on Fedora 22 http://bugs.python.org/issue23965 opened by kushal.das #23966: More clearly expose/explain native and cross-build target info http://bugs.python.org/issue23966 opened by ncoghlan #23967: Make inspect.signature expression evaluation more powerful http://bugs.python.org/issue23967 opened by larry #23968: rename the platform directory from
Re: [Python-Dev] PEP 484 (Type Hints) -- the next draft is here
Guido van Rossum schrieb am 17.04.2015 um 23:58: The ``typing`` module defines the ``Generator`` type for return values of generator functions. It is a subtype of ``Iterable`` and it has additional type variables for the type accepted by the ``send()`` method and the return type of the generator: * Generator, used as ``Generator[yield_type, send_type, return_type]`` Is this meant to accept only Python generators, or any kind of object that implements the coroutine protocol? I'm asking because asyncio currently suffers from an annoying type check here, so I'd like to avoid that this problem keeps popping up again in other places. Stefan ___ 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] async/await PEP
Hello, On Fri, 17 Apr 2015 15:12:50 -0400 Yury Selivanov yselivanov...@gmail.com wrote: Hello, I've just posted a new PEP about adding async/await to python-ideas. Maybe I should have posted it here instead.. For reference, python-ideas archive link is https://mail.python.org/pipermail/python-ideas/2015-April/033007.html Anyways, please take a look. Thanks, Yury -- Best regards, Paul mailto:pmis...@gmail.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] Summary of Python tracker Issues
Thank you, David, for all of your work. It's much appreciated. -- Eric. On Apr 17, 2015, at 7:18 PM, R. David Murray rdmur...@bitdance.com wrote: On Fri, 17 Apr 2015 18:08:24 +0200, Python tracker sta...@bugs.python.org wrote: ACTIVITY SUMMARY (2015-04-10 - 2015-04-17) 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: open4792 (-31) closed 30957 (+113) total 35749 (+82) That's a successful sprint week :) Thanks everyone! --David ___ 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/eric%2Ba-python-dev%40trueblade.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] Aware datetime from naive local time Was: Status on PEP-431 Timezones
On Thu, Apr 16, 2015 at 1:14 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Apr 15, 2015 at 4:46 PM, Akira Li 4kir4...@gmail.com wrote:
Look what happened on July 1, 1990. At 2 AM, the clocks in Ukraine were
moved back one hour. So times like 01:30 AM happened twice there on
that
day. Let's see how Python handles this situation
$ TZ=Europe/Kiev python3
from email.utils import localtime
from datetime import datetime
localtime(datetime(1990,7,1,1,30)).strftime('%c %z %Z')
'Sun Jul 1 01:30:00 1990 +0400 MSD'
So far so good, I've got the first of the two 01:30AM's. But what if I
want the other 01:30AM? Well,
localtime(datetime(1990,7,1,1,30), isdst=0).strftime('%c %z %Z')
'Sun Jul 1 01:30:00 1990 +0300 EEST'
gives me the other 01:30AM, but it is counter-intuitive: I have to ask
for the standard (winter) time to get the daylight savings (summer)
time.
It looks incorrect. Here's the corresponding pytz code:
from datetime import datetime
import pytz
tz = pytz.timezone('Europe/Kiev')
print(tz.localize(datetime(1990, 7, 1, 1, 30),
is_dst=False).strftime('%c %z %Z'))
# - Sun Jul 1 01:30:00 1990 +0300 EEST
print(tz.localize(datetime(1990, 7, 1, 1, 30),
is_dst=True).strftime('%c %z %Z'))
# - Sun Jul 1 01:30:00 1990 +0400 MSD
See also Enhance support for end-of-DST-like ambiguous time [1]
[1] https://bugs.launchpad.net/pytz/+bug/1378150
`email.utils.localtime()` is broken:
If you think there is a bug in email.utils.localtime - please open an
issue at bugs.python.org.
Your question below suggests that you believe it is not a bug i.e.,
`email.utils.localtime()` is broken *by design* unless you think it is ok
to ignore `+0400 MSD`.
pytz works for me (I can get both `+0300 EEST` and `+0400 MSD`). I don't
think `localtime()` can be fixed without the tz database. I don't know
whether it should be fixed, let somebody else who can't use pytz to pioneer
the issue. The purpose of the code example is to **inform** that
`email.utils.localtime()` fails (it returns only +0300 EEST) in this case:
from datetime import datetime
from email.utils import localtime
print(localtime(datetime(1990, 7, 1, 1, 30)).strftime('%c %z %Z'))
# - Sun Jul 1 01:30:00 1990 +0300 EEST
print(localtime(datetime(1990, 7, 1, 1, 30), isdst=0).strftime('%c %z
%Z'))
# - Sun Jul 1 01:30:00 1990 +0300 EEST
print(localtime(datetime(1990, 7, 1, 1, 30), isdst=1).strftime('%c %z
%Z'))
# - Sun Jul 1 01:30:00 1990 +0300 EEST
print(localtime(datetime(1990, 7, 1, 1, 30), isdst=-1).strftime('%c %z
%Z'))
# - Sun Jul 1 01:30:00 1990 +0300 EEST
Versions:
$ ./python -V
Python 3.5.0a3+
$ dpkg -s tzdata | grep -i version
Version: 2015b-0ubuntu0.14.04
The uncertainty about how to deal with the repeated hour was the reason
why
email.utils.localtime-like interface did not make it to the datetime
module.
repeated hour (time jumps back) can be treated like a end-of-DST
transition, to resolve ambiguities [1].
I don't understand what you are complaining about. It is quite possible
that pytz uses is_dst flag differently from the way email.utils.localtime
uses isdst.
I was not able to find a good description of what is_dst means in pytz,
but localtime's isdst is documented as follows:
a positive or zero value for *isdst* causes localtime to
presume initially that summer time (for example, Daylight Saving Time)
is or is not (respectively) in effect for the specified time.
Can you demonstrate that email.utils.localtime does not behave as
documented?
No need to be so defensive about it. *repeated hour (time jumps back)
can be treated like a end-of-DST transition, to resolve ambiguities [1].*
is just a *an example* on how to fix the problem in the same way how it is
done in pytz:
from datetime import datetime
import pytz
tz = pytz.timezone('Europe/Kiev')
after = tz.localize(datetime(1990, 7, 1, 1, 30), is_dst=False)
before = tz.localize(datetime(1990, 7, 1, 1, 30), is_dst=True)
before after
True
before
datetime.datetime(1990, 7, 1, 1, 30, tzinfo=DstTzInfo 'Europe/Kiev'
MSD+4:00:00 DST)
after
datetime.datetime(1990, 7, 1, 1, 30, tzinfo=DstTzInfo 'Europe/Kiev'
EEST+3:00:00 DST)
before.astimezone(pytz.utc)
datetime.datetime(1990, 6, 30, 21, 30, tzinfo=UTC)
after.astimezone(pytz.utc)
datetime.datetime(1990, 6, 30, 22, 30, tzinfo=UTC)
before.dst()
datetime.timedelta(0, 3600)
after.dst()
datetime.timedelta(0, 3600)
pytz.OLSON_VERSION
'2015b'
Here's summer time in both cases i.e., it is not *true* end-of-DST
transition (that is why I've used the word *like* above).
If we ignore ambiguous time that may occur more than twice then a boolean
flag such as pytz's is_dst is *always* enough to resolve the ambiguity
assuming we have access to the tz database.
And yes, the example demonstrates that the behavior of pytz's is_dst and
Re: [Python-Dev] Aware datetime from naive local time Was: Status on PEP-431 Timezones
On Fri, Apr 17, 2015 at 8:19 PM, Akira Li 4kir4...@gmail.com wrote: Can you demonstrate that email.utils.localtime does not behave as documented? No need to be so defensive about it. There is nothing defensive in my question. I simply don't understand what you are complaining about other than your code using pytz produces different results from some other your code using email.utils.localtime. If you think you found a bug in email.utils.localtime - please explain it without referring to a third party library. It will also help if you do it at the bug tracker. ___ 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
