On Thu, Oct 25, 2012 at 2:22 PM, Stephen J. Turnbull step...@xemacs.org wrote:
Nick Coghlan writes:
OK, I need to weigh in after seeing this kind of reply. Large source files
are discouraged in general because they're a code smell that points
strongly towards a *lack of modularity*
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
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
On 24 Oct, 2012, at 14:59, Daniel Holth dho...@gmail.com wrote:
On Wed, Oct 24, 2012 at 7:04 AM, Ronald Oussoren ronaldousso...@mac.com
wrote:
On 18 Oct, 2012, at 19:29, Daniel Holth dho...@gmail.com wrote:
I'd like to submit the Wheel PEPs 425 (filename metadata), 426
(Metadata 1.3),
On Thu, Oct 25, 2012 at 8:57 AM, M.-A. Lemburg m...@egenix.com 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.
On 25.10.2012 11:18, Maciej Fijalkowski wrote:
On Thu, Oct 25, 2012 at 8:57 AM, M.-A. Lemburg m...@egenix.com 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,
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
2012/10/24 Guido van Rossum gu...@python.org:
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
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
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
On Thu, Oct 25, 2012 at 8:07 PM, Maciej Fijalkowski fij...@gmail.com 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
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
Mark Lawrence breamore...@yahoo.co.uk 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
On Thu, Oct 25, 2012 at 2:59 AM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
2012/10/24 Guido van Rossum gu...@python.org:
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
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
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
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.
On 25/10/2012 15:06, Stefan Krah wrote:
Mark Lawrence breamore...@yahoo.co.uk 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
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
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
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
On Thu, 25 Oct 2012 08:13:53 -0700
Larry Hastings la...@hastings.org 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
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
23 matches
Mail list logo
