[issue12750] datetime.strftime('%s') should respect tzinfo
Changes by Santoso Wijaya santoso.wij...@gmail.com: -- nosy: +santa4nt ___ 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
[issue12755] Service application crash in python25!PyObject_Malloc
Chandra Sekhar Reddy sanc...@ca.com 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 with size 200 and a string is being copied without considering the null terminating character. static PyObject *eError; char errorString[200]; _snprintf(errorString, 200, some message content); PyErr_SetString(eError, errorString); I am not 100% sure if this may cause the PyObject_Malloc to fail. 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
Amaury Forgeot d'Arc amaur...@gmail.com 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 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
STINNER Victor victor.stin...@haypocalc.com 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
For Python 2.7 and 3.2, I would prefer to not touch a public header, and
so add the macros in unicodeobject.c.
and be public in 3.3+.
If you want to make my HIGH_SURROGATE and LOW_SURROGATE macros public,
they will use to substract 0x1 themself (whereas my macros require
the ordinal to be preproceed).
* _Py_UNICODE_NEXT and _Py_UNICODE_PUT_NEXT are useful, so once we have
agreed about the name they can go in. They can be private in all the 3
branches and made public in 3.4 if they work well;
Note: I don't think that _Py_UNICODE*NEXT should go into Python 2.7 or 3.2.
* IS_NONBMP doesn't simplify much the code but makes it more readable. ICU
has U_IS_BMP, but in most of the cases we want to check for non-BMP, so if we
add this macro it might be ok to check for non-BMP;
If you want to make it public, it's better to call it PyUNICODE_IS_BMP()
(check if the argument is in U+-U+).
* I'm not sure HIGH_SURROGATE/LOW_SURROGATE are useful with
_Py_UNICODE_NEXT. If they are they should get a better name because the
current one is not clear about what they do.
They are still useful for UTF-16 encoders (to UTF-16-LE/BE and 16-bit
wchar_t*). We can keep HIGH_SURROGATE and LOW_SURROGATE private in
unicodeobject.c.
Unless someone disagrees I'll prepare a patch with
PyUNICODE_IS_{HIGH_|LOW_|}SURROGATE and Py_UNICODE_JOIN_SURROGATES for
unicodeobject.h, using them where necessary, using with Victor implementation
and commit it (after a review).
Cool. I suppose that you mean PyUNICODE_JOIN_SURROGATES (not
Py_UNICODE_JOIN_SURROGATES). I used the verb combine, taken from a
comment in unicodeobject.c. combine is maybe better than join?
--
___
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
[issue12755] Service application crash in python25!PyObject_Malloc
STINNER Victor victor.stin...@haypocalc.com 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 - closed ___ 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
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com 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
Ezio used two different naming schemes in his email. Please always
use Py_UNICODE_... or _Py_UNICODE (not PyUNICODE_ or _PyUNICODE_).
For Python 2.7 and 3.2, I would prefer to not touch a public header, and
so add the macros in unicodeobject.c.
Why would you want to touch Python 2.7 at all ?
and be public in 3.3+.
If you want to make my HIGH_SURROGATE and LOW_SURROGATE macros public,
they will use to substract 0x1 themself (whereas my macros require
the ordinal to be preproceed).
This can be done by having two definitions of the macros: one set for
UCS2 builds and one for UCS4.
* _Py_UNICODE_NEXT and _Py_UNICODE_PUT_NEXT are useful, so once we have
agreed about the name they can go in. They can be private in all the 3
branches and made public in 3.4 if they work well;
Note: I don't think that _Py_UNICODE*NEXT should go into Python 2.7 or 3.2.
Certainly not into Python 2.7. Adding macros in patch level releases is
also not such a good idea.
* IS_NONBMP doesn't simplify much the code but makes it more readable.
ICU has U_IS_BMP, but in most of the cases we want to check for non-BMP, so
if we add this macro it might be ok to check for non-BMP;
If you want to make it public, it's better to call it PyUNICODE_IS_BMP()
(check if the argument is in U+-U+).
Py_UNICODE_IS_BMP() please.
* I'm not sure HIGH_SURROGATE/LOW_SURROGATE are useful with
_Py_UNICODE_NEXT. If they are they should get a better name because the
current one is not clear about what they do.
They are still useful for UTF-16 encoders (to UTF-16-LE/BE and 16-bit
wchar_t*). We can keep HIGH_SURROGATE and LOW_SURROGATE private in
unicodeobject.c.
Unless someone disagrees I'll prepare a patch with
PyUNICODE_IS_{HIGH_|LOW_|}SURROGATE and Py_UNICODE_JOIN_SURROGATES for
unicodeobject.h, using them where necessary, using with Victor
implementation and commit it (after a review).
Cool. I suppose that you mean PyUNICODE_JOIN_SURROGATES (not
Py_UNICODE_JOIN_SURROGATES). I used the verb combine, taken from a
comment in unicodeobject.c. combine is maybe better than join?
No, Py_UNICODE_... please !
Thanks,
--
Marc-Andre Lemburg
eGenix.com
2011-10-04: PyCon DE 2011, Leipzig, Germany48 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/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:
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 3.2 and 3.3.
If you want to make my HIGH_SURROGATE and LOW_SURROGATE macros
public, they will use to substract 0x1 themself (whereas my
macros require the ordinal to be preproceed).
If they turn out to be useful and we find a clearer name we can even make them
public in 3.3, but we'll have to see about that.
Note: I don't think that _Py_UNICODE*NEXT should go into
Python 2.7 or 3.2.
If they don't it won't be possible to fix #9200 in those branches (unless we
decide that the bug shouldn't be fixed there, but I would rather fix it).
If you want to make it public, it's better to call it
PyUNICODE_IS_BMP() (check if the argument is in U+-U+).
Yes, public APIs will follow the naming conventions. Not sure if it's better
to check if it's a BMP char, or if it's not.
They are still useful for UTF-16 encoders (to UTF-16-LE/BE and 16-bit
wchar_t*). We can keep HIGH_SURROGATE and LOW_SURROGATE private in
unicodeobject.c.
What are the naming convention for private macros in the same .c file where
they are used? Shouldn't they get at least a trailing _?
Unless someone disagrees I'll prepare a patch with
PyUNICODE_IS_{HIGH_|LOW_|}SURROGATE and Py_UNICODE_JOIN_SURROGATES for
unicodeobject.h, using them where necessary, using with Victor implementation
and commit it (after a review).
Cool. I suppose that you mean PyUNICODE_JOIN_SURROGATES (not
Py_UNICODE_JOIN_SURROGATES).
All the other macros use PyUNICODE_*.
I used the verb combine, taken from a comment in unicodeobject.c.
combine is maybe better than join?
I like join, it's clear enough and shorter.
--
___
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: 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 reason for this? We don't add new features to stable releases. If you want to make my HIGH_SURROGATE and LOW_SURROGATE macros public, they will use to substract 0x1 themself (whereas my macros require the ordinal to be preproceed). If they turn out to be useful and we find a clearer name we can even make them public in 3.3, but we'll have to see about that. I don't think that they are useful outside unicodeobject.c. Note: I don't think that _Py_UNICODE*NEXT should go into Python 2.7 or 3.2. If they don't it won't be possible to fix #9200 in those branches I don't think that #9200 is a bug, but more a feature request. Not sure if it's better to check if it's a BMP char, or if it's not. I prefer a shorter name and avoiding double negation: !Py_UNICODE_IS_NON_BMP(ch). What are the naming convention for private macros in the same .c file where they are used? Hopefully, there is no convention for private macros :-) Shouldn't they get at least a trailing _? Nope. -- ___ 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: 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 would you want to touch Python 2.7 at all ? [...] Certainly not into Python 2.7. Adding macros in patch level releases is also not such a good idea. Because it has the bug and we can fix it (the macros will be private so that we don't add any feature). 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)? My idea is to fix the bug in 2.7/3.2/3.3 using the macros, but only make them public in 3.3 so that new features are exposed only in 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: Ezio Melotti wrote: Ezio Melotti ezio.melo...@gmail.com 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. Good :-) Why would you want to touch Python 2.7 at all ? [...] Certainly not into Python 2.7. Adding macros in patch level releases is also not such a good idea. Because it has the bug and we can fix it (the macros will be private so that we don't add any feature). 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)? My idea is to fix the bug in 2.7/3.2/3.3 using the macros, but only make them public in 3.3 so that new features are exposed only in 3.3. 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 old patch level releases of Python 2.7/3.2. Also note that some of these macros change the behavior of Python - that's good if it fixes a bug (obviously :-)), but bad if it changes areas that are correctly implemented and then suddenly expose new behavior. -- ___ 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: 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 old patch level releases of Python 2.7/3.2. 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. Regarding the name, other macros in unicodeobject.c don't have any prefix, so we can do the same (e.g. IS_SURROGATE) for 2.7/3.2 if that's fine. Also note that some of these macros change the behavior of Python - that's good if it fixes a bug (obviously :-)), but bad if it changes areas that are correctly implemented and then suddenly expose new behavior. After this we can fix #9200 and make narrow builds behave correctly (i.e. like wide ones) with non-BMP chars (at least in some places). -- ___ 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: Ezio Melotti wrote: Ezio Melotti ezio.melo...@gmail.com 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 old patch level releases of Python 2.7/3.2. 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. Regarding the name, other macros in unicodeobject.c don't have any prefix, so we can do the same (e.g. IS_SURROGATE) for 2.7/3.2 if that's fine. Sure. Also note that some of these macros change the behavior of Python - that's good if it fixes a bug (obviously :-)), but bad if it changes areas that are correctly implemented and then suddenly expose new behavior. After this we can fix #9200 and make narrow builds behave correctly (i.e. like wide ones) with non-BMP chars (at least in some places). Ok. -- ___ 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
[issue12767] document threading.Condition.notify
Eli Bendersky eli...@gmail.com 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 normal deprecation process for this argument first? Adding Antoine as the listed threading expert. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12767 ___ ___ 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
Changes by Alexander Belopolsky alexander.belopol...@gmail.com: -- nosy: +belopolsky ___ 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
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Eric V. Smith e...@trueblade.com 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? -- ___ 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: Correct. -- ___ 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
Martin v. Löwis mar...@v.loewis.de 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 bugs you apparently want to fix using these macros: they should be considered on a case-by-case basis. Some of your planned bug fixes may introduce incompatibilities that rule out fixing them. -- ___ 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: 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 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
[issue12767] document threading.Condition.notify
R. David Murray rdmur...@bitdance.com 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 rep...@bugs.python.org http://bugs.python.org/issue12767 ___ ___ 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'
Charles-François Natali neolo...@free.fr added the comment: 2011/8/16 Dave Malcolm rep...@bugs.python.org: 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 Thanks Dave. To me, this sounds like yet another reason not to use sys.platform (C) (TM) (R). My patch version 2 Looks good 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
[issue12515] email modifies the message structure when the parsed email is invalid
Changes by xavierd xdelan...@cloudmark.com: Added file: http://bugs.python.org/file22919/orig.eml ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12769] String with NUL characters truncated by ctypes when assigning to a char array
New submission from Rafał Dowgird dowg...@gmail.com: 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 nosy: Rafal.Dowgird priority: normal severity: normal status: open title: String with NUL characters truncated by ctypes when assigning to a char array type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file22920/reproduce.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12769 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12769] String with NUL characters truncated by ctypes when assigning to a char array
Rafał Dowgird dowg...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue12769 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12770] Email problem on Windows XP SP3 32bits
New submission from Marcelo dapda...@yahoo.com.br: 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: open title: Email problem on Windows XP SP3 32bits ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12770 ___ ___ 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
Sturla Molden stu...@molden.no 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 Python function calls. That is why I suggested an option to return a raw buffer (e.g. bytearray or memory_view). My experience with NumPy and MATLAB tells me that random numbers are nearly always needed in arrays with scripting languages. But I cannot focus my thoughts... -- ___ 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
[issue12771] 2to3 -d adds extra whitespace
New submission from Vlada Peric vlada.pe...@gmail.com: 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 then raises an error for our automated whitespace tests (and is generally annoying). I haven't seen this happen anywhere else (and SymPy is a big codebase). It's really a minor issue, though (I can't set the priority myself, though). [0] https://github.com/sympy/sympy/blob/master/sympy/physics/quantum/represent.py -- components: 2to3 (2.x to 3.0 conversion tool) messages: 142281 nosy: Aaron.Meurer, VPeric priority: normal severity: normal status: open title: 2to3 -d adds extra whitespace versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
Changes by higery shoulderhig...@gmail.com: Added file: http://bugs.python.org/file22922/4be1917b2a9e.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
higery shoulderhig...@gmail.com 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 kind of 'gui_scripts' of setuptools. Here is a simple example to show these usecases, in setup.cfg: scripts = foo = a.b.c.main foowin = a.b.c.winmain -window Then a executable 'foo' file will be generated for Posix platform, console programm 'foo.exe' and window programm 'foowin.exe' files are generated for Windows platform. The 'window' option is just used to show that this entry is a kind of 'gui_scripts' entry to support gui programm wrappers generation. Now, there is an issue to consider when we make this change: 'scripts' belongs to the 'files' section in setup.cfg, it's still ok now to place it in 'files'? Still take the above example to say, 'foo=a.b.c.main' and 'foowin=a.b.c.winmain -window' are just dotted path strings to show main executable entry function, they are not existed files and are only just used to generate files. In addition, there are two kinds of configuration files supported in packaing - setup.py and setup.cfg, and both of them can exist in a project at the same time , and have different purposes for usage. setup.cfg just offers users a way to change the default configuration, so I think we should write the dotted strings in setup.py, do anyone agree with me? Then the above writting way of 'scripts' maybe changed... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12394 ___ ___ 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_
Vlad Riscutia riscutiav...@gmail.com 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 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
[issue12764] segfault in ctypes.Struct with bad _fields_
Vlad Riscutia riscutiav...@gmail.com added the comment: Also patch for 2.7 with unittest. BTW, bx works on 2.7. -- Added file: http://bugs.python.org/file22924/issue12764_patch2x.diff ___ 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
[issue12772] fractional day attribute in datetime class
New submission from Miguel de Val Borro miguel.de...@gmail.com: 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 observations. -- messages: 142286 nosy: Miguel.de.Val.Borro priority: normal severity: normal status: open title: fractional day attribute in datetime class type: feature request versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12772 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12773] classes should have mutable docstrings
Roundup Robot devn...@psf.upfronthosting.co.za 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 - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12773 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12567] curses implementation of Unicode is wrong in Python 3
STINNER Victor victor.stin...@haypocalc.com added the comment: what needs to happen for them to move forward? I would like a review of curses_unicode.patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12567 ___ ___ 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'
Roundup Robot devn...@psf.upfronthosting.co.za 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 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'
STINNER Victor victor.stin...@haypocalc.com 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 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
[issue12748] Problems using IDLE accelerators with OS X Dvorak - Qwerty ⌘ input method
Ned Deily n...@acm.org 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 opened a Tk issue for it: https://sourceforge.net/tracker/?func=detailaid=3393315group_id=12997atid=112997 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12720] Expose linux extended filesystem attributes
Antoine Pitrou pit...@free.fr 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 reasonable as well I also get the following test failures: == FAIL: test_fds (test.test_os.ExtendedAttributeTests) -- Traceback (most recent call last): File /home/antoine/cpython/default/Lib/test/test_os.py, line 1579, in test_fds self._check_xattrs(getxattr, setxattr, removexattr, listxattr) File /home/antoine/cpython/default/Lib/test/test_os.py, line 1542, in _check_xattrs setxattr(fn, buser.test, bbye, os.XATTR_CREATE) AssertionError: OSError not raised == FAIL: test_lpath (test.test_os.ExtendedAttributeTests) -- Traceback (most recent call last): File /home/antoine/cpython/default/Lib/test/test_os.py, line 1564, in test_lpath os.llistxattr) File /home/antoine/cpython/default/Lib/test/test_os.py, line 1542, in _check_xattrs setxattr(fn, buser.test, bbye, os.XATTR_CREATE) AssertionError: OSError not raised == FAIL: test_simple (test.test_os.ExtendedAttributeTests) -- Traceback (most recent call last): File /home/antoine/cpython/default/Lib/test/test_os.py, line 1560, in test_simple os.listxattr) File /home/antoine/cpython/default/Lib/test/test_os.py, line 1542, in _check_xattrs setxattr(fn, buser.test, bbye, os.XATTR_CREATE) AssertionError: OSError not raised -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12720] Expose linux extended filesystem attributes
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10015] Creating a multiproccess.pool.ThreadPool from a child thread blows up.
Christian brugger@googlemail.com 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 patch) -- nosy: +chris- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10015 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12774] Warning -- multiprocessing.process._dangling was modified by test_multiprocessing
New submission from Ned Deily n...@acm.org: [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 -- multiprocessing.process._dangling was modified by test_multiprocessing versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12774 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12774] Warning -- multiprocessing.process._dangling was modified by test_multiprocessing
Ned Deily n...@acm.org 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 default but not backported to 3.2. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12774 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12774] Warning -- multiprocessing.process._dangling was modified by test_multiprocessing
Changes by Ned Deily n...@acm.org: -- nosy: +georg.brandl, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12774 ___ ___ 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'
James Y Knight f...@users.sourceforge.net 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 3.x? -- ___ 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 18, 2011, at 01:20 AM, James Y Knight wrote: James Y Knight f...@users.sourceforge.net 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 3.x? My question too! I would say that stable releases should probably not get this change, but should force sys.platform to linux2 on 3.x kernels. BTW, does anybody think sys.platform should use a more dynamic approach for calculating its value? Well, maybe not necessary if Python 3.3 will just say 'linux'. -- ___ 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
[issue10320] printf %qd is nonstandard
Meador Inge mead...@gmail.com 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.inge -theller priority: normal - low stage: - test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10320 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9651] ctypes crash when writing zerolength string buffer to file
Meador Inge mead...@gmail.com added the comment: Ping. I think this one is OK to commit. -- nosy: +belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9651 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12767] document threading.Condition.notify
Eli Bendersky eli...@gmail.com 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 performance of repeated get/put calls when the Queue is created using multiprocessing.Manager. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12767 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
Vinay Sajip vinay_sa...@yahoo.co.uk 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
Vinay Sajip vinay_sa...@yahoo.co.uk 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 rep...@bugs.python.org http://bugs.python.org/issue12394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
