Re: [Python-Dev] [Python-checkins] cpython: fix formatting
Le 04/10/2011 01:35, benjamin.peterson a écrit : http://hg.python.org/cpython/rev/64495ad8aa54 changeset: 72634:64495ad8aa54 user:Benjamin Petersonbenja...@python.org date:Mon Oct 03 19:35:07 2011 -0400 summary fix formatting +++ b/Objects/unicodeobject.c @@ -1362,8 +1362,8 @@ return -1; _PyUnicode_CheckConsistency(*p_unicode); return 0; -} else -return resize_inplace((PyUnicodeObject*)unicode, length); +} +return resize_inplace((PyUnicodeObject*)unicode, length); } I chose deliberately to use else return ..., it's more readable for me. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: fix compiler warnings
Le 04/10/2011 01:34, benjamin.peterson a écrit :
http://hg.python.org/cpython/rev/afb60b190f1c
changeset: 72633:afb60b190f1c
user:Benjamin Petersonbenja...@python.org
date:Mon Oct 03 19:34:12 2011 -0400
summary:
fix compiler warnings
+++ b/Objects/unicodeobject.c
@@ -369,6 +369,12 @@
}
return 1;
}
+#else
+static int
+_PyUnicode_CheckConsistency(void *op)
+{
+return 1;
+}
#endif
Oh no, please don't do that. Calling _PyUnicode_CheckConsistency() is
reserved to debug builds. In release mode, we should not check string
consistency (it would slow down Python).
Yes, there was a warning:
Objects/unicodeobject.c:539:13: warning: statement with no effect
_PyUnicode_CHECK(unicode);
I added these checks recently to ensure that strings are consistent just
before exiting (to help me to track down a bug).
The right fix is just to replace _PyUnicode_CHECK(unicode) by
assert(_PyUnicode_CHECK(unicode)).
Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: pyexpat uses the new Unicode API
Le 03/10/2011 11:10, Amaury Forgeot d'Arc a écrit :
changeset: 72548:a1be34457ccf
user:Victor Stinnervictor.stinner at haypocalc.com
date:Sat Oct 01 01:05:40 2011 +0200
summary:
pyexat uses the new Unicode API
files:
Modules/pyexpat.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Modules/pyexpat.c b/Modules/pyexpat.c
--- a/Modules/pyexpat.c
+++ b/Modules/pyexpat.c
@@ -1234,11 +1234,13 @@
static PyObject *
xmlparse_getattro(xmlparseobject *self, PyObject *nameobj)
{
-const Py_UNICODE *name;
+Py_UCS4 first_char;
int handlernum = -1;
if (!PyUnicode_Check(nameobj))
goto generic;
+if (PyUnicode_READY(nameobj))
+return NULL;
Why is this PyUnicode_READY necessary?
Can tp_getattro pass unfinished unicode objects?
I hope we don't have to update all extension modules?
The Unicode API is supposed to only deliver ready strings. But all
extensions written for Python 3.2 use the legacy API
(PyUnicode_FromUnicode and PyUnicode_FromString(NULL, size)) and so no
string is ready.
But *no*, you don't have to update your extension reading strings to add
a call to PyUnicode_READY. You only have to call PyUnicode_READY if you
use the new API (e.g. PyUnicode_READ_CHAR), so if you modify your code.
Another extract of my commit (on pyexpat):
-name = PyUnicode_AS_UNICODE(nameobj);
+first_char = PyUnicode_READ_CHAR(nameobj, 0);
Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: fix formatting
2011/10/4 Victor Stinner victor.stin...@haypocalc.com: Le 04/10/2011 01:35, benjamin.peterson a écrit : http://hg.python.org/cpython/rev/64495ad8aa54 changeset: 72634:64495ad8aa54 user: Benjamin Petersonbenja...@python.org date: Mon Oct 03 19:35:07 2011 -0400 summary fix formatting +++ b/Objects/unicodeobject.c @@ -1362,8 +1362,8 @@ return -1; _PyUnicode_CheckConsistency(*p_unicode); return 0; - } else - return resize_inplace((PyUnicodeObject*)unicode, length); + } + return resize_inplace((PyUnicodeObject*)unicode, length); } I chose deliberately to use else return ..., it's more readable for me. Then there should be braces around it. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: fix compiler warnings
2011/10/4 Victor Stinner victor.stin...@haypocalc.com:
Le 04/10/2011 01:34, benjamin.peterson a écrit :
http://hg.python.org/cpython/rev/afb60b190f1c
changeset: 72633:afb60b190f1c
user: Benjamin Petersonbenja...@python.org
date: Mon Oct 03 19:34:12 2011 -0400
summary:
fix compiler warnings
+++ b/Objects/unicodeobject.c
@@ -369,6 +369,12 @@
}
return 1;
}
+#else
+static int
+_PyUnicode_CheckConsistency(void *op)
+{
+ return 1;
+}
#endif
Oh no, please don't do that. Calling _PyUnicode_CheckConsistency() is
reserved to debug builds. In release mode, we should not check string
consistency (it would slow down Python).
It should be optimized out.
Yes, there was a warning:
Objects/unicodeobject.c:539:13: warning: statement with no effect
_PyUnicode_CHECK(unicode);
I added these checks recently to ensure that strings are consistent just
before exiting (to help me to track down a bug).
The right fix is just to replace _PyUnicode_CHECK(unicode) by
assert(_PyUnicode_CHECK(unicode)).
But _PyUnicode_CheckConsistency is just a string of assertions. What
sense does it make to check the return value?
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-Dev Digest, Vol 99, Issue 7
Hello Python Developers, I am a Program Manager with the Ecosystem Engineering team at Microsoft. We are tracking a issue with Python 3.2.2 on Windows Developer Preview when using Internet Explorer. [...] I'd like to connect directly with a developer on the project so that we can work closesly to resolve this issue. You know, without any specifics given about the issue, this smells like comment spam. If it wasn't from such a reputable source, I'd almost think someone is just contacting projects at random with vague reports of issues relating to IE10 to pump up some interest in the new browser, whether those projects are anything to do with web browsing or not. Only kidding, they aren't that reputable ;) I Googled the phrase I am a Program Manager with the Ecosystem Engineering team at Microsoft, and it seems this scattershot approach is not new. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Using PEP384 Stable ABI for the lzma extension module
Hi, Has someone already tried to *really* use Py_LIMITED_API for some serious extension module? I wanted to give it a try for the _lzma module (see issue 6715) because liblzma does not compile with Microsoft compilers; an alternative could be to use mingw to (pre)build _lzma.pyd, which would link with a static liblzma.a also compiled with mingw. Mixing compilers in a Python process is one of the reasons of PEP384, so I added #define Py_LIMITED_API on top of the module, and fixed the issues one by one: - Py_LIMITED_API is incompatible with --with-pydebug, and compilation stops. I skipped the check to continue. - I replaced PyBytes_GET_SIZE() with Py_SIZE(), which is OK, and PyBytes_AS_STRING() with PyBytes_AsString(), which may have a slight performance impact. - I replaced Py_TYPE(self)-tp_free((PyObject *)self); with PyObject_Del(self), I hope this is the same thing (for a non-GC object) - _PyBytes_Resize() is missing; I moved it under a Py_LIMITED_API section. - For the y* argument spec, the Py_buffer structure is required (only for two fields: buf and len), as well as PyBuffer_Release() - PyType_FromSpec() does not call PyType_Ready(), which caused crashes in __new__. Now the module seems to work correctly and passes tests... at least on Linux in a standard environment. I will do other tests on Windows. What do you think about using the stable ABI even in shipped extensions? Have you already used it somewhere else? Cheers, -- Amaury Forgeot d'Arc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python compatibility issue with Windows Developer Preview
On 04/10/2011 02:20, Brian Curtin wrote: On Mon, Oct 3, 2011 at 18:32, Ryan Wells (MP Tech Consulting LLC) v-ry...@microsoft.com mailto:v-ry...@microsoft.com wrote: Hello Python Developers, I am a Program Manager with the Ecosystem Engineering team at Microsoft. We are tracking a issue with Python 3.2.2 on Windows Developer Preview when using Internet Explorer. Is there any public bug tracker or other information for this on your end? Sounds weird. How would one use Python 3.2.2 with Internet explorer? It would be possible with the pywin32 extensions, but then the correct place for support would be the pywin32 bug tracker and mailing lists (as they're not part of core Python). Michael I'd like to connect directly with a developer on the project so that we can work closesly to resolve this issue. There aren't many Windows devs around here, but while I'm one of them, I don't currently have the bandwidth to devote to getting a Windows 8 setup and working on this issue at the time. I think your best bet would be to post as much information as you have and we can go from there, either from myself or anyone available. If you think you've nailed down a specific issue in Python, http://bugs.python.org is our bug tracker. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Migrate str.expandtabs to the new API
Migrate str.expandtabs to the new API This needs if (PyUnicode_READY(self) == -1) return NULL; right after the ParseTuple call. In most cases, the check will be a noop. But if it's not, omitting it will make expandtabs have no effect, since the string length will be 0 (in a debug build, you also get an assertion failure). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using PEP384 Stable ABI for the lzma extension module
(My comments are based on the assumption Amaury started with http://hg.python.org/sandbox/nvawda/file/09d984063fca/Modules/_lzmamodule.c) On Tue, Oct 4, 2011 at 12:18 PM, Amaury Forgeot d'Arc amaur...@gmail.com wrote: - Py_LIMITED_API is incompatible with --with-pydebug, and compilation stops. I skipped the check to continue. That seems like an odd (and undesirable) restriction. If different Python versions are going to expose the same ABI, it seems strange of debug and release versions can't do the same. - I replaced PyBytes_GET_SIZE() with Py_SIZE(), which is OK, and PyBytes_AS_STRING() with PyBytes_AsString(), which may have a slight performance impact. Yes, the price of using the stable ABI is that performance tricks that depend on exact memory layouts are no longer available. - I replaced Py_TYPE(self)-tp_free((PyObject *)self); with PyObject_Del(self), I hope this is the same thing (for a non-GC object) That looks right in this particular case, but problematic in general. The stable ABI probably needs a better solution for tp_new slots invoking tp_alloc and tp_dealloc slots invoking tp_free. In fact, a systematic review of the slot documentation is probably needed, pointing out the stable ABI alternatives to all of the recommended cross slot invocations (and creating them if they don't already exist). - _PyBytes_Resize() is missing; I moved it under a Py_LIMITED_API section. No, that's not valid. Bytes are officially immutable - mutating them when the reference count is only 1 is a private for a reason. The correct way to do this without relying on that implementation detail is to use a byte array instead. - For the y* argument spec, the Py_buffer structure is required (only for two fields: buf and len), as well as PyBuffer_Release() Yeah, PEP 3118 support will eventually appear in the stable ABI, but we need to fix it first (see issue 10181). - PyType_FromSpec() does not call PyType_Ready(), which caused crashes in __new__. That sounds like it may just be a bug. Although looking at the C API docs, PEP 384 documentation appears to be basically non-existent... Now the module seems to work correctly and passes tests... at least on Linux in a standard environment. I will do other tests on Windows. What do you think about using the stable ABI even in shipped extensions? It's probably not a bad idea, otherwise we may compilation without realising it. This is especially so for extension modules that *don't* need access to any of the interpreter internals. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using PEP384 Stable ABI for the lzma extension module
On Tue, Oct 4, 2011 at 1:05 PM, Nick Coghlan ncogh...@gmail.com wrote: It's probably not a bad idea, otherwise we may compilation without realising it. s/may/may break/ Actually testing the ABI stability would be much harder - somehow building an extension module against 3.2 with the limited API then testing it against a freshly built 3.3. Perhaps we could manage something like that by building against a system installation of Python 3.2 on builders that have it available. All in all, I think PEP 384 laid the foundations, but there's still plenty of work to be done in the documentation and testing space (and perhaps a few API additions) before the majority of extensions can realistically switch to the stable ABI. A bit of eating our own dogfood in the extension modules we ship may be a good place to start (especially new ones that are added). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using PEP384 Stable ABI for the lzma extension module
Amaury: thanks for your experiment and your report. - I replaced PyBytes_GET_SIZE() with Py_SIZE(), which is OK, and PyBytes_AS_STRING() with PyBytes_AsString(), which may have a slight performance impact. That's the whole point of the stable ABI: AS_STRING assumes that there is an ob_sval field at a certain offset of the bytes object, which may not be there in a future release. PyBytes_AsString is indeed slower, but also more future-proof. - I replaced Py_TYPE(self)-tp_free((PyObject *)self); with PyObject_Del(self), I hope this is the same thing (for a non-GC object) If a subtype of self.__class__ would override tp_free, it wouldn't be the same anymore. I guess the API needs a way to read a slot from a type object. - _PyBytes_Resize() is missing; I moved it under a Py_LIMITED_API section. ??? Are you proposing to add _PyBytes_Resize to the Py_LIMITED_API set of functions? It's not even an API function in the first place (it starts with an underscore), so how can it be a limited API function? I think this whole notion of resizing immutable objects in the Python C API is flawed. If you can't know how large a buffer is in advance, first allocate a regular memory block, and then copy it into an object when done. - For the y* argument spec, the Py_buffer structure is required (only for two fields: buf and len), as well as PyBuffer_Release() Yes, this was a debate in the API PEP. I originally had the buffer API in the stable ABI, but was then advised to remove it, as it may not be that stable at all. I'll start a thread about extending the stable ABI soon; if people now want to reconsider, it would be possible. However, taking something out of the stable ABI is not possible, so if we decide the buffer API is stable, the structure is locked until Python 4. - PyType_FromSpec() does not call PyType_Ready(), which caused crashes in __new__. Oops :-) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using PEP384 Stable ABI for the lzma extension module
- Py_LIMITED_API is incompatible with --with-pydebug, and compilation stops. I skipped the check to continue. That seems like an odd (and undesirable) restriction. It's deliberate, though. If different Python versions are going to expose the same ABI, it seems strange of debug and release versions can't do the same. You'll have to specify a lot of details what precisely constitutes a debug build, and what fields precisely belong to it. Nobody volunteered to specify what it should do, so I excluded it. It's also not the objective of the PEP to support loading debug-built extensions in alternative interpreter versions. I fail to see why this is undesirable, also. It's very easy to write an extension module that only uses the limited API, and still builds fine in a debug build: just don't define Py_LIMITED_API when compiling for debug mode. The stable ABI probably needs a better solution for tp_new slots invoking tp_alloc and tp_dealloc slots invoking tp_free. In fact, a systematic review of the slot documentation is probably needed, pointing out the stable ABI alternatives to all of the recommended cross slot invocations (and creating them if they don't already exist). Doing so would probably be better than my proposed approach of just provding a generic access function that reads a slot as a void* from a type object. What do you think about using the stable ABI even in shipped extensions? It's probably not a bad idea, otherwise we may compilation without realising it. This is especially so for extension modules that *don't* need access to any of the interpreter internals. Missing a word in the first sentence? There is the xxlimited module that is there to test that it keeps compiling under the limited API. I'll review all API additions before the next release, and will exclude a) anything that shouldn't be used by extension modules at all. There was a tradition of exposing all helper function, but I think this tradition needs to stop. Instead, adding to the API should be conservative, and only add what is positively useful to extension modules. b) anything that is not sufficiently stable from the limited API (in particular stuff that refers to new structures). The DLL .def file for Windows will make sure that nothing gets added unintentionally to the stable ABI, unfortunately, there is no easy technique for Unix achieving the same. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Optimize string slicing to use the new API
+result = PyUnicode_New(slicelength, PyUnicode_MAX_CHAR_VALUE(self)); This is incorrect: the maxchar of the slice might be smaller than the maxchar of the input string. So you'll need to iterate over the input string first, compute the maxchar, and then allocate the result string. Or you allocate a temporary buffer of (1(kind-1)) * slicelength bytes, copy the slice, allocate the target object with PyUnicode_FromKindAndData, and release the temporary buffer. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python compatibility issue with Windows Developer Preview
On Tue, Oct 4, 2011 at 11:27, Michael Foord fuzzy...@voidspace.org.ukwrote: On 04/10/2011 02:20, Brian Curtin wrote: On Mon, Oct 3, 2011 at 18:32, Ryan Wells (MP Tech Consulting LLC) v-ry...@microsoft.com wrote: Hello Python Developers, I am a Program Manager with the Ecosystem Engineering team at Microsoft. We are tracking a issue with Python 3.2.2 on Windows Developer Preview when using Internet Explorer. Is there any public bug tracker or other information for this on your end? Sounds weird. How would one use Python 3.2.2 with Internet explorer? It would be possible with the pywin32 extensions, but then the correct place for support would be the pywin32 bug tracker and mailing lists (as they're not part of core Python). I took the original message as Python is screwing up because Internet Explorer is running, which is ridiculous. Until they follow up with details, I think there's nothing to see here. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Optimize string slicing to use the new API
Am 04.10.11 19:50, schrieb Antoine Pitrou: On Tue, 04 Oct 2011 19:49:09 +0200 Martin v. Löwismar...@v.loewis.de wrote: +result = PyUnicode_New(slicelength, PyUnicode_MAX_CHAR_VALUE(self)); This is incorrect: the maxchar of the slice might be smaller than the maxchar of the input string. I thought that heuristic would be good enough. I'll try to fix it. No - strings must always be in the canonical form. For example, PyUnicode_RichCompare considers string unequal if they have different kinds. As a consequence, your slice result may not compare equal to a canonical variant of itself. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): Issue #11956: Skip test_import.test_unwritable_directory on FreeBSD when run as
In article e1rb8co-0006fz...@dinsdale.python.org, charles-francois.natali python-check...@python.org wrote: http://hg.python.org/cpython/rev/7697223df6df changeset: 72670:7697223df6df branch: 3.2 parent: 72658:2484b2b8876e user:Charles-Fran?ssois Natali neolo...@free.fr date:Tue Oct 04 19:17:26 2011 +0200 summary: Issue #11956: Skip test_import.test_unwritable_directory on FreeBSD when run as root (directory permissions are ignored). The same directory permission semantics apply to other (all?) BSD-derived systems, not just FreeBSD. For example, the test still fails in the same way on OS X when run via sudo. -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python compatibility issue with Windows Developer Preview
On Tue, Oct 4, 2011 at 13:24, Ryan Wells (MP Tech Consulting LLC) v-ry...@microsoft.com wrote: Please let me know if you have an estimated timeframe to address this issue, and if our team can further assist in this process. No idea about an estimated time frame, but I've entered http://bugs.python.org/issue13101 into our tracker so we don't lose the issue and its details in our inboxes. If you're interested in tracking the results of any discussion or fixes, you could add yourself to the nosy list on that bug report (you'd have to register or use OpenID). If it is just a difference in return value like you suspected, the fix is probably pretty easy. The bigger barrier is just finding time to get a Windows 8 setup. Thanks for the report. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): Issue #11956: Skip test_import.test_unwritable_directory on FreeBSD when run as
summary: Issue #11956: Skip test_import.test_unwritable_directory on FreeBSD when run as root (directory permissions are ignored). The same directory permission semantics apply to other (all?) BSD-derived systems, not just FreeBSD. For example, the test still fails in the same way on OS X when run via sudo. Thanks, I didn't know: I only noticed this on the FreeBSD buildbots (I guess OS-X buildbots don't run as root). Note that it does behave as expected on Linux (note the use of quotation marks, I'm not sure whether this behavior is authorized by POSIX). I changed the test to skip when the effective UID is 0, regardless of the OS, to stay on the safe side. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python compatibility issue with Windows Developer Preview
Hello, I apologize for the confusion or if this is the wrong mailing listing, I wanted to get in contact with someone before I sent the bug information that I have. We do not have a public bug tracking system that I can direct you to. Based on preliminary testing, the following compatibility issue has been identified: Reference #: 70652 Description of the Problem: The application Python Module Doc is automatically closed when Internet Explorer 10 is closed. Steps to Reproduce: 1. Install Windows Developer Preview 2. Install Python 3.2.2 3. Launch Module Doc. Start Menu - All Program - Python - Manual Docs 4. Click on the button open browser 5. It should open the site http://localhost:7464/ In Internet Explorer 10 and the contents should be displayed 6. Should be able to view list of Modules, Scripts, DLLs, and Libraries etc. 7. Close Internet Explorer Expected Result: Internet Explorer 10 should only get closed and we should be able to work with the application Module Doc. Actual Result: The application Module Doc is closed with Internet Explorer 10. Developer Notes: There is likely a difference in return values between IE8 and IE9/10 when launched from the app. Please let me know if you have an estimated timeframe to address this issue, and if our team can further assist in this process. Regards, Ryan Wells Microsoft PC Ecosystem Engineering Team v-ry...@microsoft.com From: Brian Curtin [mailto:brian.cur...@gmail.com]mailto:[mailto:brian.cur...@gmail.com] Sent: Tuesday, October 04, 2011 11:07 AM To: Michael Foord Cc: Ryan Wells (MP Tech Consulting LLC); Ecosystem Engineering IE; python-dev@python.orgmailto:python-dev@python.org Subject: Re: [Python-Dev] Python compatibility issue with Windows Developer Preview On Tue, Oct 4, 2011 at 11:27, Michael Foord fuzzy...@voidspace.org.ukmailto:fuzzy...@voidspace.org.uk wrote: On 04/10/2011 02:20, Brian Curtin wrote: On Mon, Oct 3, 2011 at 18:32, Ryan Wells (MP Tech Consulting LLC) v-ry...@microsoft.commailto:v-ry...@microsoft.com wrote: Hello Python Developers, I am a Program Manager with the Ecosystem Engineering team at Microsoft. We are tracking a issue with Python 3.2.2 on Windows Developer Preview when using Internet Explorer. Is there any public bug tracker or other information for this on your end? Sounds weird. How would one use Python 3.2.2 with Internet explorer? It would be possible with the pywin32 extensions, but then the correct place for support would be the pywin32 bug tracker and mailing lists (as they're not part of core Python). I took the original message as Python is screwing up because Internet Explorer is running, which is ridiculous. Until they follow up with details, I think there's nothing to see here. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using PEP384 Stable ABI for the lzma extension module
2011/10/4 Martin v. Löwis mar...@v.loewis.de: - _PyBytes_Resize() is missing; I moved it under a Py_LIMITED_API section. ??? Are you proposing to add _PyBytes_Resize to the Py_LIMITED_API set of functions? It's not even an API function in the first place (it starts with an underscore), so how can it be a limited API function? It's not a proposal of any kind; it's just the workaround I used to compile and test. OTOH, it seems that many modules already use this function. Is there another method that does not need to copy data? -- Amaury Forgeot d'Arc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using PEP384 Stable ABI for the lzma extension module
On Tue, 4 Oct 2011 13:05:58 -0400 Nick Coghlan ncogh...@gmail.com wrote: - _PyBytes_Resize() is missing; I moved it under a Py_LIMITED_API section. No, that's not valid. Bytes are officially immutable - mutating them when the reference count is only 1 is a private for a reason. The correct way to do this without relying on that implementation detail is to use a byte array instead. Uh, no, it depends what you're doing. There's no reason not to allow people to resize a bytes object which they've just allocated and is still private to their code. That's the whole reason why _PyBytes_Resize() exists, and the use case is not exotic. Telling people to first create a bytearray and then create a bytes object from that when you're finished would be a shame. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using PEP384 Stable ABI for the lzma extension module
Am 04.10.11 21:06, schrieb Amaury Forgeot d'Arc: 2011/10/4 Martin v. Löwismar...@v.loewis.de: - _PyBytes_Resize() is missing; I moved it under a Py_LIMITED_API section. ??? Are you proposing to add _PyBytes_Resize to the Py_LIMITED_API set of functions? It's not even an API function in the first place (it starts with an underscore), so how can it be a limited API function? It's not a proposal of any kind; it's just the workaround I used to compile and test. OTOH, it seems that many modules already use this function. Is there another method that does not need to copy data? Not sure what you are using it for. If you need to extend the buffer in case it is too small, there is absolutely no way this could work without copies in the general case because of how computers use address space. Even _PyBytes_Resize will copy the data. The only way to avoid copying is to run over the input twice: once to determine how large the output will have to be, and then another time to actually produce the output. Whether or not that's actually faster than copying the output depends on how much work this size computation requires. It would be nice if LZMA had output size information embedded in it, but it may not. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using PEP384 Stable ABI for the lzma extension module
On Tue, Oct 4, 2011 at 3:12 PM, Antoine Pitrou solip...@pitrou.net wrote: Uh, no, it depends what you're doing. There's no reason not to allow people to resize a bytes object which they've just allocated and is still private to their code. That's the whole reason why _PyBytes_Resize() exists, and the use case is not exotic. Telling people to first create a bytearray and then create a bytes object from that when you're finished would be a shame. If developers want to use private CPython functions, then they can't use the stable API - the whole point of having private APIs is that we don't even promise *source* compatibility for those, let alone binary compatibility. If they want the stability guarantee, then they have to eschew hacks that rely on implementation details (like the ability to resize immutable objects). That seems pretty reasonable to me. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using PEP384 Stable ABI for the lzma extension module
On Tue, 04 Oct 2011 21:33:34 +0200 Martin v. Löwis mar...@v.loewis.de wrote: Am 04.10.11 21:06, schrieb Amaury Forgeot d'Arc: 2011/10/4 Martin v. Löwismar...@v.loewis.de: - _PyBytes_Resize() is missing; I moved it under a Py_LIMITED_API section. ??? Are you proposing to add _PyBytes_Resize to the Py_LIMITED_API set of functions? It's not even an API function in the first place (it starts with an underscore), so how can it be a limited API function? It's not a proposal of any kind; it's just the workaround I used to compile and test. OTOH, it seems that many modules already use this function. Is there another method that does not need to copy data? Not sure what you are using it for. If you need to extend the buffer in case it is too small, there is absolutely no way this could work without copies in the general case because of how computers use address space. Even _PyBytes_Resize will copy the data. That's not a given. Depending on the memory allocator, a copy can be avoided. That's why the str += str hack is much more efficient under Linux than Windows, AFAIK. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: PyUnicode_Join() checks output length in debug mode
On 10/03/11 23:35, victor.stinner wrote:
http://hg.python.org/cpython/rev/bfd8b5d35f9c
changeset: 72623:bfd8b5d35f9c
user:Victor Stinner victor.stin...@haypocalc.com
date:Mon Oct 03 23:36:02 2011 +0200
summary:
PyUnicode_Join() checks output length in debug mode
PyUnicode_CopyCharacters() may copies less character than requested size, if
the input string is smaller than the argument. (This is very unlikely, but who
knows!?)
Avoid also calling PyUnicode_CopyCharacters() if the string is empty.
files:
Objects/unicodeobject.c | 34 +++-
1 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/Objects/unicodeobject.c b/Objects/unicodeobject.c
--- a/Objects/unicodeobject.c
+++ b/Objects/unicodeobject.c
@@ -8890,20 +8890,32 @@
/* Catenate everything. */
for (i = 0, res_offset = 0; i seqlen; ++i) {
-Py_ssize_t itemlen;
+Py_ssize_t itemlen, copied;
item = items[i];
+/* Copy item, and maybe the separator. */
+if (i seplen != 0) {
+copied = PyUnicode_CopyCharacters(res, res_offset,
+ sep, 0, seplen);
+if (copied 0)
+goto onError;
+#ifdef Py_DEBUG
+res_offset += copied;
+#else
+res_offset += seplen;
+#endif
+}
itemlen = PyUnicode_GET_LENGTH(item);
-/* Copy item, and maybe the separator. */
-if (i) {
-if (PyUnicode_CopyCharacters(res, res_offset,
- sep, 0, seplen) 0)
+if (itemlen != 0) {
+copied = PyUnicode_CopyCharacters(res, res_offset,
+ item, 0, itemlen);
+if (copied 0)
goto onError;
-res_offset += seplen;
-}
-if (PyUnicode_CopyCharacters(res, res_offset,
- item, 0, itemlen) 0)
-goto onError;
-res_offset += itemlen;
+#ifdef Py_DEBUG
+res_offset += copied;
+#else
+res_offset += itemlen;
+#endif
+}
}
assert(res_offset == PyUnicode_GET_LENGTH(res));
I don't understand this change. Why would you not always add copied once you
already have it? It seems to be the more correct version anyway.
Georg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: fix compiler warnings
Why does the function even return a value? As Benjamin said, it is just a
bunch of asserts with return 1 at the end.
I believe another way you can get rid of statement with no effect is to
cast return value to void, like (void)_PyUnicode_CHECK(unicode).
Thank you,
Vlad
On Tue, Oct 4, 2011 at 4:57 AM, Benjamin Peterson benja...@python.orgwrote:
2011/10/4 Victor Stinner victor.stin...@haypocalc.com:
Le 04/10/2011 01:34, benjamin.peterson a écrit :
http://hg.python.org/cpython/rev/afb60b190f1c
changeset: 72633:afb60b190f1c
user:Benjamin Petersonbenja...@python.org
date:Mon Oct 03 19:34:12 2011 -0400
summary:
fix compiler warnings
+++ b/Objects/unicodeobject.c
@@ -369,6 +369,12 @@
}
return 1;
}
+#else
+static int
+_PyUnicode_CheckConsistency(void *op)
+{
+return 1;
+}
#endif
Oh no, please don't do that. Calling _PyUnicode_CheckConsistency() is
reserved to debug builds. In release mode, we should not check string
consistency (it would slow down Python).
It should be optimized out.
Yes, there was a warning:
Objects/unicodeobject.c:539:13: warning: statement with no effect
_PyUnicode_CHECK(unicode);
I added these checks recently to ensure that strings are consistent just
before exiting (to help me to track down a bug).
The right fix is just to replace _PyUnicode_CHECK(unicode) by
assert(_PyUnicode_CHECK(unicode)).
But _PyUnicode_CheckConsistency is just a string of assertions. What
sense does it make to check the return value?
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/riscutiavlad%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: PyUnicode_Join() checks output length in debug mode
Le 04/10/2011 23:41, Georg Brandl a écrit : I don't understand this change. Why would you not always add copied once you already have it? It seems to be the more correct version anyway. If you use copied instead of seplen/itemlen, you suppose that the string has been overallocated in some cases, and that you have to resize the string (in-place or, more probably, with a copy). Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: fix compiler warnings
Le 05/10/2011 00:30, Vlad Riscutia a écrit : Why does the function even return a value? As Benjamin said, it is just a bunch of asserts with return 1 at the end. It's just to be able to write assert(_PyUnicode_CheckConsistency(...)). assert() is just used to remove the instruction in release mode. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Migrate str.expandtabs to the new API
Le 04/10/2011 18:45, Martin v. Löwis a écrit : Migrate str.expandtabs to the new API This needs if (PyUnicode_READY(self) == -1) return NULL; right after the ParseTuple call. In most cases, the check will be a noop. But if it's not, omitting it will make expandtabs have no effect, since the string length will be 0 (in a debug build, you also get an assertion failure). This make input string ready code path is not well tested because all functions creating strings in unicodeobject.c ensure that the string is ready. I disabled the call to PyUnicode_READY() on result in debug mode in unicodeobject.c (define DONT_MAKE_RESULT_READY). It helped me to fix bugs in various functions, see my commit b66033a0f140. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Optimize string slicing to use the new API
Le 04/10/2011 20:09, Martin v. Löwis a écrit : Am 04.10.11 19:50, schrieb Antoine Pitrou: On Tue, 04 Oct 2011 19:49:09 +0200 Martin v. Löwismar...@v.loewis.de wrote: + result = PyUnicode_New(slicelength, PyUnicode_MAX_CHAR_VALUE(self)); This is incorrect: the maxchar of the slice might be smaller than the maxchar of the input string. I thought that heuristic would be good enough. I'll try to fix it. No - strings must always be in the canonical form. I added a check in _PyUnicode_CheckConsistency() (debug mode) to ensure that newly created strings always use the most efficient storage. For example, PyUnicode_RichCompare considers string unequal if they have different kinds. As a consequence, your slice result may not compare equal to a canonical variant of itself. I see this as a micro-optimization. IMO we should *not* rely on these assumptions because we cannot expect that all developers of third party modules will be able to write perfect code, and some (lazy developers!) may prefer to use a fixed maximum character (e.g. 0x). To be able to rely on such assumption, we have to make sure that strings are in canonical forms (always check before using a string?). But it would slow down Python because you have to scan the whole string to get the maximum characters (see my change in _PyUnicode_CheckConsistency). I would prefer to drop such micro-optimization and tolerate non-canonical strings (strings not using the most efficient storage). Even if PEP 393 is fully backward compatibly (except that PyUnicode_AS_UNICODE and PyUnicode_AsUnicode may now return NULL), it's already a big change (developers may want to move to the new API to benefit of the advantages of the PEP 393), and very few developers understand correctly Unicode. It's safer to see the PEP 393 as a best-effort method. Hopefuly, most (or all?) strings created by Python itself are in canonical form. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
