date:20150121

On Wednesday, January 21, 2015 at 1:27:39 PM UTC+5:30, Stephen Hansen wrote:
> On Tue, Jan 20, 2015 at 1:45 AM, Marko Rauhamaa  wrote:
> Terry Reedy :
> 
> 
> 
> > Others have answered as to why other special-purpose
> 
> > constrained-structure trees have not been added to the stdlib.
> 
> 
> 
> Ordered O(log n) mappings are not special-purpose data structures. I'd
> 
> say strings and floats are much more special-purpose than ordered
> 
> mappings, and yet Python has direct support for those.
> 
> 
> 
> Your anecdote is strong, sir.
> 
> 
> However, I use strings thousands of times, floats maybe a hundred of times, 
> and order mappings a few times.
> 
> 
> My anecdote counters yours.
> 
> 
> A tree structure is special purpose because there is a lot of options with 
> different characteristics that make certain implementations ideal in some 
> cases and not in others.
> 
> 
> A float is a float, there's a standard (IEEE 754?), its not special at all.
> 
> 
> A string, I suppose, could be special, but that's a pretty nonsense view of 
> the world since what most people use strings commonly. 
> 
> 
> I'm not arguing against including a tree, but I have no advice on which one, 
> and the one-- one!-- time I've needed a tree I got one off pypi. Not 
> everything needs to be in the stdlib.
> 
> 
> But to call strings and floats special purpose is really a silly argument to 
> make. 

Since we are trading anecdotes…

Among my teachers of CS, there were two – both brilliant — one taught me
Numerical Analysis, the other taught me programming.

[As it happens my initial practical programming was the numerical kind
because the Fortran compiler was more serviceable than the Pascal one.
But thats a different point]

The point is that the two of them disagreed strongly on what programming was
about.

The numerical analyst could see no earthly reason to use anything other than
Fortran.

The programmer had horror stories to tell about how Fortran damages the brain:
eg programs that inherently need a while-loop (eg binary search) seem to be
distinctly out of the reach of the Fortran programmer.  Recursion...
And much else.

The numerical analyst of course had no use for this philosophizing.

The view that strings and floats are more fundamental than containers and maps
reminds me of this view.

For me python is neat because I can write: [1,2,3]
when I want a list.

But it does not go nearly far enough.

I would like a set to be {1,2,3} or at worst ⦃1,2,3⦄
and a bag to be ⟅1,2,3⟆

Apart from the unicode niceness that Ive described here
http://blog.languager.org/2014/04/unicoded-python.html

Its a bit of a nuisance that we have to write set([1,2,3]) for the first

More irksome that for the second we've to preface with

from collections import Counter

And still more a PITA that a straightforward standard name like bag (or 
multiset)
is called by such an ungoogleable misleading name as counter.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Trees

On Wed, Jan 21, 2015 at 11:09 PM, Rustom Mody  wrote:
> I would like a set to be {1,2,3} or at worst ⦃1,2,3⦄
> and a bag to be ⟅1,2,3⟆
>
> Apart from the unicode niceness that Ive described here
> http://blog.languager.org/2014/04/unicoded-python.html
>
> Its a bit of a nuisance that we have to write set([1,2,3]) for the first

Wait, what?

rosuav@sikorsky:~$ python
Python 2.7.3 (default, Mar 13 2014, 11:03:55)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> type({1,2,3})

>>>
rosuav@sikorsky:~$ python3
Python 3.5.0a0 (default:4709290253e3, Jan 20 2015, 21:48:07)
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> type({1,2,3})

>>>

Looks like {1,2,3} works for me.

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

Re: Trees

On 2015-01-21 23:35, Chris Angelico wrote:
> On Wed, Jan 21, 2015 at 11:09 PM, Rustom Mody wrote
> > Its a bit of a nuisance that we have to write set([1,2,3]) for
> > the first
> 
> Wait, what?
> 
> rosuav@sikorsky:~$ python
> Python 2.7.3 (default, Mar 13 2014, 11:03:55)
> [GCC 4.7.2] on linux2
> Type "help", "copyright", "credits" or "license" for more
> information.
> >>> type({1,2,3})
> 
> >>>
> rosuav@sikorsky:~$ python3
> Python 3.5.0a0 (default:4709290253e3, Jan 20 2015, 21:48:07)
> [GCC 4.7.2] on linux
> Type "help", "copyright", "credits" or "license" for more
> information.
> >>> type({1,2,3})
> 
> >>>
> 
> Looks like {1,2,3} works for me.

That hasn't always worked:

tim@bigbox:~$ python2.5
Python 2.5.5 (r255:77872, Nov 28 2010, 16:43:48) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> type({1,2,3})
  File "", line 1
type({1,2,3})
   ^
SyntaxError: invalid syntax

tim@bigbox:~$ python2.6
Python 2.6.8 (unknown, Jan 26 2013, 14:35:25) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> type({1,2,3})
  File "", line 1
type({1,2,3})
   ^
SyntaxError: invalid syntax

And, prior to 2.4, you had to write

  from sets import Set as set

to even get sets.

  https://docs.python.org/2/whatsnew/2.4.html#pep-218-built-in-set-objects

-tkc












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

Re: Trees

On Wed, Jan 21, 2015 at 11:55 PM, Tim Chase
 wrote:
> On 2015-01-21 23:35, Chris Angelico wrote:
>> On Wed, Jan 21, 2015 at 11:09 PM, Rustom Mody wrote
>> > Its a bit of a nuisance that we have to write set([1,2,3]) for
>> > the first
>>
>> Looks like {1,2,3} works for me.
>
> That hasn't always worked:

Sure, but "we have to write" implies current status; Python 2.7 was
released in 2010, so I would expect that anyone who's complaining
about set notation should have access to it. Even if it didn't work in
2.7 and you had to use 3.x, the argument's still fairly weak when it's
alongside a pipe-dream desire to use specific mathematical Unicode
characters in source code, because that's clearly a 3.x-only feature
(where source code is Unicode text rather than ASCII).

Nobody's going to moan "It's silly that we have to use 1 and 0 instead
of nice keywords True and False" on the basis that True and False
didn't exist in Python 2.0. At very least, use 2.7 before you
complain; preferably, use 3.4 (or 3.5).

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

Re: Trees


Hello Terry,


It is not play with words. A tree is a recursive - nested -
hierachical
data structure with the restriction of no cycles or alternate
pathways.
Python collections whose members are general objects, including
collections, can be nested.  The resulting structures *are* tree
structures, if not more general directed graphs.  They are quite
commonly used in Python.


Let's get somethig clear. Tree data structures have an associated logic that 
justifies their name as a de facto Tree Data Structure. If your low level 
description was how you described a tree to someone new to the concept, they 
would be none the wiser about what a Tree represents or what uses they could 
have for them. This logic is no different from the internal logic that diferentiates 
a dictionary from a list and helps carry their distinct operations. Despite 
a dictionary being nothing more than a glorified list.


Just as well, tree data structures only make sense along with their logic. 
Storage, traversal, insertion, random searches, retrieval, etc, all these 
algorithms are what in the end define a Tree data structure and what will 
help categorize it. Python standard library doesn't have any tree data structure 
implementation. It has lists, dictionaries, and other base structures that 
in the end will help define storage patterns for tree data structures. And 
that's it.


A simple binary tree needs to be implemented in Python as a binary tree, 
if it wants to be recognized as such. All your code examples illustrate exactly 
that. And if you care about code reuse, you will want to define a number 
of associated algorithms to take advantage of your storage model and answer 
your performance or memory requirements. Along with your list pattern for 
storage, you will probably also want to implement an insertion/search/update/traversal 
algorithms. That's when you have a tree.



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

Re: Concerning Dictionaries and += in Python 2.x

2015-01-21 Thread Denis McMahon

On Wed, 21 Jan 2015 09:43:31 +0100, Peter Otten wrote:

> There is also dict.from_keys()

See, I learned something too.

> The inner loop is not just inefficient for stock sold in large
> quantities,

Agreed, but as for:

> it will fail for stock sold by weight, volume etc.

I was trying to stay true to OPs original code and not introduce [too 
many] additional complications to his learning exercise.

-- 
Denis McMahon, denismfmcma...@gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Trees

On 2015-01-22 00:01, Chris Angelico wrote:
> On Wed, Jan 21, 2015 at 11:55 PM, Tim Chase
>>> Looks like {1,2,3} works for me.
>>
>> That hasn't always worked:
> 
> the argument's still fairly weak when it's alongside a pipe-dream
> desire to use specific mathematical Unicode characters in source
> code, because that's clearly a 3.x-only feature (where source code
> is Unicode text rather than ASCII).

I'm 100% in agreement that Unicode characters are a pipe-dream.  If I
wanted that, I'd use APL ;-)

> Nobody's going to moan "It's silly that we have to use 1 and 0
> instead of nice keywords True and False" on the basis that True and
> False didn't exist in Python 2.0. At very least, use 2.7 before you
> complain; preferably, use 3.4 (or 3.5).

While 2.0 is certainly antiquated, Red Hat Enterprise Linux (RHEL) is
often considered the best definition of what's considered "oldest
supported production environment".  RHEL v4 ships with Py2.3 and one
can still obtain extended support for this environment.  RHEL v5 is
actively supported (i.e., without the need for an extended-support
contract) and ships with Py2.4 so I generally try to at least support
2.4 when I'm writing code that could possibly end deploy on a server
such as RHEL5.   Some of us are stuck supporting code in such
antediluvian environments. :-/  Then again, if you're like me and
working in such environments, you already know to use set() instead
of {...} and to avoid the "with" statement, and the like. :)

Sources:
http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Version_history

http://turbogears.org/1.0/docs/Install/Nix.html#centos-rhel RHEL=2.3

https://wiki.archlinux.org/index.php/python#Old_versions RHEL5=2.4

-tkc

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

Re: Trees

On Thu, Jan 22, 2015 at 1:26 AM, Tim Chase
 wrote:
> While 2.0 is certainly antiquated, Red Hat Enterprise Linux (RHEL) is
> often considered the best definition of what's considered "oldest
> supported production environment".  RHEL v4 ships with Py2.3 and one
> can still obtain extended support for this environment.  RHEL v5 is
> actively supported (i.e., without the need for an extended-support
> contract) and ships with Py2.4 so I generally try to at least support
> 2.4 when I'm writing code that could possibly end deploy on a server
> such as RHEL5.   Some of us are stuck supporting code in such
> antediluvian environments. :-/  Then again, if you're like me and
> working in such environments, you already know to use set() instead
> of {...} and to avoid the "with" statement, and the like. :)

I'm aware that there are reasons for wanting to support older versions
of things. I do it myself in several places (though not specifically
with Python pre-2.7). But there's still a difference between "Moan
moan, we have to use set([1,2,3]) when {1,2,3} would make *so* much
more sense" and "Sadly, I have to ensure that my code works on Python
2.4, so I can't take advantage of all the newer features". One is a
complaint about the language; the other is an acknowledgement of the
personal pain of having to support multiple versions (and is going to
get easier; as years go by, the oldest Python on a supported RHEL will
become newer).

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

Re: Trees

Rustom Mody wrote:

> On Wednesday, January 21, 2015 at 1:27:39 PM UTC+5:30, Stephen Hansen
> wrote:
[...]
> Among my teachers of CS, there were two – both brilliant — one taught me
> Numerical Analysis, the other taught me programming.

I wonder just how brilliant the Numerical Analysis guy really was.

> The point is that the two of them disagreed strongly on what programming
> was about.
> 
> The numerical analyst could see no earthly reason to use anything other
> than Fortran.

Would you consider a cook who boiled everything "brilliant"? Somebody who
insisted that there was no earthly reason to have an oven, a frying pan, a
wok, or a steamer?

Or somebody who insisted that the *one and only* use for chemistry was to
set fire to wood and boil water?

Computers are used for vastly more than just numerical analysis.

> The programmer had horror stories to tell about how Fortran damages the
> brain: eg programs that inherently need a while-loop (eg binary search)
> seem to be
> distinctly out of the reach of the Fortran programmer.  Recursion...
> And much else.
> 
> The numerical analyst of course had no use for this philosophizing.

And how did this brilliant numerical analyst perform fast, efficient
searches of sorted data?

> The view that strings and floats are more fundamental than containers and
> maps reminds me of this view.

A strange comment to make.

I can insert a string or a float inside a container or map, but I cannot
insert a container or map inside a string or float.

Consider the computer hardware we use. Certain data structures are
fundamental to the architecture we use: bytes, pointers, ints, arrays are
very low-level. Floats are a little more complex -- they have a more
complex internal structure than ints. Hash tables are more complex still.

> For me python is neat because I can write: [1,2,3]
> when I want a list.

> But it does not go nearly far enough.
> 
> I would like a set to be {1,2,3} or at worst ⦃1,2,3⦄
> and a bag to be ⟅1,2,3⟆

In Python, you can write sets {1, 2, 3}.

Out of curiosity, what input method did you use to get those Unicode
characters? How many keystrokes or mouse clicks did it take to get this?

\N{LEFT S-SHAPED BAG DELIMITER} 1, 2, 3 \N{RIGHT S-SHAPED BAG DELIMITER}

"bag([1, 2, 3])" requires only 16 keypresses, and it is visible on virtually
every computer, while ⟅ ⟆ look like small boxes to me and probably most
people.

[...]
> More irksome that for the second we've to preface with
> 
> from collections import Counter
> 
> And still more a PITA that a straightforward standard name like bag (or
> multiset) is called by such an ungoogleable misleading name as counter.

It is not misleading. collections.Counter is a class for counting (i.e. a
counter), not a bag. It is merely *similar* to a bag, but the API is not
the same as the usual bag API because the motivating design is not the same
as for bags.

As for being "ungoogleable", that is just simply false. Perhaps you forgot
to push the enter key after typing in your search terms?

https://www.google.com.au/search?q=python+counter

The top three links are:

https://docs.python.org/2/library/collections.html‎
https://docs.python.org/3.3/library/collections.html‎
http://pymotw.com/2/collections/counter.html

and seven out of the ten links on the first page of results are about
Counter.

Your results may differ from mine, since Google bubbles your searches. But
Duck Duck Go doesn't:

https://duckduckgo.com/?q=python%20counter

Its results are not quite as good as Google's, but it finds the backported
Counter class on PyPI (which Google didn't) and it too links to the Python
Module Of The Week page. Adding "collections" to the search terms brings
the results up to Google quality.

So as you can see, it simply is not true that "Counter" is ungoogleable.

-- 
Steven

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

Re: Trees

On Wednesday, January 21, 2015 at 6:06:06 PM UTC+5:30, Chris Angelico wrote:
> On Wed, Jan 21, 2015 at 11:09 PM, Rustom Mody  wrote:
> > I would like a set to be {1,2,3} or at worst ⦃1,2,3⦄
> > and a bag to be ⟅1,2,3⟆
> >
> > Apart from the unicode niceness that Ive described here
> > http://blog.languager.org/2014/04/unicoded-python.html
> >
> > Its a bit of a nuisance that we have to write set([1,2,3]) for the first
> 
> Wait, what?
> 
> rosuav@sikorsky:~$ python
> Python 2.7.3 (default, Mar 13 2014, 11:03:55)
> [GCC 4.7.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> type({1,2,3})
> 
> >>>
> rosuav@sikorsky:~$ python3
> Python 3.5.0a0 (default:4709290253e3, Jan 20 2015, 21:48:07)
> [GCC 4.7.2] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> type({1,2,3})
> 
> >>>
> 
> Looks like {1,2,3} works for me.
> 
> ChrisA

Ah thank you -- forgot -- mea culpa.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python traceroute

2015-01-21 Thread William Ray Wing


> On Jan 21, 2015, at 12:06 AM, Denis McMahon  wrote:
> 
> On Tue, 20 Jan 2015 19:37:26 -0800, Chandrakant Tiwari wrote:
> 
>> in the program below i want it to make it work  the same way as TRACERT 
>> command.
> 
> As an observation, you're re-inventing a wheel that already works 
> perfectly well, in that any failings of tracert tend to be more down to 
> the way routers are configured to handle icmp than the tracert 
> application itself. Unless you're doing this purely as an exercise in 
> socket programming with python, it might be better to find a new problem 
> to solve.
> 
> -- 
> Denis McMahon, denismfmcma...@gmail.com
> -- 
> https://mail.python.org/mailman/listinfo/python-list

I’d further add that as a security measure these days, many (soon to be most) 
hosts are configured to throw icmp packets away without acknowledging them in 
any way.

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

Re: Trees

On Wed, Jan 21, 2015 at 7:47 AM, Steven D'Aprano
 wrote:
>> More irksome that for the second we've to preface with
>>
>> from collections import Counter
>>
>> And still more a PITA that a straightforward standard name like bag (or
>> multiset) is called by such an ungoogleable misleading name as counter.
>
> It is not misleading. collections.Counter is a class for counting (i.e. a
> counter), not a bag. It is merely *similar* to a bag, but the API is not
> the same as the usual bag API because the motivating design is not the same
> as for bags.

To expand on this, Counter does provide a few multiset operations like
union and intersection. But there are a number of cases where it falls
short or does not perform as expected. To name a few:

* There are no subset or superset comparison operations provided.
* len(counter) returns the number of keys, not the number of elements.
* Unlike a multiset, Counters can have negative or zero counts; one
curious consequence of this is that an "empty" Counter can have a
non-zero length and evaluate as true in boolean contexts.

A while back I fiddled around with creating a true MultiSet class
using a Counter as the underlying implementation. Here's what I came
up with:

from collections import Counter
from collections.abc import MutableSet, Set

__all__ = ['MultiSet']

class MultiSet(MutableSet):

  """Multiset class containing hashable items."""

  # Class invariants:
  #   * self._counter is a Counter s/t all values are positive ints denoting
  # multiplicity.
  #   * set(self) == self._counter.keys()

  def __init__(self, iterable_or_mapping=()):
"""Create a new, empty MultiSet. If passed an iterable argument, initialize
the MultiSet with items from the iterable. If passed a mapping argument,
initialize the MultiSet with the keys of the mapping, each repeated a number
of times equal to the associated value.
"""
self._counter = +Counter(iterable_or_mapping)

  @classmethod
  def _from_counter(cls, counter):
self = cls.__new__(cls)
self._counter = counter
return self

  def __contains__(self, item):
return item in self._counter

  def __hash__(self):
raise TypeError('unhashable type: %s' % type(self))

  def __iter__(self):
return self._counter.elements()

  def __len__(self):
# TODO: consider caching the length.
return sum(self._counter.values())

  def __repr__(self):
if self:
  return 'MultiSet(%r)' % list(self)
return 'MultiSet()'

  def add(self, item):
"""Add an element to the MultiSet."""
self._counter[item] += 1

  def clear(self):
"""Remove all elements from the MultiSet, leaving it empty."""
self._counter.clear()

  def count(self, item):
"""Return the number of occurrences of the element."""
return self._counter[item]

  def discard(self, item):
"""Remove an element from the MultiSet.

If there are multiple occurrences, remove only one such occurrence. If the
element is not a member, do nothing.
"""
if item not in self._counter:
  return
if self._counter[item] == 1:
  del self._counter[item]
else:
  self._counter[item] -= 1

  def __or__(self, other):
"""Return the union of the MultiSet and another set."""
if not isinstance(other, Set):
  return NotImplemented
return self._from_counter(self._counter | _get_counter(other))

  __ror__ = __or__

  def __ior__(self, other):
"""Perform the in-place union of the MultiSet and another set."""
if not isinstance(other, Set):
  return NotImplemented
self._counter |= _get_counter(other)
return self

  def __and__(self, other):
"""Return the intersection of the MultiSet and another set."""
if not isinstance(other, Set):
  return NotImplemented
return self._from_counter(self._counter & _get_counter(other))

  __rand__ = __and__

  def __iand__(self, other):
"""Perform the in-place intersection of the MultiSet and another set."""
if not isinstance(other, Set):
  return NotImplemented
self._counter &= _get_counter(other)
return self

  def __sub__(self, other):
"""Return the difference of the MultiSet and another set."""
if not isinstance(other, Set):
  return NotImplemented
return self._from_counter(self._counter - _get_counter(other))

  def __rsub__(self, other):
"""Return the difference of another set and the MultiSet."""
if not isinstance(other, Set):
  return NotImplemented
return self._from_counter(_get_counter(other) - self._counter)

  def __isub__(self, other):
"""Perform the in-place set difference of the MultiSet and another set."""
if not isinstance(other, Set):
  return NotImplemented
self._counter -= _get_counter(other)
return self

  def __xor__(self, other):
"""Return the symmetric difference of the MultiSet and another set."""
if not isinstance(other, Set):
  return NotImplemented
# X ^ Y == (X - Y) | (Y - X)
other_counter = _get

What killed Smalltalk could kill Python

In 2009, Robert Martin gave a talk at RailsConf titled "What Killed
Smalltalk Could Kill Ruby". (No cheering, that sort of attitude is one of
the things that killed Smalltalk.) Although Martin discusses Ruby, the
lessons could also apply to Python.

Video is available here:

http://www.youtube.com/watch?v=YX3iRjKj7C0

Youngsters may not be aware of Smalltalk. It was the language which
popularised object oriented programming. Technically, Simula was the first
OOP language, but Smalltalk popularised it. For a decade or two in the 80s
and 90s, Smalltalk was *the* killer language, the one everybody wanted to
use if only their boss would let them. It was amazingly innovative:
Smalltalk introduced unit testing, test driven development, and it had
powerful refactoring IDEs back in the 1990s.

And now it's all but dead. Why did it die, and how can Python (or Ruby for
that matter) avoid the same fate?

Martin is a very entertaining speaker, funny and knowledgeable. It is a very
entertaining talk, and he covers not just Smalltalk and Ruby but the nature
of professionalism, how fear makes code worse, how to make code better,
Ward Cunningham, the hormonal characteristics of various languages, the
language wars of the 1990s, what is clean code, and more.



-- 
Steven

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

Re: Trees

On Wed, Jan 21, 2015 at 9:15 AM, Ian Kelly  wrote:
> class MultiSet(MutableSet):

In retrospect this probably shouldn't derive from MutableSet, since
that carries the expectation that all elements are unique (much like
how bool shouldn't be subclassed). For instance, collections.Set
includes some operators that aren't compatible with the second operand
being a multiset.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What killed Smalltalk could kill Python

2015-01-21 Thread Michiel Overtoom

Hi Steven, you wrote:

> In 2009, Robert Martin gave a talk at RailsConf titled "What Killed
> Smalltalk Could Kill Ruby".

I've yet to watch the video, I'll do that later tonight, but I also remember
what DHH said about Smalltalk in his FLOSS interview about Rails, with Randal
Schwartz, in July 2009:

"""
[...] Smalltalk in itself... I tried a few times with some of the images, but
it's too much of a different world. It's too idealistic for me in some senses.
It's too much “throw out everything you know and I will show you a new world”.
I haven't been ready to take that red pill.

I really like that Ruby is sort of, lets extract 80, 90 percent of what awesome
about that and inject it with some real-world pragmatic approaches, like: You
can use the text editor you like; You can save files on the file system; You
can all these things in tracks with the real world. You don't have to leave
everything behind to jump into this Smalltalk world. To me the whole thing
about the Smalltalk images which is always just too confusing to me. Why?
There's all this different distributions, they're not really compatible, it
just seems like a hassle. I just didn't have the patience to wade through all
that. But I'm glad somebody else did. I'm glad that all that wisdom is
available mostly to people using Ruby. So, yeah, again: Not really.
"""

Source:
http://www.transcribed-interview.com/dhh-rails-david-heinemeier-hansson-interview-randal-schwartz-floss.html

Disclosure: I'm the one who made that transcription, and I recognized it from
memory.

Greetings,

--
"You can't actually make computers run faster, you can only make them do less."
- RiderOfGiraffes

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

Re: How to "wow" someone new to Python

2015-01-21 Thread Steve Hayes

On Sat, 17 Jan 2015 02:03:57 +1100, Chris Angelico  wrote:

>Scenario: You're introducing someone to Python for the first time.
>S/he may have some previous programming experience, or may be new to
>the whole idea of giving a computer instructions. You have a couple of
>minutes to show off how awesome Python is. What do you do?
>
>I was thinking along the lines of a simple demo in the REPL, showing
>off some of Python's coolest features. But then I got stuck on the
>specifics. What are Python's best coolnesses? What makes for a good
>demo?
>
>Ideally, this should be something that can be demo'd quickly and
>easily, and it should be impressive without going into great details
>of "and see, this is how it works on the inside". So, how would you
>brag about this language?

I can only say what made me sit up and take notice.

1. I found it already on my computer. 
2. It seemed to be used to run the Gramps genealogy program, which is quite
complex. I was impressed. 
3. When I started to look at it, I found that strings could be any length and
were not limited to swomething arbitrary, like 256 characters. 



-- 
Steve Hayes from Tshwane, South Africa
Web:  http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to "wow" someone new to Python

2015-01-21 Thread Irmen de Jong

On 21-1-2015 18:59, Steve Hayes wrote:

> 3. When I started to look at it, I found that strings could be any length and
> were not limited to swomething arbitrary, like 256 characters. 

Even more fun is that Python's primitive integer type (longs for older Python 
versions)
has no arbitrary limitation either.

That amazed me at the time I discovered python :)

Irmen

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

Re: What killed Smalltalk could kill Python

On 2015-01-22 03:34, Steven D'Aprano wrote:
> In 2009, Robert Martin gave a talk at RailsConf titled "What Killed
> Smalltalk Could Kill Ruby". 

Holy pacing, Batman.  Watching it at 2x leaves me wondering how much
of the stage was worn off during the presentation.

> And now it's all but dead. Why did it die, and how can Python (or
> Ruby for that matter) avoid the same fate?

In my experience, most Python has a particularly low WTF-per-minute
score.

But mostly Michael's reply addresses my biggest pain points the last
couple times I tried Smalltalk: The whole "images" thing impeded me
from easily using my development preferred environment.

With Python, I can just install it and then either fire up the
REPL, or type some code into a file and run it (same I suppose would
go for Ruby).

I fought for over an hour trying to figure out how to just get
ANYTHING to run in Smalltalk.  I installed Squeak on Debian and yet I
couldn't get any code examples to run.  I had to go find some
environments on the web, download them, modify them, and eventually
something ran.  Eventually I just gave up and returned to a world
where everything made sense.

-tkc

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

Re: How to "wow" someone new to Python

2015-01-21 Thread André Roberge

On Friday, 16 January 2015 11:04:20 UTC-4, Chris Angelico  wrote:
> Scenario: You're introducing someone to Python for the first time.
> S/he may have some previous programming experience, or may be new to
> the whole idea of giving a computer instructions. You have a couple of
> minutes to show off how awesome Python is. What do you do?
> 
> I was thinking along the lines of a simple demo in the REPL, showing
> off some of Python's coolest features. But then I got stuck on the
> specifics. What are Python's best coolnesses? What makes for a good
> demo?
> 
> Ideally, this should be something that can be demo'd quickly and
> easily, and it should be impressive without going into great details
> of "and see, this is how it works on the inside". So, how would you
> brag about this language?
> 
> ChrisA
If you are willing to install an older version of Python (because the program I 
am going to mention has not been updated in years ... but it *should* work with 
2.6), I'm going to suggest an odd one:  Crunchy!  (ok, I'm biased :-).

The home page is at https://code.google.com/p/crunchy/ where you can find a 
link to some screencasts (based on an even older version ...)   So, before you 
install anything, just have a quick look at the screencast to see if it's 
worthwhile.

A demo using Crunchy seems to  be even more impressive if the person knows some 
programming.

(Here is what was said about an even older version of Crunchy by people at the 
Omaha Python group: " Jeff gave a presentation on Crunchy ([WWW]
http://crunchy.sourceforge.net/) Talk about a gee whiz app."  
[https://mail.python.org/pipermail/omaha/2007-July/65.html])

In a nutshell, I would open the official Python tutorial in my browser, showing 
the official Python tutorial.   (boring)

Then, I would open the exact same page using a browser tab served by Crunchy: 
"magically" some text-input boxes would have been inserted allowing you to try 
out the code in the REPL provided by Crunchy.  Then I'd use Crunchy to launch 
an external app (perhaps a tkinter program), etc.

As I said at the beginning, Crunchy has not been updated in *years* ... more or 
less since the IPython and Sage notebooks came along...

André
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to "wow" someone new to Python

On Thu, Jan 22, 2015 at 5:20 AM, Irmen de Jong  wrote:
> On 21-1-2015 18:59, Steve Hayes wrote:
>
>> 3. When I started to look at it, I found that strings could be any length and
>> were not limited to swomething arbitrary, like 256 characters.
>
> Even more fun is that Python's primitive integer type (longs for older Python 
> versions)
> has no arbitrary limitation either.
>
> That amazed me at the time I discovered python :)

I hadn't worked with length-limited strings in basically forever
(technically BASIC has a length limit, but I never ran into it; and I
never did much with Pascal), but you're right, arbitrary-precision
integers would have impressed me a lot more if I hadn't first known
REXX. So... is there a way to show that off efficiently? Normally, any
calculation that goes beyond 2**32 has already gone way beyond most
humans' ability to hold the numbers in their heads.

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

Re: How to "wow" someone new to Python


Chris,


Scenario: You're introducing someone to Python for the first time.
S/he may have some previous programming experience, or may be new to
the whole idea of giving a computer instructions. You have a couple of
minutes to show off how awesome Python is. What do you do?


Some ideas where given by others already. I especially liked the variable 
swap one liner by Emile van Sebille. That's a little simple gem that will 
impress any seasoned developer of other programming languages.


But speaking about impressing more experient programmers, I personally don't 
think Python has a wow factor in any of its features and syntax. At least 
in the way I understand the word "wow". Python shares its own brand of idiosyncracies 
with any other programming languages. Little gotchas and caveats that have 
you scratch your head and sometimes annoy you slightly. Python is it too 
cropped here and there with things worth criticizing.


Meanwhile some of its interesting language features, like Comprehensions 
and Generators, aren't really that impressive to a seasoned developer of 
functional programming languages or programming languages like C# with its 
highly powerful and expressive LINQ.


This means that, alone, Python won't really standout. But this is ok. No 
language does it on the merits of its syntax or feature set.


What does make Python standout in my opinion -- what gave me the wow -- is 
its interoperability. Here we have a general purpose scripting language with 
more hooks to other systems that any other programming language in existence. 
With just Python, I can build a modern GUI interface on any of the most popular 
operating systems, use it on PostgreSQL to build stored procedures and move 
most of my business rules to the database server and attach dynamic behavior 
to a system developed in some other programming language.



I apologize if my post was to long, but I lacked the time to make it shorter.


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

Re: What killed Smalltalk could kill Python

2015-01-21 Thread Grant Edwards

On 2015-01-21, Steven D'Aprano  wrote:
> In 2009, Robert Martin gave a talk at RailsConf titled "What Killed
> Smalltalk Could Kill Ruby".

But does he answer the more important question "and can we use it to
kill PHP?".

-- 
Grant Edwards   grant.b.edwardsYow! What UNIVERSE is this,
  at   please??
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to "wow" someone new to Python

2015-01-21 Thread André Roberge

On Wednesday, 21 January 2015 15:06:33 UTC-4, Chris Angelico  wrote:
> On Thu, Jan 22, 2015 at 5:20 AM, Irmen de Jong  wrote:
> > On 21-1-2015 18:59, Steve Hayes wrote:
> >
> >> 3. When I started to look at it, I found that strings could be any length 
> >> and
> >> were not limited to swomething arbitrary, like 256 characters.
> >
> > Even more fun is that Python's primitive integer type (longs for older 
> > Python versions)
> > has no arbitrary limitation either.
> >
> > That amazed me at the time I discovered python :)
> 
> I hadn't worked with length-limited strings in basically forever
> (technically BASIC has a length limit, but I never ran into it; and I
> never did much with Pascal), but you're right, arbitrary-precision
> integers would have impressed me a lot more if I hadn't first known
> REXX. So... is there a way to show that off efficiently? 

How about:

 >>> def fac(n):
 ... ans = 1
 ... while n > 1:
 ... ans *= n
 ... n -= 1
 ... return ans
 ...
 >>> a = fac(100)
 >>> a
 
9332621544394415268169923885626670049071596826438162146859296389521753229915608941463976156518286253697920827223758251185210916864
 >>> b = fac(102)
 >>> b
 
961446671503512660926865558697259548455355905059659464369444714048531715130254590603314961882364451384985595980362059157503710042865532928
 >>> b//a
 10302
 >>> b//a == 102 * 101
 True

André


Normally, any
> calculation that goes beyond 2**32 has already gone way beyond most
> humans' ability to hold the numbers in their heads.
> 
> ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to "wow" someone new to Python

2015-01-21 Thread Matthew Ruffalo

On 01/21/2015 02:06 PM, Chris Angelico wrote:
> On Thu, Jan 22, 2015 at 5:20 AM, Irmen de Jong  wrote:
>> On 21-1-2015 18:59, Steve Hayes wrote:
>>
>>> 3. When I started to look at it, I found that strings could be any length 
>>> and
>>> were not limited to swomething arbitrary, like 256 characters.
>> Even more fun is that Python's primitive integer type (longs for older 
>> Python versions)
>> has no arbitrary limitation either.
>>
>> That amazed me at the time I discovered python :)
> I hadn't worked with length-limited strings in basically forever
> (technically BASIC has a length limit, but I never ran into it; and I
> never did much with Pascal), but you're right, arbitrary-precision
> integers would have impressed me a lot more if I hadn't first known
> REXX. So... is there a way to show that off efficiently? Normally, any
> calculation that goes beyond 2**32 has already gone way beyond most
> humans' ability to hold the numbers in their heads.
>
> ChrisA
Yes, length-unlimited strings are *extremely* useful in some
applications. I remember bitterly cursing Java's string length limit of
2 ** 31 (maybe - 1) on multiple occasions. Python's strings seem to
behave like integers in that their size is limited only by available memory.

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

Re: How to "wow" someone new to Python

On Thu, Jan 22, 2015 at 8:20 AM, Matthew Ruffalo  wrote:
> Yes, length-unlimited strings are *extremely* useful in some
> applications. I remember bitterly cursing Java's string length limit of
> 2 ** 31 (maybe - 1) on multiple occasions. Python's strings seem to
> behave like integers in that their size is limited only by available memory.

Hmm, I don't know that you'll get much beyond 2**31 characters (even
all-ASCII characters in PEP 393) on a 32-bit Python, simply because
"available memory" is capped at 2**32 bytes minus other stuff. You'd
need a 64-bit Python to do that, and I would guess a 64-bit Java would
also raise the limit.

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

Re: How to "wow" someone new to Python

2015-01-21 Thread Alan Bawden

Chris Angelico  writes:
> ..., and I would guess a 64-bit Java would
> also raise the limit.

Even in a 64-bit Java, the _type_ returned by String.length() is 'int',
and is thus at most (2**31 - 1).  This isn't a problem for strings,
which never get that long in practice, but for some other Java datatypes
(e.g., Buffer) it is a real problem.  Score one for untyped languages.

-- 
Alan Bawden
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to "wow" someone new to Python

2015-01-21 Thread Matthew Ruffalo

On 01/21/2015 04:26 PM, Chris Angelico wrote:
> On Thu, Jan 22, 2015 at 8:20 AM, Matthew Ruffalo  wrote:
>> Yes, length-unlimited strings are *extremely* useful in some
>> applications. I remember bitterly cursing Java's string length limit of
>> 2 ** 31 (maybe - 1) on multiple occasions. Python's strings seem to
>> behave like integers in that their size is limited only by available memory.
> Hmm, I don't know that you'll get much beyond 2**31 characters (even
> all-ASCII characters in PEP 393) on a 32-bit Python, simply because
> "available memory" is capped at 2**32 bytes minus other stuff. You'd
> need a 64-bit Python to do that, and I would guess a 64-bit Java would
> also raise the limit.
>
> ChrisA
No, Java's String.length returns an int and Strings are limited to ~2 **
31 characters even in 64-bit Java.

I do seem to have encountered some strange behavior, though: creating
very large strings with str.__mul__ seems to enter an allocation loop in
Python 3.4. With a single-character string 's', I can create the
following new strings quickly:

s * 2 ** 33
s * 2 ** 34
s * 2 ** 35
s * 2 ** 36

but s * 2 ** 38 shows some odd memory usage. I'm watching the memory
usage of a Python process steadily increase to 256GB, drop to a few MB,
climb back to 256GB, drop to a few MB, and so on. It takes a half-dozen
cycles of allocation and deallocation before the interactive interpreter
gives me another prompt.

MMR...

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

Re: How to "wow" someone new to Python

2015-01-21 Thread Alan Bawden

Alan Bawden  writes:
> ...  Score one for untyped languages.

Drat.  I should have writted "dynamically typed languages".

The language has changed.  When I was a novice Lisp hacker, we were
comfortable saying that Lisp was "untyped".  But nowadays we always say
that Lisp is "dynamically typed".  I could write an essay about why...

-- 
Alan Bawden
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to "wow" someone new to Python

In article , alan@scooby-
doo.csail.mit.edu says...
> Even in a 64-bit Java, the _type_ returned by String.length() is
> 'int', and is thus at most (2**31 - 1).  This isn't a problem for
> strings, which never get that long in practice, but for some other
> Java datatypes (e.g., Buffer) it is a real problem.  Score one for
> untyped languages.

Still, assuming you have enough heap size, you can still create a 500 
million character string buffer. That's one of a heck large buffer. 
Nearly twice the online encyclopedia Britannica(1), and roughly 50 times 
the longest novel ever produced (2).

And considering you can always flush the buffer, I'm finding an hard 
time looking at unlimited string length in Python as wow factor. Even if 
we consider unicode strings. 


(1) 
http://en.wikipedia.org/wiki/Wikipedia:Size_comparisons#Comparison_of_en
cyclopedias

(2) http://en.wikipedia.org/wiki/List_of_longest_novels
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to "wow" someone new to Python

On Thu, Jan 22, 2015 at 8:46 AM, Matthew Ruffalo  wrote:
> No, Java's String.length returns an int and Strings are limited to ~2 **
> 31 characters even in 64-bit Java.

Huh, annoying. In Python, the length of a string (in characters) is
stored in a Py_ssize_t (if I recall correctly), which is, I believe, a
pointer-sized integer. So it'd be 64-bit on a 64-bit build.

> I do seem to have encountered some strange behavior, though: creating
> very large strings with str.__mul__ seems to enter an allocation loop in
> Python 3.4. With a single-character string 's', I can create the
> following new strings quickly:
>
> s * 2 ** 33
> s * 2 ** 34
> s * 2 ** 35
> s * 2 ** 36
>
> but s * 2 ** 38 shows some odd memory usage. I'm watching the memory
> usage of a Python process steadily increase to 256GB, drop to a few MB,
> climb back to 256GB, drop to a few MB, and so on. It takes a half-dozen
> cycles of allocation and deallocation before the interactive interpreter
> gives me another prompt.

That sounds like you're blooping through your page file. The exact
behaviour will depend on how much physical memory you have, how your
page file is implemented (which depends on your OS), the phase of the
moon, and what you had for breakfast three weeks ago.

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

Re: Trees

Rustom Mody  writes:
> Thats not bfs. That's inorder traversal

Oops, you're right.  How's this:

bfs x = go [x] where
  go [] = []
  go (L x:ts) = x:go ts
  go (B x lst rst:ts) = x : go (ts ++ [lst, rst])

*Main> bfs t
[6,2,8,1,4,7,9,3,5]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What killed Smalltalk could kill Python

On Thu, Jan 22, 2015 at 6:18 AM, Grant Edwards  wrote:
> On 2015-01-21, Steven D'Aprano  wrote:
>> In 2009, Robert Martin gave a talk at RailsConf titled "What Killed
>> Smalltalk Could Kill Ruby".
>
> But does he answer the more important question "and can we use it to
> kill PHP?".

PHP won't die so long as there are people willing to apologize for its
every flaw and defend it on the basis that huge sites X, Y, and Z all
use it. But we don't need it to die. All we need is for Python to
live, and we can ignore PHP and write Unicode-aware web sites with
simple, trustworthy entry points, and not worry about the rest.

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

Re: How to "wow" someone new to Python

Alan Bawden  writes:
> The language has changed.  When I was a novice Lisp hacker, we were
> comfortable saying that Lisp was "untyped".  But nowadays we always say
> that Lisp is "dynamically typed".  I could write an essay about why...

I'd be interested in seeing that.  Lisp of course descends from Church's
untyped lambda calculus but I didn't realize Lisp terminology about its
(runtime) type system had changed historically.  PL theorists sometimes
like to refer to runtime types as "tags" rather than types.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Trees

On Tue, Jan 20, 2015 at 6:23 PM, Rustom Mody  wrote:
> The Haskell is bullseye¹ in capturing the essense of a tree because
> conceptually a tree of type t is recursive in the sense that it can contain
> 2 subtrees -- (B x lst rst) -- or its a base case -- L x.

How do you create a tree containing an even number of elements under
this constraint?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What killed Smalltalk could kill Python

2015-01-21 Thread Grant Edwards

On 2015-01-21, Chris Angelico  wrote:
> On Thu, Jan 22, 2015 at 6:18 AM, Grant Edwards  
> wrote:
>> On 2015-01-21, Steven D'Aprano  wrote:
>>> In 2009, Robert Martin gave a talk at RailsConf titled "What Killed
>>> Smalltalk Could Kill Ruby".
>>
>> But does he answer the more important question "and can we use it to
>> kill PHP?".
>
> PHP won't die so long as there are people willing to apologize for
> its every flaw and defend it on the basis that huge sites X, Y, and Z
> all use it. But we don't need it to die. All we need is for Python to
> live, and we can ignore PHP and write Unicode-aware web sites with
> simple, trustworthy entry points, and not worry about the rest.

I happily ignored PHP until a couple years back when we decided to use
PHP for the web site on a small embedded Linux system.  The reasoning
was that we didn't have any significant internal web site development
skills, and using PHP on Linux would make it easy to contract out the
web site design using an off-the-shelf light-weight framework.

[At the time, a couple of us could stumble around with HTML enough to
generate web pages that looked fresh out of 1995, but that was about
it. The web pages in our older devices looked rather "retro" and had
pretty limited functionality.]

At a certain point we couldn't afford the contractors any longer and
somebody had to take over maintenance and development of the web
stuff.  The JavaScript and jQuery part of it isn't bad.  Both have had
some thought put into them: they have their quirks but there's a
certain internal consistency and elegence.

PHP, on the other hand makes me want to scream.  It's all just a
random mess -- it's nothing _but_ quirks.  As one of the contractors
once said: PHP is like a combination of all the worst features of
bash, perl, and C.

I briefly considered trying to switch to Python, but the Python
footprint is just too big...

-- 
Grant Edwards   grant.b.edwardsYow! RELATIVES!!
  at   
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Check for running DHCP daemon?

2015-01-21 Thread Jason Bailey

So I've got this python 3 script that needs to know if there is a 
running DHCP daemon (ISC DHCP server) on the local system. Is there a 
clean way to do this that (1) doesn't require me to do syscalls to local 
utilities (like ps, top, etc), and (2) doesn't require any custom 
modules (stock only)?


Thanks

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

Re: What killed Smalltalk could kill Python

2015-01-21 Thread Anthony Papillion

On 01/21/2015 04:35 PM, Chris Angelico wrote:
> On Thu, Jan 22, 2015 at 6:18 AM, Grant Edwards  
> wrote:
>> On 2015-01-21, Steven D'Aprano  wrote:
>>> In 2009, Robert Martin gave a talk at RailsConf titled "What Killed
>>> Smalltalk Could Kill Ruby".
>>
>> But does he answer the more important question "and can we use it to
>> kill PHP?".
> 
> PHP won't die so long as there are people willing to apologize for its
> every flaw and defend it on the basis that huge sites X, Y, and Z all
> use it. But we don't need it to die. All we need is for Python to
> live, and we can ignore PHP and write Unicode-aware web sites with
> simple, trustworthy entry points, and not worry about the rest.

To be fair, PHP has come a long way in the last few years and, I hear,
there's movements within the community to make it better. Namespaces
were a bit deal as were a few other things. Personally, while I am
LOVING Python, I'd be sad to see PHP die. It's got a lot of potential if
the community can get its crap together and take off the ruby coloured
glasses.

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

Re: Check for running DHCP daemon?

On Thu, Jan 22, 2015 at 10:06 AM, Jason Bailey  wrote:
> So I've got this python 3 script that needs to know if there is a running
> DHCP daemon (ISC DHCP server) on the local system. Is there a clean way to
> do this that (1) doesn't require me to do syscalls to local utilities (like
> ps, top, etc), and (2) doesn't require any custom modules (stock only)?

Not sure why you have these restrictions; normally I'd look at an
OS-provided status function (eg "/etc/init.d/isc-dhcp-server status",
which on my Debian system is implemented by looking for a PID file and
confirming with ps). But since DHCP uses port 67, you might be able to
use that; I don't know of a way, within your restrictions, to find out
if someone's bound to port 67, but you could send a DHCPDISCOVER
message to 127:0.0.1:67 and see if you get back an offer. That may not
be the best technique, but it could be done with just Python's
standard library. (Alternatively, if you're certain the DHCP server is
configured appropriately, you could send a DHCPREQUEST message with an
inappropriate IP and hope for a rejection.)

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

Re: What killed Smalltalk could kill Python

2015-01-21 Thread Tim Daneliuk

On 01/21/2015 10:34 AM, Steven D'Aprano wrote:
> In 2009, Robert Martin gave a talk at RailsConf titled "What Killed
> Smalltalk Could Kill Ruby". (No cheering, that sort of attitude is one of
> the things that killed Smalltalk.) Although Martin discusses Ruby, the
> lessons could also apply to Python.

I find these kinds of discussions sort of silly.  Once there is a critical
mass of installed base, no language EVER dies.

I suspect the real reason Smalltalk sort of got kicked to the curb is because
a) It clung to a kind of OO purity that simply is at odds with the practice
of programming at large scale  and   b) It thus never built the aforementioned
critical mass.

Language adoption at the scale needed to make a real dent doesn't happen
because of technical superiority (witness PHP as just one example).  It happens
because lots of people solve real problems faster than they used to.
In fact - outside the language cognoscenti and uber nerd community - I'd
argue that  Python adoption has little to do with functional programming,
lambda, OO, generators, or whatever happens to float your boat.  Python
got adopted because it made code production faster, and therefore cheaper.
Economics matters way more than technology here, I think.

I wrote some rambling disquisition on these matters some years ago ...

  http://www.tundraware.com/TechnicalNotes/Python-Is-Middleware

  http://www.tundraware.com/TechnicalNotes/How-To-Pick-A-Programming-Language
-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

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

Re: What killed Smalltalk could kill Python

On Thu, Jan 22, 2015 at 10:19 AM, Anthony Papillion
 wrote:
> To be fair, PHP has come a long way in the last few years and, I hear,
> there's movements within the community to make it better. Namespaces
> were a bit deal as were a few other things. Personally, while I am
> LOVING Python, I'd be sad to see PHP die. It's got a lot of potential if
> the community can get its crap together and take off the ruby coloured
> glasses.

The huge advantage of PHP over other languages is that it comes free
with any cheap web host. That's also a huge *dis*advantage when it
comes to "movements... to make it better", because you can't know when
the new version will become sufficiently prevalent to depend on it.
I've seen PHP 4 compatibility code in current versions of some big
frameworks, although I've no idea whether that implies actual support
or just that nobody's removed it yet.

But there are a few fundamental problems with PHP, which are derived
directly from its philosophies. One of them is that any file in some
directory tree is automatically an entry point - specifically, an
*executable* entry point. PHP frameworks that accept file uploads have
to go to great lengths to ensure that malicious users can't upload
code and run it. Every web framework I've seen for Python, Ruby, Pike,
etc, has URL routing defined by the application, not the file system,
and if you define a readable uploads directory, all you're going to do
is allow people to re-download the same file. Even old CGI scripts,
where file system presence defined entry points, weren't as bad as PHP
- firstly because they were usually restricted to /cgi-bin/ (and you
simply wouldn't allow world writing to that directory), and secondly
because the scripts had to be marked executable, which PHP scripts
don't.

Maybe PHP will grow true Unicode support in a future version. Maybe
it'll gain a nice object model that compares well to Python's or
Ruby's or whichever other you want to look at. Maybe there'll be a
complete reworking of string comparisons so that "12e2" is no longer
equal to "1200". But I doubt it'll ever shift away from file-system
entry points.

And that's why I will continue to push people to Python+Flask rather than PHP.

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

Re: What killed Smalltalk could kill Python

Steven D'Aprano  writes:
> In 2009, Robert Martin gave a talk at RailsConf titled "What Killed
> Smalltalk Could Kill Ruby"...  http://www.youtube.com/watch?v=YX3iRjKj7C0

That's an hour-long video; could someone who's watched it give a brief
summary?

Meanwhile, there's this:  http://prog21.dadgum.com/203.html
"Retiring Python as a Teaching Language"

tl;dr: he's switched to recommending Javascript as a first language
instead of Python, since JS makes it easier to write graphics and games,
which is what lots of beginners are interested in now.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to "wow" someone new to Python

2015-01-21 Thread Irmen de Jong

On 21-1-2015 20:06, Chris Angelico wrote:
> On Thu, Jan 22, 2015 at 5:20 AM, Irmen de Jong  wrote:
>> On 21-1-2015 18:59, Steve Hayes wrote:
>>
>>> 3. When I started to look at it, I found that strings could be any length 
>>> and
>>> were not limited to swomething arbitrary, like 256 characters.
>>
>> Even more fun is that Python's primitive integer type (longs for older 
>> Python versions)
>> has no arbitrary limitation either.
>>
>> That amazed me at the time I discovered python :)
> 
> I hadn't worked with length-limited strings in basically forever
> (technically BASIC has a length limit, but I never ran into it; and I
> never did much with Pascal), but you're right, arbitrary-precision
> integers would have impressed me a lot more if I hadn't first known
> REXX. So... is there a way to show that off efficiently? Normally, any
> calculation that goes beyond 2**32 has already gone way beyond most
> humans' ability to hold the numbers in their heads.
> 
> ChrisA
> 

Something silly that I just thought about  (Python 3):


number = 2 * 3 * 5 * 103# okay.
number = number * 3120937 * 6977407 * 8431103# hmm...
number = number * 
70546381234168412430433268433712277793053956898109255590133639943
print("I know a huge number, it is:", number)
secret_message = number.to_bytes(37, "big")
print(secret_message)


Or perhaps: (after pip install pyprimes)

>>> number = 1402811054100763300785480817886711606823329164566977593890  # wow?
>>> import pyprimes.factors
>>> print(pyprimes.factors.factorise(number))
[2, 3, 5, 557, 1559, 3413, 6991, 27799, 41333, 52999, 104681, 247001, 992441, 
211,
1299689]
>>>



Irmen


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

Re: What killed Smalltalk could kill Python

On Thu, Jan 22, 2015 at 10:37 AM, Tim Daneliuk  wrote:
> I find these kinds of discussions sort of silly.  Once there is a critical
> mass of installed base, no language EVER dies.

Not sure about that. Back in the 1990s, I wrote most of my code in
REXX, either command-line or using a GUI toolkit like VX-REXX. Where's
REXX today? Well, let's see. It's still the native-ish language of
OS/2. Where's OS/2 today? Left behind. REXX has no Unicode support (it
does, however, support DBCS - useful, no?), no inbuilt networking
support (there are third-party TCP/IP socket libraries for OS/2 REXX,
but I don't know that other REXX implementations have socket services;
and that's just basic BSD sockets, no higher-level protocol handling
at all), etc, etc. Sure, it's not technically dead... but is anyone
developing the language further? I don't think so. Is new REXX code
being written? Not a lot. Yet when OS/2 was more popular, REXX
definitely had its installed base. It was the one obvious scripting
language for any OS/2 program. Languages can definitely die, or at
least be so left behind that they may as well be dead.

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

Re: What killed Smalltalk could kill Python

On Thu, Jan 22, 2015 at 10:46 AM, Paul Rubin  wrote:
> Meanwhile, there's this:  http://prog21.dadgum.com/203.html
> "Retiring Python as a Teaching Language"
>
> tl;dr: he's switched to recommending Javascript as a first language
> instead of Python, since JS makes it easier to write graphics and games,
> which is what lots of beginners are interested in now.

Bad idea. Better to pick a language that makes it easy to get things
right, and then work on the fun side with third-party libraries, than
to tempt people in with "hey look how easy it is to do X" and then
have them stuck with an inferior or flawed language. Too many people
already don't know the difference between UTF-16 and Unicode. Please,
educators, don't make it worse.

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

Re: What killed Smalltalk could kill Python

2015-01-21 Thread Michael Torrie

On 01/21/2015 04:37 PM, Tim Daneliuk wrote:
> On 01/21/2015 10:34 AM, Steven D'Aprano wrote:
>> In 2009, Robert Martin gave a talk at RailsConf titled "What Killed
>> Smalltalk Could Kill Ruby". (No cheering, that sort of attitude is one of
>> the things that killed Smalltalk.) Although Martin discusses Ruby, the
>> lessons could also apply to Python.
> 
> 
> I find these kinds of discussions sort of silly.  Once there is a critical
> mass of installed base, no language EVER dies.
> 
> I suspect the real reason Smalltalk sort of got kicked to the curb is because
> a) It clung to a kind of OO purity that simply is at odds with the practice
> of programming at large scale  and   b) It thus never built the aforementioned
> critical mass.

I suspect Smalltalk lost relevance mainly because it never integrated
very well into any computing system.  Everything ran in a virtual
machine in its own image in isolation as it were.  The IDE and the
runtime environment were inseparable, and as OS's developed their own
environments it just never tried to fit in.  It's almost as if Smalltalk
was the language, runtime, your program source code, *and* operating
system.  That's what he meant in his talk about the problem with
smalltalk being the "image."  The only way to distribute your smalltalk
programs was to distribute the image file, which was basically a memory
dump.  When you wanted to list out a smalltalk program you were
basically decompiling it to the editor widget.

So this integrated nature of smalltalk (source code, editor, live
objects, etc) was its most powerful feature, but ultimately its downfall
too in my opinion.  And at the same time we regularly pine for some of
those features.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What killed Smalltalk could kill Python

In article , 
ros...@gmail.com says...
> 
> Bad idea. Better to pick a language that makes it easy to get things
> right, and then work on the fun side with third-party libraries, than
> to tempt people in with "hey look how easy it is to do X" and then
> have them stuck with an inferior or flawed language. Too many people
> already don't know the difference between UTF-16 and Unicode. Please,
> educators, don't make it worse.
> 
> ChrisA


Indeed. If games and funnies is what drive beginners into programming, 
that's fine. But the educational principles of programming shouldn't be 
trashed in the process. We need serious developers in today's complex 
application systems. Not uneducated programmers with nary a knowledge of 
Software Engineering. Besides if games and funnies are the only thing 
that can drive someone into programming, I'd rather not see that person 
become a developer.

"I want to become a programmer so I can make games" is, on the vast 
majority of cases, the quote of someone who will never become a 
programmer. Why should teachers reward that kind of thought?  
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What killed Smalltalk could kill Python

In article <873873ae91@jester.gateway.sonic.net>, 
no.email@nospam.invalid says...
> 
> Steven D'Aprano  writes:
> > In 2009, Robert Martin gave a talk at RailsConf titled "What Killed
> > Smalltalk Could Kill Ruby"...  http://www.youtube.com/watch?v=YX3iRjKj7C0
> 
> That's an hour-long video; could someone who's watched it give a brief
> summary?
> 

In a nutshell, he argues, along with Ward Cunningham, that what killed 
Smalltalk was how easy you could create unclean code with it. "Unclean" 
in this context means Smalltalk didn't punish bad software design 
decisions that would eventually lead into complex code and unmanageable 
systems with zero options of code maintenance.

I don't have an opinion. I didn't know Smalltalk. I started my 
programming carrer around the early nineties as a Dbase and later 
Clipper programmer.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What killed Smalltalk could kill Python

2015-01-21 Thread John Ladasky

On Wednesday, January 21, 2015 at 11:18:54 AM UTC-8, Grant Edwards wrote:
> On 2015-01-21, Steven D'Aprano  wrote:
> > In 2009, Robert Martin gave a talk at RailsConf titled "What Killed
> > Smalltalk Could Kill Ruby".
> 
> But does he answer the more important question "and can we use it to
> kill PHP?".

LOL!

Seriously, I did.

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

Re: What killed Smalltalk could kill Python

2015-01-21 Thread Marko Rauhamaa

Grant Edwards :

> [At the time, a couple of us could stumble around with HTML enough to
> generate web pages that looked fresh out of 1995, but that was about
> it. The web pages in our older devices looked rather "retro" and had
> pretty limited functionality.]

I miss that plain old look of web pages.


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

Re: What killed Smalltalk could kill Python

2015-01-21 Thread sohcahtoa82

On Wednesday, January 21, 2015 at 4:10:08 PM UTC-8, Mario Figueiredo wrote:
> In article , 
> ros...@gmail.com says...
> > 
> > Bad idea. Better to pick a language that makes it easy to get things
> > right, and then work on the fun side with third-party libraries, than
> > to tempt people in with "hey look how easy it is to do X" and then
> > have them stuck with an inferior or flawed language. Too many people
> > already don't know the difference between UTF-16 and Unicode. Please,
> > educators, don't make it worse.
> > 
> > ChrisA
> 
> 
> Indeed. If games and funnies is what drive beginners into programming, 
> that's fine. But the educational principles of programming shouldn't be 
> trashed in the process. We need serious developers in today's complex 
> application systems. Not uneducated programmers with nary a knowledge of 
> Software Engineering. Besides if games and funnies are the only thing 
> that can drive someone into programming, I'd rather not see that person 
> become a developer.
> 
> "I want to become a programmer so I can make games" is, on the vast 
> majority of cases, the quote of someone who will never become a 
> programmer. Why should teachers reward that kind of thought?

I think one of the problems is that most of the people with the "I want to 
become a programmer so I can make games" mentality really have no clue at all 
how much work it takes to produce a game.  They just see that Minecraft was 
made started by just one guy and now he's a billionaire, and they think "I want 
that to happen to me!".  They think that just because the game has 
low-resolution graphics means they could produce something similar in just a 
couple days, ignoring complexities like rendering optimizations and interaction 
with the world.

Others will pick up Python because everyone tells them its an easy language to 
learn and then think they're going to make the next Call of Duty or World of 
Warcraft with it without any knowledge of basic algorithms.  They might learn a 
few from some tutorials, but they'll have no idea how to apply them.  They 
won't be able to make the jump from "Here's how to start a TCP server in one 
window while connecting to it from a client in another window and send chat 
messages back and forth" (essentially a basic implementation of netcat) to 
creating a game server that sends game state updates to the players.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What killed Smalltalk could kill Python

On Thu, Jan 22, 2015 at 11:09 AM, Mario Figueiredo  wrote:
> "I want to become a programmer so I can make games" is, on the vast
> majority of cases, the quote of someone who will never become a
> programmer. Why should teachers reward that kind of thought?

How about "I want to become a programmer so my brother, 2.5 years
older than me, won't be better than me any more"? Should that kind of
thinking be rewarded? Because that's how I got started. My brother was
being taught the basics of programming, I was jealous (being the
second child will tend to produce that), and so at six years old, I
started learning to code. And then a few years later, I wanted to
learn C because my brother didn't know it (we'd both learned BASIC),
and since I didn't have a C compiler, I learned 8086 Assembly Language
instead, using DEBUG.EXE. Largely out of jealousy.

I hope I've gained a little maturity since then...

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

Re: What killed Smalltalk could kill Python

Mario Figueiredo  writes:
> "I want to become a programmer so I can make games" is, on the vast 
> majority of cases, the quote of someone who will never become a 
> programmer. Why should teachers reward that kind of thought?  

I don't see what the problem is.  Kids are interested in games and they
are into playing them, so of course they also want to program them.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What killed Smalltalk could kill Python

2015-01-21 Thread Ethan Furman

On 01/21/2015 05:36 PM, Chris Angelico wrote:
> On Thu, Jan 22, 2015 at 11:09 AM, Mario Figueiredo  wrote:
>> "I want to become a programmer so I can make games" is, on the vast
>> majority of cases, the quote of someone who will never become a
>> programmer. Why should teachers reward that kind of thought?
> 
> How about "I want to become a programmer so my brother, 2.5 years
> older than me, won't be better than me any more"? Should that kind of
> thinking be rewarded? Because that's how I got started. My brother was
> being taught the basics of programming, I was jealous (being the
> second child will tend to produce that), and so at six years old, I
> started learning to code. And then a few years later, I wanted to
> learn C because my brother didn't know it (we'd both learned BASIC),
> and since I didn't have a C compiler, I learned 8086 Assembly Language
> instead, using DEBUG.EXE. Largely out of jealousy.

There is a difference between /your/ motivation to learn something, and 
teachers /pandering/ to such motivations.
There's nothing wrong with "I want to make games" as a personal driving factor, 
but the educational system should still
teach decent programming, not whatever piece of garbage will produce quick 
results at the expense of long-term productivity.

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What killed Smalltalk could kill Python

On Thu, Jan 22, 2015 at 12:38 PM, Paul Rubin  wrote:
> Mario Figueiredo  writes:
>> "I want to become a programmer so I can make games" is, on the vast
>> majority of cases, the quote of someone who will never become a
>> programmer. Why should teachers reward that kind of thought?
>
> I don't see what the problem is.  Kids are interested in games and they
> are into playing them, so of course they also want to program them.

It's not a terrible justification for getting into programming. But
writing games is (almost always) a terrible way to start programming.
Either you pick up a super-restrictive "hey look, you can build a game
with just point and click" system, which isn't teaching programming at
all, or you end up getting bogged down in the massive details of what
it takes to write code.

If someone's unfazed by the "it'll take you years before you can
actually write a saleable game" consideration, then getting into
programming via toys (writing Fizz Buzz or a factorial calculator)
will put him/her on a much better footing for actual coding work.

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

Re: What killed Smalltalk could kill Python

2015-01-21 Thread Rick Johnson

On Wednesday, January 21, 2015 at 10:34:40 AM UTC-6, Steven D'Aprano wrote:
> In 2009, Robert Martin gave a talk at RailsConf titled
> "What Killed Smalltalk Could Kill Ruby". (No cheering,
> that sort of attitude is one of the things that killed
> Smalltalk.) Although Martin discusses Ruby, the lessons
> could also apply to Python.

Python is already headed towards obscurity. The fall began
with the release of Python3000 (from which we "might" have
recovered), but now it seems that GvR intends to drive the
final nail in python's coffin with this "type hinting" crap
that will convert Python syntax from a readable pseudo code
into a cryptic nightmare.

Type hinting violates the very *ESSENCE* of what Python was
meant to be, that is: a "clean and intuitive syntax". The
cleanness of Python is what attracts people to it, and the
hook is set when they discover the breadth of the stdlib.

If GvR brings this gawd awful type hinting idea to reality,
IT'S OVER! Python will be lost forever to history as just
another "interesting oddity". Time to call up the Robert 
Ripley estate and request some space in his museum!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Check for running DHCP daemon?

2015-01-21 Thread Dan Stromberg

On Wed, Jan 21, 2015 at 3:06 PM, Jason Bailey  wrote:
> So I've got this python 3 script that needs to know if there is a running
> DHCP daemon (ISC DHCP server) on the local system. Is there a clean way to
> do this that (1) doesn't require me to do syscalls to local utilities (like
> ps, top, etc), and (2) doesn't require any custom modules (stock only)?

The subprocess module is quite clean on *ix.  Don't let the subprocess
mess on Windows steer you away from it on *ix.  And don't let the
"subprocesses are bad" from the perl community misguide you either -
shell is fast today because it's highly parallel, because it's
unafraid of subprocesses.

You could open the files under /proc and look around, if you're on
Linux. But parsing "ps -eo whatever" would probably be cleaner.

A "syscall" is an interaction with a kernel.  I think you meant an
os.system() call.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What killed Smalltalk could kill Python

Chris Angelico  writes:
> Either you pick up a super-restrictive "hey look, you can build a game
> with just point and click" system, which isn't teaching programming at
> all, or you end up getting bogged down in the massive details of what
> it takes to write code.

Code Hero ran into various obstacles and never got finished, but it was
a game whose purpose was to teach the player how to write their own
games using Unity3D.  I saw some early versions and it seemed pretty
accessible.

https://en.wikipedia.org/wiki/Code_Hero

Heck, there's even a song about learning to program through wanting to
write games, and ending up treating programming as a type of
spirituality (there was an interview with the songwriter explaining
this, but it seems to have gone offline):

lyrics:
http://www.sccs.swarthmore.edu/users/01/bnewman/songs/lyrics/Code-Goddess.txt
mp3:
http://www.sccs.swarthmore.edu/users/01/bnewman/songs/music/Code-Goddess.mp3


> If someone's unfazed by the "it'll take you years before you can
> actually write a saleable game" consideration,

Wanting to write games is a completely different topic than wanting to
sell them.  It's just like any other creative outlet.  Most people who
teach themselves to juggle do it because juggling is fun, not because
they want to join the circus.  
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What killed Smalltalk could kill Python

On Thu, Jan 22, 2015 at 1:53 PM, Paul Rubin  wrote:
>> If someone's unfazed by the "it'll take you years before you can
>> actually write a saleable game" consideration,
>
> Wanting to write games is a completely different topic than wanting to
> sell them.  It's just like any other creative outlet.  Most people who
> teach themselves to juggle do it because juggling is fun, not because
> they want to join the circus.

True, but even a playable game is a long way beyond a first-day
programmer. (By "playable" I mean something that someone other than
its author would play and enjoy.) It's fine as a goal, but needs to be
viewed with a perspective of "that's where I'm trying to get to", not
"now I'm going to start writing games".

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

Re: What killed Smalltalk could kill Python

On Thu, Jan 22, 2015 at 1:59 PM, Dennis Lee Bieber
 wrote:
> To my mind, what killed REXX is that most operating systems just don't
> support its key feature well: ADDRESS targets!
>
> When the only target turns ADDRESS into the equivalent of os.system()
> (or some variant of popen() ) it just loses too much. Besides the original
> mainframe implementation, I have a feeling only ARexx managed to maintain
> the spirit of REXX -- and that may have been as it was so easy to extend
> the native AmigaOS message passing IPC to create ARexx ports letting
> processes truly communicate interactively.

Very good point. I can count the instances where ADDRESS could be used
for something else on the fingers of one hand... and one of them was a
MUD server that I wrote myself, and which nobody else ever used. And
it would have done better to use SAY rather than ADDRESS; it's kinda
cute, but not very practical, to have something like this:

/* code file for implementing, say, the 'search' command */
if arg(1) = "haystack" then do
"You find a needle in the haystack!"
"It is long, sharp, and made of metal."
call move_object create_object("needle"), caller
end
else "You find nothing of interest."

Each quoted string got sent to the client as a line of text. Yeah,
nice, but there are plenty of other ways to do it.

(The main coolness of this system was that I could update the REXX
code without restarting the server, which was pretty handy.)

Other than that, it's really not a well-used feature. Oh, what might
have been...

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

Re: What killed Smalltalk could kill Python

On 2015-01-21 23:10, Grant Edwards wrote:
> I happily ignored PHP until a couple years back when we decided to
> use PHP for the web site on a small embedded Linux system. 
[snip]
> I briefly considered trying to switch to Python, but the Python
> footprint is just too big...

Interesting that your experience swung that way.

I worked on a contract about a year ago where it involved deploying
web services & ZigBee communications on a Digi Connectport[1] which is
certainly a rather underpowered device (20MB of memory is tight).  My
biggest issue was the project-lead's choice of CherryPy and
SQLObject...neither has nearly the same quality of documentation as
I'd grown accustomed to in the Django world.  Yet I was able to run
an HTTPS CherryPy server talking to a local sqlite database with
minimal trouble, handling a modest (i.e., small business) load.

-tkc

[1]
http://www.digi.com/products/wireless-routers-gateways/gateways/xbee-gateway#specs

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

Re: What killed Smalltalk could kill Python

Mario Figueiredo wrote:

> In article ,
> ros...@gmail.com says...
>> 
>> Bad idea. Better to pick a language that makes it easy to get things
>> right, and then work on the fun side with third-party libraries, than
>> to tempt people in with "hey look how easy it is to do X" and then
>> have them stuck with an inferior or flawed language. Too many people
>> already don't know the difference between UTF-16 and Unicode. Please,
>> educators, don't make it worse.
>> 
>> ChrisA
> 
> 
> Indeed. If games and funnies is what drive beginners into programming,
> that's fine. But the educational principles of programming shouldn't be
> trashed in the process. We need serious developers in today's complex
> application systems.

Sure, but are they the *only* kinds of programmers that we need? Isn't there 
room in the world for an open-source developer who creates Firefox plug-ins, 
sys admins who write shell-scripts, cubical workers who write Excel 
worksheets, etc? Why shouldn't my Aunt Tilly write a mobile phone app to 
manage her cheesecake recipes just the way she likes?

http://livecode.com/

Programming games is hard. Arguably, it's *much* harder than most beginners 
can deal with, unless you start with a specialist language designed with 
game-related primitives:

http://scratch.mit.edu/

Even text based games are hard, and arguably need their own specialist 
language:

http://inform7.com/

Modern games *are* part of "today's complex application systems", and games 
developers may need the same skills used by "serious developers":

- project management
- testing
- change control
- release management
- documentation
- networking
- user authentication

etc. I'd further argue that many games developers have to know *more* that 
the typical developer. As a Python programmer, I don't have to manage 
memory, but many games devs are often programming down close to the metal 
and do need to care about the sort of low-level issues (memory, graphics, 
network latency) that I only have the fuzziest concept of. You don't write a 
high-performance 3D physics engine in Python. (At least not yet.)

> Not uneducated programmers with nary a knowledge of
> Software Engineering. Besides if games and funnies are the only thing
> that can drive someone into programming, I'd rather not see that person
> become a developer.

That's a terribly judgemental and rather arrogant statement. If people have 
a passion for mathematics, and that leads them to take up programming and 
invent Mathematica, would you say the world would have been better off if 
they never became a programmer?

What we need is more programmers with a passion for their job, and if that 
means learning to write games, then so be it. One of the problems with "9 to 
5 code monkeys" is that programming is just a job for them. They do the 
absolute minimum they need to keep their job. They don't program for fun, or 
to learn new skills, or to solve problems. They go to user groups and forums 
like here only when they have a question they want answered, they take and 
take and take and they never give back.

I'd rather teach somebody passionate about writing games than somebody 
apathetic about programming, and I'd rather the games person became a 
programmer.

-- 
Steven

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

Re: Check for running DHCP daemon?

2015-01-21 Thread Jason Bailey

How would I get a list of running processes with the subprocess module? The 
documentation wasn't clear to me.

On Jan 21, 2015 7:21 PM, Dan Stromberg  wrote:
On Wed, Jan 21, 2015 at 3:06 PM, Jason Bailey  wrote:
> So I've got this python 3 script that needs to know if there is a running
> DHCP daemon (ISC DHCP server) on the local system. Is there a clean way to
> do this that (1) doesn't require me to do syscalls to local utilities (like
> ps, top, etc), and (2) doesn't require any custom modules (stock only)?

The subprocess module is quite clean on *ix.  Don't let the subprocess
mess on Windows steer you away from it on *ix.  And don't let the
"subprocesses are bad" from the perl community misguide you either -
shell is fast today because it's highly parallel, because it's
unafraid of subprocesses.

You could open the files under /proc and look around, if you're on
Linux. But parsing "ps -eo whatever" would probably be cleaner.

A "syscall" is an interaction with a kernel.  I think you meant an
os.system() call.

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

Re: What killed Smalltalk could kill Python

On Thu, Jan 22, 2015 at 2:23 PM, Steven D'Aprano
 wrote:
> What we need is more programmers with a passion for their job, and if that
> means learning to write games, then so be it. One of the problems with "9 to
> 5 code monkeys" is that programming is just a job for them. They do the
> absolute minimum they need to keep their job. They don't program for fun, or
> to learn new skills, or to solve problems. They go to user groups and forums
> like here only when they have a question they want answered, they take and
> take and take and they never give back.

Absolutely agree... as long as that passion results in solid
competence. Whether someone comes into programming because s/he wants
to write games, organize recipes, automate some specific task, or
prove some mathematical point, non-trivial programming nearly always
requires non-trivial effort. That's the same as any other skill (you
wouldn't expect to be able to build a car in a day, even if you've
been driving them for *ages* - like, say, two whole years - and have
this brilliant idea for how you could improve on every car on the
roads), but for some reason a lot of people think that computers
should be easy.

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

Python is DOOMED! Again!

Occasionally you find people spreading Fear, Uncertainty, Doubt about 
Python. Python is now over 20 years old and one of the most popular 
languages in the world no matter how you measure popularity:

http://import-that.dreamwidth.org/1388.html

so you don't often get FUD these days. When you do, it's usually about 
whitespace, or "Python is too slow", or occasionally "Python 3 is killing 
Python", but the latest FUD is about PEP 484 and type-hinting:

https://www.python.org/dev/peps/pep-0484/

Here's a typical example:

Python is already headed towards obscurity. ... it seems that 
GvR intends to drive the final nail in python's coffin with 
this "type hinting" crap that will convert Python syntax from 
a readable pseudo code into a cryptic nightmare.

Type hinting violates the very ESSENCE of what Python was
meant to be, that is: a "clean and intuitive syntax". 


(Google for it if you care for the source.)

So what is this unspeakable, nightmarish, cryptic abomination going to look 
like? Here's an example from PEP 484:

def greeting(name: str) -> str:
return 'Hello ' + name


I don't know about you, but I think anyone who cannot read that and intuit 
that argument `name` is a string and the return result is also a string is 
probably going to have bigger troubles with Python than just type-hinting.

Remember too that type-hinting will *absolutely* remain *completely* 
optional for Python. Developers can choose to use it or not, they can mix 
hinted code with regular unhinted code, they can use type declarations 
purely as documentation or they can run an optional type-checker, as they 
choose.

Here's a potential real-world example, from the statistics module in Python 
3.4, before and after adding annotations:

def median_grouped(data, interval=1): ...

def median_grouped(data:Iterable[Real], interval:Real=1)->Real: ...


I say "potential" because the standard library doesn't use annotations yet, 
but it may in the future. 

So how does Python's proposed type-hints compared to that used by other 
languages?

Java:

  public double median_grouped(List data, double interval) {}

Pascal:

  function median_grouped(data: IterableOfReal; interval: Real): Real;

C:

  double
  median_grouped (IterableOfReal data, double interval)

Haskell:

  median_grouped   :: [Double] Double -> Double
  median_grouped data interval =  ...


(I may have taken some very slight liberties with the syntax, corrections or 
more idiomatic forms are very welcome.)


I think it is clear that Python's annotation syntax remains quite close to 
executable pseudo-code. Fears that type-hints will doom Python are not 
credible.


-- 
Steve

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

Re: Check for running DHCP daemon?

On Thu, Jan 22, 2015 at 2:58 PM, Jason Bailey  wrote:
> How would I get a list of running processes with the subprocess module? The
> documentation wasn't clear to me.

Using the ps command. :)

rosuav@dewey:~$ python3
Python 3.4.2 (default, Oct  8 2014, 10:45:20)
[GCC 4.9.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> b" dhcpd\n" in subprocess.check_output(["ps","-A"])
False

rosuav@sikorsky:~$ python3
Python 3.5.0a0 (default:4709290253e3, Jan 20 2015, 21:48:07)
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> b" dhcpd\n" in subprocess.check_output(["ps","-A"])
True

There's a DHCP server running on Sikorsky, but not on Dewey. :)

Of course, this can be faked. Any process can call itself 'dhcpd' and
pretend to be the DHCP server. It's up to you to decide how to deal
with that. (Probably by not caring, I would expect. Unless you
actually expect someone to maliciously try to confuse your script,
it's not worth the hassle of protecting yourself.)

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

Re: How to "wow" someone new to Python

Mario Figueiredo wrote:

> But speaking about impressing more experient programmers, I personally
> don't think Python has a wow factor in any of its features and syntax. At
> least in the way I understand the word "wow".

Quote:

I've seen Python criticized as "ugly" precisely because it doesn't 
have a trick-based view of the world. In many ways, it's a dull
language, borrowing solid old concepts from many other languages &
styles: boring syntax, unsurprising semantics, few automatic 
coercions, etc etc. But that's one of the things I like about it.
- Tim Peters




-- 
Steve

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

Re: Python is DOOMED! Again!

On Thu, Jan 22, 2015 at 3:30 PM, Steven D'Aprano
 wrote:
> C:
>
>   double
>   median_grouped (IterableOfReal data, double interval)
>
>
> (I may have taken some very slight liberties with the syntax, corrections or
> more idiomatic forms are very welcome.)

C doesn't really have iterables, so this is more likely to be passed
in as an array of doubles and a length:

double median_grouped(double *data, int datasize, double interval)

> I think it is clear that Python's annotation syntax remains quite close to
> executable pseudo-code. Fears that type-hints will doom Python are not
> credible.

Yep. If Py3K didn't kill Python, PEP 393 didn't kill Python, and the
lack of Python 2.8 didn't kill Python, then type hinting doesn't have
much chance.

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

Re: How to "wow" someone new to Python

Alan Bawden wrote:

> Alan Bawden  writes:
>> ...  Score one for untyped languages.
> 
> Drat.  I should have writted "dynamically typed languages".
> 
> The language has changed.  When I was a novice Lisp hacker, we were
> comfortable saying that Lisp was "untyped".  But nowadays we always say
> that Lisp is "dynamically typed".  I could write an essay about why...

I've always understood that strictly speaking, "untyped" refers to low-level 
languages like assembly or Forth, where everything is a machine word.

In Forth, for example, all commands operate on single words on the stack, 
except for "double" variants which operate on two words at a time. E.g. you 
might have FOO to operate on the word at the top of the stack and FOOD to 
operate on the top two words. (Actually, given Forth's reputation for 
cryptic single-character line noise, it would probably be '^ and ''^ or 
something :-) In any case, there's a single stack, and double quantities 
aren't a separate data type, they're just two words.

(Some versions of Forth are arguably typed, in that they have a separate 
stack for floating point.)

I sometimes also use "untyped" to refer to languages like Hypertalk where 
everything is a string.

-- 
Steve

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

Re: What killed Smalltalk could kill Python

2015-01-21 Thread Emil Oppeln-Bronikowski

On Thu, Jan 22, 2015 at 10:55:27AM +1100, Chris Angelico wrote:

> Where's REXX today?

Still (somehow) alive in neo-Amiga platforms like AmigaOS4.x, MorphOS and AROS. 
I know that's as good as dead but there are still people writing AREXX glue 
code.

-- 
vag·a·bond adjective \ˈva-gə-ˌbänd\
 a :  of, relating to, or characteristic of a wanderer 
 b :  leading an unsettled, irresponsible, or disreputable life

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

Re: Trees

On Thursday, January 22, 2015 at 3:57:50 AM UTC+5:30, Paul Rubin wrote:
> Rustom Mody  writes:
> > Thats not bfs. That's inorder traversal
> 
> Oops, you're right.  How's this:
> 
> bfs x = go [x] where
>   go [] = []
>   go (L x:ts) = x:go ts
>   go (B x lst rst:ts) = x : go (ts ++ [lst, rst])
> 
> *Main> bfs t
> [6,2,8,1,4,7,9,3,5]

Yeah thats right.
And now you can get the duality between dfs and bfs you were earlier after by
replacing the 
ts ++ [lst,rst]
with
[lst,rst] ++ ts

BTW this is just converting queue to stack;
And its neat; and out of reach of those who think only imperatively

PS
1. Ive not tried it
2. For n-ary trees its neater
3. In my imaginary language with first-class sets, bags, lists it would be 
neater still
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Trees

On Thursday, January 22, 2015 at 4:25:03 AM UTC+5:30, Ian wrote:
> On Tue, Jan 20, 2015 at 6:23 PM, Rustom Mody wrote:
> > The Haskell is bullseye¹ in capturing the essense of a tree because
> > conceptually a tree of type t is recursive in the sense that it can contain
> > 2 subtrees -- (B x lst rst) -- or its a base case -- L x.
> 
> How do you create a tree containing an even number of elements under
> this constraint?

Not sure what you are asking...

[And a text only group makes discussing pictur-esque things hard]
What do you mean by 'element'?
Leaf? Internal? Either?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

Steven D'Aprano  writes:
> def median_grouped(data:Iterable[Real], interval:Real=1)->Real: ...

Wow, that's really nice.  I had heard something about Python type hints
but hadn't seen them before.

> So how does Python's proposed type-hints compared to that used by other 
> languages?

The most closely comparable hinting system I can think of is the Erlang
Dialyzer:

-spec median_grouped(iterable(real())) -> real().
median_grouped(Data, Interval) -> ... 

Some more info at: 

http://learnyousomeerlang.com/types-or-lack-thereof#for-type-junkies
http://learnyousomeerlang.com/dialyzer#plt
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What killed Smalltalk could kill Python

2015-01-21 Thread Terry Reedy


On 1/21/2015 7:16 PM, Mario Figueiredo wrote:

In article <873873ae91@jester.gateway.sonic.net>,
no.email@nospam.invalid says...


Steven D'Aprano  writes:

In 2009, Robert Martin gave a talk at RailsConf titled "What Killed
Smalltalk Could Kill Ruby"...  http://www.youtube.com/watch?v=YX3iRjKj7C0


That's an hour-long video; could someone who's watched it give a brief
summary?



In a nutshell, he argues, along with Ward Cunningham, that what killed
Smalltalk was how easy you could create unclean code with it. "Unclean"
in this context means Smalltalk didn't punish bad software design
decisions that would eventually lead into complex code and unmanageable
systems with zero options of code maintenance.


He followed that by saying that fine-grained test-driven development is 
the way to prevent unholy messes.  He noted that tdd started in 
smalltalk, but never really took there.


Reason 2: arrogance -- the walled garden and disdain for the messy 
problems of real enterprises. He did not seem as sure about how to 
counteract this.


--
Terry Jan Reedy

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

Re: Python is DOOMED! Again!

2015-01-21 Thread Nicholas Cole

I don't think that Python is doomed. I *do* think that type-hinting is
useful, and Python has borrowed a syntax that is similar to that used in
other languages, so that it is a familiar one to many developers.

It is a stretch to call it intuitive though, either to write or to
read. Personally, I would have favoured a doc string solution. The magic
comments that are part of the current proposal are genuinely intuitive, I
think. The function definition syntax is something to be learned and which
it takes me a little time to process even though I'm getting used to it. I
find that it's still a slight effort to remember which way around the name
of the argument and the type go. I'm sure I've seen one language that does
the oppoosite, and the fraction of a second it takes me to remember is a
tiny friction. There's no doubt, too, that long function definitions
(Python functions tend to have lots of arguments in the real world) are
going to look cluttered, and cluttered by lots of magic punctuation.

So useful, yes. Familiar already to those who use other languages, yes.
Intuitive, no. And there is a linguistic reason for that:

Consider this:

Define function add taking price1, price2, print_error equals true.

Yes, Python wouldn't understand that, but turning it in to a valid
definition requires only a tiny amount of effort.

Type definitions add a whole level of complexity:

Define function add taking the float price1, the float price2, print_error
equals the Boolean true. Make the function return a float.

Converting that into python simply requires more effort: in other words the
gap between what one might say in speech and what the code looks like is
bigger.

The reason for this is that a lot of information is being compressed in to
a small space. In English writing it is usually clearer to avoid long and
complicated sentences with lots of subclauses (even if they make perfect,
logical sense) in favour of shorter ones, and I think there is a parallel
here.

I would have preferred Python to mimic:

Define function add taking price1, the price2, print_error equals true.
Price1 is a float. Price2 is a float. The function returns a float.

But now this is sounding a little like something from Larry Wall, and so I
had better stop!  I wasn't trying to re-litigate the decisions that have
been taken, just to understand the friction.

Just my £0.2

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

Re: Python is DOOMED! Again!

On Thu, Jan 22, 2015 at 4:50 PM, Nicholas Cole  wrote:
> I would have preferred Python to mimic:
>
> Define function add taking price1, the price2, print_error equals true.
> Price1 is a float. Price2 is a float. The function returns a float.
>
> But now this is sounding a little like something from Larry Wall, and so I
> had better stop!

Actually, it sounds like pre-ANSI C. Something like this:

float add(price1, price2)
float price1;
float price2;
{
... body of function ...
}

Compare the more modern C style:

float add(float price1, float price2)
{
... body of function ...
}

(I omitted print_error from both as I don't know how pre-ANSI C did
default arguments, if at all. It's possible in the modern version but
I want the comparison to be fair.)

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

Re: Python is DOOMED! Again!

Paul Rubin  writes:
> -spec median_grouped(iterable(real())) -> real().

Oops:

 -spec median_grouped(iterable(real()), real()) -> real().
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

2015-01-21 Thread Ethan Furman

On 01/21/2015 08:30 PM, Steven D'Aprano wrote:
> 
> So what is this unspeakable, nightmarish, cryptic abomination going to look 
> like? Here's an example from PEP 484:
> 
> def greeting(name: str) -> str:
> return 'Hello ' + name
> 
> 
> I don't know about you, but I think anyone who cannot read that and intuit 
> that argument `name` is a string and the return result is also a string

There is nothing inherently intuitive about that syntax.  The : makes it look 
like a dictionary (but it isn't) and the
-> looks like a pointer to something (but it isn't).

> is probably going to have bigger troubles with Python than just type-hinting.

Yup, true -- I do find writing meta-classes takes extra work.  ;)

--
~Ethan~




signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

2015-01-21 Thread Mark Lawrence


On 22/01/2015 05:35, Paul Rubin wrote:

Steven D'Aprano  writes:

def median_grouped(data:Iterable[Real], interval:Real=1)->Real: ...


Wow, that's really nice.  I had heard something about Python type hints
but hadn't seen them before.



Currently flying here http://code.activestate.com/lists/python-ideas/30922/

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Python is DOOMED! Again!

2015-01-21 Thread Mark Lawrence


On 22/01/2015 05:56, Chris Angelico wrote:

On Thu, Jan 22, 2015 at 4:50 PM, Nicholas Cole  wrote:

I would have preferred Python to mimic:

Define function add taking price1, the price2, print_error equals true.
Price1 is a float. Price2 is a float. The function returns a float.

But now this is sounding a little like something from Larry Wall, and so I
had better stop!


Actually, it sounds like pre-ANSI C.



*SCREAMS OUT LOUD* at the thought of the Whitesmith's compiler where 
IIRC printf was spelt format and the formatting codes weren't the same.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Python is DOOMED! Again!

2015-01-21 Thread Rick Johnson

On Wednesday, January 21, 2015 at 10:31:12 PM UTC-6, Steven D'Aprano wrote:
> Occasionally you find people spreading Fear, Uncertainty, Doubt about 
> Python. Python is now over 20 years old and one of the most popular 
> languages in the world no matter how you measure popularity:

What's next, are you going to drool over the TIOBE index
again? I can't help but giggle when folks put faith in crap
like that. You wanna know why python-list gets so much spam?
Because "Guido-bot" is attempting to improve Python's TIOBE
rating.

> so you don't often get FUD these days. When you do, it's
> usually about whitespace, or "Python is too slow", or
> occasionally "Python 3 is killing Python", but the latest
> FUD is about PEP 484 and type-hinting:

Yeah because people *NEVER* complain when they have *REAL*
problems, do they "Mr DeWaldo"?

> So what is this unspeakable, nightmarish, cryptic
> abomination going to look like? Here's an example from PEP
> 484:
> 
> def greeting(name: str) -> str:
> return 'Hello ' + name
> 
> I don't know about you, but I think anyone who cannot read
> that and intuit that argument `name` is a string and the
> return result is also a string is probably going to have
> bigger troubles with Python than just type-hinting.
> 
> Remember too that type-hinting will *absolutely* remain
> *completely* optional for Python. Developers can choose to
> use it or not, 

But they cannot choose whether to *READ* it or not. Once
it's out there, it's out there, and everyone who has to
maintain code or read tutorials will have to suffer reading
noise they did not choose to write. This is not a "self-
inflicted" wound Steven, this is "assault with a noisy weapon"!

> they can mix hinted code with regular unhinted code, they
> can use type declarations purely as documentation or they
> can run an optional type-checker, as they choose.

The only thing worse than a bad idea is an inconsistent bad idea!

> Here's a potential real-world example, from the statistics
> module in Python 3.4, before and after adding annotations:

> 
> def median_grouped(data, interval=1): ...
> 
> def median_grouped(data:Iterable[Real], interval:Real=1)->Real: ...

Nice! I like how the first "toy example" was less noisy,
and then way down here you show us the real butt-uglyness of
this "feature from hell"!

> I think it is clear that Python's annotation syntax
> remains quite close to executable pseudo-code. 

Sure, for some perverted definition of "quite" and "close"!

> Fears that type-hints will doom Python are not credible.

Listen, there is a way that type hints can be introduced
*WITHOUT* forcing folks who don't care about them to read
them. If Mr Van Rossom would like my assistance, tell him to
send me a private email or ask me in this thread. 

However, if he refuses and continues down this "road to
perdition", i will be unable to help him save the Python
language, and all his work will have been for nothing. 

For the sake of this community and the many noobs who have
not found programming bliss via Python, i implore you to do
everything in your power to convince GvR that he is making a
grave mistake, for which no recovery will be possible.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What killed Smalltalk could kill Python

2015-01-21 Thread Mark Lawrence


On 22/01/2015 02:11, Rick Johnson wrote:

On Wednesday, January 21, 2015 at 10:34:40 AM UTC-6, Steven D'Aprano wrote:

In 2009, Robert Martin gave a talk at RailsConf titled
"What Killed Smalltalk Could Kill Ruby". (No cheering,
that sort of attitude is one of the things that killed
Smalltalk.) Although Martin discusses Ruby, the lessons
could also apply to Python.


Python is already headed towards obscurity. The fall began
with the release of Python3000 (from which we "might" have
recovered), but now it seems that GvR intends to drive the
final nail in python's coffin with this "type hinting" crap
that will convert Python syntax from a readable pseudo code
into a cryptic nightmare.

Type hinting violates the very *ESSENCE* of what Python was
meant to be, that is: a "clean and intuitive syntax". The
cleanness of Python is what attracts people to it, and the
hook is set when they discover the breadth of the stdlib.

If GvR brings this gawd awful type hinting idea to reality,
IT'S OVER! Python will be lost forever to history as just
another "interesting oddity". Time to call up the Robert
Ripley estate and request some space in his museum!



April 1st already?

Or will Python be saved by RickedPython3?

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Python is DOOMED! Again!

Rick Johnson  writes:
>> def median_grouped(data:Iterable[Real], interval:Real=1)->Real: ...
>
> Nice! I like how the first "toy example" was less noisy,
> and then way down here you show us the real butt-uglyness of
> this "feature from hell"!

It looks fine to me.  I'm still using Python 2.7 because I haven't found
a really compelling reason to migrate to Python 3, but this makes it
start looking worthwhile.

> Listen, there is a way that type hints can be introduced *WITHOUT*
> forcing folks who don't care about them to read them. 

You could write some IDE features to suppress visibility of the hints.
Or maybe it could be done with a decorator-like construct:

  @-spec(Iterable[Real], Real) -> Real

> For the sake of this community and the many noobs who have not found
> programming bliss via Python, i implore you to do everything in your
> power to convince GvR that he is making a grave mistake, for which no
> recovery will be possible.

I've always found Python 3 annoying because it broke compatibility with
Python 2, but only by a little bit, not enough to add real benefits.
This is a real benefit so IMHO it makes the language more attractive
rather than less.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Trees

On Wed, Jan 21, 2015 at 11:56 PM, Ian Kelly  wrote:
> Since each element is associated with a node, the question could
> equally be phrased as "How do you create a tree containing an even
> number of elements under this constraint?"

Of course I meant to write "nodes" there, not "elements".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Trees

On Wed, Jan 21, 2015 at 10:20 PM, Rustom Mody  wrote:
> On Thursday, January 22, 2015 at 4:25:03 AM UTC+5:30, Ian wrote:
>> On Tue, Jan 20, 2015 at 6:23 PM, Rustom Mody wrote:
>> > The Haskell is bullseye¹ in capturing the essense of a tree because
>> > conceptually a tree of type t is recursive in the sense that it can contain
>> > 2 subtrees -- (B x lst rst) -- or its a base case -- L x.
>>
>> How do you create a tree containing an even number of elements under
>> this constraint?
>
> Not sure what you are asking...
>
> [And a text only group makes discussing pictur-esque things hard]
> What do you mean by 'element'?
> Leaf? Internal? Either?

By "element" I mean an individual datum contained in the tree.
Likewise the elements of a list are its contents.

Since each element is associated with a node, the question could
equally be phrased as "How do you create a tree containing an even
number of elements under this constraint?" The point I was driving at
is that the definition is incomplete -- in addition to being an
internal node or a leaf, a tree can also be empty. In fact I would
suggest that an empty tree should be the real base case, since what is
a leaf node but a node where both of its children are empty trees?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Trees

Ian Kelly  writes:
> How do you create a tree containing an even number of elements under
> this constraint?

That's a good point, I've usually seen different definitions of trees,
e.g.

   data Tree a = Leaf | Branch a (Tree a) (Tree a)

so a Leaf node doesn't have a value associated with it.

  https://en.wikipedia.org/wiki/File:Red-black_tree_example.svg

has a picture of such a tree--don't worry about the node coloring for
this purpose.  Or the multi-way tree with arbitrary branching width:

   data RoseTree a = RoseTree a [RoseTree a]

Each node has a value and a list of zero or more subtrees.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!