[issue12755] Service application crash in python25!PyObject_Malloc
New submission from Chandra Sekhar Reddy sanc...@ca.com:
Service application crashed in python25.dll, below are the environment details.
Operating System : Windows server 2008 R2 (Virtual Machine)
Application Type : Service Application
FAULTING_IP:
python25!PyObject_Malloc+2d
1e09603d 8b30mov esi,dword ptr [eax]
EXCEPTION_RECORD: -- (.exr 0x)
ExceptionAddress: 1e09603d (python25!PyObject_Malloc+0x002d)
ExceptionCode: c005 (Access violation)
ExceptionFlags:
NumberParameters: 2
Parameter[0]:
Parameter[1]:
Attempt to read from address
PROCESS_NAME: adem.exe
ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set
symbol path and load symbols.
FAULTING_MODULE: 76f8 ntdll
DEBUG_FLR_IMAGE_TIMESTAMP: 4625bfe5
ERROR_CODE: (NTSTATUS) 0xc005 - The instruction at 0x%08lx referenced
memory at 0x%08lx. The memory could not be %s.
EXCEPTION_CODE: (NTSTATUS) 0xc005 - The instruction at 0x%08lx referenced
memory at 0x%08lx. The memory could not be %s.
EXCEPTION_PARAMETER1:
EXCEPTION_PARAMETER2:
READ_ADDRESS:
FOLLOWUP_IP:
python25!PyObject_Malloc+2d
1e09603d 8b30mov esi,dword ptr [eax]
FAULTING_THREAD: 2474
BUGCHECK_STR:
APPLICATION_FAULT_INVALID_POINTER_WRITE_NULL_POINTER_WRITE_NULL_POINTER_READ_WRONG_SYMBOLS
PRIMARY_PROBLEM_CLASS: INVALID_POINTER_WRITE_NULL_POINTER_WRITE
DEFAULT_BUCKET_ID: INVALID_POINTER_WRITE_NULL_POINTER_WRITE
LAST_CONTROL_TRANSFER: from 1e0c1093 to 1e09603d
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
0505f088 1e0c1093 0025 04a128ea 04a128d0 python25!PyObject_Malloc+0x2d
python25!PyString_FromStringAndSize+0x43
STACK_COMMAND: ~4s; .ecxr ; kb
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: python25!PyObject_Malloc+2d
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: python25
IMAGE_NAME: python25.dll
BUCKET_ID: WRONG_SYMBOLS
FAILURE_BUCKET_ID:
INVALID_POINTER_WRITE_NULL_POINTER_WRITE_c005_python25.dll!PyObject_Malloc
--
components: Windows
messages: 142163
nosy: chandra
priority: normal
severity: normal
status: open
title: Service application crash in python25!PyObject_Malloc
type: crash
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12755
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12750] datetime.datetime timezone problems
Changes by Ben Finney ben+pyt...@benfinney.id.au: -- nosy: +bignose ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12750 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12756] datetime.datetime.utcnow should return a UTC timestamp
New submission from Ben Finney ben+pyt...@benfinney.id.au: = $ date -u +'%F %T %s %z' 2011-08-16 06:42:12 1313476932 + $ python -c 'import sys, datetime; now = datetime.datetime.utcnow(); sys.stdout.write(now.strftime(%F %T %s %z))' 2011-08-16 06:42:12 1313440932 = The documentation for ‘datetime.datetime.utcnow’ says “Return a new datetime representing UTC day and time.” The resulting object should be in the UTC timezone, not a naive no-timezone value. This results in programs specifically requesting UTC time with ‘utcnow’, but then Python treating the return value as representing local time since it is not marked with the UTC timezone. -- components: Library (Lib) messages: 142164 nosy: Daniel.O'Connor, bignose, r.david.murray priority: normal severity: normal status: open title: datetime.datetime.utcnow should return a UTC timestamp type: feature request versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12756 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12757] undefined name in doctest.py
New submission from Georg Brandl ge...@python.org: doctest.py, line 2274 (in 2.7): def shortDescription(self): return Skipping tests from %s % module.__name__ module is not defined here. Assigning to David since he last changed this line. Test script attached. -- assignee: r.david.murray components: Library (Lib) files: t.py messages: 142165 nosy: georg.brandl, r.david.murray priority: normal severity: normal stage: needs patch status: open title: undefined name in doctest.py versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file22907/t.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12757 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12755] Service application crash in python25!PyObject_Malloc
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Can you please give more context? From the information you gave: - Python is embedded in some program adem.exe. - Memory seems corrupted, and a C call to PyString_FromStringAndSize() segfaults in PyObject_Malloc(). Most of the time, it will be an issue in the application, and not a python bug. -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12755 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12758] time.time() returns local time instead of UTC
New submission from Maxim Koltsov kolma...@gmail.com: Python docs (http://docs.python.org/library/time.html#time.time) say that time.time() function should return UTC timestamp, but actually i get local one: time.mktime(time.gmtime()), time.time(), time.mktime(time.localtime()) (1313466499.0, 1313480899.384221, 1313480899.0) As you can see, the result of second statement is equal to result of the third, while it must be equal to result of the first. Checked on 2.7 and 3.1. My OS is Gentoo/Linux, timezone-info is the latest version (2011h). -- messages: 142167 nosy: maksbotan priority: normal severity: normal status: open title: time.time() returns local time instead of UTC versions: Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12758 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12758] time.time() returns local time instead of UTC
Marc-Andre Lemburg m...@egenix.com added the comment: Maxim Koltsov wrote: New submission from Maxim Koltsov kolma...@gmail.com: Python docs (http://docs.python.org/library/time.html#time.time) say that time.time() function should return UTC timestamp, but actually i get local one: time.mktime(time.gmtime()), time.time(), time.mktime(time.localtime()) (1313466499.0, 1313480899.384221, 1313480899.0) As you can see, the result of second statement is equal to result of the third, while it must be equal to result of the first. Checked on 2.7 and 3.1. My OS is Gentoo/Linux, timezone-info is the latest version (2011h). The description in the docs is a bit misleading. time.time() returns the local time in number of seconds since the epoch (1970-01-01 00:00:0O UTC). UTC refers to the epoch, not the timezone used by time.time(). -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12758 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12758] time.time() returns local time instead of UTC
Maxim Koltsov kolma...@gmail.com added the comment: Then docs must be fixed. By the way, help(time.time) correctly says about localtime. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12758 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12758] time.time() returns local time instead of UTC
Changes by Marc-Andre Lemburg m...@egenix.com: -- assignee: - docs@python components: +Documentation, Library (Lib) nosy: +docs@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12758 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12758] time.time() returns local time instead of UTC
Changes by Marc-Andre Lemburg m...@egenix.com: -- keywords: +easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12758 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12751] Use macros for surrogates in unicodeobject.c
Ezio Melotti ezio.melo...@gmail.com added the comment: #10542 proposes the following macros to factor out common code: #define _Py_UNICODE_ISSURROGATE #define _Py_UNICODE_ISHIGHSURROGATE #define _Py_UNICODE_ISLOWSURROGATE #define _Py_UNICODE_JOIN_SURROGATES and to avoid checking for narrow/wide builds and recombine surrogates manually (so still refactoring): #define _Py_UNICODE_NEXT #define _Py_UNICODE_PUT_NEXT Your patch proposes the same 4 macros: #define IS_SURROGATE #define IS_HIGH_SURROGATE #define IS_LOW_SURROGATE #define COMBINE_SURROGATES + 3 additional macros: #define IS_NONBMP #define HIGH_SURROGATE #define LOW_SURROGATE So the two issue looks quite similar to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12758] time.time() returns local time instead of UTC
Ezio Melotti ezio.melo...@gmail.com added the comment: Would dropping 'in UTC' from Return the time as a floating point number expressed in seconds since the epoch, in UTC. be an acceptable solution? AFAIK there are no non-UTC epochs. -- nosy: +ezio.melotti stage: - needs patch versions: +Python 3.2, Python 3.3 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12758 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12758] time.time() returns local time instead of UTC
Maxim Koltsov kolma...@gmail.com added the comment: Maybe add some words about local timezone? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12758 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Marc-Andre Lemburg m...@egenix.com added the comment: Martin v. Löwis wrote: A PEP 393 draft implementation is available at https://bitbucket.org/t0rsten/pep-393/ (branch pep-393); if this gets into 3.3, this issue will be outdated: there won't be narrow builds of Python anymore (nor will there be wide builds). Even if PEP 393 should go into Py4k one day (I don't believe that such major changes can be done in a minor release), we will still have to deal with surrogates in codecs, which is where these macros will get used, so I don't see how PEP 393 relates to the idea of adding helper macros to simplify the code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12751] Use macros for surrogates in unicodeobject.c
Marc-Andre Lemburg m...@egenix.com added the comment: Ezio Melotti wrote: Ezio Melotti ezio.melo...@gmail.com added the comment: #10542 proposes the following macros to factor out common code: #define _Py_UNICODE_ISSURROGATE #define _Py_UNICODE_ISHIGHSURROGATE #define _Py_UNICODE_ISLOWSURROGATE #define _Py_UNICODE_JOIN_SURROGATES and to avoid checking for narrow/wide builds and recombine surrogates manually (so still refactoring): #define _Py_UNICODE_NEXT #define _Py_UNICODE_PUT_NEXT Your patch proposes the same 4 macros: #define IS_SURROGATE #define IS_HIGH_SURROGATE #define IS_LOW_SURROGATE #define COMBINE_SURROGATES + 3 additional macros: #define IS_NONBMP #define HIGH_SURROGATE #define LOW_SURROGATE So the two issue looks quite similar to me. Can we please fold this issue into #10542. We've already had the discussion there. Thanks, -- Marc-Andre Lemburg eGenix.com 2011-10-04: PyCon DE 2011, Leipzig, Germany49 days to go ::: Try our new 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 tracker rep...@bugs.python.org http://bugs.python.org/issue12751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Ezio Melotti ezio.melo...@gmail.com added the comment: I think the 4 macros: #define _Py_UNICODE_ISSURROGATE #define _Py_UNICODE_ISHIGHSURROGATE #define _Py_UNICODE_ISLOWSURROGATE #define _Py_UNICODE_JOIN_SURROGATES are quite straightforward and can avoid using the trailing _. Since I would like to see #9200 fixed on 3.2 (and possibly 2.7 too), would it be ok to: 1) commit the patch with the trailing _ for all the macros on 3.2(/2.7); 2) commit the patch with the trailing _ only for the _NEXT macros in 3.3; 3) fix #9200 on all these branches using the new macros (with or without _); 4) remove the trailing _ from the _NEXT macros in 3.4 if it turns out to work well; we will still have to deal with surrogates in codecs, which is where these macros will get used They will also be used in many str methods and afaiu PEP 393 should address that. I'm not sure it addresses codecs and builtin functions like chr() and ord() too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12758] time.time() returns local time instead of UTC
Ezio Melotti ezio.melo...@gmail.com added the comment: Return the local time as a floating point number expressed in seconds since the epoch. -- nosy: +belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12758 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Antoine Pitrou pit...@free.fr added the comment: I think the 4 macros: #define _Py_UNICODE_ISSURROGATE #define _Py_UNICODE_ISHIGHSURROGATE #define _Py_UNICODE_ISLOWSURROGATE #define _Py_UNICODE_JOIN_SURROGATES are quite straightforward and can avoid using the trailing _. I don't want to bikeshed, but can we have proper consistent word separation? _Py_UNICODE_IS_HIGH_SURROGATE, not _Py_UNICODE_ISHIGHSURROGATE (etc.) we will still have to deal with surrogates in codecs, which is where these macros will get used They will also be used in many str methods and afaiu PEP 393 should address that. I'm not sure it addresses codecs and builtin functions like chr() and ord() too. AFAIU, PEP 393 avoids producing surrogate pairs in the canonical internal representation (that's one of its selling points). Only the UTF-16 codecs would need to deal with surrogate pairs, in the encoded form. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Ezio Melotti ezio.melo...@gmail.com added the comment: All the other macros[0] follow the same convention, e.g. Py_UNICODE_ISLOWER and Py_UNICODE_TOLOWER. I agree that keeping the words separate makes them more readable though. [0]: Include/unicodeobject.h:328 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12758] time.time() returns local time instead of UTC
Maxim Koltsov kolma...@gmail.com added the comment: Seems OK to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12758 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12755] Service application crash in python25!PyObject_Malloc
Chandra Sekhar Reddy sanc...@ca.com added the comment: Hi Amaury, Thanks for your update on the issue. Here are few details of our application adem.exe 1. We have three c-projects namely, AdemCube, wv, CAM, the output of the build binaries will give us _ADEMCube.pyd, _wv.pyd, _cam.pyd 2. The main project is spider project which is in python, this python code will make us of the above libraries. The output of this project will result in adem.exe The adem.exe when it executes it internally calls methods to above libraries explained in point 1. Here in this library we use call to the method below PyErr_SetString(CubeError, errorString); The call to this method is internally calls PyString_FromStringAndSize() which internally calls PyObject_Malloc(). This is the place where it is crashing. Please let me know if you need any information. Thanks, -Chandra -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12755 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12755] Service application crash in python25!PyObject_Malloc
STINNER Victor victor.stin...@haypocalc.com added the comment: Are you sure that errorString is not NULL? It looks like a bug in your application, not in Python. -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12755 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12740] Add struct.Struct.nmemb
Stefan Krah stefan-use...@bytereef.org added the comment: Including the format string in the error output is a good idea. Meador, was this a constructed failure to show the output or did it really occur? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12740 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Tom Christiansen tchr...@perl.com added the comment: Ezio Melotti ezio.melo...@gmail.com added the comment: I think the 4 macros: #define _Py_UNICODE_ISSURROGATE #define _Py_UNICODE_ISHIGHSURROGATE #define _Py_UNICODE_ISLOWSURROGATE #define _Py_UNICODE_JOIN_SURROGATES are quite straightforward and can avoid using the trailing _. For what it's worth, I've seen Unicode documentation that talks about that prefers the terms lead surrogate and trail surrogate as being clearer than the terms high surrgoate and low surrogate. For example, from the Unicode BOM FAQ at http://unicode.org/faq/utf_bom.html Q: What are surrogates? A: Surrogates are code points from two special ranges of Unicode values, reserved for use as the leading, and trailing values of paired code units in UTF-16. Leading, also called high, surrogates are from D800₁₆ to DBFF₁₆, and trailing, or low, surrogates are from DC00₁₆ to DFFF₁₆. They are called surrogates, since they do not represent characters directly, but only as a pair. BTW, considering recent discussions, you might want to read: Q: Are there any 16-bit values that are invalid? A: The two values FFFE₁₆ and ₁₆ as well as the 32 values from FDD0₁₆ to FDEF₁₆ represent noncharacters. They are invalid in interchange, but may be freely used internal to an implementation. Unpaired surrogates are invalid as well, i.e. any value in the range D800₁₆ to DBFF₁₆ not followed by a value in the range DC00₁₆ to DFFF₁₆, or any value in the range DC00₁₆ to DFFF₁₆ not preceded by a value in the range D800₁₆ to DBFF₁₆. [AF] and also the answer to: Q: Are there any paired surrogates that are invalid? whose answer I here omit for brevity, as it is a table. I suspect that you guys are now increasingly sold on the answer to the next FAQ right after that one, now. :) Q: Because supplementary characters are uncommon, does that mean I can ignore them? A: Just because supplementary characters (expressed with surrogate pairs in UTF-16) are uncommon does not mean that they should be neglected. They include: * emoji symbols and emoticons, for interoperating with Japanese mobile phones * uncommon (but not unused) CJK characters, important for personal and place names * variation selectors for ideographic variation sequences * important symbols for mathematics * numerous minority scripts and historic scripts, important for some user communities Another example of using lead and trail surrogates is in the first sentence from http://icu-project.org/apiref/icu4j/com/ibm/icu/text/UTF16.html * Naming: For clarity, High and Low surrogates are called Lead and Trail in the API, which gives a better sense of their ordering in a string. offset16 and offset32 are used to distinguish offsets to UTF-16 boundaries vs offsets to UTF-32 boundaries. int char32 is used to contain UTF-32 characters, as opposed to char16, which is a UTF-16 code unit. * Roundtripping Offsets: You can always roundtrip from a UTF-32 offset to a UTF-16 offset and back. Because of the difference in structure, you can roundtrip from a UTF-16 offset to a UTF-32 offset and back if and only if bounds(string, offset16) != TRAIL. * Exceptions: The error checking will throw an exception if indices are out of bounds. Other than than that, all methods will behave reasonably, even if unmatched surrogates or out-of-bounds UTF-32 values are present. UCharacter.isLegal() can be used to check for validity if desired. * Unmatched Surrogates: If the string contains unmatched surrogates, then these are counted as one UTF-32 value. This matches their iteration behavior, which is vital. It also matches common display practice as missing glyphs (see the Unicode Standard Section 5.4, 5.5). * Optimization: The method implementations may need optimization if the compiler doesn't fold static final methods. Since surrogate pairs will form an exceeding small percentage of all the text in the world, the singleton case should always be optimized for. You can also see this reflected in the utf.h file from the ICU project as part of their C API in ICU4C: #define U_SENTINEL (-1) This value is intended for sentinel values for APIs that (take or) return single code points (UChar32). #define U_IS_UNICODE_NONCHAR(c) Is this code point a Unicode noncharacter? #define U_IS_UNICODE_CHAR(c) Is c a Unicode code point value (0..U+10) that can be assigned a character? #define U_IS_BMP(c) ((uint32_t)(c)=0x) Is this code point a BMP code point (U+..U+)? #define U_IS_SUPPLEMENTARY(c) ((uint32_t)((c)-0x1)=0xf) Is this code point a supplementary code point (U+1..U+10)? #define U_IS_LEAD(c)
[issue12756] datetime.datetime.utcnow should return a UTC timestamp
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12756 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Tom Christiansen tchr...@perl.com added the comment: I now see there are lots of good things in the BOM FAQ that have come up lately regarding surrogates and other illegal characters, and about what can go in data streams. I quote a few of these from http://unicode.org/faq/utf_bom.html below: Q: How do I convert an unpaired UTF-16 surrogate to UTF-8? A: A different issue arises if an unpaired surrogate is encountered when converting ill-formed UTF-16 data. By represented such an *unpaired* surrogate on its own as a 3-byte sequence, the resulting UTF-8 data stream would become ill-formed. While it faithfully reflects the nature of the input, Unicode conformance requires that encoding form conversion always results in valid data stream. Therefore a converter *must* treat this as an error. Q: How do I convert an unpaired UTF-16 surrogate to UTF-32? A: If an unpaired surrogate is encountered when converting ill-formed UTF-16 data, any conformant converter must treat this as an error. By representing such an unpaired surrogate on its own, the resulting UTF-32 data stream would become ill-formed. While it faithfully reflects the nature of the input, Unicode conformance requires that encoding form conversion always results in valid data stream. Q: Can a UTF-8 data stream contain the BOM character (in UTF-8 form)? If yes, then can I still assume the remaining UTF-8 bytes are in big-endian order? A: Yes, UTF-8 can contain a BOM. However, it makes no difference as to the endianness of the byte stream. UTF-8 always has the same byte order. An initial BOM is only used as a signature — an indication that an otherwise unmarked text file is in UTF-8. Note that some recipients of UTF-8 encoded data do not expect a BOM. Where UTF-8 is used transparently in 8-bit environments, the use of a BOM will interfere with any protocol or file format that expects specific ASCII characters at the beginning, such as the use of #! of at the beginning of Unix shell scripts. Q: What should I do with U+FEFF in the middle of a file? A: In the absence of a protocol supporting its use as a BOM and when not at the beginning of a text stream, U+FEFF should normally not occur. For backwards compatibility it should be treated as ZERO WIDTH NON-BREAKING SPACE (ZWNBSP), and is then part of the content of the file or string. The use of U+2060 WORD JOINER is strongly preferred over ZWNBSP for expressing word joining semantics since it cannot be confused with a BOM. When designing a markup language or data protocol, the use of U+FEFF can be restricted to that of Byte Order Mark. In that case, any U+FEFF occurring in the middle of a file can be treated as an unsupported character. Q: How do I tag data that does not interpret U+FEFF as a BOM? A: Use the tag UTF-16BE to indicate big-endian UTF-16 text, and UTF-16LE to indicate little-endian UTF-16 text. If you do use a BOM, tag the text as simply UTF-16. Q: Why wouldn’t I always use a protocol that requires a BOM? A: Where the data has an associated type, such as a field in a database, a BOM is unnecessary. In particular, if a text data stream is marked as UTF-16BE, UTF-16LE, UTF-32BE or UTF-32LE, a BOM is neither necessary *nor permitted*. Any U+FEFF would be interpreted as a ZWNBSP. Do not tag every string in a database or set of fields with a BOM, since it wastes space and complicates string concatenation. Moreover, it also means two data fields may have precisely the same content, but not be binary-equal (where one is prefaced by a BOM). Somewhat frustratingly, I am now almost more confused than ever by the last two sentences here: Q: What is a UTF? A: A Unicode transformation format (UTF) is an algorithmic mapping from every Unicode code point (except surrogate code points) to a unique byte sequence. The ISO/IEC 10646 standard uses the term “UCS transformation format” for UTF; the two terms are merely synonyms for the same concept. Each UTF is reversible, thus every UTF supports *lossless round tripping*: mapping from any Unicode coded character sequence S to a sequence of bytes and back will produce S again. To ensure round tripping, a UTF mapping *must also* map all code points that are not valid Unicode characters to unique byte sequences. These invalid code points are the 66 *noncharacters* (including FFFE and ), as well as unpaired surrogates. My confusion is about the invalid code points. The first two FAQs I cite at the top are quite clear that it is illegal to have unpaired surrogates in a UTF stream. I don’t understand therefore what it saying about “must also” mapping all code points that aren’t valid Unicode characters to “unique byte sequences” to ensure
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Tom Christiansen tchr...@perl.com added the comment: Antoine Pitrou rep...@bugs.python.org wrote on Tue, 16 Aug 2011 09:18:46 -: I think the 4 macros: #define _Py_UNICODE_ISSURROGATE #define _Py_UNICODE_ISHIGHSURROGATE #define _Py_UNICODE_ISLOWSURROGATE #define _Py_UNICODE_JOIN_SURROGATES are quite straightforward and can avoid using the trailing _. I don't want to bikeshed, but can we have proper consistent word separation? _Py_UNICODE_IS_HIGH_SURROGATE, not _Py_UNICODE_ISHIGHSURROGATE (etc.) Oh good, I thought it was only me whohadtroublereadingthose. :) --tom -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12759] (?P=) input for Tools/scripts/redemo.py throw an exception
New submission from Alexander fred...@mail.ru: Run: python PYTHON_PATH/Tools/scripts/redemo.py Enter (?P=) in entry field. See unhandled exception occures. There is special text field in example for such cases. It should be used to show error messages, not a console. -- components: Demos and Tools files: redemo.py.png messages: 142186 nosy: fredeom priority: normal severity: normal status: open title: (?P=) input for Tools/scripts/redemo.py throw an exception type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file22908/redemo.py.png ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12759 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Tom Christiansen tchr...@perl.com added the comment:
Ezio Melotti rep...@bugs.python.org wrote
on Tue, 16 Aug 2011 09:23:50 -:
All the other macros[0] follow the same convention, e.g. Py_UNICODE_ISLOWER
and Py_UNICODE_TOLOWER. I agree that keeping the words separate makes them
more readable though.
[0]: Include/unicodeobject.h:328
I am guessing that that is not quite why those don't have underscores
in them. I bet it is actually something else. Watch:
% unigrep '^\s*#\s*define\s+Py_[\p{Lu}_]+\b' unicodeobject.h
#define Py_UNICODEOBJECT_H
#define Py_USING_UNICODE
#define Py_UNICODE_WIDE
#define Py_UNICODE_ISSPACE(ch) \
#define Py_UNICODE_ISLOWER(ch) _PyUnicode_IsLowercase(ch)
#define Py_UNICODE_ISUPPER(ch) _PyUnicode_IsUppercase(ch)
#define Py_UNICODE_ISTITLE(ch) _PyUnicode_IsTitlecase(ch)
#define Py_UNICODE_ISLINEBREAK(ch) _PyUnicode_IsLinebreak(ch)
#define Py_UNICODE_TOLOWER(ch) _PyUnicode_ToLowercase(ch)
#define Py_UNICODE_TOUPPER(ch) _PyUnicode_ToUppercase(ch)
#define Py_UNICODE_TOTITLE(ch) _PyUnicode_ToTitlecase(ch)
#define Py_UNICODE_ISDECIMAL(ch) _PyUnicode_IsDecimalDigit(ch)
#define Py_UNICODE_ISDIGIT(ch) _PyUnicode_IsDigit(ch)
#define Py_UNICODE_ISNUMERIC(ch) _PyUnicode_IsNumeric(ch)
#define Py_UNICODE_ISPRINTABLE(ch) _PyUnicode_IsPrintable(ch)
#define Py_UNICODE_TODECIMAL(ch) _PyUnicode_ToDecimalDigit(ch)
#define Py_UNICODE_TODIGIT(ch) _PyUnicode_ToDigit(ch)
#define Py_UNICODE_TONUMERIC(ch) _PyUnicode_ToNumeric(ch)
#define Py_UNICODE_ISALPHA(ch) _PyUnicode_IsAlpha(ch)
#define Py_UNICODE_ISALNUM(ch) \
#define Py_UNICODE_COPY(target, source, length) \
#define Py_UNICODE_FILL(target, value, length) \
#define Py_UNICODE_MATCH(string, offset, substring) \
#define Py_UNICODE_REPLACEMENT_CHARACTER ((Py_UNICODE) 0xFFFD)
It looks like what is actually happening there is that you started out
with names of the normal ctype(3) macroish thingies:
isalpha isupper islower isdigit isxdigit isalnum isspace ispunct
isprint isgraph iscntrl isblank isascii toupper isblank isascii
toupper tolower toascii
and wanted to preserve those, which would lead to Py_UNICODE_TOLOWER and
Py_UNICODE_TOUPPER, since there are no functions in the original C versions
those seem to mirror. Then when you wanted more of that ilk, you sensibly
kept to the same naming convention.
I eyeball few exceptions to that style here:
% perl -nle '/^\s*#\s*define\s+(Py_[\p{Lu}_]+)\b/ and print $1' Include/*.h
| sort -dfu | fmt -150
Py_ABSTRACTOBJECT_H Py_ALIGNED Py_ALLOW_RECURSION Py_ARITHMETIC_RIGHT_SHIFT
Py_ASDL_H Py_AST_H Py_ATOMIC_H Py_BEGIN_ALLOW_THREADS Py_BITSET_H
Py_BLOCK_THREADS Py_BLTINMODULE_H Py_BOOLOBJECT_H Py_BYTEARRAYOBJECT_H
Py_BYTES_CTYPE_H Py_BYTESOBJECT_H Py_CAPSULE_H Py_CELLOBJECT_H Py_CEVAL_H
Py_CHARMASK Py_CLASSOBJECT_H Py_CLEANUP_SUPPORTED Py_CLEAR
Py_CODECREGISTRY_H Py_CODE_H Py_COMPILE_H Py_COMPLEXOBJECT_H Py_CURSES_H
Py_DECREF
Py_DEPRECATED Py_DESCROBJECT_H Py_DICTOBJECT_H Py_DTSF_ALT Py_DTSF_SIGN
Py_DTST_FINITE Py_DTST_INFINITE Py_DTST_NAN Py_END_ALLOW_RECURSION
Py_END_ALLOW_THREADS Py_ENUMOBJECT_H Py_EQ Py_ERRCODE_H Py_ERRORS_H
Py_EVAL_H Py_FILEOBJECT_H Py_FILEUTILS_H Py_FLOATOBJECT_H Py_FORCE_DOUBLE
Py_FORCE_EXPANSION Py_FORMAT_PARSETUPLE Py_FRAMEOBJECT_H Py_FUNCOBJECT_H
Py_GCC_ATTRIBUTE Py_GE Py_GENOBJECT_H Py_GETENV Py_GRAMMAR_H Py_GT
Py_HUGE_VAL Py_IMPORT_H Py_INCREF Py_INTRCHECK_H Py_INVALID_SIZE Py_ISALNUM
Py_ISALPHA Py_ISDIGIT Py_IS_FINITE Py_IS_INFINITY Py_ISLOWER Py_IS_NAN
Py_ISSPACE Py_ISUPPER Py_ISXDIGIT Py_ITEROBJECT_H Py_LE Py_LISTOBJECT_H
Py_LL Py_LOCAL Py_LOCAL_INLINE Py_LONGINTREPR_H Py_LONGOBJECT_H Py_LT
Py_MARSHAL_H Py_MARSHAL_VERSION Py_MATH_E Py_MATH_PI Py_MEMCPY
Py_MEMORYOBJECT_H Py_METAGRAMMAR_H Py_METHODOBJECT_H Py_MODSUPPORT_H
Py_MODULEOBJECT_H
Py_NAN Py_NE Py_NODE_H Py_OBJECT_H Py_OBJIMPL_H Py_OPCODE_H Py_OSDEFS_H
Py_OVERFLOWED Py_PARSETOK_H Py_PGEN_H Py_PGENHEADERS_H Py_PRINT_RAW
Py_PYARENA_H Py_PYDEBUG_H Py_PYFPE_H Py_PYGETOPT_H Py_PYMATH_H Py_PYMEM_H
Py_PYPORT_H Py_PYSTATE_H Py_PYTHON_H Py_PYTHONRUN_H Py_PYTHREAD_H
Py_PYTIME_H Py_RANGEOBJECT_H Py_REFCNT Py_REF_DEBUG Py_RETURN_FALSE
Py_RETURN_INF Py_RETURN_NAN Py_RETURN_NONE Py_RETURN_TRUE Py_SAFE_DOWNCAST
Py_SET_ERANGE_IF_OVERFLOW Py_SET_ERRNO_ON_MATH_ERROR Py_SETOBJECT_H Py_SIZE
Py_SLICEOBJECT_H Py_STRCMP_H Py_STRTOD_H Py_STRUCTMEMBER_H Py_STRUCTSEQ_H
Py_SYMTABLE_H Py_SYSMODULE_H Py_TOKEN_H Py_TOLOWER Py_TOUPPER
Py_TPFLAGS_BASE_EXC_SUBCLASS Py_TPFLAGS_BASETYPE Py_TPFLAGS_BYTES_SUBCLASS
Py_TPFLAGS_DEFAULT Py_TPFLAGS_DICT_SUBCLASS Py_TPFLAGS_HAVE_GC
Py_TPFLAGS_HAVE_STACKLESS_EXTENSION Py_TPFLAGS_HAVE_VERSION_TAG
Py_TPFLAGS_HEAPTYPE
Py_TPFLAGS_INT_SUBCLASS Py_TPFLAGS_IS_ABSTRACT Py_TPFLAGS_LIST_SUBCLASS
Py_TPFLAGS_LONG_SUBCLASS Py_TPFLAGS_READY Py_TPFLAGS_READYING
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Marc-Andre Lemburg m...@egenix.com added the comment: Tom Christiansen wrote: So keeping your preamble bits, I might have considered doing it this way if it were me doing it: #define _Py_UNICODE_IS_SURROGATE #define _Py_UNICODE_IS_LEAD_SURROGATE #define _Py_UNICODE_IS_TRAIL_SURROGATE #define _Py_UNICODE_JOIN_SURROGATES But I also come from a culture that uses more underscores than you guys tend to, as shown in some of the macro names shown below from utf8.h file. I find that most projects use more underscores in uppercase names than Python does. :) The reasoning behind e.g. ISSURROGATE is that those names originate from and are consistent with the already existing ISLOWER/ISUPPER/ISTITLE macros which in return stem from the C APIs of the same names (see unicodeobject.h for reference). Regarding low/high vs. lead/trail: The Unicode database uses the terms low/high and we do in Python as well, so let's stick with those. What I don't understand is why those macros should be declared private to Python (with the leading underscore). They are quite useful for extensions implementing codecs or other transformations as well. BTW: I think the other issues mentioned in the discussion are more important to get right, than the names of those macros. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Tom Christiansen tchr...@perl.com added the comment:
Marc-Andre Lemburg rep...@bugs.python.org wrote
on Tue, 16 Aug 2011 12:11:22 -:
The reasoning behind e.g. ISSURROGATE is that those names originate
from and are consistent with the already existing ISLOWER/ISUPPER/ISTITLE
macros which in return stem from the C APIs of the same names
(see unicodeobject.h for reference).
I eventually figured that part out in the larger context.
Makes sense looked at that way.
Regarding low/high vs. lead/trail: The Unicode database uses the terms
low/high and we do in Python as well, so let's stick with those.
Yes, those are their block assignments, Block=High_Surrogates and
Block=Low_Surrogates.
I just thought I should mention that in the time since those were invented
(which cannot
be changed), after using them in real code for some years, their lingo seems to
have
evolved away from those initial names and toward lead/trail as less confusing.
What I don't understand is why those macros should be declared
private to Python (with the leading underscore). They are quite
useful for extensions implementing codecs or other transformations
as well.
I was wondering about that myself. Beyond there being a lot fewer of those
private macros in the Python *.h files, they also seem to be of rather different
character than the iswhatever() macros:
$ perl -nle '/^\s*#\s*define\s+(_Py_[\p{Lu}_]+)\b/ and print $1' *.h | sort
-dfu | fmt -160
_Py_ANNOTATE_BARRIER_DESTROY _Py_ANNOTATE_BARRIER_INIT
_Py_ANNOTATE_BARRIER_WAIT_AFTER _Py_ANNOTATE_BARRIER_WAIT_BEFORE
_Py_ANNOTATE_BENIGN_RACE
_Py_ANNOTATE_BENIGN_RACE_SIZED _Py_ANNOTATE_BENIGN_RACE_STATIC
_Py_ANNOTATE_CONDVAR_LOCK_WAIT _Py_ANNOTATE_CONDVAR_SIGNAL
_Py_ANNOTATE_CONDVAR_SIGNAL_ALL
_Py_ANNOTATE_CONDVAR_WAIT _Py_ANNOTATE_ENABLE_RACE_DETECTION
_Py_ANNOTATE_EXPECT_RACE _Py_ANNOTATE_FLUSH_STATE _Py_ANNOTATE_HAPPENS_AFTER
_Py_ANNOTATE_HAPPENS_BEFORE _Py_ANNOTATE_IGNORE_READS_AND_WRITES_BEGIN
_Py_ANNOTATE_IGNORE_READS_AND_WRITES_END _Py_ANNOTATE_IGNORE_READS_BEGIN
_Py_ANNOTATE_IGNORE_READS_END _Py_ANNOTATE_IGNORE_SYNC_BEGIN
_Py_ANNOTATE_IGNORE_SYNC_END _Py_ANNOTATE_IGNORE_WRITES_BEGIN
_Py_ANNOTATE_IGNORE_WRITES_END
_Py_ANNOTATE_MUTEX_IS_USED_AS_CONDVAR _Py_ANNOTATE_NEW_MEMORY
_Py_ANNOTATE_NO_OP _Py_ANNOTATE_PCQ_CREATE _Py_ANNOTATE_PCQ_DESTROY
_Py_ANNOTATE_PCQ_GET
_Py_ANNOTATE_PCQ_PUT _Py_ANNOTATE_PUBLISH_MEMORY_RANGE
_Py_ANNOTATE_PURE_HAPPENS_BEFORE_MUTEX _Py_ANNOTATE_RWLOCK_ACQUIRED
_Py_ANNOTATE_RWLOCK_CREATE
_Py_ANNOTATE_RWLOCK_DESTROY _Py_ANNOTATE_RWLOCK_RELEASED
_Py_ANNOTATE_SWAP_MEMORY_RANGE _Py_ANNOTATE_THREAD_NAME
_Py_ANNOTATE_TRACE_MEMORY
_Py_ANNOTATE_UNPROTECTED_READ _Py_ANNOTATE_UNPUBLISH_MEMORY_RANGE _Py_AS_GC
_Py_CHECK_REFCNT _Py_COUNT_ALLOCS_COMMA _Py_DEC_REFTOTAL _Py_DEC_TPFREES
_Py_INC_REFTOTAL _Py_INC_TPALLOCS _Py_INC_TPFREES _Py_PARSE_PID
_Py_REF_DEBUG_COMMA _Py_SET_EDOM_FOR_NAN
BTW: I think the other issues mentioned in the discussion are more
important to get right, than the names of those macros.
Yup. Just paint it red. :)
--tom
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10542
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12750] datetime.datetime how to correctly attach a timezone to an existing naive datetime
R. David Murray rdmur...@bitdance.com added the comment: OK. At a minimum there is a doc issue here, so I'm reopening. -- nosy: +belopolsky resolution: invalid - status: closed - open title: datetime.datetime timezone problems - datetime.datetime how to correctly attach a timezone to an existing naive datetime versions: +Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12750 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Changes by Stefan Krah stefan-use...@bytereef.org: Added file: http://bugs.python.org/file22909/70a8ccd53ade.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12751] Use macros for surrogates in unicodeobject.c
Changes by Benjamin Peterson benja...@python.org: -- resolution: - duplicate status: open - closed superseder: - Py_UNICODE_NEXT and other macros for surrogates ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Stefan Krah stefan-use...@bytereef.org added the comment: 70a8ccd53ade fixes conversion of NumPy-style arrays to a suboffset representation. The previous representation did not work for slicing non-contiguous arrays with backward strides. Also, I've added long comments that hopefully explain how slicing with arbitrary strides and suboffsets is supposed to work. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10744] ctypes arrays have incorrect buffer information (PEP-3118)
Pauli Virtanen p...@iki.fi added the comment:
The array notation is useful for arrays inside structs, such as T{(4)i(2,3)f}.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10744
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10744] ctypes arrays have incorrect buffer information (PEP-3118)
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10744 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12760] Add create mode to open()
New submission from David Townshend aquavita...@gmail.com: Currently, opening a file with open(file, 'w') overwrites existing files. It would be useful for open() to raise an error when the file exists. This proposal is to add a 'c' mode to open, which has the effect to creating a file and opening it for writing, but raising an IOError if it already exists (i.e. the same as os.open(file, os.O_EXCL|os.O_CREAT). The attached patch implements this, including tests and documentation. -- assignee: docs@python components: Documentation, IO, Library (Lib), Tests files: open_create.patch keywords: patch messages: 142193 nosy: David.Townshend, docs@python priority: normal severity: normal status: open title: Add create mode to open() type: feature request versions: Python 3.3 Added file: http://bugs.python.org/file22910/open_create.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12760 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12760] Add create mode to open()
STINNER Victor victor.stin...@haypocalc.com added the comment: I'm not sure that O_EXCL is portable (exist on all platforms) because Python source code uses #ifdef O_EXCL. -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12760 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw ba...@python.org added the comment: @Sandro: FTR, for Debian and derivatives, doko chose to use 'linux2' when building on linux3. Luckily that has just been reverted. No, I don't think it has: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633015 On Debian Wheezy and Ubuntu 11.10: $ python2.7 -c 'import sys; print sys.platform' linux2 $ python3.2 -c 'import sys; print(sys.platform)' linux2 oneiric$ uname -a Linux resist 3.0.0-8-generic #11-Ubuntu SMP Fri Aug 12 20:23:58 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux wheezy$ uname -a Linux chemistry 3.0.0-1-amd64 #1 SMP Sun Jul 24 02:24:44 UTC 2011 x86_64 GNU/Linux I agree with MvL that Python 3.3 should set sys.platform to 'linux' and all stable releases should be patched to return 'linux2' on MACHDEP='linux3' systems. configure.in already special cases cygwin* and darwin* to the major-version-number-less platform string, so this doesn't seem like much of a stretch to me for linux. Since applications/libraries that already test against literal sys.platform values will be broken no matter what we do (except perhaps retain 'linux2' for perpetuity, which doesn't seem like a good idea), I think we should make a clean break from the major version number in Python 3.3 and keep backward compatibility for released Pythons. Seems like the least worst option to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Sandro Tosi sandro.t...@gmail.com added the comment: On Tue, Aug 16, 2011 at 16:21, Barry A. Warsaw rep...@bugs.python.org wrote: Barry A. Warsaw ba...@python.org added the comment: @Sandro: FTR, for Debian and derivatives, doko chose to use 'linux2' when building on linux3. Luckily that has just been reverted. No, I don't think it has: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633015 On Debian Wheezy and Ubuntu 11.10: $ python2.7 -c 'import sys; print sys.platform' linux2 $ python3.2 -c 'import sys; print(sys.platform)' linux2 that's because you're on wheezy, that has 2.7.2-3, while the version which has the change reverted is -4 (still not transition to testing, since outdated on kbsd-i386) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw ba...@python.org added the comment: On Aug 16, 2011, at 02:28 PM, Sandro Tosi wrote: that's because you're on wheezy, that has 2.7.2-3, while the version which has the change reverted is -4 (still not transition to testing, since outdated on kbsd-i386) I think it's back in -5 though. $ apt-cache show python2.7 | grep Version Version: 2.7.2-5 (On Ubuntu) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12760] Add create mode to open()
Benjamin Peterson benja...@python.org added the comment: I think this should be brought up on python-ideas or python-dev. -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12760 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12740] Add struct.Struct.nmemb
Meador Inge mead...@gmail.com added the comment: Stefan, it is a constructed failure (I hacked the unit test to break it). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12740 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12760] Add create mode to open()
Charles-François Natali neolo...@free.fr added the comment:
See also issue 12105.
A couple downsides:
- O_EXCL is not necessarily portable (doesn't work well with NFS, maybe not on
Windows?)
- O_EXCL is useful, as is O_CLOEXEC: to be consistent, we should also end up
adding all other commonly-used flags, which are really OS-specific
Furthermore, you can achieve the same thing with:
os.fdopen(os.open('/etc/fstab', os.O_WRONLY|os.O_CLOEXEC|os.O_CREAT))
it's more verbose, though.
--
nosy: +neologix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12760
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12760] Add create mode to open()
David Townshend aquavita...@gmail.com added the comment: It was discussed on python-ideas, but the subject of the thread was actually on shutils.move so it was not really discussed much. I will repost this idea separately. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12760 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9723] Add shlex.quote
Éric Araujo mer...@netwok.org added the comment: FWIW there are still unnecessary escapes before '+' and '.', and possibly '-' This is IMO cosmetic and not as “important” as the duplicate characters already implied by the character class. Feel free to change it. Why can't pipes.quote can't be moved to shlex.quote verbatim as I originally proposed? I took the opportunity of changing some convoluted code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9723] Add shlex.quote
Éric Araujo mer...@netwok.org added the comment: FWIW there are still unnecessary escapes before '+' and '.', and possibly '-' This is IMO cosmetic and not as “important” as the duplicate characters already implied by the character class. Feel free to change it. Why can't pipes.quote can't be moved to shlex.quote verbatim as I originally proposed? I took the opportunity of changing some convoluted code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9723] Add shlex.quote
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 5d4438001069 by Ezio Melotti in branch 'default': #9723: refactor regex. http://hg.python.org/cpython/rev/5d4438001069 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12761] Typo in Doc/license.rst
New submission from Jakub Wilk jw...@jwilk.net: The zlib extension is built using an included copy of the zlib sources unless the zlib version found on the system is too old to be used for the build I believe it should be if rather than unless. -- messages: 142205 nosy: jwilk priority: normal severity: normal status: open title: Typo in Doc/license.rst versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12761 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12181] SIGBUS error on OpenBSD (sparc64)
Remi Pointel pyt...@xiri.fr added the comment: Hi, this is the patch in OpenBSD. Source: http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/python/2.7/patches/patch-Modules_selectmodule_c Could be usefull to work together and advance on this problem. Thanks a lot. Remi. -- Added file: http://bugs.python.org/file22911/patch-Modules_selectmodule_c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12761] Typo in Doc/license.rst
Changes by Gennadiy Zlobin gennad.zlo...@gmail.com: -- assignee: - docs@python components: +Documentation nosy: +docs@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12761 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12762] EnvironmentError_str contributes to unportable code
New submission from Jakub Wilk jw...@jwilk.net: It is a surprisingly common error in 3rd party code to write something like this: try: eggs() except OSError, e: if e.errno == 17: ham() This is wrong, because according to POSIX[0], “only […] symbolic names should be used in programs, since the actual value of the error number is unspecified.” I was wondering why Python programmers keep writing such unportable code - e.g. I've never seen C code that would compare errno variable with a hardcoded integer. I came into conclution that the Python interpreter itself is (partially) to blame. Currently exception message generated from errno looks like this: [Errno 2] No such file or directory: '/punt' It would be better if the message was: [ENOENT] No such file or directory: '/punt' or, if the above is too hard to implement, even: No such file or directory: '/punt' -- messages: 142207 nosy: jwilk priority: normal severity: normal status: open title: EnvironmentError_str contributes to unportable code ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12762 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12762] EnvironmentError_str contributes to unportable code
Jakub Wilk jw...@jwilk.net added the comment: And the lost footnote is: [0] http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_03.html#tag_02_03 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12762 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12761] Typo in Doc/license.rst
Changes by Gennadiy Zlobin gennad.zlo...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file22912/patch.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12761 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12763] test_posix failure on OpenIndiana
New submission from Antoine Pitrou pit...@free.fr: http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/1826/steps/test/logs/stdio == ERROR: test_get_and_set_scheduler_and_param (test.test_posix.PosixTester) -- Traceback (most recent call last): File /export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_posix.py, line 863, in test_get_and_set_scheduler_and_param init = posix.sched_getscheduler(1) OSError: [Errno 3] No such process -- assignee: benjamin.peterson components: Library (Lib), Tests messages: 142209 nosy: benjamin.peterson, pitrou priority: normal severity: normal status: open title: test_posix failure on OpenIndiana type: performance versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12763 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12761] Typo in Doc/license.rst
Changes by Sandro Tosi sandro.t...@gmail.com: -- nosy: +ezio.melotti, sandro.tosi stage: - commit review versions: +Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12761 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12555] PEP 3151 implementation
Changes by Antoine Pitrou pit...@free.fr: Added file: http://bugs.python.org/file22913/524e47d8b878.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12555 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12763] test_posix failure on OpenIndiana
Changes by Antoine Pitrou pit...@free.fr: -- type: performance - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12763 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12555] PEP 3151 implementation
Antoine Pitrou pit...@free.fr added the comment: Updated patch with latest changes from the PEP. The implementation is now complete. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12555 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12761] Typo in Doc/license.rst
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 80ac94ad381e by Sandro Tosi in branch '2.7': #12761: fix wording of zlib license section http://hg.python.org/cpython/rev/80ac94ad381e New changeset 16a02530fd81 by Sandro Tosi in branch '3.2': #12761: fix wording of zlib license section http://hg.python.org/cpython/rev/16a02530fd81 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12761 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12672] Some problems in documentation extending/newtypes.html
Terry J. Reedy tjre...@udel.edu added the comment: You are right, I suggested deleting too much. The first half of the sentence is needed to define 'type methods', which is used several more times and is the title of the next section. We need to keep These C functions are called “type methods”. In the context of the preceding sentence and later usages, I think this is enough. The second half of the sentence is intended to refine the definition by contrast, but it fails to do so since we cannot agree on what the contrast is. Since none of the interpretations make complete sense and since 'object methods' is not used again, making its definition irrelevant, I suggest deleting this part: to distinguish them from things like [].append (which we call “object methods”).. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12761] Typo in Doc/license.rst
Sandro Tosi sandro.t...@gmail.com added the comment: Thanks Jakub for the report and Gennadiy for the patch (that I applied on all the active braches). -- resolution: - fixed stage: commit review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12761 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12756] datetime.datetime.utcnow should return a UTC timestamp
Brett Cannon br...@python.org added the comment: This is for backwards-compatibility as the UTC object did not come into existence until (I believe) Python 2.7. The docs for utcnow() explicitly state that if you want a timezone-aware UTC datetime object that you should use now() w/ the UTC object passed in. Now if you would like to have a keyword argument for utcnow() to cause it to return a UTC object (e.g., utcnow(aware=True)), that may be a patch that could get accepted as it doesn't break backwards-compatibility if you leave the argument out. -- nosy: +brett.cannon resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12756 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1731717] race condition in subprocess module
jan matejek jmate...@suse.cz added the comment: please check my logic here, but the patched code seems to throw away perfectly valid return codes: in wait(), self._handle_exitstatus(sts) gets called unconditionally, and it resets self.returncode also unconditionally. now, if a _cleanup() already did _internal_poll and set self.returncode that way, it is lost when wait() catches the ECHILD, in the one place where it actually matters, by setting sts=0 for the _handle_exitstatus call IMHO it could be fixed by moving _handle_exitstatus to the try: section, and returning self.returncode or 0 or something like that -- nosy: +matejcik ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1731717 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11564] pickle not 64-bit ready
Changes by Nadeem Vawda nadeem.va...@gmail.com: -- nosy: +nadeem.vawda ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11564] pickle not 64-bit ready
Nadeem Vawda nadeem.va...@gmail.com added the comment: pickle64.patch applies cleanly to 3.2, but not 3.3. I've attached an adapted version that applies cleanly to 3.3. -- Added file: http://bugs.python.org/file22914/pickle64-3.3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12555] PEP 3151 implementation
Remi Pointel pyt...@xiri.fr added the comment: Hi, I have tested on OpenBSD -current, and it seems to work fine: $ ./python -E -bb Lib/test/test_mmap.py test_access_parameter (__main__.MmapTests) ... ok test_anonymous (__main__.MmapTests) ... ok test_bad_file_desc (__main__.MmapTests) ... ok test_basic (__main__.MmapTests) ... ok test_context_manager (__main__.MmapTests) ... ok test_context_manager_exception (__main__.MmapTests) ... ok test_double_close (__main__.MmapTests) ... ok test_entire_file (__main__.MmapTests) ... ok test_error (__main__.MmapTests) ... ok test_extended_getslice (__main__.MmapTests) ... ok test_extended_set_del_slice (__main__.MmapTests) ... ok test_find_end (__main__.MmapTests) ... ok test_io_methods (__main__.MmapTests) ... ok test_length_0_large_offset (__main__.MmapTests) ... ok test_length_0_offset (__main__.MmapTests) ... ok test_move (__main__.MmapTests) ... ok test_non_ascii_byte (__main__.MmapTests) ... ok test_offset (__main__.MmapTests) ... ok test_prot_readonly (__main__.MmapTests) ... ok test_read_all (__main__.MmapTests) ... ok test_read_invalid_arg (__main__.MmapTests) ... ok test_rfind (__main__.MmapTests) ... ok test_subclass (__main__.MmapTests) ... ok test_tougher_find (__main__.MmapTests) ... ok test_around_2GB (__main__.LargeMmapTests) ... ok test_around_4GB (__main__.LargeMmapTests) ... ok test_large_filesize (__main__.LargeMmapTests) ... ok test_large_offset (__main__.LargeMmapTests) ... ok -- Ran 28 tests in 0.141s OK $ ./python -E -bb Lib/test/test_exceptions.py ... -- Ran 27 tests in 0.026s OK $ ./python -E -bb Lib/test/test_pep3151.py test_blockingioerror (__main__.AttributesTest) ... ok test_errno_translation (__main__.AttributesTest) ... skipped 'Windows-specific test' test_posix_error (__main__.AttributesTest) ... ok test_windows_error (__main__.AttributesTest) ... ok test_builtin_errors (__main__.HierarchyTest) ... ok test_errno_mapping (__main__.HierarchyTest) ... ok test_ioerror_subclass_mapping (__main__.HierarchyTest) ... ok test_select_error (__main__.HierarchyTest) ... ok test_socket_errors (__main__.HierarchyTest) ... ok -- Ran 9 tests in 0.001s OK (skipped=1) Don't hesitate to indicate me if you need more tests, or if I did something wrong. Cheers, Remi. -- nosy: +rpointel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12555 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12764] segfault in ctypes.Struct with bad _fields_
New submission from Amaury Forgeot d'Arc amaur...@gmail.com: This crashes on python 3.3:: class S(ctypes.Structure): _fields_ = [(b'x', ctypes.c_int)] This also crashes on python 2.7:: class S(ctypes.Structure): _fields_ = [(u'x\xe9', ctypes.c_int)] The cause is the same: in Modules/_ctypes/stgdict.c, the assignment fieldname = _PyUnicode_AsString(name); does not check for errors. -- components: ctypes keywords: easy messages: 142218 nosy: amaury.forgeotdarc priority: normal severity: normal status: open title: segfault in ctypes.Struct with bad _fields_ type: crash ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12764 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Dave Malcolm dmalc...@redhat.com added the comment: Another datapoint: For Fedora 16, I haven't done any downstream patching (so far), because we hadn't run into any downstream problems. I did some digging into why we're _not_ experiencing issues. Currently for Fedora 16, we're shipping kernel-3.0 with python-2.7.2-4.fc16.x86_64 and python is reporting: $ python -cimport sys; print(sys.platform) linux2 I investigated why we have this discrepancy: uname with the build environment for that RPM happens to be reporting a kernel-2*, whereas we're shipping a kernel-3*: http://koji.fedoraproject.org/koji/taskinfo?taskID=3187563 What's happening here is that although the chroot that the build was done in [1] has: kernel-3.0-0.rc6.git0.1.fc16.x86_64.rpm running uname in the chroot environment is reporting the kernel that's actually running, outside the chroot, which was: 2.6.32 and thus we have: checking MACHDEP... linux2 within the build log [2] So in this case, sys.platform's final digit is reporting the major release of the kernel running outside the chroot-ed build environment (ironically bearing even less relationship to that of the currently-running kernel :( ) Hope this is helpful [1] http://koji.fedoraproject.org/koji/rpmlist?buildrootID=1096117%20start=50order=nvrtype=component [2] http://kojipkgs.fedoraproject.org/packages/python/2.7.2/4.fc16/data/logs/x86_64/build.log -- nosy: +dmalcolm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12765] test_packaging failure under Snow Leopard
New submission from Antoine Pitrou pit...@free.fr: http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%203.x/builds/789/steps/test/logs/stdio -- assignee: eric.araujo components: Library (Lib), Tests messages: 142220 nosy: eric.araujo, pitrou priority: release blocker severity: normal stage: needs patch status: open title: test_packaging failure under Snow Leopard type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12765 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12765] test_packaging failure under Snow Leopard
STINNER Victor victor.stin...@haypocalc.com added the comment: [309/358/1] test_packaging [70190 refs] test_formats (packaging.tests.test_command_bdist.BuildTestCase) ... ok test_show_formats (packaging.tests.test_command_bdist.BuildTestCase) ... ok test_skip_build (packaging.tests.test_command_bdist.BuildTestCase) ... ok test_finalize_options (packaging.tests.test_command_bdist_dumb.BuildDumbTestCase) ... ok test_simple_built (packaging.tests.test_command_bdist_dumb.BuildDumbTestCase) ... copying build/lib/foo.py - build/bdist.macosx-10.4-x86_64/dumb/usr/local/lib/python3.3/site-packages ok test_minimal (packaging.tests.test_command_bdist_msi.BDistMSITestCase) ... skipped 'runs only on win32' test_get_exe_bytes (packaging.tests.test_command_bdist_wininst.BuildWinInstTestCase) ... ok test_finalize_options (packaging.tests.test_command_build.BuildTestCase) ... ok test_build_libraries (packaging.tests.test_command_build_clib.BuildCLibTestCase) ... ok test_check_library_dist (packaging.tests.test_command_build_clib.BuildCLibTestCase) ... ok test_finalize_options (packaging.tests.test_command_build_clib.BuildCLibTestCase) ... ok test_get_source_files (packaging.tests.test_command_build_clib.BuildCLibTestCase) ... ok test_run (packaging.tests.test_command_build_clib.BuildCLibTestCase) ... ok test_build_ext (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok test_compiler_option (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok test_deployment_target_default (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok test_deployment_target_higher_ok (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok test_deployment_target_too_low (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok test_ext_fullpath (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok test_finalize_options (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok test_get_outputs (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok test_get_source_files (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok test_optional_extension (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok test_solaris_enable_shared (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok test_user_site (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok test_dont_write_bytecode (packaging.tests.test_command_build_py.BuildPyTestCase) ... ok test_empty_package_dir (packaging.tests.test_command_build_py.BuildPyTestCase) ... ok test_package_data (packaging.tests.test_command_build_py.BuildPyTestCase) ... ok test_build (packaging.tests.test_command_build_scripts.BuildScriptsTestCase) ... ok test_default_settings (packaging.tests.test_command_build_scripts.BuildScriptsTestCase) ... ok test_version_int (packaging.tests.test_command_build_scripts.BuildScriptsTestCase) ... ok test_check_all (packaging.tests.test_command_check.CheckTestCase) ... ok test_check_hooks (packaging.tests.test_command_check.CheckTestCase) ... ok test_check_metadata (packaging.tests.test_command_check.CheckTestCase) ... ok test_check_metadata_1_2 (packaging.tests.test_command_check.CheckTestCase) ... ok test_check_restructuredtext (packaging.tests.test_command_check.CheckTestCase) ... skipped 'requires docutils' test_warn (packaging.tests.test_command_check.CheckTestCase) ... ok test_simple_run (packaging.tests.test_command_clean.cleanTestCase) ... ok test_dump_options (packaging.tests.test_command_cmd.CommandTestCase) ... ok test_ensure_dirname (packaging.tests.test_command_cmd.CommandTestCase) ... ok test_ensure_filename (packaging.tests.test_command_cmd.CommandTestCase) ... ok test_ensure_string (packaging.tests.test_command_cmd.CommandTestCase) ... ok test_ensure_string_list (packaging.tests.test_command_cmd.CommandTestCase) ... ok test_make_file (packaging.tests.test_command_cmd.CommandTestCase) ... ok test_clean (packaging.tests.test_command_config.ConfigTestCase) ... ok test_dump_file (packaging.tests.test_command_config.ConfigTestCase) ... ok test_finalize_options (packaging.tests.test_command_config.ConfigTestCase) ... ok test_search_cpp (packaging.tests.test_command_config.ConfigTestCase) ... ok test_simple_run (packaging.tests.test_command_install_data.InstallDataTestCase) ... ok test_finalize_options (packaging.tests.test_command_install_dist.InstallTestCase) ... ok test_handle_extra_path (packaging.tests.test_command_install_dist.InstallTestCase) ... ok test_home_installation_scheme (packaging.tests.test_command_install_dist.InstallTestCase) ... ok test_old_record (packaging.tests.test_command_install_dist.InstallTestCase) ... ok test_user_site (packaging.tests.test_command_install_dist.InstallTestCase) ... ok test_empty_install (packaging.tests.test_command_install_distinfo.InstallDistinfoTestCase) ... ok test_installer (packaging.tests.test_command_install_distinfo.InstallDistinfoTestCase) ... ok test_no_record
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
STINNER Victor victor.stin...@haypocalc.com added the comment: I'm reposting my patch from #12751. I think that it's simpler than belopolsky's patch: it doesn't add public macros in unicodeobject.h and don't add the complex Py_UNICODE_NEXT() macro. My patch only adds private macros in unicodeobject.c to factorize the code. I don't want to add public macros because with the stable API and with the PEP 393, we are trying to hide the Py_UNICODE type and PyUnicodeObject internals. In belopolsky's patch, only Py_UNICODE_NEXT() is used outside unicodeobject.c. Copy/paste of the initial message of my issue #12751 (msg142108): --- A lot of code is duplicated in unicodeobject.c to manipulate (encode/decode) surrogates. Each function has from one to three different implementations. The new decode_ucs4() function adds a new implementation. Attached patch replaces this code by macros. I think that only the implementations of IS_HIGH_SURROGATE and IS_LOW_SURROGATE are important for speed. ((ch 0xFC00UL) == 0xD800) (from decode_ucs4) is *a little bit* faster than (0xD800 = ch ch = 0xDBFF) on my CPU (Atom Z520 @ 1.3 GHz): running test_unicode 4 times takes ~54 sec instead of ~57 sec (-3%). These 3 macros have to be checked, I wrote the first one: #define IS_SURROGATE(ch) (((ch) 0xF800UL) == 0xD800) #define IS_HIGH_SURROGATE(ch) (((ch) 0xFC00UL) == 0xD800) #define IS_LOW_SURROGATE(ch) (((ch) 0xFC00UL) == 0xDC00) I added cast to Py_UCS4 in COMBINE_SURROGATES to avoid integer overflow if Py_UNICODE is 16 bits (narrow build). It's maybe useless. #define COMBINE_SURROGATES(ch1, ch2) \ (Py_UCS4)(ch1) 0x3FF) 10) | ((Py_UCS4)(ch2) 0x3FF)) + 0x1) HIGH_SURROGATE and LOW_SURROGATE require that their ordinal argument has been preproceed to fit in [0; 0x]. I added this requirement in the comment of these macros. It would be better to have only one macro to do the two operations, but because *p++ (dereference and increment) is usually used, I prefer to avoid one unique macro (I don't like passing *p++ in a macro using its argument more than once). Or we may add a third macro using HIGH_SURROGATE and LOW_SURROGATE. I rewrote the main loop of PyUnicode_EncodeUTF16() to avoid an useless test on ch2 on narrow build. I also added a IS_NONBMP macro just because I prefer macro over hardcoded constants. --- -- Added file: http://bugs.python.org/file22915/unicode_macros.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: STINNER Victor victor.stin...@haypocalc.com added the comment: I'm reposting my patch from #12751. I think that it's simpler than belopolsky's patch: it doesn't add public macros in unicodeobject.h and don't add the complex Py_UNICODE_NEXT() macro. My patch only adds private macros in unicodeobject.c to factorize the code. I don't want to add public macros because with the stable API and with the PEP 393, we are trying to hide the Py_UNICODE type and PyUnicodeObject internals. In belopolsky's patch, only Py_UNICODE_NEXT() is used outside unicodeobject.c. PEP 393 is an optional feature for extension writers. If they don't need PEP 393 style stable ABIs and want to use the macros, they should be able to. I'm therefore -1 on making them private. Regarding separating adding the various surrogate macros and the next-macros: I don't see a problem with adding both in Python 3.3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Marc-Andre Lemburg m...@egenix.com added the comment: Marc-Andre Lemburg wrote: Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: STINNER Victor victor.stin...@haypocalc.com added the comment: I'm reposting my patch from #12751. I think that it's simpler than belopolsky's patch: it doesn't add public macros in unicodeobject.h and don't add the complex Py_UNICODE_NEXT() macro. My patch only adds private macros in unicodeobject.c to factorize the code. I don't want to add public macros because with the stable API and with the PEP 393, we are trying to hide the Py_UNICODE type and PyUnicodeObject internals. In belopolsky's patch, only Py_UNICODE_NEXT() is used outside unicodeobject.c. PEP 393 is an optional feature for extension writers. If they don't need PEP 393 style stable ABIs and want to use the macros, they should be able to. I'm therefore -1 on making them private. Sorry, I mean PEP 384, not PEP 393. Whether PEP 393 will turn out to be a workable solution has yet to be seen, but that's a different subject. In any case, Py_UNICODE and access macros for PyUnicodeObject are in wide-spread use, so trying to hide them won't work until we reach Py4k. Regarding separating adding the various surrogate macros and the next-macros: I don't see a problem with adding both in Python 3.3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
STINNER Victor victor.stin...@haypocalc.com added the comment: My patch version 2: don't test for a specific major version of an OS, test only its name. My patch now changes also tests for FreeBSD, NetBSD, OpenBSD, (...), and the _expectations list in regrtest.py. -- Added file: http://bugs.python.org/file22916/linux3-v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Changes by STINNER Victor victor.stin...@haypocalc.com: Removed file: http://bugs.python.org/file22916/linux3-v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@haypocalc.com added the comment: My patch version 2: don't test for a specific major version of an OS, test only its name. My patch now changes also tests for FreeBSD, NetBSD, OpenBSD, (...), and the _expectations list in regrtest.py. -- Added file: http://bugs.python.org/file22917/linux3-v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Changes by STINNER Victor victor.stin...@haypocalc.com: -- Removed message: http://bugs.python.org/msg142225 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
STINNER Victor victor.stin...@haypocalc.com added the comment: (oops, msg142225 was for issue #12326) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Changes by STINNER Victor victor.stin...@haypocalc.com: Removed file: http://bugs.python.org/file22613/linux3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12730] Python's casemapping functions are incorrect for non-BMP chars due to narrow/wide build issues
Martin v. Löwis mar...@v.loewis.de added the comment: Python's casemapping functions are not at all untrustworthy or unreliable. They are entirely deterministic - just limited to the BMP in some builds (in a way that has already been discussed). Changing the title of the issue. -- title: Python's casemapping functions are untrustworthy due to narrow/wide build issues - Python's casemapping functions are incorrect for non-BMP chars due to narrow/wide build issues ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12730 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12755] Service application crash in python25!PyObject_Malloc
Martin v. Löwis mar...@v.loewis.de added the comment: Notice that Python 2.5 is not supported for bug fixes anymore, so if you truly believe that there is a bug in Python that needs to be fixed, it would be better if you could reproduce it in 2.7. That said, the kind of information you provided really does suggest that the bug is in your application, and not in Python. Without having the full source of your application, it will be impossible to do anything meaningful about it. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12755 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: The code review links point to something weird. Victor, can you upload your patch for review? My first impression is that your patch does not accomplish much beyond replacing some literal expressions with macros. What I wanted to achieve with this issue was to enable writing code without #ifdef Py_UNICODE_WIDE branches. In your patch these branches seem to still be there and in fact it appears that new code is longer than the old one (I am not sure why, but I see more '+' than '-'s in your patch.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
STINNER Victor victor.stin...@haypocalc.com added the comment: The code review links point to something weird. That's because I posted a patch for another issue. It's the patch set 5, not the patch set 6 :-) Direct link: http://bugs.python.org/review/10542/patch/3174/9874 My first impression is that your patch does not accomplish much beyond replacing some literal expressions with macros. Yes, and it avoids the duplication of some code patterns, as explained in my message. I would like to avoid constants in the code. Some macros are *a little bit* faster than the current code. What I wanted to achieve with this issue was to enable writing code without #ifdef Py_UNICODE_WIDE branches. Yes, and I think that it's better to split this issue in two steps: 1- add macros for the surrogates (test, join, ...) 2- Py_UNICODE_NEXT() In your patch these branches seem to still be there and in fact it appears that new code is longer than the old one Yes, the code adds more lines than it removes. Is it a problem? My goal is to have more readable code (easier to maintain). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12766] strange interaction between __slots__ and class-level attributes
New submission from Antoine Pitrou pit...@free.fr: class Foo: ...__slots__ = ['foo'] ...foo = None ... x = Foo() x.foo x.foo = 5 Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'Foo' object attribute 'foo' is read-only -- components: Interpreter Core messages: 142232 nosy: benjamin.peterson, pitrou priority: normal severity: normal status: open title: strange interaction between __slots__ and class-level attributes type: behavior versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12766 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12763] test_posix failure on OpenIndiana
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 09f2ddd3d15a by Benjamin Peterson in branch 'default': some *nixes decided not to call init process 1 (closes #12763) http://hg.python.org/cpython/rev/09f2ddd3d15a -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12763 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12766] strange interaction between __slots__ and class-level attributes
Benjamin Peterson benja...@python.org added the comment: This sort of thing is true of any slotted class with class attributes: class X: ... __slots__ = () ... foo = None ... X().foo = hello Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'X' object attribute 'foo' is read-only I think what needs to happen is the error message needs to be improved in both cases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12766 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12766] strange interaction between __slots__ and class-level attributes
Antoine Pitrou pit...@free.fr added the comment: This sort of thing is true of any slotted class with class attributes: class X: ... __slots__ = () ... foo = None ... X().foo = hello Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'X' object attribute 'foo' is read-only But that's quite different. In your example, the attribute can't be set on the instance, while it should be in mine (since 'foo' is amongst the __slots__). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12766 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12766] strange interaction between __slots__ and class-level attributes
Benjamin Peterson benja...@python.org added the comment: So would you prefer to see x.foo Traceback (most recent call last): File stdin, line 1, in module AttributeError: foo x.foo = 5 x.foo 5 ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12766 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12766] strange interaction between __slots__ and class-level attributes
Antoine Pitrou pit...@free.fr added the comment: So would you prefer to see x.foo Traceback (most recent call last): File stdin, line 1, in module AttributeError: foo x.foo = 5 x.foo 5 ? No, I would prefer to see True x.foo = 5 x.foo 5 ... exactly as in the same class without a __slots__ (the whole point of class attributes being to set default values without complicating the constructor) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12766 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12766] strange interaction between __slots__ and class-level attributes
Benjamin Peterson benja...@python.org added the comment: I'm afraid that's not (easily) possible. Using __slots__ implicitly gives classes attributes, so what you are seeing is the effect of toying with that. It's not really possible to pretend there are different attributes on the class than the descriptors. We can: - Silently override slot descrs with attributes (as currently done). - Warn or error out on conflicts. - Just override other class attributes with the descrs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12766 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12766] strange interaction between __slots__ and class-level attributes
Antoine Pitrou pit...@free.fr added the comment: I'm afraid that's not (easily) possible. Using __slots__ implicitly gives classes attributes, so what you are seeing is the effect of toying with that. It's not really possible to pretend there are different attributes on the class than the descriptors. We can: - Silently override slot descrs with attributes (as currently done). - Warn or error out on conflicts. - Just override other class attributes with the descrs. Erroring on conflicts would seem reasonable. If that threatens to break existing code, at least improving the current error message would be nice. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12766 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12754] Add alternative random number generators
STINNER Victor victor.stin...@haypocalc.com added the comment: I don't know if it would help you, but I wrote a C library offering a simple API and supporting various RNG (cryptographic, hardware, pseudo, ...). It reuses existing libraries like GSL, OpenSSL, glib, gcrypt, etc. It supports UNIX/BSD /dev/*random devices and the Windows CryptGen API. It has many tests and reuses external tools to test the RNG. I added recently RAND_bytes to the Python ssl module, you may reuse it. -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12754 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12766] strange interaction between __slots__ and class-level attributes
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 45b63a8a76c9 by Benjamin Peterson in branch 'default': complain when a class variable shadows a name in __slots__ (closes #12766) http://hg.python.org/cpython/rev/45b63a8a76c9 -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12766 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12754] Add alternative random number generators
STINNER Victor victor.stin...@haypocalc.com added the comment: On my laptop, KISS4691 could produce about 110 million random numbers per second (148 millon if inlined), whereas MT19937 produced 118 million random numbers per second. The problem is that the Python API can only produce one number per call and a function call in Python is really slow (it creates a Python frame). If you want to speed it Python, it would be better to add methods to generate arrays to limit the overhead of Python function calls. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12754 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12758] time.time() returns local time instead of UTC
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Return the local time as a floating point number expressed in seconds since the epoch. No. Seconds since the epoch is neither local nor UTC. It is just an elapsed number of seconds since an agreed upon time called the epoch. I would say: Return the current time as a floating point number representing the number of seconds elapsed since the epoch. Suggestions for a shorter formulation that would not change the meaning are welcome. Maybe Return the number of seconds elapsed since the epoch as a floating point number. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12758 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12750] datetime.datetime how to correctly attach a timezone to an existing naive datetime
Alexander Belopolsky alexander.belopol...@gmail.com added the comment: i.e. it appears that replace() applies the TZ offset to a naive datetime object effectively assuming it is local time rather than un-timezoned (which is what the docs imply to me) I don't understand your issue. The replace method does not assume anything, it just replaces whatever fields you specify with new values. You can replace tzinfo just like any other field, year, month, day, etc while preserving the other fields. I think this is fairly well documented. I think what you are looking for is the astimezone() method which, however may not work well on naive datetime instances simply because a naive instance may be ambiguous in presence of DST. However, if you start with an aware UTC datetime, you should be able to use astimezone() to convert to any local TZ. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12750 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12750] datetime.datetime how to correctly attach a timezone to an existing naive datetime
Daniel O'Connor dar...@dons.net.au added the comment:
On 17/08/2011, at 10:30, Alexander Belopolsky wrote:
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
i.e. it appears that replace() applies the TZ offset to a naive datetime
object effectively assuming it is local time rather than un-timezoned
(which is what the docs imply to me)
I don't understand your issue. The replace method does not assume anything,
it just replaces whatever fields you specify with new values. You can
replace tzinfo just like any other field, year, month, day, etc while
preserving the other fields. I think this is fairly well documented. I think
what you are looking for is the astimezone() method which, however may not
work well on naive datetime instances simply because a naive instance may be
ambiguous in presence of DST. However, if you start with an aware UTC
datetime, you should be able to use astimezone() to convert to any local TZ.
Hmm I see, it would appear the problem lies with strftime().
[ur 10:34] ~ ipython-2.7
Python 2.7.2 (default, Aug 6 2011, 23:46:16)
Type copyright, credits or license for more information.
IPython 0.10.2 -- An enhanced Interactive Python.
? - Introduction and overview of IPython's features.
%quickref - Quick reference.
help - Python's own help system.
object? - Details about 'object'. ?object also works, ?? prints more.
In [48]: now = datetime.datetime.utcnow()
In [49]: nowtz = now.replace(tzinfo = pytz.utc)
In [50]: nowadl = now.replace(tzinfo = pytz.timezone('Australia/Adelaide'))
In [51]: now
Out[51]: datetime.datetime(2011, 8, 17, 1, 53, 51, 451118)
In [52]: nowtz
Out[52]: datetime.datetime(2011, 8, 17, 1, 53, 51, 451118, tzinfo=UTC)
In [53]: nowadl
Out[53]: datetime.datetime(2011, 8, 17, 1, 53, 51, 451118, tzinfo=DstTzInfo
'Australia/Adelaide' CST+9:30:00 STD)
In [54]: now.strftime(%F %r %s)
Out[54]: '2011-08-17 01:53:51 AM 1313511831'
In [55]: nowtz.strftime(%F %r %s)
Out[55]: '2011-08-17 01:53:51 AM 1313511831'
In [56]: nowadl.strftime(%F %r %s)
Out[56]: '2011-08-17 01:53:51 AM 1313511831'
Wed 17 Aug 2011 01:54:52 UTC
[ur 11:24] ~ date +%s
1313546093
[ur 11:24] ~ date -ujr `date +%s`
Wed 17 Aug 2011 01:54:59 UTC
[ur 11:24] ~ date -ujr 1313511831
Tue 16 Aug 2011 16:23:51 UTC
i.e. strftime disregards tzinfo and seems to treat the time as LT (I think).
It certainly doesn't behave the way I'd expect after using strftime(3) et al :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12750
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
