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
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 no
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
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
_
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 perceiv
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 equ
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.
Eith
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 wit
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 o
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.
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
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 surpri
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
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
>
> 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 n
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 mes
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 deco
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,
b
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 j
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. Th
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 i
21 matches
Mail list logo
