Re: [Python-Dev] Split unicodeobject.c into subfiles
On 25.10.2012 08:42, Nick Coghlan wrote: > unicodeobject.c is too big, and should be restructured to make any > natural modularity explicit, and provide an easier path for users that > want to understand how the unicode implementation works. You can also achieve that goal by structuring the code in unicodeobject.c in a more modular way. It is already structured in sections, but there's always room for improvement, of course. As mentioned before, it is impossible to split out various sections into separate .c or .h files which then get included in the main unicodeobject.c. If that's where consensus is going, I'm with Stephen here in that such a separation should be done in higher level chunks, rather than creating >10 new files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 25 2012) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2012-09-27: Released eGenix PyRun 1.1.0 ... http://egenix.com/go35 2012-09-26: Released mxODBC.Connect 2.0.1 ... http://egenix.com/go34 2012-10-29: PyCon DE 2012, Leipzig, Germany ... 4 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] accept the wheel PEPs 425, 426, 427
On 24 Oct, 2012, at 14:59, Daniel Holth wrote:
> On Wed, Oct 24, 2012 at 7:04 AM, Ronald Oussoren
> wrote:
>>
>> On 18 Oct, 2012, at 19:29, Daniel Holth wrote:
>>
>>> I'd like to submit the Wheel PEPs 425 (filename metadata), 426
>>> (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has
>>> been stable since May and we are preparing a patch to support it in
>>> pip, but we need to earn consensus before including it in the most
>>> widely used installer.
>>
>> PEP 425:
>>
>> * "The version is py_version_nodot. CPython gets away with no dot, but if
>> one is needed the underscore _ is used instead"
>>
>> I don't particularly like replacing dots by underscores. That needed
>> because you use the dot character in compressed tag sets, but why not use a
>> comma to separate items in the compressed tag set?
>
>> * "The platform tag is simply distutils.util.get_platform() with all hyphens
>> - and periods . replaced with underscore _."
>>
>> Why the replacement? The need for replacement could be avoided by using a
>> different separator between elements of a tag (for example "~" or "+"), and
>> furthermore the platform tag is at a know
>> location, and hence the use of hyphens in the platform tag is harmless
>> (use "python_tag, abi_tag, platform_tag = tag.split('-', 2)" to split the
>> tag into its elements.
>
> This is based on the longstanding convention of folding - and _
> (hyphen and underscore) in built distribution filenames and using - to
> separate parts.
AFAIK distutils and setuptools do not replace hyphens in the platform name in
the name of bdist files.
>
>> * "compressed tag sets"
>>
>> Using '"," instead of "." to separate elements of the tag set takes away
>> the need to replace dots in tag elements, and seems more natural to me
>> (you'd also use comma to separate the elements
>> when you write them down in prose or python code.
>
> I kindof like the ,
>
> The + might transform into a space in URLs?
You're right, + is not a good choice because that character must be quoted in
URLs.
Ronald
___
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] Split unicodeobject.c into subfiles
On Thu, Oct 25, 2012 at 8:57 AM, M.-A. Lemburg wrote: > On 25.10.2012 08:42, Nick Coghlan wrote: >>> Why are any of these codecs here in unicodeobjectland in the first >>> place? Sure, they're needed so that Python can find its own stuff, >>> but in principle *any* codec could be needed. Is it just an heuristic >>> that the codecs needed for 99% of the world are here, and other codecs >>> live in separate modules? >> >> I believe it's a combination of history and whether or not they're >> needed by the interpreter during the bootstrapping process before the >> encodings namespace is importable. > > They are in unicodeobject.c so that the compilers can inline the > code in the various other places where they are used in the Unicode > implementation directly as necessary and because the codecs use > a lot of functions from the Unicode API (obviously), so the other > direction of inlining (Unicode API in codecs) is needed as well. I'm sorry to interrupt, but have you actually measured? What effect the lack of said inlining has on *any* benchmark is definitely beyond my ability to guess and I suspect is beyond the ability to guess of anyone else on this list. I challenge you to find a benchmark that is being significantly affected (>15%) with the split proposed by Victor. It does not even have to be a real-world one, although that would definitely buy it more credibility. Cheers, fijal ___ 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] Split unicodeobject.c into subfiles
On 25.10.2012 11:18, Maciej Fijalkowski wrote: > On Thu, Oct 25, 2012 at 8:57 AM, M.-A. Lemburg wrote: >> On 25.10.2012 08:42, Nick Coghlan wrote: Why are any of these codecs here in unicodeobjectland in the first place? Sure, they're needed so that Python can find its own stuff, but in principle *any* codec could be needed. Is it just an heuristic that the codecs needed for 99% of the world are here, and other codecs live in separate modules? >>> >>> I believe it's a combination of history and whether or not they're >>> needed by the interpreter during the bootstrapping process before the >>> encodings namespace is importable. >> >> They are in unicodeobject.c so that the compilers can inline the >> code in the various other places where they are used in the Unicode >> implementation directly as necessary and because the codecs use >> a lot of functions from the Unicode API (obviously), so the other >> direction of inlining (Unicode API in codecs) is needed as well. > > I'm sorry to interrupt, but have you actually measured? What effect > the lack of said inlining has on *any* benchmark is definitely beyond > my ability to guess and I suspect is beyond the ability to guess of > anyone else on this list. > > I challenge you to find a benchmark that is being significantly > affected (>15%) with the split proposed by Victor. It does not even > have to be a real-world one, although that would definitely buy it > more credibility. I think you misunderstood. What I described is the reason for having the base codecs in unicodeobject.c. I think we all agree that inlining has a positive effect on performance. The scale of the effect depends on the used compiler and platform. Victor already mentioned that he'll check the impact of his proposal, so let's wait for that. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 25 2012) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2012-09-27: Released eGenix PyRun 1.1.0 ... http://egenix.com/go35 2012-09-26: Released mxODBC.Connect 2.0.1 ... http://egenix.com/go34 2012-10-29: PyCon DE 2012, Leipzig, Germany ... 4 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] Split unicodeobject.c into subfiles
On 25.10.12 12:18, Maciej Fijalkowski wrote: I challenge you to find a benchmark that is being significantly affected (>15%) with the split proposed by Victor. It does not even have to be a real-world one, although that would definitely buy it more credibility. I see 10% slowdown for UTF-8 decoding for UCS2 strings, but 10% speedup for mostly-BMP UCS4 strings. For encoding the situation is reversed (but up to +27%). Charmap decoding speedups 10-30%. GCC 4.4.3, 32-bit Linux. https://bitbucket.org/storchaka/cpython-stuff/src/default/bench ___ 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] Some joker is trying to unsubscribe me
2012/10/24 Guido van Rossum : > I've received three messages in the past hour from mailman at > python.org notifying me of various attempts to receive a password > reminder or to remove me from python-dev. I hope they don't succeed. That's probably because most of your replies contain the full message, which contains the "Unsubscribe" link, and some stupid bot followed it. See the one below for my account. Please don't click it! > > -- > --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/amauryfa%40gmail.com -- 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] Split unicodeobject.c into subfiles
> > I think you misunderstood. What I described is the reason for having > the base codecs in unicodeobject.c. > > I think we all agree that inlining has a positive effect on > performance. The scale of the effect depends on the used compiler > and platform. > Well. Inlining can have positive or negative effects, depending on various details. Too much inlining causes more cache misses for example. However, this is absolutely irrelevant if you don't create benchmarks and run them. Guessing is seriously not a very good optimization strategy. Cheers, fijal ___ 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] Split unicodeobject.c into subfiles
On 25.10.12 12:49, M.-A. Lemburg wrote: I think you misunderstood. What I described is the reason for having the base codecs in unicodeobject.c. For example PyUnicode_FromStringAndSize and PyUnicode_FromString are thin wrappers around PyUnicode_DecodeUTF8Stateful. I think this is a reason to keep this functions together. ___ 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] Split unicodeobject.c into subfiles
On Thu, Oct 25, 2012 at 8:07 PM, Maciej Fijalkowski wrote: >> >> I think you misunderstood. What I described is the reason for having >> the base codecs in unicodeobject.c. >> >> I think we all agree that inlining has a positive effect on >> performance. The scale of the effect depends on the used compiler >> and platform. >> > > Well. Inlining can have positive or negative effects, depending on > various details. Too much inlining causes more cache misses for > example. However, this is absolutely irrelevant if you don't create > benchmarks and run them. Guessing is seriously not a very good > optimization strategy. Yep, that's why I made the point that speed.python.org should be a going concern well before 3.4 release, and will be able to let us know if we have a problem relative to 3.3. 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] Fwd: Python 3.3 can't sort memoryviews as they're unorderable
On 24/10/2012 13:19, Nick Coghlan wrote: (Oops, originally replied only to Mark) Is a 3x3 array greater or less than a 2x4 array or another 3x3 array? The contents of a 1D memory view may be sortable, but the "logical structure" part isn't, and neither is any multi-dimensional view. I'm surprised by the lack of inheritance support though - is that a regression from 3.2? If yes, that's definitely a bug to be fixed in a 3.3 maintenance release, otherwise it's probably a feature request for 3.4. Cheers, Nick. -- Sent from my phone, thus the relative brevity :) The lack of inheritance support is the same in Python 2.7.3 so I doubt that there's any change there. Quoting Nick Coghlan from http://bugs.python.org/issue15622#msg167957 "PEP 3118 contains way too many errors (as has been found out the hard way) to be considered a normative document.". I can't say that this gives me a great deal of confidence. It strikes me that a lot of code has been written, tested and released without having anything like a requirement. For example when is any given memoryview equal to or not equal to any other memoryview? -- Cheers. Mark Lawrence. ___ 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] Fwd: Python 3.3 can't sort memoryviews as they're unorderable
Mark Lawrence wrote: > I can't say that this gives me a great deal of confidence. It strikes me > that a lot of code has been written, tested and released without having > anything like a requirement. For example when is any given memoryview > equal to or not equal to any other memoryview? A lot of documentation has been written and released as well. Use it. In case you don't know: If a PEP and the current documentation diverge, the documentation takes precedence. 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] Some joker is trying to unsubscribe me
On Thu, Oct 25, 2012 at 2:59 AM, Amaury Forgeot d'Arc wrote: > 2012/10/24 Guido van Rossum : >> I've received three messages in the past hour from mailman at >> python.org notifying me of various attempts to receive a password >> reminder or to remove me from python-dev. I hope they don't succeed. > > That's probably because most of your replies contain the full message, > which contains the "Unsubscribe" link, and some stupid bot followed it. > > See the one below for my account. Please don't click it! Or, more likely, someone *else* posted that link in their quoting of my message. Good hypothesis! -- --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] Split unicodeobject.c into subfiles
Le 25/10/2012 02:03, Nick Coghlan a écrit : speed.python.org is also making progress, and once that is up and running (which will happen well before any Python 3.4 release) it will be possible to compare the numbers between 3.3 and trunk to help determine the validity of any concerns regarding optimisations that can be performed within a module but not across modules. Nobody needs speed.python.org to run benchmarks before and after a specific change, though. Cloning http://hg.python.org/benchmarks and using the perf.py runner is everything that is needed. Moreover, you would want to run benchmarks *before* committing and pushing the changes. We don't want the huge splitting to be recorded and then backed out in the repository history. 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] Split unicodeobject.c into subfiles
Le 25/10/2012 00:15, Nick Coghlan a écrit : However, -1 on the "faux modularity" idea of breaking up the files on disk, but still exposing them to the compiler and linker as a monolithic block, though. That would be completely missing the point of why large source files are bad. I disagree with you. Source files are meant to be read by humans, we don't really care whether the compiler has a modular view of the source code. 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] Split unicodeobject.c into subfiles
On 10/24/2012 03:15 PM, Nick Coghlan wrote: Breaking such files up into separately compiled modules serves two purposes: 1. It proves that the code *isn't* a tangled monolithic mess; 2. It enlists the compilation toolchain's assistance in ensuring that remains the case in the future. Either the code is a "tangled monolithic mess" or it isn't. If it is, then let's fix that, regardless of the size of the file. If it isn't, I don't see breaking up the code among multiple files as providing any benefit. And I see no need for the toolchain's assistance to help us do something without benefit. The line count of the file is essentially unrelated to its inherent quality / maintainability. We are not special snow flakes - good software engineering practice is advisable for us as well, so a big +1 from me for breaking up the monstrosity that is unicodeobject.c and lowering the barrier to entry for hacking on the individual pieces. This should come with a large block comment in unicodeobject.c explaining how the pieces are put back together again. I'm all for good software engineering practice. But can you cite objective reasons why large source files are provably bad? Not "tangled monolithic messes", not poorly-factored code. I agree that those are bad--but so far nobody has proposed that either of those is true about unicodeobject.c (unless you are implicitly doing so above), nor have they proposed credible remedies. All I've seen is that unicodeobject.c is a large file, and some people want to break it up into smaller files. I have yet to see anything but handwaving as justification. For example, what is this barrier to entry you suggest exists to hacking on the str object, that will apparently be dispelled simply by splitting one file into multiple files? Someone proposed breaking up unicodeobject.c into three distinct subsystems and putting those in separate files. I still don't agree. It seems natural to me to have everything associated with the str object in one file, just as we do with every other object I can think of. If this were a genuinely good idea, we should consider doing it with every similar object. But nobody is proposing that. My guess is because the other files in CPython are "small enough". At which point we're right back to the primary motivation simply being the line count of unicodeobject.c, as a purely aesthetic and subjective judgment. //arry/ ___ 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] Fwd: Python 3.3 can't sort memoryviews as they're unorderable
On 25/10/2012 15:06, Stefan Krah wrote: Mark Lawrence wrote: I can't say that this gives me a great deal of confidence. It strikes me that a lot of code has been written, tested and released without having anything like a requirement. For example when is any given memoryview equal to or not equal to any other memoryview? A lot of documentation has been written and released as well. Use it. In case you don't know: If a PEP and the current documentation diverge, the documentation takes precedence. Stefan Krah Thanks for completely snipping the context that I gave, it gives me the sense that my bodyline tactics have you on the back foot. The documentation states "__eq__(exporter) A memoryview and a PEP 3118 exporter are equal if their shapes are equivalent and if all corresponding values are equal when the operands’ respective format codes are interpreted using struct syntax.". Where is the requirement that states this is all that the implementation provides? In the savaged PEP 3118? Why can't I have a situation such that two memoryviews that I've created that meet the criteria above shouldn't be tested using the other comparison operators? I'm guessing that I've missed something that's blatantly obvious to everybody except myself. I can't find a rationale anywhere as to why I can't subclass memoryviews for my code, so I can't work around what I perceive as a glaring deficiency. Is it a case whereby even consenting adults aren't allowed? This strikes me as so different to the Python that I've been using for the last 10 years that it stood out, at least to me, like a sore thumb. Perhaps I need yet another visit to the opticians? -- Cheers. Mark Lawrence. ___ 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] Fwd: Python 3.3 can't sort memoryviews as they're unorderable
On 26/10/12 02:57, Mark Lawrence complained that he can't subclass memoryviews: I'm guessing that I've missed something that's blatantly obvious to everybody except myself. I can't find a rationale anywhere as to why I can't subclass memoryviews for my code, so I can't work around what I perceive as a glaring deficiency. Is it a case whereby even consenting adults aren't allowed? This strikes me as so different to the Python that I've been using for the last 10 years that it stood out, at least to me, like a sore thumb. Perhaps I need yet another visit to the opticians? Possibly. There are many things that you can't subclass in Python. NoneType NotImplementedType Ellipsis functions slices frames tracebacks and probably others. As annoying as it is when you run into something like this, it's hardly without precedent. Hell, for about half of Python's existence, you couldn't even subtype basic types like int, str and list! Subclassing is not the only way to add functionality to a class. While it is much less convenient with new-style classes than classic classes, why don't you try delegation? Actually, since the problem you are trying to solve is to sort a list of memoryviews, you don't even need delegation. You just need a dirt-simple key function. py> mv = memoryview py> x = list(map(mv, (b'xyz', b'abc', b'pqr'))) py> x.sort(key=lambda x: x.obj) py> [a.obj for a in x] [b'abc', b'pqr', b'xyz'] What was the problem again? :) -- Steven ___ 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] Who I am
Hello pythoners! I am Jose Figueroa from Mexico. I work usually with C/C++, Ruby and PHP (yeah I know =( ) but I will start again with python because I got some free time after finishing a project. I gonna use python for my Master Degree in Computer Sciences. Thanks Jose Figueroa ___ 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] Who I am
Hello. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you are going to only use Python but not develop it probably python-list/comp.lang.python mailing list/news group is the best place. See http://www.python.org/community/ In any case -- welcome! On Thu, Oct 25, 2012 at 12:38:40PM -0500, Jose Figueroa wrote: > Hello pythoners! > > I am Jose Figueroa from Mexico. I work usually with C/C++, Ruby and > PHP (yeah I know =( ) but I will start again with python because I > got some free time after finishing a project. > > I gonna use python for my Master Degree in Computer Sciences. > > Thanks > Jose Figueroa Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Split unicodeobject.c into subfiles
On Thu, 25 Oct 2012 08:13:53 -0700 Larry Hastings wrote: > > I'm all for good software engineering practice. But can you cite > objective reasons why large source files are provably bad? Not "tangled > monolithic messes", not poorly-factored code. I agree that those are > bad--but so far nobody has proposed that either of those is true about > unicodeobject.c (unless you are implicitly doing so above) Well, "tangled monolithic mess" is quite true about unicodeobject.c, IMO. Seriously, I agree with Victor: navigating around unicodeobject.c is a PITA. Perhaps it isn't if you are using emacs, or you have 35 fingers, or just a lot of spare time, but in my experience it's painful. 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] Split unicodeobject.c into subfiles
Antoine Pitrou writes: > Well, "tangled monolithic mess" is quite true about unicodeobject.c, > IMO. s/object.c// and your point remains valid. Just reading the table of contents for UTR#17 (http://www.unicode.org/reports/tr17/) should convince you that it's not going to be easy to produce an elegant implementation! > Seriously, I agree with Victor: navigating around unicodeobject.c is a > PITA. Perhaps it isn't if you are using emacs, or you have 35 fingers, > or just a lot of spare time, but in my experience it's painful. Sure, but I don't know of a Unicode implementation which isn't. I don't think that having a unicode/*.[ch] with a dozen files (including the README etc) in it is going to make it much more navigable. If there are too many files, it's going to be a PITA to maintain because there won't be an obvious place to put certain functions. Eg, I've already mentioned my suspicions about the charmap code (I apologize for not reading Victor's code to confirm them). I don't object in principle to splitting the unicodeobject.c. At the very least, with all due respect to MAL, XEmacs experience with coding systems (the Emacs equivalent of Python codecs) suggests that there is very little to be lost by moving the codec implementations to a separate file from the Unicode object implementation. (Here I'm talking about codecs in the narrow sense of wire-format to Python3 str and back, not the more general Python2 sense that included zip and base64 and so on. Ie, PyUnicode_Translate is not a codec in the relevant sense.) On the other hand, I wouldn't be surprised if (despite my earlier suggestion) codecs and unicode object internals need a close relationship. (My intuition and sense of style says splitting codecs from the low level memory management and PEP 393 stuff is a good idea, but I'm not confident it would have no impact on performance.) ___ 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
