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

[Santoso Wijaya]

Changes by Santoso Wijaya :


--
nosy: +santa4nt

___
Python tracker 

___
___
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]

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

___
___
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]

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 

___
___
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]

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

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 

___
___
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]

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 -> closed

___
Python tracker 

___
___
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]

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

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

___
___
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]

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

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

___
___
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]

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

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

___
___
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]

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 to refactor this so that notify itself does 
>not take an argument but instead both it an notify_all call an explicitly 
>internal routine _notify.

--
nosy: +r.david.murray

___
Python tracker 

___
___
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]

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

___
___
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 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 normal deprecation process for this argument first?

Adding Antoine as the listed threading expert.

--
nosy: +pitrou

___
Python tracker 

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

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
nosy: +belopolsky

___
Python tracker 

___
___
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]

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?

--

___
Python tracker 

___
___
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 Melotti  added the comment:

Correct.

--

___
Python tracker 

___
___
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]

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

___
___
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]

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 

___
___
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]

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 

___
___
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]

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

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

[xavierd]

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 'email.errors.CloseBoundaryNotFoundDefect' when a boundary isn't 
closed.
   - the error 'email.errors.MissingHeaderBodySeparator' when the header/body 
isn't found
(patch for python 2.7.2)
 - orig.email: a email without a header/body separator

--
Added file: http://bugs.python.org/file22918/email.patch

___
Python tracker 

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

[xavierd]

Changes by xavierd :


Removed file: http://bugs.python.org/file22887/email.patch

___
Python tracker 

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

[xavierd]

Changes by xavierd :


Added file: http://bugs.python.org/file22919/orig.eml

___
Python tracker 

___
___
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]

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

___
___
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]

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 

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

[STINNER Victor]

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 how to get the raw value of a c_char array in a structure. 
You should maybe use another type.

--
nosy: +haypo

___
Python tracker 

___
___
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]

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 

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

[Marcelo]

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: open
title: Email problem on Windows XP SP3 32bits

___
Python tracker 

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

[Brian Curtin]

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

___
Python tracker 

___
___
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]

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

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

[Vlada Peric]

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

___
___
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]

Changes by higery :


Added file: http://bugs.python.org/file22922/4be1917b2a9e.diff

___
Python tracker 

___
___
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]

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

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

[Nicholas Cole]

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?

--

___
Python tracker 

___
___
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]

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 

___
___
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]

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 

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

[Miguel de Val Borro]

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

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

[Eric Snow]

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 writable

That is on 3.3, but apparently it's the case all the way back to 2.2.
I mentioned this on python-list and several people indicated that it
should be an unnecessary restriction [1].  I also found that this only impacts 
classes that do not have a custom metaclass.

Regardless, it looks like this is something that no one has take the time to 
address but would be nice to have done [2][3].  I found that the type_getset 
for __doc__ does not have a getter:

http://hg.python.org/cpython/file/default/Objects/typeobject.c#l634

I have attached a patch that adds one and fixes the problem.  "make test" 
passed after the fix.


[1] http://mail.python.org/pipermail/python-list/2011-June/1274079.html
[2] http://mail.python.org/pipermail/python-ideas/2011-June/010462.html
[3] http://mail.python.org/pipermail/python-ideas/2011-August/011185.html

--
components: Interpreter Core
files: mutable_class_docstrings.diff
keywords: patch
messages: 142287
nosy: eric.snow, michael.foord, ncoghlan
priority: normal
severity: normal
status: open
title: classes should have mutable docstrings
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file22925/mutable_class_docstrings.diff

___
Python tracker 

___
___
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]

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 -> closed

___
Python tracker 

___
___
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]

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 

___
___
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]

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 

___
___
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]

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 

___
___
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]

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 opened a Tk issue for it:

https://sourceforge.net/tracker/?func=detail&aid=3393315&group_id=12997&atid=112997

--

___
Python tracker 

___
___
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]

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 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, b"user.test", b"bye", 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, b"user.test", b"bye", 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, b"user.test", b"bye", os.XATTR_CREATE)
AssertionError: OSError not raised

--
nosy: +pitrou

___
Python tracker 

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

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

___
___
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]

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 patch)

--
nosy: +chris-

___
Python tracker 

___
___
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]

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 -- multiprocessing.process._dangling was modified by 
test_multiprocessing
versions: Python 3.2, Python 3.3

___
Python tracker 

___
___
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]

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 default but not backported to 3.2.

--

___
Python tracker 

___
___
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]

Changes by Ned Deily :


--
nosy: +georg.brandl, pitrou

___
Python tracker 

___
___
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]

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 
3.x?

--

___
Python tracker 

___
___
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]

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

___
___
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]

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.inge -theller
priority: normal -> low
stage:  -> test needed

___
Python tracker 

___
___
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]

Meador Inge  added the comment:

Ping.  I think this one is OK to commit.

--
nosy: +belopolsky

___
Python tracker 

___
___
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 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 
performance of repeated get/put calls when the Queue is created using 
multiprocessing.Manager."

--

___
Python tracker 

___
___
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 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.

--

___
Python tracker 

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

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com