Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!tudelft.nl!txtfeed1.tudelft.nl!multikabel.net!newsfeed20.multikabel.net!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Newsgroups: comp.lang.python
Date: Sat, 7 Jan 2012 07:43:56 -0800 (PST)
In-Reply-To: <mailman.4424.1325708545.27778.python-list@python.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=1.168.129.131; posting-account=5JdMBQoAAABHnS4mjpqEzxnmWtgiiVNw
References: <CAOFf2a0dG1tR1-2sJnqCCGqVXocqvzGScGeDJXeXwKdfdvuT-Q@mail.gmail.com> <jdvovs$iri$1@dough.gmane.org> <CABicbJ+jQ7e7FD+2waKVS5F5-WwQCykTUh=h4Y=mE_0Pjep_2g@mail.gmail.com> <jdvsor$dha$1@dough.gmane.org> <CABicbJKO_2iN-B4+B8O81qEFqeVQ85s_CUa70U0s9JWnrPTYgQ@mail.gmail.com> <je0s2j$2k6$1@dough.gmane.org> <mailman.4424.1325708545.27778.python-list@python.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Subject: Re: python philosophical question - strong vs duck typing
From: 88888 Dihedral <dihedral88888@googlemail.com>
To: comp.lang.python@googlegroups.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: python-list@python.org
Precedence: list
Reply-To: comp.lang.python@googlegroups.com
Message-ID: <mailman.4514.1325951044.27778.python-list@python.org>
Lines: 60
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:18648

Terry Reedy=E6=96=BC 2012=E5=B9=B41=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=9B=9BUTC+8=E4=B8=8A=E5=8D=884=E6=99=8222=E5=88=8603=E7=A7=92=E5=AF=AB=E9=
=81=93=EF=BC=9A
> On 1/4/2012 1:37 AM, Terry Reedy wrote:
> > On 1/3/2012 8:04 PM, Devin Jeanpierre wrote:
>=20
> >> [ An example of a simple dependently typed program:
> >> http://codepad.org/eLr7lLJd ]
> >
> > Just got it after a minute delay.
>=20
> A followup now that I have read it. Removing the 40 line comment, the=20
> function itself is
>=20
> fun getitem{n,m:nat}(arr : array(int, n) ,
>   length : int(n), index : int m) : int =3D
>      if index < length then
>          arr[index]
>      else
>          ~1 (* -1, error *)
>=20
> where n,m are compiler variables used to define the dependent=20
> (paramaterized) types array(int,n) and int(n)/ The double use of n means=
=20
> that the compiler checks that length n of the array equals the length=20
> passed.
>=20
> My response: in Python, there is no need to pass concrete collection=20
> sizes because they are packaged with the collection at runtime as an=20
> attribute. So:
>=20
> 1) In Python, there is no need for such checking. In addition, the=20
> for-loop construct, 'for item in iterable:', removes the possibility of=
=20
> indexing errors.
>=20
> 2) Python classes are, in a sense, or in effect, runtime dependent=20
> types. While the formal implementation type of a 'list' is just 'list',=
=20
> the effective computation type is 'mutable sequence of length n'. The=20
> type of an iterator is 'read-only sequence of indefinite length'. I find=
=20
> this an interesting way to look at Python.

Also it is easy to turn an indexed object to be an iterator by a
function decorator that returns a generator in the object level=20
without declaring a new class from a class written by others.

Thus this can lead to  a decoupled design of software among many contributo=
rs
in an elegant way. =20

I prefer a factorized decoupled blocks of modules to be completed=20
by several programmers to build a package. =20


>=20
> --=20
> Terry Jan Reed