Re: Message passing syntax for objects | OOPv2

[Mark Janssen]

On Fri, Apr 12, 2013 at 11:28 PM, Mark Janssen
 wrote:
>> Mark, this proposal is out of place on a Python list, because it proposes an
>> object methodology radically different from any that is implemented in
>> Python now, or is even remotely likely to be implemented in Python in the
>> future.
>
> Wow, you guys are a bunch of ninnies.  I'm going to find some
> theoretical folks

Okay, to anyone who might be listening, I found the core of the problem.

This issue is/was much deeper than OOP (which would be roughly a 20
year refactoring) -- that was my mistake.  The issue goes right to the
core to models of computation and the historical factions within
theoretical CS itself (a 50+ year refactoring).

The field needs re-invented and re-centered.  Mark my words.  There
has been a half-century of confusion between two entirely separate
domains and they've been using the same lexicon.  Long story short:
the lambda calculus folks have to split from the Turing machine folks.
 These models of computation should not use the same language.  Their
computation models are too radically different.  Lisp will remain a
pinnacle of the lambda calculus, but should be remanded to philosophy.
 The logic of the binary/boolean arithmetic is simply not compatible,
but forms the basis of any sensible computer science here in the West.

Here pronouncith the whatever

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: object.enable() anti-pattern

[Mark Janssen]

> I'm looking for some help in finding a term, it's not Python-specific but
> does apply to some Python code.
>
> This is an anti-pattern to avoid. The idea is that creating a resource
> ought to be the same as "turning it on", or enabling it, or similar. For
> example, we don't do this in Python:

I would call it "user-mediated resource allocation" as distinct from
"object-mediated" resource allocation.
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: object.enable() anti-pattern

[Mark Janssen]

>> This is an anti-pattern to avoid. The idea is that creating a resource
>> ought to be the same as "turning it on", or enabling it, or similar. For
>> example, we don't do this in Python:
>
> I would call it "user-mediated resource allocation" as distinct from
> "object-mediated" resource allocation.

I should point out, though, it's not really an anti-pattern (coming
form the C community).

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Message passing syntax for objects | OOPv2

[Mark Janssen]

> "Lisp will remain the pinnacle of lambda calculus" ???  : Surreal
> feeling of falling into a 25-year time-warp
>
> Read this http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf
>
> Just for historical context:
> When this was written in the 80s:
> - The FP languages of the time -- KRC, SASL, Miranda, Orwell -- were
> elegant and academic
> - Lisp was quasi-industrial-strength but as Wadler argues above, was
> not doing good service to functional programming

Fascinating.
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Message passing syntax for objects | OOPv2

[Mark Janssen]

>>  These models of computation should not use the same language.  Their
>> computation models are too radically different.
>
> Their computation models are exactly equivalent.

No they are not.  While one can find levels of indirection to
translate between one and the other, that doesn't mean they're
equivalent.  It's like saying that because I can make an equivalence
between the complex plane and the real, that they should be treated as
equivalent.  But they shouldn't -- else you run into a domain error.

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Message passing syntax for objects | OOPv2

[Mark Janssen]

On Thu, May 9, 2013 at 10:33 AM, Ian Kelly  wrote:
> On Wed, May 8, 2013 at 8:35 PM, Mark Janssen  
> wrote:
>> Okay, to anyone who might be listening, I found the core of the problem.
>
> What "problem" are you referring to?  You've been posting on this
> topic for going on two months now, and I still have no idea of what
> the point of it all is.

You see Ian, while you and the other millions of coding practitioners
have (mal)adapted to a suboptimal coding environment where "hey
there's a language for everyone"  and terms are thrown around,
misused, this is not how it needs or should be.  Instead of the
thriving Open Source culture on the web we could have, the community
stays fractured.   Languages can reach for an optimal design (within a
constant margin of leeway).   Language "expressivity" can be measured.

--Tron
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Message passing syntax for objects | OOPv2

[Mark Janssen]

On Thu, May 9, 2013 at 4:58 PM, alex23  wrote:
> On 10 May, 07:51, Mark Janssen  wrote:
>> You see Ian, while you and the other millions of coding practitioners
>> have (mal)adapted to a suboptimal coding environment where "hey
>> there's a language for everyone"  and terms are thrown around,
>> misused, this is not how it needs or should be.
>
> Please cite your industry experience so we know this is a pragmatic
> exercise for you and not a display of public onanism.

"Industry experience"

Do you know all the world's [industrial] leaders are endorsing an
impossible path of endless, exponential growth on a finite planet?

Is that who you answer to?

--m
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: object.enable() anti-pattern

[Mark Janssen]

> I think where things went pear shaped is when you made the statement:
>
>>> There is no sensible use-case for creating a file OBJECT unless it
>>> initially wraps an open file pointer.
>
> That's a pretty absolute point of view.  Life is rarely so absolute.

In the old days, it was useful to have fine-grained control over the
file object because you didn't know where it might fail, and the OS
didn't necessarily give you give good status codes.  So being able to
step through the entire process was the job of the progammers.

Now, with languages so high like python and hardware so common, it
almost is never necessary, so he has some point.   A closed file
pointer is useful from a OS-progamming point-of-view though because
you generally never want to leave files open where they'd block other
I/O.


-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: object.enable() anti-pattern

[Mark Janssen]

>> There is no sensible use-case for creating a file OBJECT unless it
>> initially wraps an open file pointer.
>>
>>> So far the only counter-examples given aren't counter-examples ...
>>
>> Well, sure, if you discount operations like "create this file" and
>> queries like "could I delete this file if I wanted to?" [0] as methods
>> of the file system rather than of a hypothetical file object.
>>
>> What about a distributed system?  Suppose I want to create a file object
>> in one place, and send that object to the another place for the file to
>> be read from or written to [1]?  Suppose that for security reasons, I
>> have to do it that way, because the first place can only create the
>> objects, and the second place can only access the underly file contents
>> through an existing object?
>
> Unless you have re-implemented the file I/O system, it doesn't matter. If
> your file objects are based on C I/O, then even if the first server
> cannot read or write to the files it still creates file objects in an
> open state, because that is how C works.
>
> Or maybe the first server only creates some sort of proxy to the real
> underlying file object. Or maybe you're re-implemented the I/O system,
> and aren't following C's design. Since you're just making this up as a
> thought experiment, anything is possible.
>
> But either way, that's fine. You've found an object where it does make
> sense to have an explicit "make it go" method: first one entity has
> permission to construct the object, but not to open the underlying file.
> Another entity has permission to open the underlying file, but not to
> create the object. I have no idea whether this is a reasonable security
> design or not, it actually sounds a bit rubbish to me but what do I know?
> So let's treat it as a reasonable design.
>
> As I've said, repeatedly, that's not what I'm talking about.
>
> When you DON'T have useful things that can be done with the object before
> calling "enable", then it is an anti-pattern to require a separate call
> to "enable" method, and the enable functionality should be moved into the
> object constructor. If you DO have useful things that can be done, like
> pass the object to another entity, for security, then that's a whole
> 'nuther story.

You're missing one other case:  if there's useful things that can be
checked before calling enable().  Remember, on multi-user and/or
multi-processing systems, there could be contention for a slow
resource.  If you automatically open a file for write, you're
preventing everyone else from writing and potentially reading it.  So
there is something useful: did that file exist?  Is that resource
available for writing?

Prior to such hi-level languages like Python and reliable hardware,
such fine-grained control was important and vital.   Now it can
probably be relegated to special OS libraries.

Mark

> Really, what I'm describing is *normal* behaviour for most objects. We
> don't usually design APIs like this:
>
> n = int("42")
> n.enable()
> m = n + 1
> m.enable()
> x = m*2 + n*3
> print x - 1  # oops, raises because I forgot to call x.enable()

Again, you only do that for shared resources.  In this case, memory
would have to be a (protected) shared resources, but the OS manages
memory allocation, so it's not an issue.

Mark

> That's a rubbish API, and for simple data-like objects, we all agree it
> is a rubbish API. So why accept the same rubbish API just because the
> object is more complicated?

I think I just told you, but let me know . :)

> For my next controversial opinion, I'm going to argue that we should do
> arithmetic using numbers rather than by inserting lists inside other
> lists:

Try arguing that we should have a common message-passing syntax.

> # Do this:
>
> count = 0
> count += 1
>
> # Not this:
>
> count = []
> count.insert(0, [])

That's actually what they do in "set theory", believe it or not.

MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: object.enable() anti-pattern

[Mark Janssen]

> | No, I've created a file descriptor, which is, by definition, an integer.
> | It has nothing to do with C.  This is all defined by the POSIX
> | interface.  For example, the getdtablesize(2) man page says:
> |
> | "The entries in the descriptor table are numbered with small integers
> | starting at 0.  The call getdtablesize() returns the size of this table."
> [... snip ...]
>
> I'm with Steven here.
>
> You've made a number that can be used with calls that access the
> OS file descriptor table. But it isn't a file descriptor. (Yes, the
> in-program number is just a number either way.)

Steven, don't be misled.  POSIX is not the model to look to -- it does
not acknowledge that files are actual objects that reside on a piece
of hardware.  It is not simply an integer.

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: object.enable() anti-pattern

[Mark Janssen]

>> In the old days, it was useful to have fine-grained control over the
>> file object because you didn't know where it might fail, and the OS
>> didn't necessarily give you give good status codes.  So being able to
>> step through the entire process was the job of the progammers.
>
> I don't know what you mean by the "old days", but a couple of decades
> ago, there were no such things as "file objects".

My apologies.  I used the word "object" when I shouldn't have.

> I'm beginning to wonder if you and Dihedral are swapping notes.
> Dihedral's been sounding fairly coherent lately.

Dihedral...  That's my dream-self.  Where did you encounter him?  heh

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Message passing syntax for objects | OOPv2

[Mark Janssen]

> ...The field needs re-invented and re-centered.[...]

For anyone who want to be involved.  See the wikiwikiweb -- a tool
that every programmer should know and use --  and these pages:
ComputerScienceVersionTwo and ObjectOrientedRefactored.

Cheers!
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: object.enable() anti-pattern

[Mark Janssen]

> Steven, don't be misled.  POSIX is not the model to look to -- it does
> not acknowledge that files are actual objects that reside on a piece
> of hardware.  It is not simply an integer.

Please disregard this (my own) flame bait.
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python for philosophers

[Mark Janssen]

On Sat, May 11, 2013 at 1:03 PM, Citizen Kant  wrote:
>[...] the starting question I make to myself about Python is: which is the 
>single
> and most basic use of Python as the entity it is? I mean, beside
> programming, what's the single and most basic result one can expect from
> "interacting" with it directly (interactive mode)? I roughly came to the
> idea that Python could be considered as an economic mirror for data, one
> that mainly mirrors the data the programmer types on its black surface, not
> exactly as the programmer originally typed it, but expressed in the most
> economic way possible. That's to say, for example, if one types >>>1+1
> Python reflects >>>2. When data appears between apostrophes, then the mirror
> reflects, again, the same but expressed in the most economic way possible
> (that's to say without the apostrophes).

Wow.  You must be from another planet.  Find Socrates if you wish to
know these things.  He's from there also.

A-dam.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Message passing syntax for objects | OOPv2

[Mark Janssen]

On Sun, May 12, 2013 at 10:18 AM, Ned Batchelder  wrote:
> I've never understood why people use that site: the pages end up being
> unintelligible cocktail-party noise-scapes with no hope of understanding who
> is saying what, or in response to whom.

You're very right.  But that is what has made it sort of a test-bed
for internet collaboration.   The project I'm working on is aimed to
solve that problem and take the Wiki philosophy to its next or even
ultimate level.  By adding a "natural" per-revision voting and
user-ranking it can clear up all the noise and scale to the whole
internet itself.  But no one around here seem to think its
possible.
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python for philosophers

[Mark Janssen]

On Sat, May 11, 2013 at 1:03 PM, Citizen Kant  wrote:
>I'm making my way to Python (and
> OOP in general) from a philosophical perspective or point of view and try to
> set the more global definition of Python's core as an "entity". In order to
> do that, and following Wittgenstein's indication about that the true meaning
> of words doesn't reside on dictionaries but in the use that we make of them,
> the starting question I make to myself about Python is: which is the single
> and most basic use of Python as the entity it is?

It is a way to form order from ideas, an *experimental* philosophy.
One can apply and implement a philosophy, taking it out of the realm
of ideas and simulate them in the machine.

> I mean, beside
> programming, what's the single and most basic result one can expect from
> "interacting" with it directly (interactive mode)?

A game of interactions.

> I roughly came to the
> idea that Python could be considered as an economic mirror for data, one
> that mainly mirrors the data the programmer types on its black surface,

That is called the "editor window" in our world that is displayed on
an electronic device called a computer display, but in Samael's world
it is a mirror into our world.  He misused it to rape the crown of the
Hebrew story (found in the Bible).

> So, would it be legal (true) to define Python's core as an entity that
> mirrors whatever data one presents to it (or feed it with) showing back the
> most shortened expression of that data?

No, that is me, Marcos.
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Message passing syntax for objects | OOPv2

[Mark Janssen]

> Sounds a lot like reddit threads.

It's similar, but it goes a lot further.  Where every other site
without centralized editors, the thread mess on a simple flat page
doesn't scale after about a 100 interactions.  To sort out the mess,
it takes another dimension.  The project I'm working on uses a 3
dimensional visualization model that can scale and order millions of
nodes.

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Magazine

[Mark Janssen]

I always liked the daily Python-URL from Dr. Dobbs.

Summaries of salient discussions on python-dev, ideas, list.

interviews with devs on philosophies.

quote of the week

--m

On 5/24/13, DRJ Reddy  wrote:
> Planning to start a python online chronicle.What you want to see in it. :)
> --
> http://mail.python.org/mailman/listinfo/python-list
>


-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How clean/elegant is Python's syntax?

[Mark Janssen]

You might try http://wiki.python.org/moin/BeginnersGuide

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Mark Janssen]

> Whatever benefit there is in declaring the type of a function is lost due
> to the inability to duck-type or program to an interface. There's no type
> that says "any object with a 'next' method", for example. And having to
> declare local variables is a PITA with little benefit.
>
> Give me a language with type inference, and a nice, easy way to keep duck-
> typing, and I'll reconsider. But until then, I don't believe the benefit
> of static types comes even close to paying for the extra effort.

Okay, I'm going straighten out you foo(l)s once and for all.

Python has seduced us all into lazy typing.  That's what it is.
Manual type checking is obviously inferior to compiler type-checking.
 This is what I was trying to tell you all with the post of re-vamping
the Object model.

Python, and I along with it, went towards this idea of a grand god
Object that is the father of everything, but it turned out to be the
wrong direction.  Refer to my post on OOPv2.

The fact is, that none of us is close enough to God and the
programming art isn't evolved enough to try to accomplish some grand
generic object at the top of the ObjectModel.  It just isn't.  We were
better off closer to the machine.  Automatic conversion from int to
long was good enough.
-- 
MarkJ
Tacoma, Washington

P.S. See also PythonThreeThousand on wikiwikiweb

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Mark Janssen]

>> Python has seduced us all into lazy typing.  That's what it is.
>
> Bulshytt. If you have no idea what polymorphism is, you shouldn't even
> be participating in this conversation.

I am aware of what it means, but Python doesn't really have it
(although it may evolve to it with annotations).  But then these
debates were over a decade ago.

MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Mark Janssen]

>> I am aware of what it means, but Python doesn't really have it (although
>> it may evolve to it with annotations).
>
> No polymorphism huh?
>
>
> py> len([1, 2, 3])  # len works on lists
> 3
> py> len((1, 2))  # and on tuples
> 2
> py> len({})  # and on dicts
> 0
> py> len('I pity the fool')  # and on strings
> 15
> py> len(b'\x23')  # and on bytes
> 1
> py> len(set(range(2)))  # and on sets
> 2
> py> len(frozenset(range(4)))  # and on frozensets
> 4
> py> len(range(1000))  # and on range objects
> 1000

Okay, wow, it looks like we need to define some new computer science
terms here.

You are making an "outside view of a function" (until a better term is
found).  So that give you one possible view of polymorphism.  However,
*within* a class that I would write, you would not see polymorphism
like you have in C++,  where it is within the *function closure*
itself.   Instead you would see many if/then combinations to define
the behavior given several input types.  I would call this simulated
polymorphism.

But don't quote me on this because I have to review my 20 years of CS
and see if it matches what the field says -- if the field has settled
on a definition.  If not, I go with the C++ definition, and there it
is very different than python.

But then, you weren't going to quote me anyway, right?

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Mark Janssen]

> Fairly definitive terms have existed since 1985:
> http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf
>>
>> You are making an "outside view of a function" (until a better term is
>> found).  So that give you one possible view of polymorphism.  However,
>> *within* a class that I would write, you would not see polymorphism
>> like you have in C++,  where it is within the *function closure*
>> itself.   Instead you would see many if/then combinations to define
>> the behavior given several input types.  I would call this simulated
>> polymorphism.
>
> Cardelli and Wegner cited above call this ad-hoc polymorphism.
> What you are calling polymorphism, they call universal polymorphism.

Okay, THANK YOU for the reference.  The main thing to note is that
there is a difference.  Those terms sound good enough.
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Mark Janssen]

On 6/6/13, alex23  wrote:
> On Jun 7, 11:44 am, Mark Janssen  wrote:
>> > Bulshytt. If you have no idea what polymorphism is, you shouldn't even
>> > be participating in this conversation.
>>
>> I am aware of what it means, but Python doesn't really have it
>
> You really need to stop commenting when you clearly have no
> understanding of what you're talking about.

"Clearly", okay.  You've added a wee bit of constructive argument *if*
you're considered reputable to the rest of the list; however,
"polymorophism", should really only be considered "true" when
specifically in a "functional enclosure".  C++ has this, through it's
type system, more strictly when there is no references to variables
outside the function scope.  Python does not.

But this all relates to theoretical ObjectArchitecture and
ModelsOfComputation that aren't well-understood outside a few
specialized folks.  Good luck trying to work through the chaff, if you
don't want to know the difference.

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re-using copyrighted code

[Mark Janssen]

I can't tell you as a lawyer, but I can tell you that regarding code
for non-commercial use, the only supportable case is requiring
fair-credit assignment.  If reading the original license (which you
are obligated to do if you re-use and re-distribute the code), it
stipulates that you must re-share accordingly, then you should,
otherwise there's very little case that could be brought about if the
code was put into a published, "open-source" project, whatever the
license.

mark

On Sat, Jun 8, 2013 at 2:31 PM, Malte Forkel  wrote:
> Hello,
>
> I have written a small utility to locate errors in regular expressions
> that I want to upload to PyPI.  Before I do that, I would like to learn
> a litte more about the legal aspects of open-source software. What would
> be a good introductory reading?
>
> Plus, I have one very specific question: In my package, I use modified
> code from sre_parse.py, which is part of the Python release. That file
> has the following header:
>
> #
> # Secret Labs' Regular Expression Engine
> #
> # convert re-style regular expression to sre pattern
> #
> # Copyright (c) 1998-2001 by Secret Labs AB.  All rights reserved.
> #
> # See the sre.py file for information on usage and redistribution.
> #
>
> The referenced information is missing in the version of sre.py that
> comes with current versions of Python, but I found it in the archive
> http://effbot.org/media/downloads/sre-2.2.1.zip. It reads:
>
> #
> # Secret Labs' Regular Expression Engine
> #
> # re-compatible interface for the sre matching engine
> #
> # Copyright (c) 1998-2001 by Secret Labs AB.  All rights reserved.
> #
> # This version of the SRE library can be redistributed under CNRI's
> # Python 1.6 license.  For any other use, please contact Secret Labs
> # AB (i...@pythonware.com).
> #
> # Portions of this engine have been developed in cooperation with
> # CNRI.  Hewlett-Packard provided funding for 1.6 integration and
> # other compatibility work.
> #
>
> Now, how am I supposed to deal with that? Ask Secret Labs for some kind
> of permission? Leave it as it is and add my own copyright line?
>
> Malte
>
> --
> http://mail.python.org/mailman/listinfo/python-list



-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re-using copyrighted code

[Mark Janssen]

> The Secret Labs license is very explicit: "All rights reserved". That line 
> means you can't touch it under pain of lawsuit.

That's not true.  It means whatever rights they do have, they are
stating, in effect, that they have not given them away.  But this is a
difficult legal point, because by open sourcing their IP, they've
already given away from of their rights.
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re-using copyrighted code

[Mark Janssen]

> At least partially, my confusion seems to be caused by the dichotomy of
> the concepts of copyright and license. How do these relate to each other?

A license emerges out of the commercial domain is purely about
commercial protections.   A copyright comes from the "academic" domain
is pure about protecting your "intellectual property", or non-physical
creations (most from encroachment of the commercial domain, by the
way).   They are on opposite ends of the spectrum, but because of our
bi-polar system the terms get used as synonyms .

In a way they are not related and it all depends on what court would
listen to the case.  In a German court, you would almost certainly be
tried under the commercial framework,  In the US, in theory (and this
is where it must be pushed to enforce the people), it *should* be the
opposite if the court is doing its job of upholding the Constitution.

You use a license when you want to authorize use of something you own
in a commercial setting.  You use copyright when you're protecting
authorship of something and have not given it away (something you
never really want to do anyway).

> I understand that I have to pick a license for my package.

You actually do not.  Attaching a legal document is purely a secondary
protection from those who would take away right already granted by US
copyright.

> And may be
> I'm not free to pick any open source license due the license used by
> Secret Labs AB. But how does that relate to the copyright statements?

The thing, like I noted, is that they've already released the code
into the public eye.   Now you must only do your due diligence to
honor the *spirit* of their intent.  And that spirit, regardless of
whether they made it explicit, is almost certainly for non-commercial
(non-profit) use.

> Should I put my own copyright line in every source file in the package?

I would put it as a separate file in the package as well as a comment
line in each file referring to your file.

> How about the file that re-uses portions of sre_parse.py? Can there or
> should there be two copyright lines in that file, one from Secret Labs,
> one my own?

Show (c) YourName, Secret Labs and carry-forward any additional usage
terms from them.

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re-using copyrighted code

[Mark Janssen]

On Sun, Jun 9, 2013 at 12:50 PM, Michael Torrie  wrote:
> On 06/09/2013 11:18 AM, Mark Janssen wrote:
>> You actually do not.  Attaching a legal document is purely a secondary
>> protection from those who would take away right already granted by US
>> copyright.
>
> You are correct, except that the OP has already stated he wishes to have
> his code distributed. Without granting a license, the code cannot be
> distributed beyond the people he personally gives the code too.  PyPi
> cannot legally allow others to download it without a license.

That's not entirely correct.  If he *publishes* his code (I'm using
this term "publish" technically to mean "put forth in a way where
anyone of the general public can or is encouraged to view"), then he
is *tacitly* giving up protections that secrecy (or *not* disclosing
it) would *automatically* grant.  The only preserved right is
authorship after that.   So it can be re-distributed freely, if
authorship is preserved.  The only issue after that is "fair use" and
that includes running the program (not merely copying the source).

Re-selling for money violates fair-use, as does redistribution without
preserving credit assignment (unless they've naively waived those
rights away).  I will have to take a look at  PyPi.  But if you are
*publishing*, there's no court which can protect your IP afterwards
from redistribution, unless you explicitly *restrict* it.  In which
case, if you restrict terms of re-use, you're putting the court in
jeopardy because you making two actions opposed to one another.  The
only thing the court can easily uphold is your authorship and
non-exploitation from a violation of fair-use (note again the key word
is "use", nor merely copying the code).  But then if you waive *that*
right away, you put the court in jeopardy again.

> Here's how the GPL puts it, and of course this applies to any and all
> licenses, even proprietary ones:
>
> "However, nothing else [besides the License] grants you permission to
> modify or distribute the Program or its derivative works. These actions
> are prohibited by law if you do not accept this License. Therefore, by
> modifying or distributing the Program (or any work based on the
> Program), you indicate your acceptance of this License to do so, and all
> its terms and conditions for copying..."

Well this is where one must make a distinction with fair-use -- if I
re-publish my modifications then the code is still subject to the
terms by the original author.  If I make a copy for myself and run the
problem for personal, non-commercial use, then I am in the domain of
fair use and have no other obligations.

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re-using copyrighted code

[Mark Janssen]

>> That's not entirely correct.  If he *publishes* his code (I'm using
>> this term "publish" technically to mean "put forth in a way where
>> anyone of the general public can or is encouraged to view"), then he
>> is *tacitly* giving up protections that secrecy (or *not* disclosing
>> it) would *automatically* grant.  The only preserved right is
>> authorship after that.   So it can be re-distributed freely, if
>> authorship is preserved.  The only issue after that is "fair use" and
>> that includes running the program (not merely copying the source).
>
> No, the original author retains all rights except those explicitly
> granted. The same way that obtaining the "source" to a song does not
> give you the right to redistribute the song all you want.

No, you are right only by the *word* of the law, but you have not
included the authors *actions*.  A court has to include both.

He explicitly did not *retain* his rights when he *published* his
code.  There is not word of law that is necessary when his actions
have already done the deed (unless under coercion, of course).

> Fair use has nothing to do with money. It depends on how the work is
> used and how you've changed it. Weird Al's song parodies are fair use,
> even though he sells them.

That can't really be claimed without a case being brought against him.
 Michael Jackson, for example, probably could have made a case against
WierdAl, but did not -- that does not automatically mean that
WierdAl's use was fair-use in the slightest.  In fact, it probably was
not, but MJ made enough money that he probably also didn't want to the
PR loss.

> You distributing copies of a commercial
> software to everyone is not fair use, even though you aren't making
> money.

It *is* absolutely fair use, if that commercial software *published*
their code (in the definition I gave earlier).  If you stole the code
off their protected servers, it is not fair use.

>> Well this is where one must make a distinction with fair-use -- if I
>> re-publish my modifications then the code is still subject to the
>> terms by the original author.  If I make a copy for myself and run the
>> problem for personal, non-commercial use, then I am in the domain of
>> fair use and have no other obligations.
>
> Again, no. The GPL does not restrict your rights when running on
> machines you control, but that's just because of the terms of the
> license. Most commercial licenses include terms like "no reverse
> engineering the software" that have nothing to do with distribution.

Close-source software could automatically be considered "protected",
but that is only out of kindness.  Publishing software, even
closed-source software opens a company to some level
reverse-engineering by the nature of computers and by the fact that
the techniques of turning machine code into assembly are well known.
So they explicitly state that they do not give permission to do so,
yet this is not worth much of anything except for the fact that most
people are intimidated to go against a large software company to argue
their rights.

Apparently these companies have already seen this loophole and have
made things like DRM to put a legalistic container around what would
otherwise be de facto published (machine) code.  But this is not a
legit workaround either and companies have essentially stealing from
the intellectual and creative communities.

There is no legitimate argument against a personal user figuring out
how software works for personal use.  If they don't want people to
"figure it out", they'll have to open stores where people can run
their special software on machines that are under their control.

I'm sorry, this is just the way it is -- everyone's just gone along
with the program tacitly because they get intimidated by the legal
system.  But the law is for people, not for lawyers.

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re-using copyrighted code

[Mark Janssen]

> (Digression follows.) ...(by Gilbert and
> Sullivan - one of my other loves), and according to US law at the
> time, the publication (in this case, public performance, along with
> the public sale of libretti (books of the words) and some sheet music)
> of the work voided the authors' claim to ownership.
> Came across a nice little history of copyright here:
> http://www.edwardsamuels.com/illustratedstory/isc10.htm
> Or if you're curious about how copyright applied to the works of
> Gilbert and Sullivan, join Savoynet -
> http://savoynet.oakapplepress.com/ - and ask. There are plenty of
> experts around.

Thank you for that reference.

> In any case, that's all ancient history now. Unless someone can cite a
> jurisdiction that still maintains that publication relinquishes all
> rights of ownership, I would assume that things remain in copyright.

My apologies, if any of my writing wasn't clear.  By no means did I
wish to suggest that publication relinquishes copyright -- only that
the author's actions eliminate some natural protections afforded by
non-publication.  This is just common sense.  If I'm a game developer
and release my game to the public, I expose it to some risk -- that
just the trade-off of getting noticed.  FairUse explicitly allows
others to derive works from yours and you're going to have to accept
that to some degree, but copyright requires that they give you credit
and if they make money from your work you may be due proceeds.  But
here is where Lawrence Lessig is way ahead of the crowd.  FairUse
should mean "ShareAlike".

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re-using copyrighted code

[Mark Janssen]

> Mark, ever watched TV? Or gone to the movies? Or walked into a bookshop?
> Listened to the radio? All these things publish copyrighted work. It is
> utter nonsense that merely publishing something in public gives up the
> monopoly privileges granted by copyright.

That's not correct.  Keep in mind, that the law is for people:  there
is no automatic right to profit.  There certainly is no "right to
monopoly" (which you are absurdly arguing) on *anything* released to
the public.  If you want that monopoly *you* have to provide the means
to protect your IP.  You, sir, are being ridiculous and perhaps the
court along with you -- I'm just telling you what is correct.  That's
important.

A movie producer, publishes his/her work as soon as he/she puts it on
the market or otherwise releases it for public viewing.  That's just
the risk of doing business.  Fortunately, for them, its not easy to
make a verbatim copy of a film, in a theatre or otherwise.   But
copyright ensures that they get the credit for making the movie -- not
for profit of publishing it.

Now copyright includes the clause of "fair-use", so that means one can
make a copy of something if they aren't depriving the original creator
of legitimate gains.  If they are truly depriving the creator(s) of
legit gains, then they are in violation.  That's all the law should
support.  Don't think there is any law that can determine, once and
for all, what counts as "legitimate gains" and what violates "fair
use".   *You* have simply *sold out*.   "Legitimate gains" is
something the courts have to work out, on a case-by-case basis, but if
the movie producers are that worried about losing their gains, then
they can do the f-ing work and require movie goers to sign a simple
clause promising that they won't try to copy the movie (on concealed
cameras and such).

The issue beyond that, like code, is when it comes to digital media.
Because digital media allows verbatim copying and *tacitly removes*
*by its nature* any privilege or monopoly on public viewing.  That,
again, is just the risk of doing business of trying to "maximize your
market" for-profit.  Tough nuts asshole.  Things are quite clear
despite the FUD the media establishment would have you believe.  Stop
capitulating and selling out.

The only issue is whether you're depriving the original content
creator of *legitimate* gains.  That means many things:  how much is
that movie a derived product of popular culture, for example?  (Did
you get rewarded for participating in some small part of that?)  How
much would you have paid if was offered to you to set the price?

> Armchair lawyering is one thing, but please at least *try* to apply
> thought to these things before making ridiculous claims.

I have, and I assure you they are not ridiculous claims.  You have
just been lulled into complacency, like most everyone else.  That's
why people like the DeCSS folks are doing the rest of us a favor.
Shame on you for defending the status quo.

> If merely
> publishing something voided copyright monopoly,

Here you already shown your ignorance of the concept.  Copyright
protects your *authorship*, not your profit.  Perhaps you're confusing
patent law with copyright.

> then copyright would
> hardly encourage people to publish things they wished to monopolise,
> would it?

Why would they publish something they wished to monopolize?

>> The only issue after that is "fair use" and that includes running the
>> program (not merely copying the source).
>
> Running the program is irrelevant to copyright.

Technically, the law likely recognizes the distinction from
reproducing and "running" a program.  If I am a secretary and am
copying something for my boss, I'm not liable am I?  But if I derive
benefit from the program, I am, yes?

> Copyright does not grant
> the creator a monopoly of *running* the program.

No, perhaps you are getting hung up on the misnomer of calling it
"copyright" which would otherwise imply "right to copy".  Copyright,
could potentially grant the creator rights (like the DMCA) to who
*can* run the program.

>> Re-selling for money violates fair-use,
>
> The principle of re-sale have nothing to do with fair use.

Yes it does.  You are simply wrong.  The point of the law is fairness,
not supporting monopolies.

>> as does redistribution without
>> preserving credit assignment (unless they've naively waived those rights
>> away).
>
> One cannot *naively* waive away copyright monopoly privileges.

Why not?  That is what happens, generally speaking, when one releases
something to the "public domain", so what are you arguing?

> It
> requires an explicit and overt act to give away the rights granted.

That's what i just implied by saying "waived away their rights".

> One
> might deliberately publish your work under a permissive licence without
> realising that it is permissive, but that's not an act of naivety, it's
> an act of stupidity for not reading the licence and understanding it
> before publishin

Re: Re-using copyrighted code

[Mark Janssen]

> The fact that a work is non commercial is one of several factors that
> is taken into account when determining fair use. It is not an
> automatic fair use for non-commercial works. I have no idea where your
> understanding of copyright law came from, but here is the relevant
> section of the US legal code:

Thanks for digging out the legal code.  Upon reading, it is stunningly
clear that the legal system has not established a solid framework or
arching philosophy in which to contain and express the desire (in law)
to protect content creators of all kinds or the general public with
the fair use of such works and has been running on the sheer
confidence of "the American spirit", however facile or misdirected
that may be.

> 17 USC § 107 - Limitations on exclusive rights: Fair use
> Notwithstanding the provisions of sections 106 and 106A, the fair use
> of a copyrighted work, including such use by reproduction in copies or
> phonorecords or by any other means specified by that section, for
> purposes such as criticism, comment, news reporting, teaching
> (including multiple copies for classroom use), scholarship, or
> research, is not an infringement of copyright. In determining whether
> the use made of a work in any particular case is a fair use the
> factors to be considered shall include—
> (1) the purpose and character of the use, including whether such use
> is of a commercial nature or is for nonprofit educational purposes;
> (2) the nature of the copyrighted work;
> (3) the amount and substantiality of the portion used in relation to
> the copyrighted work as a whole; and
> (4) the effect of the use upon the potential market for or value of
> the copyrighted work.
> The fact that a work is unpublished shall not itself bar a finding of
> fair use if such finding is made upon consideration of all the above
> factors.
>
> Can you provide any citations for your interpretation? Besides "that's
> what the law should be", I mean.

I don't think I even have to:  the legal code you're citing above is
not very clear, consistent, or well-defined at all.  As such, it shows
that this area remains an area that has yet to be worked out by all
parties involved.   I would happily volunteer for any interested
parties to such a broken system.  Alternatively, I've been working on
a real fix to IP protections in the form of a unified data model for
the internet and data ecosystem.

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re-using copyrighted code

[Mark Janssen]

> What is clear is the mandate that sets up the framework in the first
> place:
>
>   "To promote the Progress of Science and useful Arts, by securing
>   for limited Times to Authors and Inventors the exclusive Right to
>   their respective Writings and Discoveries"
> -- USC Article I, Section 8
>
> If it doesn't "promote the Progress of Science and useful Arts", then
> it misses the spirit of the law as drafted.

Exactly, academia has known what this is intuitively for some time.
It's just the commercial world and the populace at large that is
confused and exploited.  This also disproves Steven D'Aprano's thesis
that monopoly rights is its purpose, but no.

> Granted, courts seem to miss that interpretation on a regular basis,
> leaving me a bit disgusted at the whole mess. :-/

Yeah, and stranger is that people *defend* the interpretation which
*takes away* their rights!

Bizarre!
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re-using copyrighted code

[Mark Janssen]

> Granted, IANAL, but the scholarly article I linked to above refers to
> several of the same issues. I don't know about publication revoking
> *all rights*, but there was definitely an understanding by the court
> that publication meant a reduction of copyright claim.

Again, I don't think I said that publication revokes "all rights", but
it certainly opens the can of worms that wouldn't have been open had
you kept it to yourself.  So while it *exposes you*, it does not still
*deprive you of rights*.  That is what copyright is for:  to protect
you after you've exposed yourself.
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re-using copyrighted code

[Mark Janssen]

>>> Can you provide any citations for your interpretation? Besides "that's
>>> what the law should be", I mean.
>>
>> I don't think I even have to:  the legal code you're citing above is
>> not very clear, consistent, or well-defined at all.  As such, it shows
>> that this area remains an area that has yet to be worked out by all
>> parties involved.   I would happily volunteer for any interested
>> parties to such a broken system.  Alternatively, I've been working on
>> a real fix to IP protections in the form of a unified data model for
>> the internet and data ecosystem.
>
> Except that's now how law works in the US.  All laws are unclear,
> inconsistent or ill-defined.

Yes, but the issue is that some participants were suggesting that the
law *is* clear when it is not -- so what is the procedure to follow
when that is the case?

>Many laws even contradict existing laws.
> That's why there's a long history and tradition (for good or ill) of
> courts establishing case law to clarify and codify the implementation of
> law, and to resolve incompatibilities and consistencies.
>
> So while your views may be logical to you, and even common sense, unless
> case law backs you up, your opinions are irrelevant to the actual
> implementation of copyright law.

No, the system of law is made for, and by the people, so while it may
not reflect consensus, it isn't necessarily irrelevant and in any case
where there are people spouting law as if it WAS clear, someone must
do the job breaking down the walls.

> As much as many of us are open source or even free software advocates,
> we do have to live within the copyright law currently,

We do not have to live within it, we can create it.  Where did you get
this idea?

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re-using copyrighted code

[Mark Janssen]

> Weird Al can be a complex case, because sometimes his songs are true 
> parodies, and sometimes they're more satires.  Parody has a pretty firm 
> history of being protected under fair use, and Weird Al's MJ-inspired songs 
> ("Fat" and "Eat It") are clearly parodies.  (As is his more recent Lady Gaga 
> sendup "Perform This Way", while his Star wars saga "The Story Begins" and 
> Coolio-esque "Amish Paradise" are more like satires).
>
> So in the case of Weird Al's Michael Jackson parodies, he would be protected 
> under law if MJ had decided to sue.

Not entirely.  The use of the musical tune is not a parody, only the
lyrics.  But if, like you say, he did get permission, then he is safe.

But you bring up a point of *criticism* which is distinct from re-use.
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Don't rebind built-in names*" - it confuses readers

[Mark Janssen]

>> list = []
>> Reading further, one sees that the function works with two lists, a list of
>> file names, unfortunately called 'list',
>
> That is very good advice in general:  never choose a variable name
> that is a keyword.

Btw,  shouldn't it be illegal anyway?  Most compilers don't let you do
use a keyword as a variable name

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Don't rebind built-in names*" - it confuses readers

[Mark Janssen]

> There's a subtle difference between a keyword and a built-in.  Good
> Python style generally avoids masking built-ins but allows it:

Right, thank you for reminding me.  My C-mind put them in the same category.
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Don't rebind built-in names*" - it confuses readers

[Mark Janssen]

> list = []
> Reading further, one sees that the function works with two lists, a list of
> file names, unfortunately called 'list',

That is very good advice in general:  never choose a variable name
that is a keyword.
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re-using copyrighted code

[Mark Janssen]

>> At least partially, my confusion seems to be caused by the dichotomy of
>> the concepts of copyright and license. How do these relate to each other?
>
> A license emerges out of the commercial domain is purely about
> commercial protections.

I should clarify, that "commercial protections" here means *money*,
not other potentially legal assets.  As soon as money is exchange you
entangle yourself with their domain.  Otherwise, as long as you give
credit, you're really quite safe, from a Constitutional perspective.

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Don't rebind built-in names*" - it confuses readers

[Mark Janssen]

On Wed, Jun 12, 2013 at 7:24 AM, Grant Edwards  wrote:
> On 2013-06-11, Mark Janssen  wrote:
>>> list = []
>>> Reading further, one sees that the function works with two lists, a list of
>>> file names, unfortunately called 'list',
>>
>> That is very good advice in general:  never choose a variable name
>> that is a keyword.
>
> You can't choose a vriable name that is a keyword: the compiler won't
> allow it.
>
> "list" isn't a keyword.

You're right.  I was being sloppy.
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Don't rebind built-in names*" - it confuses readers

[Mark Janssen]

>> You're right.  I was being sloppy.
>
> ['ArithmeticError', 'AssertionError', 'AttributeError',
> 'BaseException', 'BlockingIOError', 'BrokenPipeError', 'BufferError',
> 'BytesWarning', 'ChildProcessError', 'ConnectionAbortedError',
> 'ConnectionError', 'ConnectionRefusedError', 'ConnectionResetError',
> 'DeprecationWarning', 'EOFError', 'Ellipsis', 'EnvironmentError',
> 'Exception', 'False', 'FileExistsError', 'FileNotFoundError',
> 'FloatingPointError', 'FutureWarning', 'GeneratorExit', 'IOError',
> 'ImportError', 'ImportWarning', 'IndentationError', 'IndexError',
> 'InterruptedError', 'IsADirectoryError', 'KeyError',
> 'KeyboardInterrupt', 'LookupError', 'MemoryError', 'NameError',
> 'None', 'NotADirectoryError', 'NotImplemented', 'NotImplementedError',
> 'OSError', 'OverflowError', 'PendingDeprecationWarning',
> 'PermissionError', 'ProcessLookupError', 'ReferenceError',
> 'ResourceWarning', 'RuntimeError', 'RuntimeWarning', 'StopIteration',
> 'SyntaxError', 'SyntaxWarning', 'SystemError', 'SystemExit',
> 'TabError', 'TimeoutError', 'True', 'TypeError', 'UnboundLocalError',
> 'UnicodeDecodeError', 'UnicodeEncodeError', 'UnicodeError',
> 'UnicodeTranslateError', 'UnicodeWarning', 'UserWarning',
> 'ValueError', 'Warning', 'WindowsError', 'ZeroDivisionError', '_',
> '__build_class__', '__debug__', '__doc__', '__import__', '__name__',
> '__package__', 'abs', 'all', 'any', 'ascii', 'bin', 'bool',
> 'bytearray', 'bytes', 'callable', 'chr', 'classmethod', 'compile',
> 'complex', 'copyright', 'credits', 'delattr', 'dict', 'dir', 'divmod',
> 'enumerate', 'eval', 'exec', 'exit', 'filter', 'float', 'format',
> 'frozenset', 'getattr', 'globals', 'hasattr', 'hash', 'help', 'hex',
> 'id', 'input', 'int', 'isinstance', 'issubclass', 'iter', 'len',
> 'license', 'list', 'locals', 'map', 'max', 'memoryview', 'min',
> 'next', 'object', 'oct', 'open', 'ord', 'pow', 'print', 'property',
> 'quit', 'range', 'repr', 'reversed', 'round', 'set', 'setattr',
> 'slice', 'sorted', 'staticmethod', 'str', 'sum', 'super', 'tuple',
> 'type', 'vars', 'zip']
>
> I think I can safely say that all the names beginning with an
> uppercase letter (exceptions, True/False/None/Ellipsis), and the ones
> beginning with underscores, should not be overridden. Well and good.
> Still leaves 72 builtins. Obviously overriding len, print, range, etc
> would be risky (unless, as mentioned above, you're making a drop-in
> replacement), but there are plenty that you'd never notice (eg if you
> use "hash" for an encoded password, or "input" for the string the user
> typed into an HTML form). I would hope, for instance, that an editor
> would not color-highlight 'credits' differently, as it's designed for
> interactive work. There are plenty in the grey area - is it safe to
> use "sum" as an accumulator or "min" for a unit of time? What about
> using "super" to store the amount of retirement money you've put away?
> I'd be inclined to avoid this sort any time I'm aware of them, just
> because it'll make debugging easier on the day when something goes
> wrong.

Okay, now I'm a bit confused.  "print" is both a  and a
member of the builtins.  What happens then?

And abs(), max(), hex()  and such seemed like keywords to my
scientific self (due to never having to "include"/import them), but
clearly their not.  And int, list, tuple, dict and such always seemed
like keywords to my CS self because they were included in Python's
type system (like "int" would be in C).

They are all one-step removed from keywords.   And yet, since they are
not in a separate namespace, they should not be used as variable
names.  Perhaps since they are very different from one another, they
should be put in separate namespaces off of a global, root
namespace...  (math, string, etc.)

Despite that, seems like PEP8 should suggest this not shadowing these
built-ins which are at global scope.

MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Version Control Software

[Mark Janssen]

> I am looking for an appropriate version control software for python 
> development, and need professionals' help to make a good decision. Currently 
> I am considering four software: git, SVN, CVS, and Mercurial.

I'm not real experienced, but I understand that SVN is good if your
hosting your own code base, and CVS is hardly used anymore as it
doesn't support atomic commits (when having many developers work on
the same code base).  Git and hg have ben vying for several years with
no clear winner, yet

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Don't rebind built-in names*" - it confuses readers

[Mark Janssen]

>> This has caused more trouble than it has solved.
>
> I take it you have never programmed in a programming language with a
> single, flat, global namespace? :-)

Hey, the purpose a programming language (i.e. a language which has a
consistent lexical specification), is to provide some modicum of
structure.  Yes, that implies that you're implicitly following a
language designers tacit philosophy (their "ObjectArchitecture") for
relating data to computers, but that's fine.  People always have the
option of going back to assembly and starting over.

> Apart from Erlang, got any other examples? Because it seems to me that in
> languages with nested scopes or namespaces, shadowing higher levels is
> exactly the right thing to do.

Really?

>>> int="five"
>>> [int(i) for i in ["1","2","3"]]
TypeError:  str is not callable

Now how are you going to get the original int type back?

> Certainly it would be a PITA, and defeat
> the purpose of having nested scopes, if inner names had to be globally
> unique. Wouldn't it be absolutely horrible if adding a global variable
> "foo"[1] suddenly meant that all your functions that used "foo" as a
> local variable stopped working?

Not necessarily, but this is what I'm talking about in defining a
ObjectArchitecture (or in some circles a "type system").
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Don't rebind built-in names*" - it confuses readers

[Mark Janssen]

> The builtins don't need to be imported, but they're identifiers like
> anything else. They're a namespace that gets searched after
> module-globals.

Yes, I understand, though for clarity and separability, it seems that
having them in a namespace that gets explicitly pulled into the global
space is less messy, despite the extra step (the default python
distribution could include a STARTUP file that imports the builtin
types).  But I must withhold my personal philosophy lest it get too
complicated.

>> And int, list, tuple, dict and such always seemed
>> like keywords to my CS self because they were included in Python's
>> type system (like "int" would be in C).
>
> Yep, but in Python, types/classes are themselves objects, so you can
> pass them around like anything else. This also downgrades them from
> "language keyword" to "always-available name", which in effect
> upgrades your _own_ classes to the same level.

Yes, and here is where I've been trying to argue that Python's object
model isn't right.  But I must abstain from commenting further.

>> They are all one-step removed from keywords.   And yet, since they are
>> not in a separate namespace, they should not be used as variable
>> names.  Perhaps since they are very different from one another, they
>> should be put in separate namespaces off of a global, root
>> namespace...  (math, string, etc.)
>
> There's no point forcing them to be looked up in a two-step process.
> If you want that, you can simply reference them as
> __builtins__.whatever, but you can instead just reference them as the
> unadorned name whatever. They contribute heavily to the simplicity and
> readability of Python code - imagine if every call to len() had to be
> qualified.

Well I would anticipate a keyword ("load"?) so one could load a
particular namespace into the global scope.  The issue I guess is when
should modules be "on file" vs. "in memory" like the builtins?  The
reason this is coming up, is because I would like to imagine a data
ecosystem, where I can import a set of objects from the network as if
they are local right into my interpreter environment.

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: My son wants me to teach him Python

[Mark Janssen]

> Despite not want to RTFM as you say, you might set him in front of
> VPython, type

I totally forgot PyGame -- another likely source of self-motivated
learning for a teen programmer.
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.]

[Mark Janssen]

>>> Whats the difference of "interpreting " to "compiling" ?
>>
>> OK, I give up!
>
> Actually, that's a more subtle question than most people think. Python,
> for example, is a compiled language. (What did you think the "c" in
> ".pyc" files stood for? and the compile() function>?)

Careful there.  This terminology is not agreed upon universally (that
is, within the realm of academia where the notion of mastery exists),
and unless you are citing an actual reference or publishing one
yourself, then you may be adding more confusion than illumination.
For example, I would say that it is an *interpreted language* that
gets compiled at run-time.  Some (*valid*) definitions of "compiler"
mean a strict mapping from the language syntax and lexical definition
to a sequence of bytes that can be fed to a (hardware not virtual)
machine architecture to do perform what is requested.  The face that
an extension ends in the letter "c" is not sufficient evidence, since
file extensions have no strict standard.

> And these days, for many types of hardware, even machine-code is often
> interpreted by a virtual machine on a chip. And even languages which
> compile to machine-code often use an intermediate platform-independent
> form rather than targeting pure machine-code.

Do you have a reference for this?  What language?

> The line between compilers
> and interpreters is quite fuzzy.

It shouldn't be.  What is fuzzy is the definition of "interpreter",
however.  The definition of compiler has only become fuzzy with the
advent of the personal computer.

> Probably the best definition I've seen for the difference between a
> modern compiler and interpreter is this one:
>
> "...the distinguishing feature of interpreted languages is not that they
> are not compiled, but that the compiler is part of the language runtime
> and that, therefore, it is possible (and easy) to execute code generated
> on the fly."

That's reasonable.
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: n00b question on spacing

[Mark Janssen]

> Also remember when entering long lines of text that strings concatenate
> within parenthesis.
> So,
> ("a, b, c"
> "d, e, f"
> "g, h, i")
>
> Is the same as ("a, b, cd, e, fg, h, i")

There was a recent discussion about this (under "implicit string
concatenation").  It seems this is a part of the python language
specification that was simply undefined.   (A rule probably should be
added to the lexer to make this explicit.)

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is the semantics meaning of 'object'?

[Mark Janssen]

>> Mostly I'm saying that super() is badly named.
>
> What else would you call a function that does lookups on the current
> object's superclasses?

^.  You make a symbol for it.  ^__init__(foo, bar)

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: n00b question on spacing

[Mark Janssen]

On Mon, Jun 24, 2013 at 4:48 PM, alex23  wrote:
> On 23/06/2013 3:43 AM, Mark Janssen wrote:
>>
>> There was a recent discussion about this (under "implicit string
>> concatenation").  It seems this is a part of the python language
>> specification that was simply undefined.
>
>
> It's part of the language reference, not an accidental artifact:
> http://docs.python.org/2/reference/lexical_analysis.html#string-literal-concatenation

When I say "specification", I mean "specified in the formal notation"
(BNF, etc).  "whitespace" is not defined (otherwise there would be a
line in the token list for "linefeed" and "carriagereturn".

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is the semantics meaning of 'object'?

[Mark Janssen]

> This bothers me as well.  If you look at Raymond Hettinger's "super()
> considered super" article, he includes the (correct) advice that
> super() needs to be used at every level of the call chain.  At the end
> of the article, he offers this example to show how "easy" multiple
> inheritance can be:
> [...]
> oc = OrderedCounter('abracadabra')
>
> Which is pretty cool in its simplicity, but here's the rub (which I
> have previously noted on this list): OrderedDict doesn't use super.
> Counter does, but not cooperatively; it just calls super().__init__()
> with no arguments.  So the fact that this example works at all is
> basically luck.

Ah, and here we see the weakness in the object architecture that has
evolved in the past decade (not just in Python, note).  It hasn't
really ironed out what end is what.   Here's a proposal:  the highest,
most "parental", most general object should be in charge, not
subclasses calling specific parent's init methods
(Parent.__init__(myparams)), etc. -- ***THIS IS WHERE WE WENT
WRONG***.

After the "type/class unification", python tried to make the most
generic, most useless class be the parent of *all of them*, but
there's been no use whatsoever in that.  It was a good idea in the
beginning, so pure as it was, but it has not panned out in practice.
Sorry...

I'm trying to start a recovery plan at the wikiwikiweb
(http://c2.com/cgi/wiki?WikiWikiWeb) and I don't want to hear any more
smarmy comments about it.  The confusion is deeper than Python.
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is the semantics meaning of 'object'?

[Mark Janssen]

> So instead of super(), you would have sub()?  It's an interesting
> concept, but I don't think it changes anything.  You still have to
> design your classes cooperatively if you expect to use them with
> multiple inheritance.

Yes, and let new instances of the child classes automatically ensure
the contracts of the parent classes.  I suppose it could be called
delegation
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is the semantics meaning of 'object'?

[Mark Janssen]

> The main problem is getting to the top/end of the call chain. Classic
> example is with __init__, but the same problem can also happen with
> other calls. Just a crazy theory, but would it be possible to
> construct a black-holing object that, for any given method name,
> returns a dummy function that ignores its args? (Other forms of
> attribute lookup aren't going to be a problem, I think, so this can be
> just methods/functions.) Then you just subclass from that all the
> time, instead of from object itself, and you should be able to safely
> call super's methods with whatever kwargs you haven't yourself
> processed. Would that work?
>
> Caveat: I have not done much with MI in Python, so my idea may be
> complete balderdash.

Here's how it *should* be made:  the most superest, most badassed
object should take care of its children.  New instances should
automatically call up the super chain (and not leave it up to the
subclasses), so that the parent classes can take care of the chil'en.
 When something goes wrong the parent class has to look in and see
what's wrong.

In other words, this habit of specializing a Class to make up for the
weaknesses of its parent are THE WRONG WAY.   Instead, let the
specialization start at the machine types (where it doesn't get more
specialized), and work UPWARDS.

Let the standard library make the grouping (or collection types) to
point to the standard way of data structuring, and then everything
else becomes little mini-apps making a DataEcosystem.

--mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is the semantics meaning of 'object'?

[Mark Janssen]

Sorry my last message got sent prematurely.  Retrying...

> So instead of super(), you would have sub()?  It's an interesting
> concept, but I don't think it changes anything.  You still have to
> design your classes cooperatively if you expect to use them with
> multiple inheritance.

Yes, and let new instances of the child classes automatically ensure
the contracts of the parent classes -- managed within the Python
interpreter, not the developer.

As for sub(), I suppose it could be called delegate().

The issue of classes cooperating isn't as big as it seems, because
since you're working now from a useful, agreed-upon common base (the
non-negotiable, but also non-arbitrary) machine types, you're now all
(the python and ideally the *object* community) speaking the same
language.   Who's going to argue about integers (as the atomic type)
and sets (as the most basic grouping type) being THE common set of
bases for everything else?  I mean, it doesn't get anymore ideal and
pure than integers and sets.  Combining integers with sets I can make
a Rational class and have infinite-precision arithmetic, for example.

That's a lot of power derived simply from using generic data
structures, not some panzy generic meta-Object that doesn't do
anything but tie people to an implicit type-theology.

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is the semantics meaning of 'object'?

[Mark Janssen]

>> Combining integers with sets I can make
>> a Rational class and have infinite-precision arithmetic, for example.
>
> Combining two integers lets you make a Rational.

Ah, but what is going to group them together?  You see you've already
gotten seduced.  Python already uses a set to group them together --
it's called a Dict and it's in every Class object.

> Python integers are
> already infinite-precision. Or are you actually talking of using
> "machine words" and sets as your fundamental?

Probably.  It depends on where we need the flexibility of the
abstraction and where the code is written.

>  Also, you need an
> ordered set - is the set {5,3} greater or less than the set {2} when
> you interpret them as rationals?

The ordering (and hence the interpretation) is done WITHIN the Class
(i.e. the SET as I say above).

> One must assume, I suppose, that any
> one-element set represents the integer 1, because any number divided
> by itself is 1.

Ah, very good, observation.  But that must remain an improper question.  ;^)

>> That's a lot of power derived simply from using generic data
>> structures, not some panzy generic meta-Object that doesn't do
>> anything but tie people to an implicit type-theology.
>
> Sure. And if you want assembly language, you know where to find it.

Well you've been spoiled by all the work that came before you.  The
issue now is not to go "back to the machine" so much as to tear down
and build up again from raw materials, objects of more and more
complexity where very complex "meta-objects" upon meta-objects can be
built until the "whole of human knowledge can be contained".

Did you ever hear of the Glass Bead Game?
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is the semantics meaning of 'object'?

[Mark Janssen]

>> Here's how it *should* be made:  the most superest, most badassed
>> object should take care of its children.  New instances should
>> automatically call up the super chain (and not leave it up to the
>> subclasses), so that the parent classes can take care of the chil'en.
>>  When something goes wrong the parent class has to look in and see
>> what's wrong.
>
> So what you're saying is that the first class defined does everything,
> and subclasses _restrict_ what can be done? I disagree strongly:

That's right.  Just as the *machine* restricts what can be done.  It's
an upturning of the purity model and going back to practicality.

> 1) That breaks the Liskov Substitution Principle. A subclass of list
> ought to fulfill the contracts of a basic list.

We don't need LSP.  I write about this on the WIkiWikiWeb where there
were many arguments documented and many hairs frazzled.  LSP was
derived from AlanKay's abstract idea of "Everything is an object".
But no -- there is a *physics* for information, and it ends at the
machine types.

> 2) It implies that someone can invent an all-encompassing superclass
> before any subclassing is done.

No, we start with basic types and work upwards.  The
"all-encompassing" superclass it an all-encompassing data object:  in
mathematics, it's called a SET -- and mathematics has already done the
work to prove that it's the most generic and all-encompassing, a field
of SET THEORY.

> This kinda violates the laws of
> information. Programmers, being creative entities, will be adding to
> the pool of knowledge. Trying to shoehorn everything into one object
> won't work.

No, we don't need programmers adding to the "pool of knowledge" -- the
internet does that.  We need programmers making data objects that can
present data in new and more interesting ways -- starting from basic
principles.

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is the semantics meaning of 'object'?

[Mark Janssen]

>>> Combining two integers lets you make a Rational.
>>
>> Ah, but what is going to group them together?  You see you've already
>> gotten seduced.  Python already uses a set to group them together --
>> it's called a Dict and it's in every Class object.
>
> When you inherit a "set" to make a Rational, you're making the
> statement (to the interpreter, if nothing else) that a Rational is-a
> set.

No you don't *inherit* a set to make a Rational, although you gain a
set to make it.  It's a subtle thing, because at the center of it
articulates the very difference between a piece of data and a
container to hold that data.  Or is the container the data?

C++ already solves this di-lemma.  It made "class" which is exactly
like a "struct", but hides all it's data members.  That critical
distinction makes all the difference.  I don't know how many people on
the list really appreciate it.

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is the semantics meaning of 'object'?

[Mark Janssen]

> On 26/06/2013 9:19 AM, Mark Janssen wrote:
>>
>> Did you ever hear of the Glass Bead Game?
>
> Which was Hesse's condemnation of the
> pure-academic-understanding-unbound-by-pragmatic-use approach as mental
> masturbation,

It was not.  He was conflicted.  On the one hand he knew the
enterprise was noble, but on the other he saw it could lead to crystal
palaces that were good to nobody.
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to calculate reputation

[Mark Janssen]

> Hi all, this seems to be quite stupid question but I am "confused"..
> We set the initial value to 0, +1 for up-vote and -1 for down-vote! nice.
>
> I have a list of bool values True, False (True for up vote, False for
> down-vote).. submitted by users.
>
> should I take True = +1, False=0  [or] True = +1, False=-1 ?? for adding
> all.
>
> I am missing something here.. and that's clear.. anyone please help me on
> it?

If False is representing a down-vote, like you say, then you have to
incorporate that information, in which case False=-1  ==> a user not
merely ignored another user, but marked him/her down.

MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Documenting builtin methods

[Mark Janssen]

> I have this innocent and simple code:
>
> from collections import deque
> exhaust_iter = deque(maxlen=0).extend
> exhaust_iter.__doc__ = "Exhaust an iterator efficiently without
> caching any of its yielded values."
>
> Obviously it does not work. Is there a way to get it to work simply
> and without creating a new scope (which would be a rather inefficient
> a way to set documentation, and would hamper introspection)?
>
> How about dropping the "simply" requirement?

I think the canonical way to specialize a class (even if it's only
docstrings or method re-names) is to extend it with a new class.

markj
-- 
http://mail.python.org/mailman/listinfo/python-list

Casting classes WAS: Documenting builtin methods

[Mark Janssen]

A user was wondering why they can't change a docstring in a module's class.

This made me think: why not have a casting operator ("reciprocal"?) to
transform a bonafide class into a mere carcass of a class which can
then modified and reanimated back into its own type with the type
function?  Such that "type(reciprocal(myClass))==myClass"...

reciprocal(myClass) returns a writeable, nonproxy class.__dict__
(perhaps also a list of its bases and name)

Just a thought to consider...

MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Beowulf clusters

[Mark Janssen]

On Sun, Jan 13, 2013 at 8:19 PM, Oscar Benjamin
 wrote:
> On 14 January 2013 02:10, Mark Janssen  wrote:
>> Has anyone used python for high-performance computing on Beowulf clusters?
>
> Yes.

How did they deal with the Global interpreter lock across many machines?

Cheers,

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Beowulf clusters

[Mark Janssen]

On Sun, Jan 13, 2013 at 8:37 PM, Oscar Benjamin
 wrote:
> On 14 January 2013 02:33, Mark Janssen  wrote:
>> Lol, well that's why I'm asking.  I don't see how they can do it
>> without considerable difficulties.
>
> What do you want the GIL for across machines? The normal purpose of
> the GIL is to preserve the integrity of Python's in-memory data
> structures. These are only accessible within one process so what good
> would a multi-process GIL be?

Excuse me, I actually thought you knew what you were talking about.  A
Beowulf cluster, by it's nature, is across many-machines.  Now you
can't have a GIL and a single python program across many-machines
without some tricks.  I'm just wondering how (or if) they solved that
problem

mark
-- 
http://mail.python.org/mailman/listinfo/python-list

atexit handler in IDLE?

[Mark Janssen]

On Tue, Jan 15, 2013 at 6:25 AM, Steve Spicklemire  wrote:
> I'm trying to get this program, which works on the command line, to run 
> correctly in the IDLE environment:
>
> import atexit
>
> print "This is my program"
>
> def exit_func():
> print "OK.. that's all folks!"
>
> atexit.register(exit_func)
>
> print "Program is ending..."

You know, I think I looked at this problem once.  It was rather
strange, but I think you need to create a tempfile, so that Python
knows that IDLE is running.   There's an item for this in IDLE's TODO
list.  I was going to implement it, which is fairly east, but never
got to it.

mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Newbie - Trying to Help a Friend

[Mark Janssen]

> Think they just needed a starting point really to be honest as they can't get 
> there head round it.

Then the problem is that your friend doesn't understand one or more of
the words being used.  This is s necessary prerequisite for making an
algorithm from a text description.  Perhaps they don't know what it
means to be "divisible".

-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Extending the 'function' built-in class

[Mark Janssen]

> Hi, I can't figure out how I can extend the 'function' built-in class. I 
> tried:
>   class test(function):
> def test(self):
>   print("test")
> but I get an error. Is it possible ?

It has to do with differing models of computation, and python isn't
designed for this.  Perhaps you're searching for the ultimate lambda?.
-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: interactive help on the base object

[Mark Janssen]

>>> Is it just me, or is this basically useless?
>>>
>>> class object
>>>  |  The most *base* type
>>
[[Terry Reedy:]]
> How about something like.
> The default top *superclass* for all Python classes.

How 'bout you foos just admit that you didn't realize you've been
confused this whole time?  (It *is* possible isn't it?)

Mr. Ewing says "base" has to be interpreted as an *adjective* because
otherwise it would mean the BOTTOM (like the BASE of the pyramid),
while Terry responds that it is the TOP (*super*class).  Earlier,
Steven D'Aprano wanted to argue that this distinction was irrelevant,
but obviously it can't very well be both at once now cannit?

Could-the-world-be-so-crazy-confused-and-then-shoot-the-messenger?

Sadly, yes.

MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: interactive help on the base object

[Mark Janssen]

On Sun, Dec 8, 2013 at 2:33 AM, Steven D'Aprano
 wrote:
> On Sat, 07 Dec 2013 20:21:06 -0800, Mark Janssen wrote:
>
>>>>> Is it just me, or is this basically useless?
>>>>>
>>>>> class object
>>>>>  |  The most *base* type
>>>>
>> [[Terry Reedy:]]
>>> How about something like.
>>> The default top *superclass* for all Python classes.
>>
>> How 'bout you foos just admit that you didn't realize you've been
>> confused this whole time?  (It *is* possible isn't it?)
>>
>> Mr. Ewing says "base" has to be interpreted as an *adjective* because
>> otherwise it would mean the BOTTOM (like the BASE of the pyramid), while
>> Terry responds that it is the TOP (*super*class).  Earlier, Steven
>> D'Aprano wanted to argue that this distinction was irrelevant,
>
> What are you talking about? Until this very post, I haven't made any
> comments in this thread.

It was a few months ago.  You do know what I'm talking about because
you just expounded with the exact same argument below.  It's like a
broken record.  (Now if *I* sound like a broken record, it's because
no seems to see the obvious, but carry on.)

>> but obviously it can't very well be both at once now cannit?
>
> Family trees and other hierarchies, including class inheritance diagrams,
> have a *relative* direction not an absolute direction. We can all agree
> that Fred and Wilma are the parents of Pebbles, but it doesn't really
> matter whether we draw the family tree like this:
>
>
> Fred  Wilma  (diagrams best viewed in a fixed-width font
>   | | like Courier, Monaco or Lucinda Typewriter)
>   +++
>|
> Pebbles
>
>
> (inheritance goes *down* the page from ancestors to descendants)
>
> or like this:
>
> Pebbles
>|
>   +++
>   | |
> Fred  Wilma
>
>
> (inheritance goes *up* the page from ancestors to descendants).
>
> What matters is the relationships between the entities, not the specific
> direction they are drawn in relative to some imaginary absolute space.
> [yadda, yagni, yadda]

But, there IS A DIFFERENCE.  Let me explain the concept of a object
model (or "type model" if you prefer).

In a family inheritance tree,  there is this difference -- called the
"calendar" --  which imposes an ordering which can't be countermanded
by flipping your silly chart around.  You made a bullshit example to
simply argue a point and *fooled yourself* into ignoring this.  Yes?

Likewise, WITH A COMPUTER, there is a definite order which can't be
countermanded by simply having this artifice called "Object".  If you
FEE(L)s hadn't noticed (no longer using the insult "foo"s out of
respect for the sensativities of the brogrammers), this artifice has
just been *called on the floor* with this little innocent question
that fired up this discussion again (don't hate the messenger).
Again:  people entering the community are pointing out a problem --
that Object is both trying to be the BASE and the SUPERclass of all
objects.

CS554: A type/object *model* has to define the relationship of these
nice abstractions so that they can be mapped to the *actual
concreteness* of the machine.  And there, bro, there is an ordering.
You're not going to magically flip the hierarchy so that your bitless
Object becomes a machine word that is the base of all your types.
You've been fooled by the magic of the Turing Machine.   The modern
computer mollifies you with the illusion of "total abstraction" where
there are no bits or 1s and 0s involved, but yea, it did not turn out
that way.  (Note bene: as a comparison, C++ is very UNAMBIGUOUS about
this fact -- all objects inherit from concrete machine types, which is
why it remains important, *despite* being one of the worst to do OOP
in.  Its *type model* is probably the most clear of any
object-oriented language).

> Likewise it doesn't matter whether we draw class hierarchies from the top
> down or the bottom up or even sidewise:

Have you caught it by now, friends:  IT MATTERS TO THE COMPUTER.
With some apologies for Ned for attempting to be neutral.   Apparently
you guys are philosophers more than Computer Engineers.

MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: interactive help on the base object

[Mark Janssen]

  >>> help(object)
 Help on class object in module builtins:

 class object
   |  The most base type
>
>>> '''The default top superclass for all Python classes.
>>> Its methods are inherited by all classes unless overriden.
>>> '''
>
> """ The root class for all Python classes. Its methods are inherited by
> all classes unless overriden. """

*sits back*.
-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: interactive help on the base object

[Mark Janssen]

>> What methods, if any does it provide?  Are they all abstract? etc???
>
> Pretty much nothing useful :-)
>
> py> dir(object)
> [...]
>

So (prodding the student), Why does everything inherit from Object if
it provides no functionality?

Practicality-beats-purity-yours?

-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: interactive help on the base object

[Mark Janssen]

On Sun, Dec 8, 2013 at 6:44 PM, Chris Angelico  wrote:
> On Mon, Dec 9, 2013 at 10:01 AM, Mark Janssen  
> wrote:
>> (Note bene: as a comparison, C++ is very UNAMBIGUOUS about
>> this fact -- all objects inherit from concrete machine types, which is
>> why it remains important, *despite* being one of the worst to do OOP
>> in.  Its *type model* is probably the most clear of any
>> object-oriented language).
>
> Factually wrong. In C++, it is actually *impossible* to inherit from a
> "concrete machine type", by which presumably you mean the classic
> types int/char/float etc.

Wow, you guys trip me out, but I guess I've been working in a
different universe where I was mapping classes into basic types (using
generic programming along with typedef).  I'm going to have to
re-think all this confusion.

But, in any case, if you don't have a way to map your abstract objects
into machine types, you're working on magic, not computer science.

MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "More About Unicode in Python 2 and 3"

[Mark Janssen]

>> Most of the complaints about Py3 are "it's harder to get something
>> started (or port from Py2)". My answer is that it's easier to get
>> something finished.
>
> I like all of this logic, it makes sense to me.  But Armin and Kenneth have
> more experience than I do actually writing networking software. They are
> both very smart and very willing to do a ton of work.  And both are unhappy.
> I don't know how to square that with the logic that makes sense to me.
>
> And no amount of logic about why Python 3 is better is going to solve the
> problem of the two of them being unhappy.  They are speaking from experience
> working with the actual product.

+1, well-said.

I hope you'll see my comments on the thread on the "bytestring type".
This issue also goes back to the schism in 2004 from the VPython folks
over floating point.  Again the ***whole*** issue is ignoring the
relationship between your abstractions and your concrete architectural
implementations.  I honestly think Python3 will have to be regressed
despite all the circle jerking about how "everyone's moving to Python
3 now".  I see how I was inadequately explaining the whole issue by
using high-level concepts like "models of computation", but the
comments on the aforementioned thread go right down to the heart of
the issue.

markj
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "More About Unicode in Python 2 and 3"

[Mark Janssen]

> The argument is that a very important, if small, subset a data manipulation
> become very painful in Py3.  Not impossible, and not difficult, but painful
> because the mental model and the contortions needed to get things to work
> don't sync up anymore.

You are confused.  Please see my reply to you on the bytestring type thread.

> Painful because Python is, at heart, a simple and
> elegant language, but with the use-case of embedded ascii in binary data
> that elegance went right out the window.

It went out the window only because the Object model with the
type/class unification was wrong.  It was fine before.

Mark

>> It can't be both things. It's either bytes or it's text.
>
> Of course it can be:
>
> 000: 0372 0106   6100 1d00    .r..a...
> 010:          
> 020: 4e41 4d45    0043 0100   NAME...C
> 030: 1900         
> 040: 4147 4500    004e 1a00   AGEN
> 050: 0300         
> 060: 0d1a 0a  ...
>
> And there we are, mixed bytes and ascii data.

No, you are printing a debug output which shows both.  That's called CHEATING.

Mark
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "More About Unicode in Python 2 and 3"

[Mark Janssen]

>> Chris didn't say "bytes and ascii data", he said "bytes and TEXT".
>> Text != "ascii data", and the fact that some people apparently think it
>> does is pretty much the heart of the problem.
>
> The heart of a different problem, not this one.  The problem I refer to is
> that many binary formats have well-defined ascii-encoded text tidbits.

Really?  If people are using binary with "well-defined ascii-encoded
tidbits", they're doing something wrong.  Perhaps you think escape
characters "\n" are "well defined tidbits", but YOU WOULD BE WRONG.
The purpose of binary is to keep things raw.  WTF?  You guys are so
strange.

>
>> If you (generic you) don't get that, you'll have a bad time. I mean
>> *really*
>> get it, deep down in the bone. The long, bad habit of thinking as
>> ASCII-encoded bytes as text is the problem here.

I think the whole forking community is confused at because of your own
arrogance.  Foo(l)s.

markj
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: the Gravity of Python 2

[Mark Janssen]

> http://blog.startifact.com/posts/python-2-gravity.html
>
> "A Way Forward - How to go forward then? I think it makes sense to work as
> hard as possible to lift those Python 2 codebases out of the gravity well."
>
> I think this is complete nonsense.  There's only been five years since the
> first release of Python 3.  Surely much more time should be made available
> for people using Python 2 to plan for a migration?

What makes no sense is that you've started a whole 'nother thread on
an issue whose gravity is right here, already on the list.  Add your
new commentary and links to existing threads would be easier, yes?

Mark unLawrence
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "More About Unicode in Python 2 and 3"

[Mark Janssen]

> Looks like another bad batch, time to change your dealer again.

??? Strange, when the debate hits bottom, accusations about doing
drugs come up.  This is like the third reference (and I don't even
drink alcohol).

mark
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "More About Unicode in Python 2 and 3"

[Mark Janssen]

>> Really?  If people are using binary with "well-defined ascii-encoded
>> tidbits", they're doing something wrong.  Perhaps you think escape
>> characters "\n" are "well defined tidbits", but YOU WOULD BE WRONG.
>> The purpose of binary is to keep things raw.  WTF?

> If you want to participate in this discussion, do so.  Calling people
> strange, arrogant, and fools with no technical content is just rude. Typing
> "YOU WOULD BE WRONG" in all caps doesn't count as technical content.

Ned -- IF
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "More About Unicode in Python 2 and 3"

[Mark Janssen]

>> Really?  If people are using binary with "well-defined ascii-encoded
>> tidbits", they're doing something wrong.  Perhaps you think escape
>> characters "\n" are "well defined tidbits", but YOU WOULD BE WRONG.
>> The purpose of binary is to keep things raw.  WTF?
>
> If you want to participate in this discussion, do so.  Calling people
> strange, arrogant, and fools with no technical content is just rude. Typing
> "YOU WOULD BE WRONG" in all caps doesn't count as technical content.

Ned -- IF YOU'RE A REAL PERSON -- you will see that several words
prior to that declaration, you'll find (or be able to arrange) the
proposition: "Escape characters are well-defined tidbits of binary
data is FALSE".

Now that is a technical point that i'm saying is simply the "way
things are" coming from the mass of experience held by the OS
community and the C programming community which is responsible for
much of the world's computer systems.  Do you have an argument against
it, or do you piss off and argue against anything I say?? Perhaps I
said it too loudly, and I take responsibility for that, but don't
claim I'm not making a technical point which seems to be at the heart
of all the confusion regarding python/python3 and str/unicode/bytes.

mark
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "More About Unicode in Python 2 and 3"

[Mark Janssen]

>> I would still point out that "Kenneth and Armin" are not the whole Python
>> community.
>
> I never said they were the whole community, of course. But they are not
> outliers either.  [...]
>
>> Your whole argument seems to be that a couple "revered" (!!)
>> individuals should see their complaints taken for granted. I am opposed to
>> rockstarizing the community.
>
> I'm not creating rock stars.  I'm acknowledging that these two people are
> listened to by many others.  It sounds like part of your effort to avoid
> rockstars is to ignore any one person's specific feedback?  I must be
> misunderstanding what you mean.

To Ned's defense, it doesn't always work to treat everyone in the
community as equal.  That's not to say that those two examples are the
most important, but some people work on core aspects of the field
which are critical for everything else to work properly.  Without
diving into it, one can't say whether Ned's intuition is wrong or not.

markj
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Language design

[Mark Janssen]

> * Imports are fiendishly complex, hidden below deceptively simple
>   syntax.
>
>   It's a reasonable expectation that one can import a module from a
>   source code file given its path on the filesystem, but this turns out
>   to be much more complicated than in many other languages.

Why is this so difficult?  Add a Graph class to the collections module
(networkx is quite good) and simply check for circular imports.  The
remaining difficulty I encounter is because the user hasn't defined
their PYTHONPATH variable.

-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Language design

[Mark Janssen]

1) It tried to make Object the parent of every class.  No one's close
enough to God to make that work.
2) It didn't make dicts inherit from sets when they were added to Python.
3) It used the set literal for dict, so that there's no obvious way to
do it.  This didn't get changed in Py3k.
4?) It allowed [reference] variables to be used as dict keys.  This
creates a parsing difficulty for me, mentally.  Keys should be direct,
hashable values, not hidden in a variable name.

A few of the top of the head

Mark

On Mon, Sep 9, 2013 at 11:09 PM, Steven D'Aprano  wrote:
> Some time ago, Tom Christiansen wrote about the "Seven Deadly Sins of
> Perl":
>
> http://www.perl.com/doc/FMTEYEWTK/versus/perl.html
>
>
> What design mistakes, traps or gotchas do you think Python has? Gotchas
> are not necessarily a bad thing, there may be good reasons for it, but
> they're surprising.
>
> To get started, here are a couple of mine:
>
>
> - Python is so dynamic, that there is hardly anything at all that can be
> optimized at compile time.
>
> - The behaviour of mutable default variables is a gotcha.
>
> - Operators that call dunder methods like __add__ don't use the same
> method resolution rules as regular methods, they bypass the instance and
> go straight to the type, at least for new-style classes.
>
>
>
> --
> Steven
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Language design

[Mark Janssen]

>> On Tue, 10 Sep 2013, Ben Finney wrote:
>> >  The sooner we replace the erroneous
>> >  “text is ASCII” in the common wisdom with “text is Unicode”, the
>> >  better.
>>
>> I'd actually argue that it's better to replace the common wisdom with
>> "text is binary data, and we should normally look at that text through
>> Unicode eyes". A little less catchy, but more accurate ;)
>
> No, that's inaccurate. A sequence of bytes is binary data. Unicode is
> not binary data.

Well now, this is an area that is not actually well-defined.  I would
say 16-bit Unicode is binary data if you're encoding in base 65,536,
just as 8-bit ascii is binary data if you're encoding in base-256.
Which is to say:  there is no intervening data to suggest a TYPE.
-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Language design

[Mark Janssen]

>> Why is this so difficult?
>> Add a Graph class to the collections module (networkx is quite good)
>> and simply check for circular imports.
>
> Er? That doesn't address the task of importing a module from a source
> code file given its path on the filesystem.

That's true, I guess was hooked on Python's abstraction mechanism for
making the file system invisible.  But I like the idea of programming
*relative* path addressing, so you can create a sort of "name space"
for your modules.  So instead of "import /path/to/file.py" which makes
a system dependency (i.e. *yours*), you could have "import
TestPackage.collections.bag" (using periods for file path separators
in keeping with the Pythonic Way).

-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Language design

[Mark Janssen]

> Unicode is not 16-bit any more than ASCII is 8-bit. And you used the
> word "encod[e]", which is the standard way to turn Unicode into bytes
> anyway. No, a Unicode string is a series of codepoints - it's most
> similar to a list of ints than to a stream of bytes.

Okay, now you're in blah, blah land.

--mark
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Language design

[Mark Janssen]

>> 1) It tried to make Object the parent of every class.
>
> Tried, and succeeded.

Really?  Are you saying you (and the community at-large) always derive
from Object as your base class?

>> No one's close enough to God to make that work.
>
> Non-sequitor. One doesn't need to be close to a deity to have a single
> root of the object hierarchy.

But wait is it the "base" (at the bottom of the hierarchy) or is it
the "parent" at the top?  You see, you, like everyone else has been
using these terms loosely, confusing yourself.

>> 2) It didn't make dicts inherit from sets when they were added to
>> Python.
>
> Why would you want dicts to inherit from sets?

A dict is-a set of {key:object, key:object} pairs bound together with
a colon ":".  By inheriting from sets you get a lot of useful
functionality for free.  That you don't know how you could use that
functionality is a failure of your imagination, not of the general
idea.

>> 3) It used the set literal for dict, so that there's no obvious
>> way to do it.  This didn't get changed in Py3k.
>
> No, it uses the dict literal for dicts.

Right.  The dict literal should be {:} -- the one obvious way to do
it.  Pay me later.

> And the obvious way to form an empty set is by calling set(), the same as
> str(), int(), list(), float(), tuple(), dict(), ...

Blah, blah.  Let me know when you got everyone migrated over to Python.v3.

>> 4?) It allowed
>> [reference] variables to be used as dict keys.  This creates a parsing
>> difficulty for me, mentally.  Keys should be direct, hashable values,
>> not hidden in a variable name.
>
> I don't even understand what you are talking about here. "[reference]
> variables"? What does that mean?

It's a just a tricky point, that I will wait to comment on.

--mark
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Language design

[Mark Janssen]

>> Really?  Are you saying you (and the community at-large) always derive
>> from Object as your base class?
>
> Not directly, that would be silly.

Silly?  "Explicit is better than implicit"... right?

>> But wait is it the "base" (at the bottom of the hierarchy) or is it the
>> "parent" at the top?  You see, you, like everyone else has been using
>> these terms loosely, confusing yourself.
>
> Depends on whether I'm standing on my head or not.
>
> Or more importantly, it depends on whether I visualise my hierarchy going
> top->down or bottom->up. Both are relevant, and both end up with the
> *exact same hierarchy* with only the direction reversed.

Ha,  "only the direction reversed".  That little directionality that
you're passing by so blithely is the difference between whether you're
talking about galaxies or atoms.  Please.

The simplicity of Python has seduced you into making an "equivocation"
of sorts.  It's subtle and no one in the field has noticed it.  It
crept in slowly and imperceptively.

>> By inheriting from sets you get a lot of useful
>> functionality for free.  That you don't know how you could use that
>> functionality is a failure of your imagination, not of the general idea.
>
> No you don't. You get a bunch of ill-defined methods that don't make
> sense on dicts.

They are not necessarily ill-defined.  Keep in mind Python already
chose (way back in 1.x) to arbitrary overwrite the values in a key
collision.  So this problem isn't new.  You've simply adapted to this
limitation without knowing what you were missing.

 3) It used the set literal for dict, so that there's no obvious way to
 do it.  This didn't get changed in Py3k.
>>>
>>> No, it uses the dict literal for dicts.
>>
>> Right.  The dict literal should be {:} -- the one obvious way to do it.
>
> I don't agree it is obvious. It is as obvious as (,) being the empty tuple
> or [,] being the empty list.

You're just being argumentative.  If there are sets as built-ins, then
{:} is the obvious dict literal, because {} is the obvious one for
set.  You don't need [,] to be the list literal because there is no
simpler list-type.

>>> And the obvious way to form an empty set is by calling set(), the same
>>> as str(), int(), list(), float(), tuple(), dict(), ...
>>
>> Blah, blah.  Let me know when you got everyone migrated over to
>> Python.v3.
>
> What does this have to do with Python 3? It works fine in Python 2.

I mean, you're suggestions are coming from a "believer", not someone
wanting to understand the limitations of python or whether v3 has
succeeded at achieving its potential.

>>> I don't even understand what you are talking about here. "[reference]
>>> variables"? What does that mean?
>>
>> It's a just a tricky point, that I will wait to comment on.
>
> I'm looking forward to an explanation, as I'm intrigued.

Well, wer'e here at junior-high.  It will take some time
-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Language design

[Mark Janssen]

On Fri, Sep 13, 2013 at 4:57 PM, Chris Angelico  wrote:
> Evangelical vicar in want of a portable second-hand font. Would
> dispose, for the same, of a portrait, in frame, of the Bishop-elect of
> Vermont.
>
> I think you could quite easily reconstruct the formatting of that,
> based on its internal structure. Even in poetry, English doesn't
> depend on its formatting nearly as much as Python does;

(Just to dispose of this old argument:)  Both Python and English
depend on both syntactical, material delimiters and whitespace.  While
it may seem that Python depends more on whitespace than English, that
is highly contentious, poetry or not.  Take some literature, remove
all the tabs at paragraph start and CRs at paragraph-end so that it
all runs together and you'll find that it impossible to read -- you
just won't be able to enter into the universe that the author is
attempting to build.

-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Language design

[Mark Janssen]

>>>> Really?  Are you saying you (and the community at-large) always derive
>>>> from Object as your base class?
>>>
>>> Not directly, that would be silly.
>>
>> Silly?  "Explicit is better than implicit"... right?
>
> If I'm inheriting from str, I inherit from str explicitly:
>
> class MyStr(str): ...
>
> and then str in turn inherits from object explicitly. I certainly do not
> inherit from object and then re-implement all the string methods from
> scratch:

I know that.  Str already inherits from object (due to the language
definition).  Your inheritance from object is implied by your
inheritance from a child class (str), but note there is an implied
directionality:  you don't say str is the parent of object.  But tell
me this:  is str the superclass of object or is it the other way
around?

> class MyStr(object):
> def __new__(cls, value): ...
> def upper(self): ...
> def lower(self): ...
> # and so on...
>
> That would be ridiculous, and goes against the very idea of inheritance.
> But nor do I feel the need to explicitly list the entire superclass
> hierarchy:
>
> class MyStr(str, object):
> ...

Now you've lost your marbles.  You are arguing points that a python
programmer would not argue.  Now, since I know you to be a decent
python programmer, I can only conclude that your sanity is in
question.

> which would be silly. Only somebody who doesn't understand how
> inheritance works in Python would do that. There's simply no need for it,
> and in fact it would be actively harmful for larger hierarchies.

Explicitly inheriting from object ("class myBase(object):" rather than
"class myBase():") would not be "actively harmful" in any way.

>>>> But wait is it the "base" (at the bottom of the hierarchy) or is it
>>>> the "parent" at the top?  You see, you, like everyone else has been
>>>> using these terms loosely, confusing yourself.
>>>
>>> Depends on whether I'm standing on my head or not.
>>>
>>> Or more importantly, it depends on whether I visualise my hierarchy
>>> going top->down or bottom->up. Both are relevant, and both end up with
>>> the *exact same hierarchy* with only the direction reversed.
>>
>> Ha,  "only the direction reversed".  That little directionality that
>> you're passing by so blithely is the difference between whether you're
>> talking about galaxies or atoms.
>
> It makes no difference whether I write:
>
> atoms -> stars -> galaxies
>
> or
>
> galaxies <- stars <- atoms
>
> nor does it make any difference if I write the chain starting at the top
> and pointing down, or at the bottom and pointing up.

Here again, your sanity is questioned.  You are simply wrong.  Atoms
lie within galaxies, but galaxies do not lie within atoms (poetic
license excluded); i.e. there is a difference, whether your talking
about syntactically by the parser or conceptually by a human being.
Somewhere you have to put yourself in the middle.  And that point
defines how you relate to the machine -- towards abstraction (upwards)
or towards the concrete (to the machine itself).

>> The simplicity of Python has seduced you into making an "equivocation"
>> of sorts.  It's subtle and no one in the field has noticed it.  It crept
>> in slowly and imperceptively.
>
> Ah, and now we come to the heart of the matter -- people have been
> drawing tree-structures with the root at the top of the page for
> centuries, and Mark Janssen is the first person to have realised that
> they've got it all backwards.

I'll be waiting for your apology once you simply grasp the simple
(however inconvenient and unbelievable) truth. ;*)

>>>> By inheriting from sets you get a lot of useful functionality for
>>>> free.  That you don't know how you could use that functionality is a
>>>> failure of your imagination, not of the general idea.
>>>
>>> No you don't. You get a bunch of ill-defined methods that don't make
>>> sense on dicts.
>>
>> They are not necessarily ill-defined.  Keep in mind Python already chose
>> (way back in 1.x) to arbitrary overwrite the values in a key collision.
>> So this problem isn't new.  You've simply adapted to this limitation
>> without knowing what you were missing.
>
> No, Python didn't "arbitrarily" choose this behaviour.

Perhaps you don't recall the discussion.

> It is standard,
> normal behaviour for a key-value mapping, and it is the standard
> behaviour because it is th

Re: What minimum should a person know before saying "I know Python"

[Mark Janssen]

> I started Python 4 months ago. Largely self-study with use of Python 
> documentation, stackoverflow and google. I was thinking what is the minimum 
> that I must know before I can say that I know Python?

Interesting.  I would say that you must know the keywords, how to make
a Class, how to write a loop.  That covers about 85% of it.
-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tail recursion to while iteration in 2 easy steps

[Mark Janssen]

>> def fact(n): return 1 if n <= 1 else n * fact(n-1)
>>
>> into a tail recursion like
> [...]
>
> How do know that either "<=" or "*" didn't rebind the name "fact" to
> something else? I think that's the main reason why python cannot apply
> any procedural optimization (even things like inlining are impossible,
> or possible only under very conservative assumption, that make it
> worthless).

It's called "operator precedence".

-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tail recursion to while iteration in 2 easy steps

[Mark Janssen]

On Wed, Oct 2, 2013 at 1:23 PM, Alain Ketterlin  wrote:
> On 10/02/2013 08:59 PM, Mark Janssen wrote:
>>>>
>>>> def fact(n): return 1 if n <= 1 else n * fact(n-1)
>>>
>>> How do know that either "<=" or "*" didn't rebind the name "fact" to
>>> something else? I think that's the main reason why python cannot apply
>>> any procedural optimization
>>
>> It's called "operator precedence".
>
> Operator precedence is totally irrelevant here, you misunderstand what
> "bind" means.
>
> Imagine that you call fact(x) where x is an instance of the following class:
>
> class Strange:
>   ...
>   def __le__(dummy):
> global fact
> fact = someotherfun # this is "binding"
> return false
>
> i.e., executing "n<=1" calls __le__, which rebinds the name "fact" to
> someting else. Then, there is no recursive call at all. At the time
> fact(x-1) is executed, "fact" is not the same function any more.
>
> You cannot prevent this in python.


No, but you can't prevent a lot of bad moves in python.  What you just
did there is a total bonehead ("strange"?) of an idea.

-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tail recursion to while iteration in 2 easy steps

[Mark Janssen]

>> Part of the reason that Python does not do tail call optimization is
>> that turning tail recursion into while iteration is almost trivial, once
>> you know the secret of the two easy steps. Here it is.
>
> That should be a reason it _does_ do it - saying people should rewrite
> their functions with loops means declaring that Python is not really a
> multi-paradigm programming language but rather rejects functional
> programming styles in favor of imperative ones.

Yes, but that's fine.  A PL language that includes every programming
paradigm would be a total mess, if even possible.  Python has
functional programming where it does not conflict with its overall
design.  The only place I find that this is not the case is with
lambda, but that is now adequately fixed with the addition of the
ternary operator.

-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tail recursion to while iteration in 2 easy steps

[Mark Janssen]

>> That's fine. My point was: you can't at the same time have full
>> dynamicity *and* procedural optimizations (like tail call opt).
>> Everybody should be clear about the trade-off.
>
> Your wrong. Full dynamics is not in contradiction with tail call
> optimisation. Scheme has already done it for years. You can rebind
> names to other functions in scheme and scheme still has working
> tail call optimisatiosn.

Yeah, and this is where two models of computation have been conflated,
creating magical effects, confusing everybody.  I challenge you to get
down to the machine code in scheme and formally describe how it's
doing both.
-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tail recursion to while iteration in 2 easy steps

[Mark Janssen]

> Only that you've got a consistent, stable (and therefore,
> formalizable) translation from your language to the machine.  That's
> all.  Everything else is magic.  Do you know that the Warren
> Abstraction Engine used to power the predicate logic in Prolog into
> machien code for a VonNeumann machine is so complex, no one has
> understood it (or perhaps even verified it)?

Sorry, I mean the Warren Abstraction Machine (or WAM).  I refer you to
www.cvc.uab.es/shared/teach/a25002/wambook.pdf.

Now, one can easily argue that I've gone too far to say "no one has
understood it" (obviously), so it's very little tongue-in-cheek, but
really, when one tries to pretend that one model of computation can be
substituted for another (arguing *for* the Church-Turing thesis), they
are getting into troubling territory (it is only a thesis,
remember)

-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tail recursion to while iteration in 2 easy steps

[Mark Janssen]

On Mon, Oct 7, 2013 at 4:50 PM, Steven D'Aprano
 wrote:
> On Mon, 07 Oct 2013 15:47:26 -0700, Mark Janssen wrote:
>> I challenge you to get
>> down to the machine code in scheme and formally describe how it's doing
>> both.
>
> For which machine?

Right, I should stop assuming a modern implementation of vonNeumann
architecture (even though that, too, is ambiguous) since I'm talking
about theory, but yet it is relevant.  My demarcation point for
arguments between "the scheme way" and other procedural languages
(which, apart from Pascal variants, I blithely all "the C way") gets
down to differing models of computation which shouldn't get conflated,
even though everyone thinks and lumps it all as "computation".  They
simply can't get *practically* translated between one and the other,
even though they are *theoretically* translated between each other all
the time.  Humans, of course know how to translate, but that doesn't
count from the pov of computer *science*.

> Frankly, asking somebody to *formally* describe a machine code
> implementation strikes me as confused. Normally formal descriptions are
> given in terms of abstract operations, often high level operations,
> sometimes *very* high level, and rarely in terms of low-level "flip this
> bit, copy this byte" machine code operations. I'm not sure how one would
> be expected to generate a formal description of a machine code
> implementation.

It's like this: there *should* be one-to-one mappings between the
various high-level constructs to the machine code, varying only
between different chips (that is the purpose of the compiler after
all), yet for some operations, in languages like scheme, well... I
cannot say what happens...  hence my challenge.

> But even putting that aside, even if somebody wrote such a description,
> it would be reductionism gone mad. What possible light on the problem
> would be shined by a long, long list of machine code operations, even if
> written using assembly mnemonics?

Only that you've got a consistent, stable (and therefore,
formalizable) translation from your language to the machine.  That's
all.  Everything else is magic.  Do you know that the Warren
Abstraction Engine used to power the predicate logic in Prolog into
machien code for a VonNeumann machine is so complex, no one has
understood it (or perhaps even verified it)?   One hardly knows where
these things originate.  But here it gets into dark arts best not
entered into too deeply.  It will turn you mad, like that guy in the
movie "pi".

-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tail recursion to while iteration in 2 easy steps

[Mark Janssen]

>>> But even putting that aside, even if somebody wrote such a description,
>>> it would be reductionism gone mad. What possible light on the problem
>>> would be shined by a long, long list of machine code operations, even
>>> if written using assembly mnemonics?
>>
>> Only that you've got a consistent, stable (and therefore, formalizable)
>> translation from your language to the machine.
>
> You are mistaken to think that there is a single, one-to-one, mapping
> between high-level code and machine code.

It's not mistaken.  Given a stable and formalized language definition,
there should only be continued optimization of the lexical and
procedural constructs into better machine code. In the case of an
"interpreted" language like Python (which I'll define as a language
which includes a layer of indirection between the user and the
machine, encouraging the nice benefits of interactivity), such
optimization isn't really apropos, because it's not the purpose of
python to be optimal to the machine as much as "optimal to the
programmer".  In any case, while such optimization can continue over
time, they generally create new compiler releases to indicate such
changes.  The one-to-one mapping is held by the compiler.

Such determinism *defines* the machine, otherwise you might as well
get rid of the notion of computer *science*.  All else is error, akin
to cosmic rays or magic.  Unless the source code changes, all else
remaining equal, the machine code is supposed to be the same, no
matter how many times it is compiled.

>[Only if you use the exact source, compiler, switches, etc]] will the output 
>be the same.
> And even that is not guaranteed.

Oh, and what would cause such non-determinism?

> Take, for example, the single high-level operation:
>
> sort(alist)
>
> What machine code will be executed? Obviously that will depend on the
> sort algorithm used. There are *dozens*. Here are just a few:

Well, since you didn't specify your programming language, you're then
merely stating an English construct.  As such, there can be no single
mapping from English into the machine, which is why there are so many
different languages and experiments that map your [English] concepts
into source code.

> Now sorting is pretty high level, but the same principle applies to even
> simple operations like "multiply two numbers". There are often multiple
> algorithms for performing the operation, and even a single algorithm can
> often be implemented in slightly different ways. Expecting all compilers
> to generate the same machine code is simply naive.

You are both over-simplifying and complexifying things at once.  Pick one.

-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tail recursion to while iteration in 2 easy steps

[Mark Janssen]

>> Yeah, and this is where two models of computation have been conflated,
>> creating magical effects, confusing everybody.  I challenge you to get
>> down to the machine code in scheme and formally describe how it's
>> doing both.
>
> Which two models of computation are you talking about? And what magica; 
> effects?

Well, I delineate all computation involving predicates (like lambda
calculus) between those using digital logic (like C).  These realms of
computation are so different, they are akin to mixing the complex
numbers with the real.  Yet hardly anyone points it out (I've
concluded that hardly anyone has ever noticed -- the Church-Turing
thesis has lulled the whole field into a shortcut in thinking which
actually doesn't pan out in practice).

> AFAIK there is no magic in computer science, although every sufficiently 
> advanced ...

Ha!  That's very good.  I'm glad you catch the spirit of my rant.
"Any sufficiently advanced compiler can be substituted with magic to
the neophyte without a change in output."  A mini Liskov substitution.

-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Formal-ity and the Church-Turing thesis

[Mark Janssen]

> On Tuesday, October 8, 2013 5:54:10 AM UTC+5:30, zipher wrote:
>> Now, one can easily argue that I've gone too far to say "no one has
>> understood it" (obviously), so it's very little tongue-in-cheek, but
>> really, when one tries to pretend that one model of computation can be
>> substituted for another (arguing *for* the Church-Turing thesis), they
>> are getting into troubling territory (it is only a thesis,
>> remember)
>
> The CT thesis is scientific and provable in one sense and vague/philosophical 
> in another.
> The Science: Turing computability and lambda-computability are equivalent.
> The proofs just consist of writing interpreters for one in terms of the other.

Ah, good, a fellow theoretician.  Now it's nice that you use language
that makes it seem quite clear, but understand that there's a hidden,
subconscious, *cultural* encoding to your *statement*.  The use of the
term "equivalent", for example.  Equivalent for the programmer, or for
the machine?  (etc., et cetera), and further:  "writing interpreters
for one in terms of the other", but again, this will change depending
on your pragmatic requirements.  To the theorist, you've accomplished
something, but then that is a self-serving kind of accomplishment.  To
the programmer, operating under different requirements, you haven't
accomplished anything.  I don't have an infinite stack to implement
lambda calculus, but I can treat my computer's memory as a TM and
*practically* infinite and only rarely hit against the limits of
physicality.  This is just being "respectful"... ;^)

(For the purposes of discussion, if I make a word in CamelCase, I am
referring to a page on the WikiWikiWeb with the same name:
http://c2.com/cgi/wiki?WikiWikiWeb.)

> The philosophy: *ALL* computational models are turing equivalent (and 
> therefore lambda-equivalent) or weaker.
> The Idea (note not proof) is that for equivalence one can write 
> pair-interpreters like above. For the 'weaker' case, (eg DFA and TMs) one 
> proves that TMs can interpret DFAs and disproves the possibility of the other 
> direction.
>
> This must remain an idea (aka thesis) and not a proof because one cannot 
> conceive of all possible computational models.

Why not?  I can "conceive" of all possible integer numbers even if I
never "pictured" them.  Is there not an inductive way to conceive of
and define computation?  I mean, I observe that the field seems to
define several ModelsOfComputation.  Intuitively I see two primary
domains

> It is hard science however for all the models that anyone has so far come up 
> with.

And what of "interactive computation"?

> As for:
>
>> I challenge you to get down to the machine code in scheme and formally
>> describe how it's doing both.
>
> I can only say how ironic it sounds to someone who is familiar with the 
> history of our field:
> Turing was not a computer scientist (the term did not exist then) but a 
> mathematician.  And his major contribution was to create a form of argument 
> so much more rigorous than what erstwhile mathematicians were used to that he 
> was justified in calling that math as a machine.

Hmm, I'm wondering if my use of the word "formally" is confusing you.
In mathematics, this word has a subtly differing meaning, I think,
than in computer science.  Turing was "justified in calling that math
as a machine" because he was using a definition (the translation table
+ finite dictionary) such that it remained perfectly deterministic.

And here, again, one can easily gets mixed up using the same lexicon
across two different domains:  that of math and that of CS.  I advise
you to look at the dialog at ConfusedComputerScience.

> The irony is that today's generation assumes that 'some-machine' implies its 
> something like 'Intel-machine'.
> To get out of this confusion ask yourself: Is it finite or infinite?

But this only gets us out of the confusion for the mathematicians.
For the programmer and perhaps even the computer scientist (the one's
coming from physics), it is something different.

> If the TM were finite it would be a DFA

But this is not a useful formalism.  Any particular Program implements
a DFA, even as it runs on a TM.  The issue of whether than TM is
finite or not can be dismissed because a simple calculation can
usually suffice, or at least establish a range "usefulness" so as not
to "run out of memory".

> If the Intel-machine (and like) were infinite they would need to exist in a 
> different universe.

Ha, yeah.  Let us dismiss with that.

> And so when you understand that TMs are just a kind of mathematical rewrite 
> system (as is λ calculus as are context free grammars as is school arithmetic 
> etc etc) you will not find the equivalence so surprising

It's not that it's surprising, it's that it's *practically* a problem.
 The translation between one PL and another which assumes a different
model of computation can get intractible.

Maybe that makes sense

MarkJ
Tacoma, Washington
-- 
https://

Re: Formal-ity and the Church-Turing thesis

[Mark Janssen]

>> I don't have an infinite stack to implement
>> lambda calculus, but...
>
> And then
>
>> But this is not a useful formalism.  Any particular Program implements
>> a DFA, even as it runs on a TM.  The issue of whether than TM is
>> finite or not can be dismissed because a simple calculation can
>> usually suffice, or at least establish a range "usefulness" so as not
>> to "run out of memory".
>
> Having it both ways aren't you?

I'm just speaking from programmer experience and the fact that most
machines are VonNeumann architecture.  Being that as it is, maxing out
the stack simply happens, and I don't dare do any non-simple
recursion, but otherwise, practically speaking, I can calculate my
memory usage that may grow on the heap so that is effectively a
non-issue.  This may not be an important distinction for computing,
the "art" (Hello ultimate lambda friends), but it is significant for
the computing, the science.

MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

[Mark Janssen]

On Mon, Oct 14, 2013 at 12:18 PM, John Nagle  wrote:
> On 10/12/2013 3:37 PM, Chris Angelico wrote:
>> On Sat, Oct 12, 2013 at 7:10 AM, Peter Cacioppi
>>  wrote:
>>> Along with "batteries included" and "we're all adults", I think
>>> Python needs a pithy phrase summarizing how well thought out it is.
>>> That is to say, the major design decisions were all carefully
>>> considered, and as a result things that might appear to be
>>> problematic are actually not barriers in practice. My suggestion
>>> for this phrase is "Guido was here".
>>
>> "Designed".
>>
>> You simply can't get a good clean design if you just let it grow by
>> itself, one feature at a time.
>
> No, Python went through the usual design screwups.

I hesitate to poke my nose in here, but Python is fine.  No one knows
how to design the perfect language from the start, otherwise it would
be here.   But Python has set the precedent for allowing
backwards-incompatibility to fix language problems and that's what
will keep it from breaking.

> Look at how
> painful the slow transition to Unicode was, from just "str" to
> Unicode strings, ASCII strings, byte strings, byte arrays,

This is where I wish I could have been involved with the discussion,
but I was outside of civilization at the time, and was not able to
contribute.

> 16 and 31 bit character builds, and finally automatic switching
> between rune widths. Old-style classes vs. new-style classes.  Adding a
> boolean type as an afterthought (that was avoidable; C went through
> that painful transition before Python was created).Operator "+"
> as concatenation for built-in arrays but addition for NumPy
> arrays.

All of this will get fixed, but the problem is that you are stirring
up issues without really understanding the problem.   The problem is
something that is at the bleeding-edge of Computer Science itself and
settling on a theory of types.  I've answered this by creating a
unified object model, but no one has understood why the hell anyone
needs one, so I'm sitting around waiting for a friend..

> Each of those reflects a design error in the type system which
> had to be corrected.

To call it a "design error" makes it seem like someone make a decision
that resulted in a mistake, but it isn't (wasn't) that simple.

> The type system is now in good shape. The next step is to
> make Python fast.

Woah, boy.  There's no reason to make an incomplete design faster, for
psuedo-problems that no one will care about in 5-10 years.  The field
has yet to realize that it needs an object model, or even what that
is.

> Python objects have dynamic operations suited
> to a naive interpreter like CPython.

Naive, no.

> These make many compile
> time optimizations hard. At any time, any thread can monkey-patch
> any code, object, or variable in any other thread.  The ability
> for anything to use "setattr()" on anything carries a high
> performance price.  That's part of why Unladen Swallow failed
> and why PyPy development is so slow.

Yes, and all of that is because, the world has not settled on some
simple facts.  It needs an understanding of type system.  It's been
throwing terms around, some of which are well-defined, but others,
not:  there has been enormous cross-breeding that has made mutts out
of everybody and someone's going to have to eat a floppy disk for
feigning authority where there wasn't any.

Mark J
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list