[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Ezio Melotti added the comment: As I said in msg142175 I think the Py_UNICODE_IS{HIGH|LOW|}SURROGATE and Py_UNICODE_JOIN_SURROGATES can be committed without trailing _ in 3.3 and with trailing _ in 2.7/3.2. They should go in unicodeobject.h and be public in 3.3+. Regarding the name, it would

[issue9893] Usefulness of the Misc/Vim/ files?

Changes by Brett Cannon : -- keywords: +easy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue9893] Usefulness of the Misc/Vim/ files?

Brett Cannon added the comment: OK, I like Eric's idea of the README.vim file explaining where to grab the community-maintained files and how to get set up. Anyone care to take a stab at writing the file? -- ___ Python tracker

[issue1559549] ImportError needs attributes for module and file name

Brett Cannon added the comment: I have a use for this in my bootstrapping for importlib, so I am assigning this to myself in order to make sure that at least ImportError grows the needed keyboard argument and attribute. I will probably not bother with tweaking import.c, though. -- as

[issue12750] datetime.strftime('%s') should respect tzinfo

Daniel O'Connor added the comment: On 17/08/2011, at 12:42, Alexander Belopolsky wrote: > Alexander Belopolsky added the comment: > >> it would appear the problem lies with strftime() > > Yes, strftime('%s') ignores tzinfo at the moment. This is not a bug. Support > for '%s' format code is

[issue12750] datetime.strftime('%s') should respect tzinfo

Alexander Belopolsky added the comment: > it would appear the problem lies with strftime() Yes, strftime('%s') ignores tzinfo at the moment. This is not a bug. Support for '%s' format code is incidental and not documented in Python. Nevertheless I think this is a good feature request. I am

[issue12767] document threading.Condition.notify

Eli Bendersky added the comment: Opened Issue 12768 on the general lack of docstrings in the threading module -- ___ Python tracker ___ _

[issue12768] docstrings for the threading module

New submission from Eli Bendersky : The threading module has very few methods with docstrings. Docstrings should be added to all public methods (contents can be borrowed from the documentation). -- assignee: docs@python components: Documentation keywords: easy messages: 142247 nosy: doc

[issue12767] document threading.Condition.notify

New submission from Eli Bendersky : User report (Jiachang Xu) from the docs mailing list: The theading.Condition.notify method has a parameter - n, which isn't documented in the the documentation of the threading module. 1. The parameter should be documented 2. notify() is mentioned multiple t

[issue12750] datetime.datetime how to correctly attach a timezone to an existing naive datetime

Daniel O'Connor added the comment: On 17/08/2011, at 10:30, Alexander Belopolsky wrote: > Alexander Belopolsky 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

[issue12750] datetime.datetime how to correctly attach a timezone to an existing naive datetime

Alexander Belopolsky 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 an

[issue12758] time.time() returns local time instead of UTC

Alexander Belopolsky 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: "Retu

[issue12754] Add alternative random number generators

STINNER Victor 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

[issue12766] strange interaction between __slots__ and class-level attributes

Roundup Robot 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/

[issue12754] Add alternative random number generators

STINNER Victor 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 an

[issue12766] strange interaction between __slots__ and class-level attributes

Antoine Pitrou 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.

[issue12766] strange interaction between __slots__ and class-level attributes

Benjamin Peterson 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

[issue12766] strange interaction between __slots__ and class-level attributes

Antoine Pitrou added the comment: > So would you prefer to see > > >>> x.foo > Traceback (most recent call last): > File "", line 1, in > 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 witho

[issue12766] strange interaction between __slots__ and class-level attributes

Benjamin Peterson added the comment: So would you prefer to see >>> x.foo Traceback (most recent call last): File "", line 1, in AttributeError: foo >>> x.foo = 5 >>> x.foo 5 ? -- ___ Python tracker __

[issue12766] strange interaction between __slots__ and class-level attributes

Antoine Pitrou 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 "", line 1, in > AttributeError: 'X' object att

[issue12766] strange interaction between __slots__ and class-level attributes

Benjamin Peterson 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 "", line 1, in AttributeError: 'X' object attribute 'foo' is r

[issue12763] test_posix failure on OpenIndiana

Roundup Robot 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 sta

[issue12766] strange interaction between __slots__ and class-level attributes

New submission from Antoine Pitrou : >>> class Foo: ...__slots__ = ['foo'] ...foo = None ... >>> x = Foo() >>> x.foo >>> x.foo = 5 Traceback (most recent call last): File "", line 1, in AttributeError: 'Foo' object attribute 'foo' is read-only -- components: Interpreter Core

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

STINNER Victor 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

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Alexander Belopolsky 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 is

[issue12755] Service application crash in python25!PyObject_Malloc

Martin v. Löwis 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 sugg

[issue12730] Python's casemapping functions are incorrect for non-BMP chars due to narrow/wide build issues

Martin v. Löwis 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 casema

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

Changes by STINNER Victor : Removed file: http://bugs.python.org/file22613/linux3.patch ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

STINNER Victor added the comment: (oops, msg142225 was for issue #12326) -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Changes by STINNER Victor : -- Removed message: http://bugs.python.org/msg142225 ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

STINNER Victor 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/l

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Changes by STINNER Victor : Removed file: http://bugs.python.org/file22916/linux3-v2.patch ___ Python tracker ___ ___ Python-bugs-list mailing

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

STINNER Victor 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/l

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Marc-Andre Lemburg added the comment: Marc-Andre Lemburg wrote: > > Marc-Andre Lemburg added the comment: > > STINNER Victor wrote: >> >> STINNER Victor 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 m

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Marc-Andre Lemburg added the comment: STINNER Victor wrote: > > STINNER Victor 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.

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

STINNER Victor 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 cod

[issue12765] test_packaging failure under Snow Leopard

STINNER Victor 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 t

[issue12765] test_packaging failure under Snow Leopard

New submission from Antoine Pitrou : 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:

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

Dave Malcolm 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-

[issue12764] segfault in ctypes.Struct with bad _fields_

New submission from Amaury Forgeot d'Arc : 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

[issue12555] PEP 3151 implementation

Remi Pointel 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_ba

[issue11564] pickle not 64-bit ready

Nadeem Vawda 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

[issue11564] pickle not 64-bit ready

Changes by Nadeem Vawda : -- nosy: +nadeem.vawda ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue1731717] race condition in subprocess module

jan matejek 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_

[issue12756] datetime.datetime.utcnow should return a UTC timestamp

Brett Cannon 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.

[issue12761] Typo in Doc/license.rst

Sandro Tosi 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

[issue12672] Some problems in documentation extending/newtypes.html

Terry J. Reedy 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 conte

[issue12761] Typo in Doc/license.rst

Roundup Robot 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.

[issue12555] PEP 3151 implementation

Antoine Pitrou added the comment: Updated patch with latest changes from the PEP. The implementation is now complete. -- ___ Python tracker ___

[issue12763] test_posix failure on OpenIndiana

Changes by Antoine Pitrou : -- type: performance -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue12555] PEP 3151 implementation

Changes by Antoine Pitrou : Added file: http://bugs.python.org/file22913/524e47d8b878.diff ___ Python tracker ___ ___ Python-bugs-list mailing

[issue12761] Typo in Doc/license.rst

Changes by Sandro Tosi : -- nosy: +ezio.melotti, sandro.tosi stage: -> commit review versions: +Python 3.2, Python 3.3 ___ Python tracker ___ ___

[issue12763] test_posix failure on OpenIndiana

New submission from Antoine Pitrou : 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)

[issue12761] Typo in Doc/license.rst

Changes by Gennadiy Zlobin : -- keywords: +patch Added file: http://bugs.python.org/file22912/patch.diff ___ Python tracker ___ ___ Py

[issue12762] EnvironmentError_str contributes to unportable code

Jakub Wilk 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 ___ _

[issue12762] EnvironmentError_str contributes to unportable code

New submission from Jakub Wilk : 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,

[issue12761] Typo in Doc/license.rst

Changes by Gennadiy Zlobin : -- assignee: -> docs@python components: +Documentation nosy: +docs@python ___ Python tracker ___ ___ Pyt

[issue12181] SIGBUS error on OpenBSD (sparc64)

Remi Pointel 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.py

[issue12761] Typo in Doc/license.rst

New submission from Jakub Wilk : "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 s

[issue9723] Add shlex.quote

Roundup Robot added the comment: New changeset 5d4438001069 by Ezio Melotti in branch 'default': #9723: refactor regex. http://hg.python.org/cpython/rev/5d4438001069 -- ___ Python tracker __

[issue9723] Add shlex.quote

Éric Araujo 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 s

[issue9723] Add shlex.quote

Éric Araujo 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 s

[issue12760] Add create mode to open()

David Townshend 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

[issue12760] Add create mode to open()

Charles-François Natali 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

[issue12740] Add struct.Struct.nmemb

Meador Inge added the comment: Stefan, it is a constructed failure (I hacked the unit test to break it). -- ___ Python tracker ___ __

[issue12760] Add create mode to open()

Benjamin Peterson added the comment: I think this should be brought up on python-ideas or python-dev. -- nosy: +benjamin.peterson ___ Python tracker ___

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

Barry A. Warsaw 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-

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

Sandro Tosi added the comment: On Tue, Aug 16, 2011 at 16:21, Barry A. Warsaw wrote: > > Barry A. Warsaw 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 thin

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

Barry A. Warsaw 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:

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue12760] Add create mode to open()

STINNER Victor 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

[issue12760] Add create mode to open()

New submission from David Townshend : 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

[issue10744] ctypes arrays have incorrect buffer information (PEP-3118)

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue10744] ctypes arrays have incorrect buffer information (PEP-3118)

Pauli Virtanen added the comment: The array notation is useful for arrays inside structs, such as "T{(4)i(2,3)f}". -- ___ Python tracker ___

[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)

Stefan Krah 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 st

[issue12751] Use macros for surrogates in unicodeobject.c

Changes by Benjamin Peterson : -- resolution: -> duplicate status: open -> closed superseder: -> Py_UNICODE_NEXT and other macros for surrogates ___ Python tracker ___

[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)

Changes by Stefan Krah : Added file: http://bugs.python.org/file22909/70a8ccd53ade.diff ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue12750] datetime.datetime how to correctly attach a timezone to an existing naive datetime

R. David Murray 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 d

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Tom Christiansen added the comment: Marc-Andre Lemburg 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

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Marc-Andre Lemburg 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 >

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Tom Christiansen added the comment: Ezio Melotti 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]: Inclu

[issue12759] "(?P=)" input for Tools/scripts/redemo.py throw an exception

New submission from Alexander : Run: python /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: redem

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Tom Christiansen added the comment: Antoine Pitrou 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 stra

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Tom Christiansen 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

[issue12756] datetime.datetime.utcnow should return a UTC timestamp

Changes by R. David Murray : -- nosy: +belopolsky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Tom Christiansen added the comment: >Ezio Melotti 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 trai

[issue12740] Add struct.Struct.nmemb

Stefan Krah 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 __

[issue12755] Service application crash in python25!PyObject_Malloc

STINNER Victor 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 ___

[issue12755] Service application crash in python25!PyObject_Malloc

Chandra Sekhar Reddy 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

[issue12758] time.time() returns local time instead of UTC

Maxim Koltsov added the comment: Seems OK to me. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Ezio Melotti 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 -- ___ Py

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Antoine Pitrou 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 bikesh

[issue12758] time.time() returns local time instead of UTC

Ezio Melotti added the comment: """ Return the local time as a floating point number expressed in seconds since the epoch. """ -- nosy: +belopolsky ___ Python tracker ___ _

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Ezio Melotti 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 fixe

[issue12751] Use macros for surrogates in unicodeobject.c

Marc-Andre Lemburg added the comment: Ezio Melotti wrote: > > Ezio Melotti 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_UNIC

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Marc-Andre Lemburg 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

[issue12758] time.time() returns local time instead of UTC

Maxim Koltsov added the comment: Maybe add some words about local timezone? -- ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue12758] time.time() returns local time instead of UTC

Ezio Melotti 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

[issue12751] Use macros for surrogates in unicodeobject.c

Ezio Melotti 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 recombin

[issue12758] time.time() returns local time instead of UTC

Changes by Marc-Andre Lemburg : -- keywords: +easy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

  1   2   >