[issue12394] packaging: generate scripts from callable (dotted paths)

Vinay Sajip added the comment: BTW higery, did you use any of the build-scripts functionality I developed in the pythonv branch? Ref. https://bitbucket.org/vinay.sajip/pythonv/changeset/d2453f281baf -- ___ Python tracker

[issue12394] packaging: generate scripts from callable (dotted paths)

Vinay Sajip added the comment: IIUC the support for setup.py is transitional, i.e. "legacy support", for existing packages transitioning from distutils/setuptools/Distribute to packaging. New features should not rely on the existence of setup.py. -- __

[issue12767] document threading.Condition.notify

Eli Bendersky added the comment: I asked the user who reported this documentation omission what he's using the 'n' argument for. His reply: "Yes I am using the n parameter, it is mainly to implement a subclass of Queue that supports "bulk" get and put operations. This enhances the perfor

[issue9651] ctypes crash when writing zerolength string buffer to file

Meador Inge added the comment: Ping. I think this one is OK to commit. -- nosy: +belopolsky ___ Python tracker ___ ___ Python-bugs-li

[issue10320] printf %qd is nonstandard

Meador Inge added the comment: I agree that this violates C99, but is this actually causing any real world problems with the platforms Python supports? If so, then we need a test case. This seems low priority -- assignee: theller -> nosy: +amaury.forgeotdarc, belopolsky, meador.ing

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

Barry A. Warsaw added the comment: On Aug 18, 2011, at 01:20 AM, James Y Knight wrote: >James Y Knight added the comment: > >> I will backport the fix to 2.7 and 3.2. > >Uh, wait, so does that mean you're *not* going to do the >compatibility-preserving thing and force sys.platform to stay linu

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

James Y Knight added the comment: > I will backport the fix to 2.7 and 3.2. Uh, wait, so does that mean you're *not* going to do the compatibility-preserving thing and force sys.platform to stay linux2 even when python is built (BUILT! not run!) on a machine where the active kernel is linux

[issue12774] Warning -- multiprocessing.process._dangling was modified by test_multiprocessing

Changes by Ned Deily : -- nosy: +georg.brandl, pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue12774] Warning -- multiprocessing.process._dangling was modified by test_multiprocessing

Ned Deily added the comment: This warning is a regression in 3.2.2 from previous 3.2 releases due to the dangling Thread and Process checks added to 3.2 by 64e35f3bcda5 for Issue12573; the same checks introduce a new warning in 3.2.2 for test_threaded_import which has already been fixed in de

[issue12774] Warning -- multiprocessing.process._dangling was modified by test_multiprocessing

New submission from Ned Deily : [188/352] test_multiprocessing Warning -- multiprocessing.process._dangling was modified by test_multiprocessing -- components: Tests messages: 142295 nosy: ned.deily priority: normal severity: normal stage: needs patch status: open title: Warning -- mult

[issue10015] Creating a multiproccess.pool.ThreadPool from a child thread blows up.

Christian added the comment: A workaround would be to call the following in the thread you want to use ThreadPool: if not hasattr(threading.current_process(), "_children"): threading.current_process()._children = weakref.WeakKeyDictionary() (putting this in Process could be a very simple

[issue12720] Expose linux extended filesystem attributes

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue12720] Expose linux extended filesystem attributes

Antoine Pitrou added the comment: I think the functions should: - accept both str and bytes for keys and values; when it's an str, encoding it using the FS encoding - return str for attribute names, using the FS encoding - return bytes for attribute values, although returning str might be reaso

[issue12748] Problems using IDLE accelerators with OS X Dvorak - Qwerty ⌘ input method

Ned Deily added the comment: A footnote: I brought this issue up on the Mac Tcl mailing list and it was demonstrated that the problem with mishandling of the menu accelerators with the Dvorak - Qwerty Cmd input method is a general Cocoa Tk problem, and not unique to IDLE or Tkinter. I've ope

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

STINNER Victor added the comment: > New changeset 50f1922bc1d5 by Victor Stinner in branch 'default': I will backport the fix to 2.7 and 3.2. -- ___ Python tracker ___

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

Roundup Robot added the comment: New changeset 50f1922bc1d5 by Victor Stinner in branch 'default': Issue #12326: don't test the major version of sys.platform http://hg.python.org/cpython/rev/50f1922bc1d5 -- ___ Python tracker

[issue12567] curses implementation of Unicode is wrong in Python 3

STINNER Victor added the comment: > what needs to happen for them to move forward? I would like a review of curses_unicode.patch. -- ___ Python tracker ___

[issue12773] classes should have mutable docstrings

Roundup Robot added the comment: New changeset ed2511c23dae by Benjamin Peterson in branch 'default': make __doc__ mutable on heaptypes (closes #12773) http://hg.python.org/cpython/rev/ed2511c23dae -- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open ->

[issue12773] classes should have mutable docstrings

New submission from Eric Snow : Apparently docstrings for classes are immutable: >>> class X: ... "some doc" ... >>> X.__doc__ 'some doc' >>> X.__doc__ = "another doc" Traceback (most recent call last): File "", line 1, in AttributeError: attribute '__doc__' of 'type' objects is not writab

[issue12772] fractional day attribute in datetime class

New submission from Miguel de Val Borro : It would be useful to have a fractional day method in datetime.datetime that returns a float object calculated from the day, hour, minute, second, and microseconds. Fractional days in UTC are often used in science, in particular to record astronomical o

[issue12764] segfault in ctypes.Struct with bad _fields_

Vlad Riscutia added the comment: Also patch for 2.7 with unittest. BTW, b"x" works on 2.7. -- Added file: http://bugs.python.org/file22924/issue12764_patch2x.diff ___ Python tracker ___

[issue12764] segfault in ctypes.Struct with bad _fields_

Vlad Riscutia added the comment: Attached patch for 3.3 with unittest -- keywords: +patch nosy: +vladris Added file: http://bugs.python.org/file22923/issue12764_patch3x.diff ___ Python tracker

[issue12567] curses implementation of Unicode is wrong in Python 3

Nicholas Cole added the comment: There are now several bugs dealing with related issues here. Are we any closer to a solution to any of them? The suggested patches look like a good idea - what needs to happen for them to move forward? -- ___ Pyth

[issue12394] packaging: generate scripts from callable (dotted paths)

higery added the comment: Current patch has removed old-style scripts support and just retain new-style wrapper scripts generation support. Now, it uses only dotted path string to support kind of 'console_scripts' of setuptools, and uses dotted path with a 'window' or 'win' option to support

[issue12394] packaging: generate scripts from callable (dotted paths)

Changes by higery : Added file: http://bugs.python.org/file22922/4be1917b2a9e.diff ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue12771] 2to3 -d adds extra whitespace

New submission from Vlada Peric : When running 2to3 -d on this doctest (from this file[0] in SymPy): >>> class SzUpKet(Ket): ... def _represent_SzOp(self, basis, **options): ... return Matrix([1,0]) ... 2to3 adds an extra space in the last line. This

[issue12754] Add alternative random number generators

Sturla Molden added the comment: "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 Pyt

[issue12770] Email problem on Windows XP SP3 32bits

Brian Curtin added the comment: This is a bug tracker for the Python programming language and interpreter. You should contact Emesene for help with their product. -- nosy: +brian.curtin resolution: -> invalid stage: -> committed/rejected status: open -> closed __

[issue12770] Email problem on Windows XP SP3 32bits

New submission from Marcelo : I use Emesene 2.11.7 on Windows XP SP3, 32Bits. When I clic on the Email botom, Emesene don´t open my email aconunt in Internet Explorer, or Mozilla Firefox or any other browser. -- messages: 142278 nosy: butuntu priority: normal severity: normal status: o

[issue12769] String with NUL characters truncated by ctypes when assigning to a char array

Rafał Dowgird added the comment: The buffer output of the script suggests that the part after the '\000' has not been copied into the array at all. If that's the case, then the 'raw' output wouldn't print it anyway. -- ___ Python tracker

[issue12769] String with NUL characters truncated by ctypes when assigning to a char array

STINNER Victor added the comment: I don't think that it's a bug, but a feature. Example: buffer=ctypes.create_string_buffer(4) buffer.value='a\0bc' print("buffer.value=%r" % buffer.value) print("buffer.raw=%r" % buffer.raw) displays buffer.value='a' buffer.raw='a\x00bc' Sorry, I don't know

[issue12769] String with NUL characters truncated by ctypes when assigning to a char array

Rafał Dowgird added the comment: Attaching output of the script. 'x\000y\000' becomes 'x' after assigning to a char array. -- Added file: http://bugs.python.org/file22921/output.txt ___ Python tracker ___

[issue12769] String with NUL characters truncated by ctypes when assigning to a char array

New submission from Rafał Dowgird : The ctypes module seems to truncate NUL-containing strings when assigning to structure fields of type c_char*1024. Reproduced on a 2.7.2 compiled from tarball. Script to reproduce attached. -- components: ctypes files: reproduce.py messages: 142274 n

[issue12515] email modifies the message structure when the parsed email is invalid

Changes by xavierd : Added file: http://bugs.python.org/file22919/orig.eml ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue12515] email modifies the message structure when the parsed email is invalid

Changes by xavierd : Removed file: http://bugs.python.org/file22887/email.patch ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue12515] email modifies the message structure when the parsed email is invalid

xavierd added the comment: I also noticed that 'email' modifies the message structure when the header/body separator is missing. And nothing is added to the defect list. In the attachment, you'll find : - email.patch: this patch add the following error to the defects list : - the error 'em

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

Charles-François Natali added the comment: 2011/8/16 Dave Malcolm : > 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 kerne

[issue12767] document threading.Condition.notify

R. David Murray added the comment: Good point. Probably, then, we should just put a comment in the code that 'n' is an internal implementation detail and leave it at that. -- ___ Python tracker _

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

STINNER Victor added the comment: > OK, so in 2.7/3.2 I'll put them in unicodeobject.c It looks like #9200 only needs Py_UNICODE_NEXT, which can be implemented without the other Py_UNICODE_*SURROGATE* macros. -- ___ Python tracker

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Martin v. Löwis added the comment: > Also what about 3.2? Are you saying that we should fix the bug in > 3.2/3.3 only and leave 2.x alone or that you don't want the bug to be > fixed in all the bug-fix releases (i.e. 2.7/3.2)? Notice that the macros themselves don't fix any bugs. As for the bu

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Ezio Melotti added the comment: Correct. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Eric V. Smith added the comment: On 8/17/2011 6:30 AM, Ezio Melotti wrote: > OK, so in 2.7/3.2 I'll put them in unicodeobject.c, and in 3.3 I'll move them > in unicodeobject.c. I believe the second file should be unicodeobject.h, correct? -- ___ Py

[issue12757] undefined name in doctest.py

Changes by Alexander Belopolsky : -- nosy: +belopolsky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue12767] document threading.Condition.notify

Eli Bendersky added the comment: David, while you make a valid point, consider that 'n' is part of the public API of the threading module (although not documented) and it's conceivable that there is existing code "in the wild" using it. To do what you suggest we should maybe go through a norm

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Marc-Andre Lemburg added the comment: Ezio Melotti wrote: > > Ezio Melotti added the comment: > >> For bug fixes, you can put the macros straight into unicodeobject.c, >> but please leave unicodeobject.h untouched - otherwise people will >> mess around with these macros (even if they are priv

[issue12767] document threading.Condition.notify

R. David Murray added the comment: >From a quick look at the code and docs I suspect that 'n' is an internal >implementation detail and not meant to be exposed. Is there an use case for >notifying waiters where n!=1 and n!=len(waiters)? If my speculation is >correct it might be a good idea

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Ezio Melotti added the comment: > For bug fixes, you can put the macros straight into unicodeobject.c, > but please leave unicodeobject.h untouched - otherwise people will > mess around with these macros (even if they are private) and users > will start to wonder about linker errors if they use

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Marc-Andre Lemburg added the comment: Ezio Melotti wrote: > > Ezio Melotti added the comment: > >> Ezio used two different naming schemes in his email. Please always >> use Py_UNICODE_... or _Py_UNICODE (not PyUNICODE_ or _PyUNICODE_). > > Indeed, that was a typo + copy/paste. I meant to sa

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Ezio Melotti added the comment: > Ezio used two different naming schemes in his email. Please always > use Py_UNICODE_... or _Py_UNICODE (not PyUNICODE_ or _PyUNICODE_). Indeed, that was a typo + copy/paste. I meant to say Py_UNICODE_* and _Py_UNICODE_*. Sorry about the confusion. > Why wou

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

STINNER Victor added the comment: Ah yes, the correct prefix for functions working on Py_UNICODE characters/strings is "Py_UNICODE", not "PyUNICODE", sorry. >> For Python 2.7 and 3.2, I would prefer to not touch a public header, >> and so add the macros in unicodeobject.c. > > Is there some re

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Ezio Melotti added the comment: > For Python 2.7 and 3.2, I would prefer to not touch a public header, > and so add the macros in unicodeobject.c. Is there some reason for this? I think it's better if we have them in the same place rather than renaming and moving them in another file between

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Marc-Andre Lemburg added the comment: STINNER Victor wrote: > > STINNER Victor added the comment: > > Le 17/08/2011 07:04, Ezio Melotti a écrit : >> 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

[issue12755] Service application crash in python25!PyObject_Malloc

STINNER Victor added the comment: I close this issue because it looks like a bug in your application (you say that there is a least a buffer overrun). If it's really a bug in Python and you use a usecase to reproduce it, please reopen the issue. -- resolution: -> invalid status: open

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

STINNER Victor added the comment: Le 17/08/2011 07:04, Ezio Melotti a écrit : > 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

[issue12755] Service application crash in python25!PyObject_Malloc

Amaury Forgeot d'Arc added the comment: With a buffer overrun anything can happen... Here, I would recommend PyErr_Format() instead. But it also may be some other corruption happening before! -- ___ Python tracker

[issue12755] Service application crash in python25!PyObject_Malloc

Chandra Sekhar Reddy added the comment: Hi, Thanks for your valuable feedback, As per your suggestion I have re-verified the code for the possibility of NULL values, intrestingly I have observed that buffer overrun is happening in our application, where there is a character array declared w

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

Changes by Santoso Wijaya : -- nosy: +santa4nt ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth