Re: [Python-Dev] Adding NewType() to PEP 484

2016-06-01 Thread rndblnch
Nick Coghlan  gmail.com> writes:
> On 31 May 2016 3:12 pm, "Glenn Linderman" <v+python  g.nevcal.com> wrote:
> > On 5/31/2016 12:55 PM, rndblnch wrote:
> >> Guido van Rossum  gmail.com> writes:
> >>
> >>>
> >>> Also -- the most important thing.  What to call these things?

[...]

> > Interesting! Prior art. And parallel type isn't a bad name...
> If I heard "parallel type", I'd assume it had something to do with
parallel processing.

sure, it was 15 years ago, parallel processing was not so widely widespread.

but looking at synonyms for parallel, i stumbed upon: counterpart, analog,
miror, etc.
and then from here: countertype ...

my 2 cents.
renaud

[...]
> Cheers,
> Nick.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Adding NewType() to PEP 484

2016-05-31 Thread rndblnch
Guido van Rossum  gmail.com> writes:

> 
> Also -- the most important thing.  What to call these things? We're
> pretty much settled on the semantics and how to create them (A =
> NewType('A', int)) but what should we call types like A when we're
> talking about them? "New types" sounds awkward.

back in high school, i was introduced to c programming with the "disciplined
C" preprocessor [0].
it made the distinction between information type and representation type
(e.g. between the semantic and the implementation).
those new types where created using typedefs and were named 'parallel types'
below is the relevant part of the dcc presentation:

"""
a major innovation of Disciplined C is the notion of "parallel type", that
allows a distinction between information type and representation type. The
following:

typedef int Tindex, Tval;
typedef Tindex Trow, Tcol;

creates four distinct types, but which all accept the same operations and
the same constants as the "representation" type ('int' here). Tindex, Tval,
Trow and Tcol are examples of "information" types, because they convey an
idea of the semantics of the corresponding objects. For example, they may be
put to use in a checkers playing program: Tval will name 'int's that
represent values of checkers, Trow and Tcol, 'int's that represent row and
column indexes, Tindex, generic type for indexes.
Tindex, Tval, Trow and Tcol are called parallel types; in fact, a type T1 is
said to be parallel to a type T2 iff both are defined through a chain of
typedefs starting from the same 'baseType', with no intervening qualifier
nor modifier (pointer/array/function decla- rator, see grammar in Appendix
A). In other words, T and T2 must be strict synonyms of baseType.
"""

renaud

0. Disciplined C

ACM SIGPLAN Notices Homepage archive
Volume 30 Issue 12, Dec. 1995
Pages 43 - 50
http://dl.acm.org/citation.cfm?id=219726.219747
http://www.digiater.nl/openvms/freeware/v50/dcc/dcc-v2_7d/dccarticle.ps

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Let's get PEP 380 into Python 3.3

2011-03-25 Thread rndblnch
rndblnch rndblnch at gmail.com writes:
 Now that I have figured out how to use patch queues with bitbucket, I will
 maintain greg's pep380 implementation as a patch on top of cpython here:
 https://bitbucket.org/rndblnch/cpython-pep380/

snip

 The patch is now visible here:
 https://bitbucket.org/rndblnch/cpython-pep380/qseries?
apply=tqs_apply=pep380

There is a bug (acknowledged by bitbucket) preventing this page to display the
patch.
The error message is misleading, it states that the patch pep380 did not apply
cleanly but the problem is with bitbucket patching mechanism, not with the
patch.

The raw path is visible there:
https://bitbucket.org/rndblnch/cpython-pep380/src/tip/pep380
and I have documented how to use it on the wiki:
https://bitbucket.org/rndblnch/cpython-pep380/wiki/

I will stop spamming python-dev now...
It was just an attempt to help getting pep380 in python3.3 :)

renaud


___
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] Let's get PEP 380 into Python 3.3

2011-03-08 Thread rndblnch
Greg Ewing greg.ewing at canterbury.ac.nz writes:

 
 Guido van Rossum wrote:
  Ok. Will you hvae time to port your patches to 3.3?
 
 I'm not sure -- I'll see what I can do.
 

If this can help, I've ported the patch YieldFrom-Python3.1.2-rev5.patch
against current cpython tip.
What I've done:
- cloned current http://hg.python.org/cpython/ tip
- replaced tabs by 4 spaces in YieldFrom-Python3.1.2-rev5.patch and applied
result to tip
- manually applied failed hunks
- built and tested resulting python (configure/make/make test smoothly pass)
- successfully ran yield from samples with resulting binary
Resulting patch obtained by running hg diff is available here:
http://tinypaste.com/4cc47d

This patch includes graminit.[ch] modification since those files are versioned,
but I guess they are not necessary since they seem to be generated.

Hope this helps.

renaud

___
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