Split unicodeobject.c into subfiles - python-dev

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Split unicodeobject.c into subfiles
Received-SPF: pass (google.com: domain of python-dev-bounces+dev-python+garchive-30976=googlegroups....@python.org designates 2001:888:2000:d::a6 as permitted sender) client-ip=2001:888:2000:d::a6;
Message-ID: <50895731.7040...@hastings.org>
Date: Thu, 25 Oct 2012 08:13:53 -0700
From: Larry Hastings <la...@hastings.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Nick Coghlan <ncogh...@gmail.com>
References: <CAMpsgwbQRZMugSprcM9CQGnraFG39AKpDAz-b1YM2j-ag=1...@mail.gmail.com>
	<CAPZV6o_0hANb7QbnJwF-j7oRak8oCBpvjsp0uvi+3XHWyOA...@mail.gmail.com>
	<k66glu$r1...@ger.gmane.org> <50881178.4010...@hastings.org>
	<CADiSq7dvFyjMBBs3nBJbJTrShkMhDFbrjPXZnJ+b=PHS64z...@mail.gmail.com>
In-Reply-To: <CADiSq7dvFyjMBBs3nBJbJTrShkMhDFbrjPXZnJ+b=PHS64z...@mail.gmail.com>
Cc: python-...@python.org
Subject: Re: [Python-Dev] Split unicodeobject.c into subfiles
Precedence: list
Content-Type: multipart/mixed; boundary="===============1849858665=="
Errors-To: python-dev-bounces+dev-python+garchive-30976=googlegroups....@python.org
Sender: "Python-Dev"
	<python-dev-bounces+dev-python+garchive-30976=googlegroups....@python.org>

This is a multi-part message in MIME format.
--===============1849858665==
Content-Type: multipart/alternative;
 boundary="------------090902030607000000000603"

This is a multi-part message in MIME format.
--------------090902030607000000000603
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


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/

--------------090902030607000000000603
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><br>
      On 10/24/2012 03:15 PM, Nick Coghlan wrote:<br>
    </div>
    <blockquote
cite="mid:CADiSq7dvFyjMBBs3nBJbJTrShkMhDFbrjPXZnJ+b=PHS64z...@mail.gmail.com"
      type="cite">Breaking such files up into separately compiled
      modules serves two purposes:<br>
      <p>
        1. It proves that the code *isn't* a tangled monolithic mess;<br>
        2. It enlists the compilation toolchain's assistance in ensuring
        that remains the case in the future.</p>
    </blockquote>
    <br>
    Either the code is a "tangled monolithic mess" or it isn't.&nbsp; If it
    is, then let's fix that, regardless of the size of the file.&nbsp; If it
    isn't, I don't see breaking up the code among multiple files as
    providing any benefit.&nbsp; And I see no need for the toolchain's
    assistance to help us do something without benefit.&nbsp; The line count
    of the file is essentially unrelated to its inherent quality /
    maintainability.<br>
    <br>
    <br>
    <blockquote
cite="mid:CADiSq7dvFyjMBBs3nBJbJTrShkMhDFbrjPXZnJ+b=PHS64z...@mail.gmail.com"
      type="cite">
      <p>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.</p>
    </blockquote>
    <br>
    I'm all for good software engineering practice.&nbsp; But can you cite
    objective reasons why large source files are provably bad?&nbsp; Not
    "tangled monolithic messes", not poorly-factored code.&nbsp; 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.&nbsp; All I've seen is
    that unicodeobject.c is a large file, and some people want to break
    it up into smaller files.&nbsp; I have yet to see anything but handwaving
    as justification.&nbsp; 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?<br>
    <br>
    Someone proposed breaking up unicodeobject.c into three distinct
    subsystems and putting those in separate files.&nbsp; I still don't
    agree.&nbsp; 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.&nbsp; If this were a genuinely good idea, we should
    consider doing it with every similar object.&nbsp; But nobody is
    proposing that.&nbsp; My guess is because the other files in CPython are
    "small enough".&nbsp; 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.<br>
    <br>
    <br>
    <i>/arry</i><br>
  </body>
</html>

--------------090902030607000000000603--

--===============1849858665==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Python-Dev mailing list
Python-...@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/dev-python%2Bgarchive-30976%40googlegroups.com

--===============1849858665==--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
