Re: [Python-Dev] Windows 8 support
Another question is whether Python can take advantage of WinRT (the new UI framework). It should be possible, as the new APIs were designed to be used from dynamic languages, but I haven't decided if I'm crazy enough to try it. WinRT certainly sounds like the way to go in the future. I'm glad to hear that .NET isn't going to take over the world after all! I'm not sure whether I prefer Javascript doing that, though :) Eli ___ 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] Not able to do unregister a code
Hi, I am facing a memory leaking issue with codecs. I make my own ABC class and register it with codes. import codecs codecs.register(ABC) but I am not able to remove ABC from memory. Is there any alternative to do that. Thanks ___ 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] Not able to do unregister a code
Below is reference pattern: 0: _ --- [-] 4 size = 6280: 0xa70ca44, 0xa70e79c, 0xe5c602c, 0xe6219bc 1: a [-] 4 tuple: 0xab11c5c*3, 0xe72a43c*3, 0xe73c16c*3, 0xe73c1bc*3 2: aa [-] 4 function: ABC.l_codecs.decode... 3: a3 [S] 2 dict of class: ..Codec, ..Codec 4: aab [-] 4 types.MethodType: ABC at 0x... 5: aaba [-] 2 tuple: 0xe72a2d4*4, 0xe734d24*4 6: aabaa [-] 2 dict (no owner): 0x9b029bc*2, 0xb789f24cL*6 7: aaba3 [S] 1 dict of class: ..ABC 8: aabaab [-] 1 tuple: 0x9b10f8c*2 9: aabaaba [+] 1 function: ABC.__l_codecs On Thu, Sep 15, 2011 at 12:26 PM, Jai Sharma jai.u...@gmail.com wrote: Hi, I am facing a memory leaking issue with codecs. I make my own ABC class and register it with codes. import codecs codecs.register(ABC) but I am not able to remove ABC from memory. Is there any alternative to do that. Thanks ___ 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] Not able to do unregister a code
Jai Sharma wrote: Hi, I am facing a memory leaking issue with codecs. I make my own ABC class and register it with codes. import codecs codecs.register(ABC) but I am not able to remove ABC from memory. Is there any alternative to do that. The ABC codec search function gets added to the codec registry search path list which currently cannot be accessed directly. There is no API to unregister a codec search function, since deregistration would break the codec cache used by the registry to speedup codec lookup. Why would you want to unregister a codec search function ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 15 2011) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2011-10-04: PyCon DE 2011, Leipzig, Germany19 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-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] LZMA compression support in 3.3
Another update - I've added proper documentation. Now the code should be pretty much complete - all that's missing is the necessary bits and pieces to build it on Windows. Cheers, Nadeem ___ 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] Do we have interest in a clang buildbot?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, pals. I am seeing a few commits related to clang (a C compiler, alternative to GCC), but we ¿only? have a buildbot using clang as the compiler. If there is interest, I would deploy 32 and 64 bits buildbots under my current OpenIndiana buildbot. What do you think? - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTnHhl5lgi5GaxT1NAQKlJgQApAwlZODoeG3G+HODkoSh6G5myqEXkS/0 YZM6wo+/uWb6ul50Kb9mWhucGhY1tc8wAxCDNsRcm8Vv/6sDLZOV0G++DIK0JXIw BA8TyF/5CI8c5K3wnrVkazTo/Io1kVYMGc1FekIoQFI3oRKdXs/A6h63XWwxDMNu PsGwVD4bizs= =lJ/r -END PGP SIGNATURE- ___ 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] PEP 393: Porting Guidelines
I added a section on porting guidelines to the PEP, resulting from my own porting experience. Please review. http://www.python.org/dev/peps/pep-0393/#porting-guidelines 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
[Python-Dev] PEP 393: Special-casing ASCII-only strings
In reviewing memory usage, I found potential for saving more memory for
ASCII-only strings. Both Victor and Guido commented that something like
this be done; Antoine had asked whether there was anything that could
be done. Here is the idea:
In an ASCII-only string, the UTF-8 representation is shared with the
canonical one-byte representation. This would allow to drop the
UTF-8 pointer and the UTF-8 length field; instead, a flag in the state
would indicate that these fields are not there.
Likewise, the wchar_t/Py_UNICODE length can be shared (even though the
data cannot), since the ASCII-only string won't contain any surrogate
pairs.
To comply with the C aliasing rules, the structures would look like this:
typedef struct {
PyObject_HEAD
Py_ssize_t length;
union {
void *any;
Py_UCS1 *latin1;
Py_UCS2 *ucs2;
Py_UCS4 *ucs4;
} data;
Py_hash_t hash;
int state; /* may include SSTATE_SHORT_ASCII flag */
wchar_t *wstr;
} PyASCIIObject;
typedef struct {
PyASCIIObject _base;
Py_ssize_t utf8_length;
char *utf8;
Py_ssize_t wstr_length;
} PyUnicodeObject;
Code that directly accesses the structures would become more
complex; code that use the accessor macros wouldn't notice.
As a result, ASCII-only strings would lose three pointers,
and shrink to their 3.2 structure size. Since they also save
in the individual characters, strings with more than
3 characters (16-bit Py_UNICODE) or more than one character
(32-bit Py_UNICODE) would see a total size reduction compared
to 3.2.
Objects created throught the legacy API (PyUnicode_FromUnicode)
that are only later found to be ASCII-only (in PyUnicode_Ready)
would still have the UTF-8 pointer shared with the data pointer,
but keep including separate fields for pointer size.
What do you think?
Regards,
Martin
P.S. There are similar reductions that could be applied
to the wstr_length in general: on 32-bit wchar_t systems,
it could be always dropped, on a 16-bit wchar_t system,
it could be dropped for UCS-2 strings. However, I'm not
proposing these, as I think the increase in complexity
is not worth the savings.
___
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] Packaging in Python 2 anyone ?
Le 13/09/2011 18:34, Michael Foord a écrit : On 13/09/2011 16:57, Éric Araujo wrote: (IIRC PyPI will require us to play games to have both 2.x and 3.x versions of distutils2.) What I'm doing for unittest2. [...] 2) I have a pypi project called unittestpy3k that holds the Python 3 version of unittest2 Projects using unittest2 for Python 3 then have a dependency on unittest2py3k - but the actual Python package name is unittest2. That’s what I call playing games. I think it would make more sense to push 2.x-compatible and 3.x-compatible sdists to PyPI (with an appropriate 'Programming Language :: Python :: 2' or '3' classifier) and have the download tools be smart. Regards ___ 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] Packaging in Python 2 anyone ?
On Thu, Sep 15, 2011 at 12:23 PM, Éric Araujo mer...@netwok.org wrote: I think it would make more sense to push 2.x-compatible and 3.x-compatible sdists to PyPI (with an appropriate 'Programming Language :: Python :: 2' or '3' classifier) and have the download tools be smart. FWIW, I prefer this as well. I'd certainly appreciate the option to do it this way. -Fred -- Fred L. Drake, Jr. fdrake at acm.org A person who won't read has no advantage over one who can't read. --Samuel Langhorne Clemens ___ 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] Packaging in Python 2 anyone ?
+2 for promoting naming consistency and putting metadata where it's supposed to be. --Yuval On Sep 15, 2011 9:23 AM, Éric Araujo mer...@netwok.org wrote: Le 13/09/2011 18:34, Michael Foord a écrit : On 13/09/2011 16:57, Éric Araujo wrote: (IIRC PyPI will require us to play games to have both 2.x and 3.x versions of distutils2.) What I'm doing for unittest2. [...] 2) I have a pypi project called unittestpy3k that holds the Python 3 version of unittest2 Projects using unittest2 for Python 3 then have a dependency on unittest2py3k - but the actual Python package name is unittest2. That’s what I call playing games. I think it would make more sense to push 2.x-compatible and 3.x-compatible sdists to PyPI (with an appropriate 'Programming Language :: Python :: 2' or '3' classifier) and have the download tools be smart. Regards ___ 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/ubershmekel%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] Do we have interest in a clang buildbot?
Jesus Cea j...@jcea.es wrote: I am seeing a few commits related to clang (a C compiler, alternative to GCC), but we ¿only? have a buildbot using clang as the compiler. If there is interest, I would deploy 32 and 64 bits buildbots under my current OpenIndiana buildbot. I think it makes sense. clang has different warnings and the versions = 2.9 apparently optimize extremely aggressively. Probably it would be most useful to run these bots with -O2 (and not --with-pydebug). Stefan Krah ___ 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] Packaging in Python 2 anyone ?
On 15/09/2011 17:23, Éric Araujo wrote: Le 13/09/2011 18:34, Michael Foord a écrit : On 13/09/2011 16:57, Éric Araujo wrote: (IIRC PyPI will require us to play games to have both 2.x and 3.x versions of distutils2.) What I'm doing for unittest2. [...] 2) I have a pypi project called unittestpy3k that holds the Python 3 version of unittest2 Projects using unittest2 for Python 3 then have a dependency on unittest2py3k - but the actual Python package name is unittest2. That’s what I call playing games. I think it would make more sense to push 2.x-compatible and 3.x-compatible sdists to PyPI (with an appropriate 'Programming Language :: Python :: 2' or '3' classifier) and have the download tools be smart. Hah, sure. In the meantime my way works *now* and with the existing tools. :-) (But only actually true for the way I make it available from pypi - the rest of the technique is not playing games, right?) Yes, I would prefer to have a single project name with different distributions for Python 2 and 3 (and I looked into it) - but with the current tools the only way to achieve that is to put both versions into a single distribution. This prevents you from versioning them separately and is a pain to do anyway if the different versions are in different repos. The current tools are a real pain for versioning anyway. If your pypi page even *links* to a page that offers an alpha or beta (in development version) for download then both pip and easy_install will fetch that, in preference to the most recent version on pypi. So yes, I agree there is room for improvement in the current tools. Hopefully distutils2 will fix that. ;-) All the best, Michael Foord Regards ___ 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] PEP 393: Special-casing ASCII-only strings
On 9/15/2011 11:50 AM, Martin v. Löwis wrote:
To comply with the C aliasing rules, the structures would look like this:
typedef struct {
PyObject_HEAD
Py_ssize_t length;
union {
void *any;
Py_UCS1 *latin1;
Py_UCS2 *ucs2;
Py_UCS4 *ucs4;
} data;
Py_hash_t hash;
int state; /* may include SSTATE_SHORT_ASCII flag */
wchar_t *wstr;
} PyASCIIObject;
typedef struct {
PyASCIIObject _base;
Py_ssize_t utf8_length;
char *utf8;
Py_ssize_t wstr_length;
} PyUnicodeObject;
Code that directly accesses the structures would become more
complex; code that use the accessor macros wouldn't notice.
...
What do you think?
That nearly all code outside CPython itself should treat the unicode
types, especially, as opaque types and only access instances through
functions and macros -- the 'public' interfaces. We need to be free to
fiddle with internal implementation details as experience suggests changes.
P.S. There are similar reductions that could be applied
to the wstr_length in general: on 32-bit wchar_t systems,
it could be always dropped, on a 16-bit wchar_t system,
it could be dropped for UCS-2 strings. However, I'm not
proposing these, as I think the increase in complexity
is not worth the savings.
I would certainly do just the one change now and see how it goes. I
think you should be free to do more like the above if you change your
mind with experience.
--
Terry Jan Reedy
___
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] PEP 393: Special-casing ASCII-only strings
On Thu, Sep 15, 2011 at 8:50 AM, Martin v. Löwis mar...@v.loewis.de wrote:
In reviewing memory usage, I found potential for saving more memory for
ASCII-only strings. Both Victor and Guido commented that something like
this be done; Antoine had asked whether there was anything that could
be done. Here is the idea:
In an ASCII-only string, the UTF-8 representation is shared with the
canonical one-byte representation. This would allow to drop the
UTF-8 pointer and the UTF-8 length field; instead, a flag in the state
would indicate that these fields are not there.
Likewise, the wchar_t/Py_UNICODE length can be shared (even though the
data cannot), since the ASCII-only string won't contain any surrogate
pairs.
To comply with the C aliasing rules, the structures would look like this:
typedef struct {
PyObject_HEAD
Py_ssize_t length;
union {
void *any;
Py_UCS1 *latin1;
Py_UCS2 *ucs2;
Py_UCS4 *ucs4;
} data;
Py_hash_t hash;
int state; /* may include SSTATE_SHORT_ASCII flag */
wchar_t *wstr;
} PyASCIIObject;
typedef struct {
PyASCIIObject _base;
Py_ssize_t utf8_length;
char *utf8;
Py_ssize_t wstr_length;
} PyUnicodeObject;
Code that directly accesses the structures would become more
complex; code that use the accessor macros wouldn't notice.
As a result, ASCII-only strings would lose three pointers,
and shrink to their 3.2 structure size. Since they also save
in the individual characters, strings with more than
3 characters (16-bit Py_UNICODE) or more than one character
(32-bit Py_UNICODE) would see a total size reduction compared
to 3.2.
Objects created throught the legacy API (PyUnicode_FromUnicode)
that are only later found to be ASCII-only (in PyUnicode_Ready)
would still have the UTF-8 pointer shared with the data pointer,
but keep including separate fields for pointer size.
What do you think?
Regards,
Martin
P.S. There are similar reductions that could be applied
to the wstr_length in general: on 32-bit wchar_t systems,
it could be always dropped, on a 16-bit wchar_t system,
it could be dropped for UCS-2 strings. However, I'm not
proposing these, as I think the increase in complexity
is not worth the savings.
This sounds like a good plan.
--
--Guido van Rossum (python.org/~guido)
___
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] PEP 393: Special-casing ASCII-only strings
Le jeudi 15 septembre 2011 17:50:41, Martin v. Löwis a écrit :
In reviewing memory usage, I found potential for saving more memory for
ASCII-only strings. (...)
typedef struct {
PyObject_HEAD
Py_ssize_t length;
union {
void *any;
Py_UCS1 *latin1;
Py_UCS2 *ucs2;
Py_UCS4 *ucs4;
} data;
Py_hash_t hash;
int state; /* may include SSTATE_SHORT_ASCII flag */
wchar_t *wstr;
} PyASCIIObject;
I like it. If we start which such optimization, we can also also remove data
from strings allocated by the new API (it can be computed: object pointer +
size of the structure). See my email for my proposition of structures:
Re: [Python-Dev] PEP 393 review
Thu Aug 25 00:29:19 2011
You may reorganize fields to be able to cast PyUnicodeObject to PyASCIIObject.
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] PEP 393: Special-casing ASCII-only strings
I like it. If we start which such optimization, we can also also remove data from strings allocated by the new API (it can be computed: object pointer + size of the structure). See my email for my proposition of structures: Re: [Python-Dev] PEP 393 review Thu Aug 25 00:29:19 2011 I agree it is tempting to drop the data pointer. However, I'm not sure how many different structures we would end up with, and how the aliasing rules would defeat this (you cannot interpret a struct X* as a struct Y*, unless either X is the first field of Y or vice versa). Thinking about this, the following may work: - ASCIIObject: state, length, hash, wstr*, data follow - SingleBlockUnicode: ASCIIObject, wstr_len, utf8*, utf8_len, data follow - UnicodeObject: SingleBlockUnicode, data pointer, no data follow This is essentially your proposal, except that the wstr_len is dropped for ASCII strings, and that it uses nested structs. The single-block variants would always be ready, the full unicode object is ready only if the data pointer is set. I'll try it out, unless somebody can punch a hole into this proposal :-) 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] PEP 393: Special-casing ASCII-only strings
On Fri, Sep 16, 2011 at 7:39 AM, Martin v. Löwis mar...@v.loewis.de wrote: Thinking about this, the following may work: - ASCIIObject: state, length, hash, wstr*, data follow - SingleBlockUnicode: ASCIIObject, wstr_len, utf8*, utf8_len, data follow - UnicodeObject: SingleBlockUnicode, data pointer, no data follow This is essentially your proposal, except that the wstr_len is dropped for ASCII strings, and that it uses nested structs. The single-block variants would always be ready, the full unicode object is ready only if the data pointer is set. In your UnicodeObject here, is the 'data pointer' the any/latin1/ucs2/ucs4 union from the original structure definition? Also, what are the constraints on the SingleBlockUnicode? Does it only hold strings that can be represented in latin1? Or can the size of the individual elements be more than 1 byte? 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
[Python-Dev] Meta coding in Python
Hi list, I thought it would be nice in Python to allow some sort of meta coding (which goes far ahead of simple function descriptors). The most straight forward way would be to allow operations on the AST. I wrote a small patch for CPython 2.7.1 which, for each code object, adds the related AST of the statement to a new attribute `co_ast`. https://github.com/albertz/CPython/commit/2670e621458fd80311fc02897b698ea2a36d494b Some simple demonstration of what you can do with this: https://github.com/albertz/CPython/blob/astcompile_patch/test_co_ast.py I'm not sure wether the Python AST in this form is optimal for doing such things, though. Maybe another representation would be more efficient and result in simpler code for doing transformations. Discussion about this is very welcome. Regards, Albert ___ 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] Meta coding in Python
2011/9/15 Albert Zeyer alb...@googlemail.com: Hi list, I thought it would be nice in Python to allow some sort of meta coding (which goes far ahead of simple function descriptors). The most straight forward way would be to allow operations on the AST. I wrote a small patch for CPython 2.7.1 which, for each code object, adds the related AST of the statement to a new attribute `co_ast`. https://github.com/albertz/CPython/commit/2670e621458fd80311fc02897b698ea2a36d494b Some simple demonstration of what you can do with this: https://github.com/albertz/CPython/blob/astcompile_patch/test_co_ast.py I'm not sure wether the Python AST in this form is optimal for doing such things, though. Maybe another representation would be more efficient and result in simpler code for doing transformations. It would be useful, but is a waste of memory is 99.99% of programs. -- 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] Meta coding in Python
On Fri, Sep 16, 2011 at 8:44 AM, Albert Zeyer alb...@googlemail.com wrote: Hi list, I thought it would be nice in Python to allow some sort of meta coding (which goes far ahead of simple function descriptors). The most straight forward way would be to allow operations on the AST. 1. This kind of suggestion is more appropriately directed to python-ideas 2. We already support this, look at the ast module and in particular the ast.PyCF_ONLY_AST flag to the compile() builtin function. For an example of advanced usage, look at the py.test module and it's meta-importer that rewrites assert statements Regards, 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] PEP 393: Special-casing ASCII-only strings
Am 16.09.11 00:42, schrieb Nick Coghlan: On Fri, Sep 16, 2011 at 7:39 AM, Martin v. Löwis mar...@v.loewis.de wrote: Thinking about this, the following may work: - ASCIIObject: state, length, hash, wstr*, data follow - SingleBlockUnicode: ASCIIObject, wstr_len, utf8*, utf8_len, data follow - UnicodeObject: SingleBlockUnicode, data pointer, no data follow This is essentially your proposal, except that the wstr_len is dropped for ASCII strings, and that it uses nested structs. The single-block variants would always be ready, the full unicode object is ready only if the data pointer is set. In your UnicodeObject here, is the 'data pointer' the any/latin1/ucs2/ucs4 union from the original structure definition? Yes, it is. I'm considering dropping the union again, since you'll have to cast the data pointer anyway in the compact cases. Also, what are the constraints on the SingleBlockUnicode? Does it only hold strings that can be represented in latin1? Or can the size of the individual elements be more than 1 byte? Any size - what matters is whether the maximum character is known at creation time (i.e. whether you've used PyUnicode_New(size, maxchar) or PyUnicode_FromUnicode(NULL, size)). In the latter case, a Py_UNICODE block will be allocated in wstr, and the data pointer left NULL. Then, when PyUnicode_Ready is called, the maxmimum character is determined in the Py_UNICODE block, and a new data block allocated - but that will have to be a second memory block (the Py_UNICODE block is then dropped in _Ready). 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
