Socket ICMP V6 error

[ermanolillo]

I've made a snniferr for a ICMP socket that works with IPv4. This is the
code:


import sys
import socket
import struct
import select
import time
import signal
import re

HOST = raw_input("Enter the interface to listen: ")

s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_ICMP)
s.bind((HOST, 0))
s.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1)

print "Server Started.."
for i in range(1,2000):

data = s.recvfrom(65565)
d1 = str(data[0])
data1 = re.search('@@(.*)', d1)

command = data1.group(0)
cmd = command[2:]
if i%2 == 0:
d = data[1]
d1 = str(d)
ip = d1[2:-5]

print cmd 
print ip

I have done a modification to adapt it to IPv6:



s = socket.socket(socket.AF_INET6, socket.SOCK_RAW, socket.IPPROTO_ICMPV6)

However I recive the next error:



File "server.py", line 16, in 
s.bind((HOST, 0))
File "/usr/lib/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
socket.error: [Errno 22] Invalid argument

Could someone please help me?.

Thanks in advance



--
View this message in context: 
http://python.6.x6.nabble.com/Socket-ICMP-V6-error-tp5083962.html
Sent from the Python - python-list mailing list archive at Nabble.com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Mario Figueiredo]

In article <54c0a571$0$13002$c3e8da3$54964...@news.astraweb.com>, 
steve+comp.lang.pyt...@pearwood.info says...
> 
> The point isn't that there are no other alternative interpretations 
> possible, or that annotations are the only syntax imaginable, but that 
> they're not hard to guess what they mean, and if you can't guess, they're 
> not hard to learn and remember.

Possibly one common use case will be Unions. And that factory syntax is 
really awful and long when you look at a function definition with as 
little as 3 arguments. The one below has only 2 arguments.

def handle_employees(emp: Union[Employee, Sequence[Employee]], raise: 
Union[float, Sequence[float]]) -> Union[Employee, Sequence[Employee], 
None]:

That's for a generic list-like container. Have fun with the Mapping 
union.

Meanwhile there's quite a few more generics like the Sequence one above 
you may want to take a look at and try and remember. And that's just one 
factory (the generics support factory). You may also want to take a look 
at TypeVar and Callable for more syntactic hell.
 
Meanwhile, there's the strange decision to implement type hints for 
local variables # comment lines. I have an hard time wrapping my head 
around this one. Really, comments!?

Finally, remember all this is being added to your code just to 
facilitate static analysis. Strangely enough though I was taught from 
the early beginning that once I start to care about types in Python, I 
strayed from the pythonic way. I'm confused now... What is it then?
-- 
https://mail.python.org/mailman/listinfo/python-list

An improper change in httplib.py

[Guohua Ouyang]

This is my first post to the list, I apologies firstly if I made any mistake.

I was trying to get a package in golang behind the http or https
proxy, and it reports  an error "AttributeError: httpsconnection
instance has no attribute '_set_hostport'", details in the bottom.
After some trace work, I found it caused by the changes in the issue issue7776.

@@ -718,7 +734,7 @@
 else:
 self._tunnel_headers.clear()

-def _set_hostport(self, host, port):
+def _get_hostport(self, host, port):

First, it changes the method's name, doesn't it break the
compatibility for other packages, on my system,
mercurial-3.0-2.fc21.x86_64 still use "_set_hostport" as the error
shows.

Second, I found that line 1132 of [2] still use "
self._conn._set_hostport(host, port)", which should be
"_get_hostport", right?

[1] http://bugs.python.org/issue7776
[2] https://github.com/python/cpython/blob/2.7/Lib/httplib.py


$ go get code.google.com/p/go-uuid/uuid
# cd .; hg clone -U https://code.google.com/p/go-uuid
/home/guohua/go/src/code.google.com/p/go-uuid
** unknown exception encountered, please report by visiting
** http://mercurial.selenic.com/wiki/BugTracker
** Python 2.7.8 (default, Nov 10 2014, 08:19:18) [GCC 4.9.2 20141101
(Red Hat 4.9.2-1)]
** Mercurial Distributed SCM (version 3.0)
** Extensions loaded:
Traceback (most recent call last):
  File "/usr/bin/hg", line 38, in 
mercurial.dispatch.run()
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py",
line 28, in run
sys.exit((dispatch(request(sys.argv[1:])) or 0) & 255)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py",
line 69, in dispatch
ret = _runcatch(req)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py",
line 138, in _runcatch
return _dispatch(req)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py",
line 810, in _dispatch
cmdpats, cmdoptions)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py",
line 590, in runcommand
ret = _runcommand(ui, options, cmd, d)
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py",
line 901, in _runcommand
return checkargs()
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py",
line 872, in checkargs
return cmdfunc()
  File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py",
line 807, in 
d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
  File "/usr/lib64/python2.7/site-packages/mercurial/util.py", line
518, in check
return func(*args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/mercurial/commands.py",
line 1298, in clone
branch=opts.get('branch'))
  File "/usr/lib64/python2.7/site-packages/mercurial/hg.py", line 295, in clone
srcpeer = peer(ui, peeropts, source)
  File "/usr/lib64/python2.7/site-packages/mercurial/hg.py", line 129, in peer
return _peerorrepo(rui, path, create).peer()
  File "/usr/lib64/python2.7/site-packages/mercurial/hg.py", line 106,
in _peerorrepo
obj = _peerlookup(path).instance(ui, path, create)
  File "/usr/lib64/python2.7/site-packages/mercurial/httppeer.py",
line 261, in instance
inst._fetchcaps()
  File "/usr/lib64/python2.7/site-packages/mercurial/httppeer.py",
line 58, in _fetchcaps
self.caps = set(self._call('capabilities').split())
  File "/usr/lib64/python2.7/site-packages/mercurial/httppeer.py",
line 172, in _call
fp = self._callstream(cmd, **args)
  File "/usr/lib64/python2.7/site-packages/mercurial/httppeer.py",
line 119, in _callstream
resp = self.urlopener.open(req)
  File "/usr/lib64/python2.7/urllib2.py", line 404, in open
response = self._open(req, data)
  File "/usr/lib64/python2.7/urllib2.py", line 422, in _open
'_open', req)
  File "/usr/lib64/python2.7/urllib2.py", line 382, in _call_chain
result = func(*args)
  File "/usr/lib64/python2.7/site-packages/mercurial/url.py", line
372, in https_open
return self.do_open(self._makeconnection, req)
  File "/usr/lib64/python2.7/site-packages/mercurial/keepalive.py",
line 254, in do_open
self._start_transaction(h, req)
  File "/usr/lib64/python2.7/site-packages/mercurial/url.py", line
358, in _start_transaction
return keepalive.KeepAliveHandler._start_transaction(self, h, req)
  File "/usr/lib64/python2.7/site-packages/mercurial/keepalive.py",
line 352, in _start_transaction
h.endheaders()
  File "/usr/lib64/python2.7/httplib.py", line 991, in endheaders
self._send_output(message_body)
  File "/usr/lib64/python2.7/httplib.py", line 844, in _send_output
self.send(msg)
  File "/usr/lib64/python2.7/site-packages/mercurial/url.py", line
144, in _sendfile
orgsend(self, data)
  File "/usr/lib64/python2.7/site-packages/mercurial/keepalive.py",
line 532, in safesend
self.connect()
  File "/usr/lib64/python2.7/site-packages/mercurial/url.py", line
342, in connect
_generic_proxytunnel(self)
  File "/usr/lib64/python2.7/site-packages/mercurial/url.py", line
228, in _generic_proxytunnel
self.

Re: Python is DOOMED! Again!

[Rick Johnson]

On Thursday, January 22, 2015 at 12:48:46 AM UTC-6, Paul Rubin wrote:
> Sir Richard Johnson writes:
> 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

Yes, YES, *YES* That would be my first choice, or 
docstrings as a secondary. But to introduce new syntax 
into the method signatures is SUICIDE! What the hell is
this man thinking?

> > 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.

Agreed. I'm not against the idea, heck, i want to see Python
improve just like anybody who loves this language, but the
implementation just plain sucks! Please convince GvR to move
this noisy syntax OUTSIDE of the signature! It's too noisy 
and its going to turn people off.
-- 
https://mail.python.org/mailman/listinfo/python-list

python client call Java server by xmlrpc

[fan . ding1]

Hi all

I have xmlrpc server written in Java, and it has a method like

Fun( vector, vector), the vector is array of user-defined object, which is 
a class  extends HashMap.

And I call it like:

server = xmlrpclib.ServerProxy("http://myserver";)

server.Fun( [ {"0.5":0.1}], [ ] )

It always fails with error

'No method matching arguments: , [Ljava.lang.Object;, [Ljava.lang.Object; 
'


Does anyone use this before? It troubles me some days.

Thanks a  lot.

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

Re: Python is DOOMED! Again!

[Mark Lawrence]

On 22/01/2015 08:24, Rick Johnson wrote:


Yes, YES, *YES* That would be my first choice, or
docstrings as a secondary. But to introduce new syntax
into the method signatures is SUICIDE! What the hell is
this man thinking?


I take it you mean these men Guido van Rossum , 
Jukka Lehtosalo , Łukasz Langa langa.pl> as they are the authors of PEP484?




Agreed. I'm not against the idea, heck, i want to see Python
improve just like anybody who loves this language, but the
implementation just plain sucks! Please convince GvR to move
this noisy syntax OUTSIDE of the signature! It's too noisy
and its going to turn people off.



What implementation?  The PEP is quite clearly marked as draft.  The 
Re-enactment of the Battle of Pearl Harbour is currently ongoing over on 
python-ideas regarding exactly what should be implemented.  There is 
also nothing to stop you writing another PEP with an alternative 
proposal, although I suspect there is as much chance of that ever 
happening as there is of ever seeing RickedPython(3).


--
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]

On Thursday, January 22, 2015 at 1:23:40 AM UTC-6, Steven D'Aprano wrote:

> The point isn't that there are no other alternative
> interpretations possible, or that annotations are the only
> syntax imaginable, but that they're not hard to guess what
> they mean, and if you can't guess, they're not hard to
> learn and remember.

That's highly subjective. Could you please stop licking
Guido's boots long enough to take a whiff of what the hell
you're shoveling? Is being teachers pet so important that
you're willing to turn off a vast majority of new Python
programmers? How much longer can this hemorrhaging go on
Steven?

Python is the only thing that is pure in the programming
world. The only language that offers the cleanest and most
intuit-able syntax, AND YOU"RE JUST GOING TO THROW IT ALL
AWAY SO YOU CAN BE A LAPDOG OF SATAN?

Everybody better listen up, and you'd better listen up good
folks. Because we've only got a short time to act before
this monstrosity is enacted. You need send Guido emails (and
lots of them) and tell him how destructive this is going to
be to our community. Stop being cowards, it's time to put
the big boy pants on. 

If you don't act now, then don't bother complaining later.
Python is dangling by a thin thread, and this is your last
chance to save everything we've worked for. All the lines of
code we've written won't mean spit if the language takes a
swan dive into obscurity!

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

Re: An improper change in httplib.py

[Mark Lawrence]

On 22/01/2015 03:38, Guohua Ouyang wrote:

This is my first post to the list, I apologies firstly if I made any mistake.

I was trying to get a package in golang behind the http or https
proxy, and it reports  an error "AttributeError: httpsconnection
instance has no attribute '_set_hostport'", details in the bottom.
After some trace work, I found it caused by the changes in the issue issue7776.

@@ -718,7 +734,7 @@
  else:
  self._tunnel_headers.clear()

-def _set_hostport(self, host, port):
+def _get_hostport(self, host, port):

First, it changes the method's name, doesn't it break the
compatibility for other packages, on my system,
mercurial-3.0-2.fc21.x86_64 still use "_set_hostport" as the error
shows.

Second, I found that line 1132 of [2] still use "
self._conn._set_hostport(host, port)", which should be
"_get_hostport", right?

[1] http://bugs.python.org/issue7776
[2] https://github.com/python/cpython/blob/2.7/Lib/httplib.py


You've found a bug so please raise it on bugs.python.org :)

--
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!

[Mark Lawrence]

On 22/01/2015 04:30, 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:

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 it's doomed again, big deal, it's the third time this week and the 
dustmen simply won't take it.


--
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!

[Nicholas Cole]

On Thu, Jan 22, 2015 at 8:10 AM, Mario Figueiredo  wrote:
> In article <54c0a571$0$13002$c3e8da3$54964...@news.astraweb.com>,
> steve+comp.lang.pyt...@pearwood.info says...
>>
>> The point isn't that there are no other alternative interpretations
>> possible, or that annotations are the only syntax imaginable, but that
>> they're not hard to guess what they mean, and if you can't guess, they're
>> not hard to learn and remember.
>
> Possibly one common use case will be Unions. And that factory syntax is
> really awful and long when you look at a function definition with as
> little as 3 arguments. The one below has only 2 arguments.
>
> def handle_employees(emp: Union[Employee, Sequence[Employee]], raise:
> Union[float, Sequence[float]]) -> Union[Employee, Sequence[Employee],
> None]:
>
> That's for a generic list-like container. Have fun with the Mapping
> union.

To be fair, is it clearer with some kind of formatting?

def handle_employees(
emp: Union[Employee, Sequence[Employee]],
raise: Union[float, Sequence[float]])
-> Union[Employee, Sequence[Employee], None]:

I still find that hard to read, but the line breaks help.  Just for
fun, I'd like to put out that without all of that noise the function
reads:

def handle_employees(employees, raise):
.
return employees

And suddenly it looks like what most people who know anything about
programming recognise as Python again! With some kind of doc-string or
similar syntax it would read something like:

def handle_employees(employees, rasie):
# employees: Union[Employee, Sequence[Employee]]
# raise:  Union[float, Sequence[float]]
# return: Union[Employee, Sequence[Employee], None]
.
return employeees

There's a reasonable case that this is not all that dissimilar from
the function annotation syntax above, but the difference is surely
that in the one case you see immediately that there are two arguments,
and in the other you can't be sure without parsing some very cluttered
punctuation-heavy syntax.

Still, it would have been nicer to be able to write something like
this (where the Unions are implicit):

def handle_employees(employees, rasie):
# employees: Employee, Sequence[Employee]
# raise:  float, Sequence[float]
# return: Employee, Sequence[Employee], None


Yes, I know that function annotations have been defined for a while,
and yes, I know that they are similar to a syntax used in other
languages, and yes, I know that they are optional.  All the same,
either they are going to become the norm or they are not. If they
become the norm (as I think they will because type hinting seems to
solve many problems that the community cares about) then I think we
have to accept that an important part of the language will become much
more cluttered, much less intuitive, and much more off-putting to
many.

I think the fact that the current proposals mix the annotation syntax
with an inline comment syntax is also horrible (though I don't see any
alternatives).  I would much rather have put all of the "magic" in to
comments or none.

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

Re: Python is DOOMED! Again!

[Chris Angelico]

On Thu, Jan 22, 2015 at 7:10 PM, Mario Figueiredo  wrote:
> Possibly one common use case will be Unions. And that factory syntax is
> really awful and long when you look at a function definition with as
> little as 3 arguments. The one below has only 2 arguments.
>
> def handle_employees(emp: Union[Employee, Sequence[Employee]], raise:
> Union[float, Sequence[float]]) -> Union[Employee, Sequence[Employee],
> None]:

Hold on a moment, how often do you really do this kind of thing with
"might be one of them or a sequence"? Do you really have a function
that could take an Employee and a float, or a sequence of Employees
and a single float, or a single Employee and a sequence of floats, or
a sequence of both? Or do you, much more likely, actually have two
separate functions:

def handle_employee(emp: Employee, raise: float) -> Optional[Employee]:

def handle_employees(emp: Sequence[Employee], raise: Sequence[float])
-> List[Employee]:

The union in the return value seems particularly unlikely... and unhelpful.

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

Re: Python is DOOMED! Again!

[Marko Rauhamaa]

Rick Johnson :

> Python is the only thing that is pure in the programming world. The
> only language that offers the cleanest and most intuit-able syntax,
> AND YOU"RE JUST GOING TO THROW IT ALL AWAY SO YOU CAN BE A LAPDOG OF
> SATAN?

I think the SATAN is in the optional type declarations, not in the
particular syntax chosen.


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

Re: Socket ICMP V6 error

[Chris Angelico]

On Thu, Jan 22, 2015 at 7:00 PM, ermanolillo  wrote:
> s = socket.socket(socket.AF_INET6, socket.SOCK_RAW, socket.IPPROTO_ICMPV6)
>
> However I recive the next error:
>
>
>
> File "server.py", line 16, in 
> s.bind((HOST, 0))
> File "/usr/lib/python2.7/socket.py", line 224, in meth
> return getattr(self._sock,name)(*args)
> socket.error: [Errno 22] Invalid argument
>
> Could someone please help me?.
>

For a start, what HOST are you using?

(Point of style: It's unusual to use an all-uppercase name like HOST
for something non-constant - in this case, it's coming from keyboard
input.)

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

Re: Python is DOOMED! Again!

[Chris Angelico]

On Thu, Jan 22, 2015 at 9:05 PM, Marko Rauhamaa  wrote:
> Rick Johnson :
>
>> Python is the only thing that is pure in the programming world. The
>> only language that offers the cleanest and most intuit-able syntax,
>> AND YOU"RE JUST GOING TO THROW IT ALL AWAY SO YOU CAN BE A LAPDOG OF
>> SATAN?
>
> I think the SATAN is in the optional type declarations, not in the
> particular syntax chosen.

So optional type declarations are officially "the details" now? :)

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

Re: Python is DOOMED! Again!

[Mario Figueiredo]

Rick,


Python is the only thing that is pure in the programming world. The
only language that offers the cleanest and most intuit-able syntax,
AND YOU"RE JUST GOING TO THROW IT ALL AWAY SO YOU CAN BE A LAPDOG OF
SATAN?


Nonsense. You are just used to it. I can read C with the same feeling of 
intuitiveness as you do Python. There's nothing inherently more intuitive 
about python and I just wished that meme died already. Besides it's all in 
the eye of the beholder. Some people, for intance, aren't all that comfortable 
about python white space as much as many die-hard pythonists would like to 
admit. It's not even a feature that gained traction on programming languages 
that came after python. 


If you don't act now, then don't bother complaining later. Python is
dangling by a thin thread, and this is your last chance to save
everything we've worked for. All the lines of code we've written won't
mean spit if the language takes a swan dive into obscurity!


PEP 484 just becomes silly when it comes to the section where it discusses 
whether type hints are pythonic. If that ridiculous paragraph reflects how 
we are looking today at the inclusion of new features, than I agree python 
is walking a dangerous road. But that also means Type Hints aren't the real 
problem here. We have a much bigger problem about the programming language 
principles and phylosophy.


In all honesty though, I never cared much about the ideals and zens in programming 
languages, especially ones want to want to adopt a batteries-included philosophy. 
Always seemed to me like nonsense talk. My experience taught me that you 
can't just have the latter without eventually breaking the former. 'import 
this' always read to me like wishful thinking.


Python isn't going anywhere towards obscurity. Not at least until a competiting 
language comes (it hasn't yet). I agree though that Python complexity has 
increased greatly over the years and this isn't showing any signs of stopping. 
And that is exactly the type of thing that promotes the birth of a new and 
better programming language. And, interestingly enough, that is always a 
good thing.



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

Re: Python is DOOMED! Again!

[Mario Figueiredo]

Chris,


Hold on a moment, how often do you really do this kind of thing with
"might be one of them or a sequence"?


Is it really that important that I give a more real-life example, or can't 
you just get the problem from a ad-hoc example?


I could replace the variable names with spam, ham and eggs, if you wish.


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

Python is DOOMED! Again!

[Nicholas Cole]

On Thursday, 22 January 2015, Chris Angelico > wrote:

> On Thu, Jan 22, 2015 at 7:10 PM, Mario Figueiredo 
> wrote:
> > Possibly one common use case will be Unions. And that factory syntax is
> > really awful and long when you look at a function definition with as
> > little as 3 arguments. The one below has only 2 arguments.
> >
> > def handle_employees(emp: Union[Employee, Sequence[Employee]], raise:
> > Union[float, Sequence[float]]) -> Union[Employee, Sequence[Employee],
> > None]:
>
> Hold on a moment, how often do you really do this kind of thing with
> "might be one of them or a sequence"? Do you really have a function
> that could take an Employee and a float, or a sequence of Employees
> and a single float, or a single Employee and a sequence of floats, or
> a sequence of both? Or do you, much more likely, actually have two
> separate functions:
>
> def handle_employee(emp: Employee, raise: float) -> Optional[Employee]:
>
> def handle_employees(emp: Sequence[Employee], raise: Sequence[float])
> -> List[Employee]:
>
> The union in the return value seems particularly unlikely... and unhelpful.
>

Hang on! The particular example may not make a lot of sense but there are
plenty of places in ordinary Python where functions can accept different
objects in arguments and return different things. The point here is that
that will become rapidly messy and hard to read.

Perhaps the new PEP will discourage this kind of thing and perhaps that is
to be welcomed not feared, but I don't think the example itself was
particularly contrived. I've seen it in plenty of code in the wild.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Chris Angelico]

On Thu, Jan 22, 2015 at 9:46 PM, Nicholas Cole  wrote:
> Hang on! The particular example may not make a lot of sense but there are
> plenty of places in ordinary Python where functions can accept different
> objects in arguments and return different things. The point here is that
> that will become rapidly messy and hard to read.

Yes; but with proper use of TypeVar can simplify things a lot - have a
read of the PEP.

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

Re: Python is DOOMED! Again!

[Chris Angelico]

On Thu, Jan 22, 2015 at 9:37 PM, Mario Figueiredo  wrote:
> Chris,
>
>> Hold on a moment, how often do you really do this kind of thing with
>> "might be one of them or a sequence"?
>
>
> Is it really that important that I give a more real-life example, or can't
> you just get the problem from a ad-hoc example?
>
> I could replace the variable names with spam, ham and eggs, if you wish.

I'd rather see a real-world example that can't be solved with either
better design or some simple aliases. (And yes, the type hinting does
allow for aliases.)

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

Re: Python is DOOMED! Again!

[Mario Figueiredo]

Chris,


I'd rather see a real-world example that can't be solved with either
better design or some simple aliases. (And yes, the type hinting does
allow for aliases.)


Python is a duck-typing language, Chris. It is in its nature -- and we have 
been taught -- to ignore types and care only about operators. This means 
one of the most common design decisions in Python is exactly to code functions 
that are type ignorant. That is exactly why we need Type Hinting, because 
duck-typing complicates static analysis. And that is exactly why the Unions 
factory are a necessary part of the type hinting mechanism in PEP 484.


You will be seeing lots and lots of Unions in type annotated code once it 
gets implemented. And it's not because of the complexity of Unions syntax 
that I should now care about refactoring my code. That is a no-no.


If you don't know of any real-life example of python functions that will 
eventually force you into annotate them with unions syntax, look no further 
than your standard library. And also start questioning if you aren't complicating 
your own code with unnecessary function overloads.



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

Re: Python is DOOMED! Again!

[Mario Figueiredo]

Chris,


On Thu, Jan 22, 2015 at 9:46 PM, Nicholas Cole
 wrote:


Hang on! The particular example may not make a lot of sense but there
are plenty of places in ordinary Python where functions can accept
different objects in arguments and return different things. The point
here is that that will become rapidly messy and hard to read.


Yes; but with proper use of TypeVar can simplify things a lot - have a
read of the PEP.

ChrisA



I agree. TypeVar will help tremendously by removing the need for union in 
cases of object inheritance. But only on cases of object inheritance.



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

Re: Python is DOOMED! Again!

[Chris Angelico]

On Thu, Jan 22, 2015 at 10:12 PM, Mario Figueiredo  wrote:
> I agree. TypeVar will help tremendously by removing the need for union in
> cases of object inheritance. But only on cases of object inheritance.

Why only inheritance? One of the examples is of str and bytes, which
don't have any inheritance relationship (they both just subclass
object), and it works just fine for that.

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

Re: What killed Smalltalk could kill Python

[Gene Heskett]

On Wednesday 21 January 2015 23:46:09 Emil Oppeln-Bronikowski did opine
And Gene did reply:
> 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.

He asked about REXX, not AREXX. There is no comparison between the two as 
AREXX was a huge superset of REXX.

I have co-written some rather widely distributed amiga code in AREXX, then 
compiled it to standalone with RexxPlus.

When I switched platforms to linux in 1998, the first thing I did was to 
go find an AREXX for linux.  But had to settle for IBM's REXX/Regina, 
which wasn't capable of running any of our AREXX code.  AREXX hooked into 
the OS and there wasn't anything I ever wanted to do that could not be 
done in AREXX.

REXX/Regina is an extremely emasculated language that has zero connection 
into the os, and I found it completely useless when compared to AREXX.

If, when anyone here was using an amiga, and was using EzCron to schedule 
stuff, Jim Hines and I wrote it as there was no such scheduler for 
amigados.  Everything else we laid our hands on killed time by 
busywaiting, killing the machines performance. EzCron put itself to sleep 
intelligently by asking what time it was, and then sleeping until the 
first second of the next minute. That we published at the time, and then 
built on that for EzHome, which was a dumber version of what we call heyu 
today.

Trivia bit: William Hawes, who wrote AREXX and sold it thru the commode 
door sales channels, was never paid a dime for his work. But those 2 guys 
screwed everybody. He had an account on kernel.org in 1998, might still 
have, but it was empty then and the last time I looked, probably 5 years 
ago.

So I have no clue what a very talented programmer is doing for a living 
today. To me, that sad as hell.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Steven D'Aprano]

Mario Figueiredo wrote:

> In article <54c0a571$0$13002$c3e8da3$54964...@news.astraweb.com>,
> steve+comp.lang.pyt...@pearwood.info says...
>> 
>> The point isn't that there are no other alternative interpretations
>> possible, or that annotations are the only syntax imaginable, but that
>> they're not hard to guess what they mean, and if you can't guess, they're
>> not hard to learn and remember.
> 
> Possibly one common use case will be Unions. And that factory syntax is
> really awful and long when you look at a function definition with as
> little as 3 arguments. The one below has only 2 arguments.
> 
> def handle_employees(emp: Union[Employee, Sequence[Employee]], raise:
> Union[float, Sequence[float]]) -> Union[Employee, Sequence[Employee],
> None]:

You can't use "raise" as a parameter name, since that's a keyword. Using
floats for money is Just Wrong and anyone who does so should have their
licence to program taken away. And I really don't understand what this
function is supposed to do, that it returns None, a single Employee, or a
sequence of Employees. (If it's hard to declare what the return type is,
perhaps your function does too much or the wrong thing.)

But putting those aside, let's re-write that with something a little closer
to PEP-8 formatting:

def handle_employees(
emp: Union[Employee, Sequence[Employee]],
pay_raise: Union[int, Sequence[int]]
) -> Union[Employee, Sequence[Employee], None]:
pass


That's quite nice and easy to follow. I can think of three improvements:

(1) Allow the return annotation to be on a line on its own rather than force
it to follow the closing bracket;

(2) Support | to make Unions of types;

(3) Have a shorter way to declare "Spam or Sequence (tuple?) of Spam". 


def handle_employees(
emp: OneOrMore[Employee],
pay_raise: OneOrMore[int])
-> OneOrMore[Employee] | None:
pass


(2) has been rejected by Guido, but he may change his mind. The name I've
chosen for (3) is just the first thing I've thought of.



> Meanwhile there's quite a few more generics like the Sequence one above
> you may want to take a look at and try and remember. And that's just one
> factory (the generics support factory). You may also want to take a look
> at TypeVar and Callable for more syntactic hell.

Exaggerate, much?

  
> Meanwhile, there's the strange decision to implement type hints for
> local variables # comment lines. I have an hard time wrapping my head
> around this one. Really, comments!?

Yes, really. There is plenty of prior art for machine-meaningful comments:

- mypy uses it, and it works fine
- Pascal uses {$ ...} compiler directives
- Unix uses a special hash-bang #! comment in the first line to 
  specify the executable that runs the script
- Python supports a special encoding declaration using #
- doctest uses comments for directives
- HTML puts code (Javascript usually) inside of comments
- JMSAssert for Java uses comments for design-by-contract assertions


But note that the type declarations have *no runtime effect*. They truly are
comments, aimed at the human reader and any compliant type-checker.


Guido has said that he isn't ruling out an explicit syntactic support for
type declarations in the future, but right now there are various
constraints:

- it must be backwards compatible, i.e. something that Python 3.4 and older
  will just ignore
- it must be available by lexical analysis, that is, from reading the 
  source code, which rules out anything that happens at runtime
- it must be human-readable
- and easily parsed by even simple tools



> Finally, remember all this is being added to your code just to
> facilitate static analysis. 

You say "just" to facilitate static analysis, but let me put it this way. It
is "just" to facilitate:

- improved correctness of programs
- to assist in finding bugs as early as possible
- reduced need to write tedious, boring unit tests to check things 
  that an automated type-checker can deal with instead
- to reduce the need for runtime type-checks and isinstance() calls
- to aid in producing documentation
- to give hints to IDEs, editors, linters, code browsers and 
  similar tools.



> Strangely enough though I was taught from 
> the early beginning that once I start to care about types in Python, I
> strayed from the pythonic way. I'm confused now... What is it then?

That's actually a really good question.

Good practice in Python will not change. If anything, explicitly checking
types with isinstance will become even less common: if you can use lexical
analysis to prove that the argument passed to a function is always a float,
there is no need to perform a runtime check that it is a float.

Notice that nearly all the examples in the PEP use abstract classes like
Sequence instead of concrete classes like list? This is a good thing, and
will encourage more flexible code. You don't need a specific type of
sequence, any type of sequence wil

Re: Python is DOOMED! Again!

[Jon Ribbens]

On 2015-01-22, Steven D'Aprano  wrote:
> You can't use "raise" as a parameter name, since that's a keyword. Using
> floats for money is Just Wrong and anyone who does so should have their
> licence to program taken away. And I really don't understand what this
> function is supposed to do, that it returns None, a single Employee, or a
> sequence of Employees. (If it's hard to declare what the return type is,
> perhaps your function does too much or the wrong thing.)

That makes me think - it seems odd to me that PEP 484 doesn't even
mention function overloading (even to say that it's outside the
scope).

I think overloading should certainly be considered, and unless the
consensus is that it is something that should never happen, it
should either be explicitly allowed or at least the type-hinting
syntax should be checked to ensure it is forward-compatible with it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Steven D'Aprano]

Chris Angelico wrote:

> Hold on a moment, how often do you really do this kind of thing with
> "might be one of them or a sequence"? 

isinstance(obj, one_class_or_tuple_of_classes)
issubclass(cls, one_class_or_tuple_of_classes)
mystr.startswith(prefix_or_tuple_of_prefixes)
mystr.endswith(suffix_or_tuple_of_suffixes)
template % one_string_or_tuple_of_strings  # or a dict :-)


I'm not suggesting that the specific example is a good one, but the
principle is sound.



-- 
Steven

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

Re: Python is DOOMED! Again!

[Chris Angelico]

On Fri, Jan 23, 2015 at 1:16 AM, Steven D'Aprano
 wrote:
> Mario Figueiredo wrote:
>
>> def handle_employees(emp: Union[Employee, Sequence[Employee]], raise:
>> Union[float, Sequence[float]]) -> Union[Employee, Sequence[Employee],
>> None]:
>
> Using
> floats for money is Just Wrong and anyone who does so should have their
> licence to program taken away.

But using a float to specify a percentage raise that an employee (or
class of employees) gets would be reasonable. You could "handle" all
your problem employees by giving them an across-the-board 3% raise to
try to stop them from going on strike (they have a Union, as we can
see there, so strikes are clearly possible).

Not that that matters to the typing question. If it really is a
monetary type, all you need to do is replace 'float' with 'Money'
which would be a superclass to USD, AUD, GBP, and RepublicCredits.
There's still the question of what it's doing.

My best guess about this function is that it has three modes:

1) handle_employee(emp: Employee, pay_raise: float)
Give one employee a percentage raise. (Note the different function name.)
2) handle_employees(emp: Sequence[Employee], pay_raise: float)
Give all these employees the same percentage raise.
3) handle_employees(emp: Sequence[Employee], pay_raise: Sequence[float])
Equivalent to [handle_employee(e, r) for e, r in zip(emp, pay_raise)]

I can't figure out any sane meaning for passing a single employee and
a sequence of floats, and I think the one-and-one case should have a
different name. That would mean that there's really only one Union
involved, and the plural function would look like this:

def handle_employees(emp: Sequence[Employee], pay_raise: Union[float,
Sequence[float]]):
"""Atomically give many employees raises.

If pay_raise is a float, gives each employee that raise; otherwise, it
should be a sequence of the same length as emp.
"""
if isinstance(pay_raise, collections.Sequence):
for e, r in zip(emp, pay_raise):
handle_employee(e, r)
else:
for e in emp:
handle_employee(e, pay_raise)

But I still have no clue what the return value of either the
one-and-one case or the multiple case should be.

> (3) Have a shorter way to declare "Spam or Sequence (tuple?) of Spam".
>
>
> def handle_employees(
> emp: OneOrMore[Employee],
> pay_raise: OneOrMore[int])
> -> OneOrMore[Employee] | None:
> pass

Yes, that would be a reasonable thing. It might even be possible to
implement it on top of TypeVar. That said, though, APIs that accept
"just one, or maybe more" have problems; for instance, you can't write
a "pretty-print" function that can take either an arbitrary object, or
a sequence of arbitrary objects. Fundamentally not possible. But when
you can guarantee that the thing you're getting OneOrMore of is not
itself iterable, it would be useful.

>> Meanwhile there's quite a few more generics like the Sequence one above
>> you may want to take a look at and try and remember. And that's just one
>> factory (the generics support factory). You may also want to take a look
>> at TypeVar and Callable for more syntactic hell.
>
> Exaggerate, much?

Maybe. Callable does get pretty hairy; specifying the arguments and
return values of a function is never pretty. Pike is no better:

> typeof(write);
(1) Result: function(array(string) | string, mixed ... : int)

That's a function which takes either a single string or an array of
strings, followed by any number of additional arguments, and returns
an integer.

> typeof(GTK2.setup_gtk);
(2) Result: function(void | array(string) | string, void | int : array(string))

Optional arguments: one or more strings, and maybe an integer. Returns
an array of strings.

> typeof(rm);
(3) Result: function(string : int)

This one's pretty simple. It takes a string (path name), and returns
an integer (success or failure flag). And deletes a file/directory.

> typeof(asin);
(4) Result: function(int | float : float)

Could take an integer or a float, and returns a float.

The PEP 484 equivalents would be, I think:

write = Callable[[Union[str, Sequence[str]], AnyArgs], int]
# I have no idea how to do optional args.
rm = Callable[[str], int]
asin = Callable[[Union[int, float]], float]

It's not too bad when the function signature is really simple. And
that's going to be the common case. But it is syntactically
complicated to type-check a callback's arguments. Imagine, for
instance, GUI toolkit callbacks; chances are you can stuff extra args
into them (so they need a *args equivalent at the end), and they'll
take a variety of different args. They will not be pretty... or else
they'll be type-hinted simply as Callable, with nothing else.

But ultimately, that's not a fault of the type hinting structure. It's
a natural consequence of the complexity of callbacks. You can't get
away from it.

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

Re: Python is DOOMED! Again!

[Chris Angelico]

On Fri, Jan 23, 2015 at 1:57 AM, Steven D'Aprano
 wrote:
> Chris Angelico wrote:
>
>> Hold on a moment, how often do you really do this kind of thing with
>> "might be one of them or a sequence"?
>
> isinstance(obj, one_class_or_tuple_of_classes)
> issubclass(cls, one_class_or_tuple_of_classes)
> mystr.startswith(prefix_or_tuple_of_prefixes)
> mystr.endswith(suffix_or_tuple_of_suffixes)
> template % one_string_or_tuple_of_strings  # or a dict :-)
>
>
> I'm not suggesting that the specific example is a good one, but the
> principle is sound.

All of your examples are "might be one of them or a tuple". Not
"sequence", "tuple". That gets around the problem of recognition,
because in no case is a single tuple a valid argument.

I suspect it would be possible to use TypeVar to create a nice
"OneOrMore" like you suggested, but for reliability, it should
probably be "or tuple" rather than "or sequence".

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

Re: Socket ICMP V6 error

[ermanolillo]

HOST is  send by the keyboard. It´s the IPv6 address of my interface eth0.
For example, FE80::0202:B3FF:FE1E:8329.



Thanks



--
View this message in context: 
http://python.6.x6.nabble.com/Socket-ICMP-V6-error-tp5083962p5083982.html
Sent from the Python - python-list mailing list archive at Nabble.com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Socket ICMP V6 error

[Chris Angelico]

On Fri, Jan 23, 2015 at 2:24 AM, ermanolillo  wrote:
> HOST is  send by the keyboard. It´s the IPv6 address of my interface eth0.
> For example, FE80::0202:B3FF:FE1E:8329.

I can't duplicate the problem. Are you certain that this is indeed an
appropriate address?

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

Re: What killed Smalltalk could kill Python

[Emil Oppeln-Bronikowski]

On Thu, Jan 22, 2015 at 07:26:31AM -0500, Gene Heskett wrote:

> > 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.
> He asked about REXX, not AREXX. There is no comparison between the two as 
> AREXX was a huge superset of REXX.

Never seeing a proper REXX I always assumed it's just Amiga port retrofitted to 
serve as OS' needs as IPC language.

You learn everyday.

> If, when anyone here was using an amiga, and was using EzCron to schedule 
> stuff, Jim Hines and I wrote it as there was no such scheduler for 
> amigados.

I used few cron-like daemons and the name rings a bell!

> Trivia bit: William Hawes, who wrote AREXX and sold it thru the commode 
> door sales channels, was never paid a dime for his work.

There are still problems with AREXX copyright/distribution, but as you can 
guess after few changes of hand Amiga's IP is mess.

AROS, begin FOSS reimplementation of AmigaOS API, uses Regina to replace AREXX

http://regina-rexx.sourceforge.net/
-- 
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: Socket ICMP V6 error

[Alain Ketterlin]

ermanolillo  writes:

> HOST is  send by the keyboard. It´s the IPv6 address of my interface eth0.
> For example, FE80::0202:B3FF:FE1E:8329.

This is a link-local address, you can't use it just like that (you may
have several interfaces with the same link-local addr). Use getaddrinfo
on "FE80...%eth0" (change eth0 to the name of the interface you want to
use) to get a valid 4-tuple. Use that instead of your (HOST,0). You can
also try '::' (kind of inaddr6_any), I don't know if that's what you
want.

But I think you can't bind a raw socket in IPv6. (Not sure, try it and
see.)

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

Re: Trees

[Rustom Mody]

On Thursday, January 22, 2015 at 12:46:22 PM UTC+5:30, Paul Rubin wrote:
> 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.

Maybe you should call 'Leaf' instead as EmptyTree 

Then does it answer Ian's question?

Or Nil Null or some such then it is most obviously isomorphic to
the typical way of doing it in C.

The point is that these are frameworks for structural induction.
So choosing base-cases carefully is important.

This may seem harmless but is probably not a good idea

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

OTOH the classic S-exp of lisp would be modelled as

 data Sexp b = Cons (Sexp b) (Sexp b) | Leaf b

which captures the fact that the elements (b) are only at the leaves
and the conses provide pure branching without content

ie its not ... Cons b (Sexp b) (Sexp b)...
-- 
https://mail.python.org/mailman/listinfo/python-list

kivy secret of mana game

[Automn]

Hello,

I am programming a "Secret of Mana" (Seiken Densetsu) game in kivy, it runs
on a phone with kivy launcher.

Features for now are : movement by swiping, polygon collision and image state
changes with resource handling.

The codebase can be found at : 
https://sourceforge.net/projects/kivypriestsoflore2

The graphics have been licensed for this.

Automn
-- 
my blog : http://thediaryofelvishhealer.blogspot.com/
Time heals.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What killed Smalltalk could kill Python

[Grant Edwards]

On 2015-01-22, Tim Chase  wrote:
> 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.

Maybe I should look at Python again.

It's too late for this product, but maybe in the future...

-- 
Grant Edwards   grant.b.edwardsYow! But was he mature
  at   enough last night at the
  gmail.comlesbian masquerade?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Sturla Molden]

Steven D'Aprano  wrote:

> Remember too that type-hinting will *absolutely* remain *completely* 
> optional for Python. Developers can choose to use it or not,

No! Developers have to do what managers and customers tell them to do. They
will start to require type hinting everywhere. And then the question is
what Python has to offer over Java or Swift.

Python will no longer be dynamic, it will just be a slow static language.

Yes, Python could still be used as a dynamic language, but nobody will
allow you to do it. Even packages in widespread use will be banned because
they don't typehint. And then there will be complaint about lack of such
packages.

And in 5 years every textbook read by new Python programmers will require
type hinting as a "best practice".

Forget about compatibility with Python 2.

People will upgrade from Python 2 to Swift.

And then goodbye.

Sturla

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

Re: Python is DOOMED! Again!

[Sturla Molden]

Marko Rauhamaa  wrote:

> I think the SATAN is in the optional type declarations, not in the
> particular syntax chosen.

Yes.

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

Re: Python is DOOMED! Again!

[Skip Montanaro]

On Thu, Jan 22, 2015 at 12:03 PM, Sturla Molden 
wrote:

> Python will no longer be dynamic, it will just be a slow static language.
>
> Yes, Python could still be used as a dynamic language, but nobody will
> allow you to do it. Even packages in widespread use will be banned because
> they don't typehint. And then there will be complaint about lack of such
> packages.
>

FUD? What evidence do you have that this will be the way things shake out?

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

Re: Python is DOOMED! Again!

[Sturla Molden]

Skip Montanaro  wrote:

> FUD? What evidence do you have that this will be the way things shake out?

I don't underestimate the stupidity of those who are not writing the code
themselves.

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

Re: Python is DOOMED! Again!

[Mark Lawrence]

On 22/01/2015 18:14, Skip Montanaro wrote:


On Thu, Jan 22, 2015 at 12:03 PM, Sturla Molden mailto:sturla.mol...@gmail.com>> wrote:

Python will no longer be dynamic, it will just be a slow static
language.

Yes, Python could still be used as a dynamic language, but nobody will
allow you to do it. Even packages in widespread use will be banned
because
they don't typehint. And then there will be complaint about lack of such
packages.

FUD? What evidence do you have that this will be the way things shake out?



Evidence in completely the opposite direction if I'm reading this 
correctly https://www.python.org/dev/peps/pep-0484/#usage-patterns


"The main use case of type hinting is static analysis using an external 
tool without executing the analyzed program. Existing tools used for 
that purpose like pyflakes [pyflakes] or pylint [pylint] might be 
extended to support type checking. New tools, like mypy's mypy -S mode, 
can be adopted specifically for this purpose.


Type checking based on type hints is understood as a best-effort 
mechanism. In other words, whenever types are not annotated and cannot 
be inferred, the type checker considers such code valid. Type errors are 
only reported in case of explicit or inferred conflict. Moreover, as a 
mechanism that is not tied to execution of the code, it does not affect 
runtime behaviour. In other words, even in the case of a typing error, 
the program will continue running.


The implementation of a type checker, whether linting source files or 
enforcing type information during runtime, is out of scope for this PEP."


--
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!

[Chris Angelico]

On Fri, Jan 23, 2015 at 5:03 AM, Sturla Molden  wrote:
> Steven D'Aprano  wrote:
>
>> Remember too that type-hinting will *absolutely* remain *completely*
>> optional for Python. Developers can choose to use it or not,
>
> No! Developers have to do what managers and customers tell them to do. They
> will start to require type hinting everywhere. And then the question is
> what Python has to offer over Java or Swift.

Uhh... if your managers and customers are stipulating non-Pythonic
coding styles, then it's time to find new managers/customers. If
they're not writing the code, code quality shouldn't be their concern.

Of course, if you want to switch to Swift, sure, but I'm going to keep
working on Python. Just please don't FUD this list.

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

Re: Python is DOOMED! Again!

[random832]

On Thu, Jan 22, 2015, at 13:28, Mark Lawrence wrote:
> Evidence in completely the opposite direction if I'm reading this 
> correctly https://www.python.org/dev/peps/pep-0484/#usage-patterns
> 
> "The main use case of type hinting is static analysis using an external 
> tool without executing the analyzed program. Existing tools used for 
> that purpose like pyflakes [pyflakes] or pylint [pylint] might be 
> extended to support type checking. New tools, like mypy's mypy -S mode, 
> can be adopted specifically for this purpose.

How is that the opposite direction? It's a short jump from there to
"pylint [or whatever tool] will consider a lack of type hinting to be
something to warn for" and "managers/customers will consider this
warning to mean your program has failed and is unacceptable".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Mark Lawrence]

On 22/01/2015 18:41, random...@fastmail.us wrote:

On Thu, Jan 22, 2015, at 13:28, Mark Lawrence wrote:

Evidence in completely the opposite direction if I'm reading this
correctly https://www.python.org/dev/peps/pep-0484/#usage-patterns

"The main use case of type hinting is static analysis using an external
tool without executing the analyzed program. Existing tools used for
that purpose like pyflakes [pyflakes] or pylint [pylint] might be
extended to support type checking. New tools, like mypy's mypy -S mode,
can be adopted specifically for this purpose.


How is that the opposite direction? It's a short jump from there to
"pylint [or whatever tool] will consider a lack of type hinting to be
something to warn for" and "managers/customers will consider this
warning to mean your program has failed and is unacceptable".



You've snipped the other two paragraphs of the quote that I gave thus 
completely altering the context.  If they're too stupid to know the 
meaning of the word "hint" that's their problem.


--
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!

[Sturla Molden]

Chris Angelico  wrote:

> Uhh... if your managers and customers are stipulating non-Pythonic
> coding styles, then it's time to find new managers/customers. If
> they're not writing the code, code quality shouldn't be their concern.

I am saying the day someone requires me to write a type hint, I will no
longer be using Python or recommending it. Python is great, but not that
great.

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

Re: Python is DOOMED! Again!

[Marko Rauhamaa]

Sturla Molden :

> No! Developers have to do what managers and customers tell them to do.
> They will start to require type hinting everywhere. And then the
> question is what Python has to offer over Java or Swift.

Yes, but that's what GvR is after, I'm guessing: have Python take over
the realms of Java and C#.

> Python will no longer be dynamic, it will just be a slow static language.

Defeating Java will be worth the loss! The business value of the
disillusioned early adopters is minuscule compared with the bounty of
enterprise computing.

Py3EE — how cool is that!

> Yes, Python could still be used as a dynamic language, but nobody will
> allow you to do it. Even packages in widespread use will be banned
> because they don't typehint. And then there will be complaint about
> lack of such packages.

The managers want type checking, not to optimize, but to mechanically
guarantee the correctness of the code. Most people they hire aren't all
that skilled at coding and will fall in every trap they can. They'd like
automated tools to put straitjackets on their reports so they can do as
little damage as possible.

Then there will be the optimizers, enthusiastic hackers who just need to
tweak with nanoseconds, overclock and benchmark everything and add
liquid nitrogen cooling on top of that. They will sprinkle elaborate
type declarations anywhere they can and indirectly force applications
that interface with their code to declare types as well.


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

Re: Python is DOOMED! Again!

[Sturla Molden]

Mark Lawrence  wrote:

> If they're too stupid to know the 
> meaning of the word "hint" that's their problem.

It will also be Python's problem, because people are that stupid.

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

Re: Python is DOOMED! Again!

[Mario Figueiredo]

In article , 
random...@fastmail.us says...
> How is that the opposite direction? It's a short jump from there to
> "pylint [or whatever tool] will consider a lack of type hinting to be
> something to warn for" and "managers/customers will consider this
> warning to mean your program has failed and is unacceptable".

Customers don't have access to static analysis output and project 
managers should know better than to demand static analysis without 
properly contextualize it. I just don't see a project manager having no 
idea what static analysis means.

I think you are completely of the mark here, if you think type 
annotations will become some sort of obligatory feature.

The criticism is about the choices regarding its syntax and whether it 
should couple so tightly with our source code (as is suggested on the 
PEP) and whether it should be entirely moved to comment-like structures.

No one in their right mind looks at static analysis as an obligatory 
feature in Python, or any other programming language.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Marko Rauhamaa]

Mark Lawrence :

> Evidence in completely the opposite direction if I'm reading this
> correctly https://www.python.org/dev/peps/pep-0484/#usage-patterns

That's not evidence, that's a prophecy.

What I'm seeing is a bad shift in the Python culture. What's next?
Unboxed objects? Unsafe objects? Micromanaged GC?

I'm afraid Python will lose its taste. Why not let Java handle its
niche? Maybe Go is the way to go for some applications? C++ might have
its uses. C is still the weapon of choice in many situations. Python is
perfect already. It doesn't need to get any faster.


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

Re: Python is DOOMED! Again!

[Terry Reedy]

On 1/22/2015 3:24 AM, Rick Johnson wrote:


Yes, YES, *YES* That would be my first choice, or
docstrings as a secondary. But to introduce new syntax
into the method signatures is SUICIDE! What the hell is
this man thinking?


You are years late for complaining about new signature syntax.  The 
'new' annotation syntax was introduced 5+ years ago in 3.0 and is 
already being used for various purposes, but mostly for type hinting.


The current proposal is to introduce a new module that standardizes the 
type-hinting use.  It is true that it will likely make the use of 
annotation more common.


--
Terry Jan Reedy

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

Re: Python is DOOMED! Again!

[Marko Rauhamaa]

Chris Angelico :

> Uhh... if your managers and customers are stipulating non-Pythonic
> coding styles, then it's time to find new managers/customers.

Hah! What's considered Pythonic seems to be changing. Old-school
Pythonic will be heresy, and new-school Pythonic will be exalted to
dogma.

> Just please don't FUD this list.

Why do you think opinions on Python's future should be kept off this
list?


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

Re: Python is DOOMED! Again!

[Paul Rubin]

Mario Figueiredo  writes:
> Strangely enough though I was taught from the early beginning that
> once I start to care about types in Python, I strayed from the
> pythonic way. 

That's a weird concept.  You always have to care about types.  It's just
that with a bit of discipline combined with unit tests to catch any
errors, you can keep the flow of types through the program simple enough
that you can get by without static analysis.  That frees your style in
some ways and cramps it in others.

https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/
gets posted here now and then, and is still well worth reading.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Paul Rubin]

Steven D'Aprano  writes:
> Since the "language wars" of the 1990s, dynamic languages have won. 

Are you kidding?  Nothing has won, the wars are still going on, and
dynamic and static typing both have their winning use cases and will be
around forever.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Paul Rubin]

>> correctly https://www.python.org/dev/peps/pep-0484/#usage-patterns
> That's not evidence, that's a prophecy.
> What I'm seeing is a bad shift in the Python culture. What's next?
> Unboxed objects? Unsafe objects? Micromanaged GC?

Why are you freaking out so much?  The "prophecy" is for something like
the Erlang Dialyzer, which has been very successful and useful in the
Erlang world.  Erlang is still dynamically typed (it's essentially Lisp
under the skin) but you can include some annotations that let external
tools (Dialyzer) check your program for type consistency.  Lots of bugs
in supposedly reliable production code were found after the Dialyzer was
deployed.  It would be great to have something like it for Python.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Skip Montanaro]

On Thu, Jan 22, 2015 at 1:22 PM, Marko Rauhamaa  wrote:

> > Just please don't FUD this list.
>
> Why do you think opinions on Python's future should be kept off this
> list?


The way you couched your opinion as a certainty, as if you could see the
future, not as if you had an opinion stated like, "do you think this might
happen?"

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

Re: Python is DOOMED! Again!

[Sturla Molden]

On 22/01/15 20:10, Mario Figueiredo wrote:


Customers don't have access to static analysis output and project
managers should know better than to demand static analysis without
properly contextualize it. I just don't see a project manager having no
idea what static analysis means.


I don't know how it works in you country, but here projects managers are 
selected for having any kind of skill other than technical knowledge. I 
know of one who got the job because he was a professional hockey player. 
So yes, they can very well be unaware what static analysis means. But 
what they will do is pick up "buzzwords" from the kind of journals that 
project managers read. And then they want that buzzword implemented.


Sturla

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

Re: Python is DOOMED! Again!

[Mark Lawrence]

On 22/01/2015 19:25, Paul Rubin wrote:

Steven D'Aprano  writes:

Since the "language wars" of the 1990s, dynamic languages have won.


Are you kidding?  Nothing has won, the wars are still going on, and
dynamic and static typing both have their winning use cases and will be
around forever.



Unless you offer a new language that is absolutely guaranteed to have 
the best of both worlds, in which case there'd be major flame wars over 
whether you'd call it dynatically or stamically typed.


--
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!

[Sturla Molden]

On 22/01/15 20:43, Skip Montanaro wrote:


The way you couched your opinion as a certainty, as if you could see the
future,


How do you know I cannot?




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

Re: Python is DOOMED! Again!

[Mario Figueiredo]

In article , 
sturla.mol...@gmail.com says...
> 
> On 22/01/15 20:10, Mario Figueiredo wrote:
> 
> > Customers don't have access to static analysis output and project
> > managers should know better than to demand static analysis without
> > properly contextualize it. I just don't see a project manager having no
> > idea what static analysis means.
> 
> I don't know how it works in you country, but here projects managers are 
> selected for having any kind of skill other than technical knowledge. I 
> know of one who got the job because he was a professional hockey player. 
> So yes, they can very well be unaware what static analysis means. But 
> what they will do is pick up "buzzwords" from the kind of journals that 
> project managers read. And then they want that buzzword implemented.
> 
> Sturla

That is fine. But then the problem isn't type hinting, is it? Neither I 
think you are suggesting we don't introduce language because there are 
bad project managers out there.

The problem is then bad project managers. That has nothing to do with 
type hinting, or Python for that matter.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: kivy secret of mana game

[Ian Kelly]

On Thu, Jan 22, 2015 at 10:13 AM, Automn  wrote:
> The graphics have been licensed for this.

Really? I'm surprised Square-Enix would even give consideration to
licensing something like this.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Rick Johnson]

On Thursday, January 22, 2015 at 4:32:04 AM UTC-6, Mario Figueiredo wrote:
> Rick,
> 
> > Python is the only thing that is pure in the programming
> > world. The only language that offers the cleanest and
> > most intuit-able syntax, AND YOU"RE JUST GOING TO THROW
> > IT ALL AWAY [...] ?
> 
> Nonsense. You are just used to it. I can read C with the
> same feeling of intuitiveness as you do Python. There's
> nothing inherently more intuitive about python and I just
> wished that meme died already. Besides it's all in the eye
> of the beholder.

And is *YOUR* eye the only eye in this universe? A concert
pianist could say the same about a piece of music that only
a handful of people in the world could play!

YOU'RE IGNORING WHAT PYTHON WAS, AND IS MEANT TO BE!

Python was not created to be some esoteric language that
sadistic professors could drop on students heads like a
grand piano from a third story window, *NO*, python was
meant to be a gateway to intuitive programming bliss. 

Python was meant to be the "lingua franca" of the
Programming world. The idea was to cut out the noisy syn
taxes that plagued other language and thereby allow the
programmer to focus on solving problems and writing
algorithms.

As the complexity of a syntax increases, so too does the
work required to comprehend it. If you like C so much then
go back to writing C code, Python fills a niche, and we must
remain committed to our founding goals.

  THIS "TYPE HINTING" IDEA HAS TO BE THE SINGLE WORSE CASE
  OF FEATURE CREEP I'VE EVER HEARD OF!

> PEP 484 just becomes silly when it comes to the section
> where it discusses whether type hints are pythonic. If
> that ridiculous paragraph reflects how we are looking
> today at the inclusion of new features, than I agree
> python is walking a dangerous road. 

  "IF THE IMPLEMENTATION IS HARD TO EXPLAIN, IT'S A BAD
  IDEA."
  
> But that also means Type Hints aren't the real problem
> here. We have a much bigger problem about the programming
> language principles and philosophy.

I don't understand??? 

Now it seems you are agreeing with me?

Are you sure you've given this issue it's due consideration?
And have you weighed that consideration from an objective
perspective? I think any rational person would agree that
Python is more important than our personal needs, wants, or
desires.

> In all honesty though, I never cared much about the ideals
> and zens in programming languages, especially ones want to
> want to adopt a batteries-included philosophy.

And yet you're here, using the Python language who's
*SECOND-PHILOSOPHICAL-GOAL* was to provide a large stdlib.

Why are you torturing yourself by using a language you
obviously don't like? But more importantly, why are you
attempting to torture everyone else by encouraging the
demise of this fine language? At best this idea will violate
Python's founding philosophy, at worst it will be the end of
something that brought light into a dark world.

> Always seemed to me like nonsense talk. My experience
> taught me that you can't just have the latter without
> eventually breaking the former. 'import this' always read
> to me like wishful thinking.

The "python zen" will always be under attack because it's a
difficult set of rules to follow, but despite the practical
application of the rules, the philosphy they describe is
*SOUND*!

Many times killing an opponent may be easier than attempting
to compromise with him, but we don't sacrifice logical
foundations just to appease every Python programmer who
wants Python to be more like X, Y, or Z! (or REXX!)

What's next? Are we going to cow-tow to the lispers and
adopt "nesting to infinity" just so we can go around
blabbing about how easy a lisp interpreter is to write,
never mind that writing any *REAL* lisp code is an exercise
in *EYEBALL-PARSING-ASININITY*!

How about taking after the Perl philosophy of peppering the
syntax with punctuation until the very sight of it causes an
intellectual sneeze fest! 

Not enough for you? Heck, why allow Dijkstra to rest-in-
peace in an upward facing position when we could resurrect
GOTO!

Need more examples?


> Python isn't going anywhere towards obscurity. Not at
> least until a competiting language comes (it hasn't yet).
> I agree though that Python complexity has increased
> greatly over the years and this isn't showing any signs of
> stopping. And that is exactly the type of thing that
> promotes the birth of a new and better programming
> language. And, interestingly enough, that is always a good
> thing.

I agree. The birth of new languages is always a good thing,
(i'm a huge fan of evolution if you have not noticed!), and
i am fully aware that Python is not going to live forever.

Sooner or later someone will see the deficiencies of Python
and think: "Hey, i can do better!", but that time is not
now. Python still has a firm grip on the niche of
"intuitive syntax with batteries included" and we have a
*DUTY* to every potential programmer to ensure that

Re: Python is DOOMED! Again!

[Rick Johnson]

On Thursday, January 22, 2015 at 4:37:49 AM UTC-6, Mario Figueiredo wrote:

> I could replace the variable names with spam, ham and eggs, if you wish.

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

Re: Python is DOOMED! Again!

[Skip Montanaro]

On Thu, Jan 22, 2015 at 1:56 PM, Sturla Molden 
wrote:

> On 22/01/15 20:43, Skip Montanaro wrote:
>
>  The way you couched your opinion as a certainty, as if you could see the
>> future,
>>
>
> How do you know I cannot?


Perhaps you can, but then your statements are opinions, then are they?

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

Re: Python is DOOMED! Again!

[Skip Montanaro]

On Thu, Jan 22, 2015 at 2:31 PM, Skip Montanaro 
wrote:

> Perhaps you can, but then your statements are opinions, then are they?


Crap. I meant:

"... then your statements aren't opinions ..."

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

Re: Python is DOOMED! Again!

[Rick Johnson]

On Thursday, January 22, 2015 at 12:15:11 PM UTC-6, Skip Montanaro wrote:
> On Thu, Jan 22, 2015 at 12:03 PM, Sturla Molden  wrote:
>
> > Python will no longer be dynamic, it will just be a slow
> > static language. Yes, Python could still be used as a
> > dynamic language, but nobody will allow you to do it.
> > Even packages in widespread use will be banned because
> > they don't typehint. And then there will be complaint
> > about lack of such packages.
> 
> FUD? What evidence do you have that this will be the way
> things shake out?

And what evidence do *YOU* have that supports your argument?
You cannot invalidate an unproven argument by juxtaposing
it with another unproven argument.

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

Re: Python is DOOMED! Again!

[Rick Johnson]

On Thursday, January 22, 2015 at 12:28:47 PM UTC-6, Mark Lawrence wrote:
> Evidence in completely the opposite direction if I'm
> reading this correctly [snip link]
> 
> "The main use case of type hinting is static analysis
> using an external tool without executing the analyzed
> program. Existing tools used for that purpose like
> pyflakes [pyflakes] or pylint [pylint] might be extended
> to support type checking. New tools, like mypy's mypy -S
> mode, can be adopted specifically for this purpose.

So if the purpose is "static analysis", what is the
justification for injecting new syntax into function sigs?
I'm not *TOTALLY* against the idea of "type hints", but i am
*TOTALLY* against their proposed location.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[MRAB]

On 2015-01-22 20:23, Rick Johnson wrote:

On Thursday, January 22, 2015 at 4:32:04 AM UTC-6, Mario Figueiredo wrote:

Rick,

> Python is the only thing that is pure in the programming
> world. The only language that offers the cleanest and
> most intuit-able syntax, AND YOU"RE JUST GOING TO THROW
> IT ALL AWAY [...] ?

Nonsense. You are just used to it. I can read C with the
same feeling of intuitiveness as you do Python. There's
nothing inherently more intuitive about python and I just
wished that meme died already. Besides it's all in the eye
of the beholder.


And is *YOUR* eye the only eye in this universe? A concert
pianist could say the same about a piece of music that only
a handful of people in the world could play!

 YOU'RE IGNORING WHAT PYTHON WAS, AND IS MEANT TO BE!

Python was not created to be some esoteric language that
sadistic professors could drop on students heads like a
grand piano from a third story window, *NO*, python was
meant to be a gateway to intuitive programming bliss.

Python was meant to be the "lingua franca" of the
Programming world. The idea was to cut out the noisy syn
taxes that plagued other language and thereby allow the
programmer to focus on solving problems and writing
algorithms.


If you want to know why Python was created, ask its creator:

"""My original motivation for creating Python was the perceived need
for a higher level language in the Amoeba project. I realized that the
development of system administration utilities in C was taking too
long. ... So there was a need for a language that would "bridge the gap
between C and the shell." For a long time, this was Python’s main
catchphrase."""

http://python-history.blogspot.co.uk/2009/01/personal-history-part-1-cwi.html

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

Re: Python is DOOMED! Again!

[Mark Lawrence]

On 22/01/2015 20:44, Rick Johnson wrote:

On Thursday, January 22, 2015 at 12:28:47 PM UTC-6, Mark Lawrence wrote:

Evidence in completely the opposite direction if I'm
reading this correctly [snip link]

"The main use case of type hinting is static analysis
using an external tool without executing the analyzed
program. Existing tools used for that purpose like
pyflakes [pyflakes] or pylint [pylint] might be extended
to support type checking. New tools, like mypy's mypy -S
mode, can be adopted specifically for this purpose.


So if the purpose is "static analysis", what is the
justification for injecting new syntax into function sigs?
I'm not *TOTALLY* against the idea of "type hints", but i am
*TOTALLY* against their proposed location.



Fine, just write an alternative PEP.

Personally I couldn't give one hoot let alone two whether or not this 
proposal ever sees the light of day.


--
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]

On Thursday, January 22, 2015 at 1:23:11 PM UTC-6, Marko Rauhamaa wrote:
> Chris Angelico:
>
> > Just please don't FUD this list.
> 
> Why do you think opinions on Python's future should be
> kept off this list?
 
Because he's one of the more prevalent boot licking rabbid
fanboys of GvR. If you don't believe me then Google this 
thread:

  [Python-ideas] Need help converting HTML doc to ReST
  
He replied within 15 mins with great enthusiasm to do his
"master's bidding". How pathetic!

Python is not as "open" as the PSF policy statements would
have you believe. You either agree with GvR (and his
minions), or you don't exist. It's that simple.

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

Re: Python is DOOMED! Again!

[Mario Figueiredo]

In article , 
rantingrickjohn...@gmail.com says...

> python was meant to be a gateway to intuitive programming bliss. 
> Python was meant to be the "lingua franca" of the Programming world.

And it failed miserably on both instances. Like any other programming 
language before and after it which pretended to be the one stop solution 
to world hunger.
 
No. Python most important goal is to solve software requirements, like 
any programming language should. Intuitiveness, simplicity, easy of use, 
expressiveness, and all the other waiving flags you like to carry, are 
secondary-only goals. You sacrifice them for the first goal if they get 
in the way. It's the way of any evolving language.

> You argue that readability is a relative construct, and you
> are correct, but what you fail to acknowledge is that while
> the ability to read noisy syntaxes improves with practice,
> the comprehensive abilities of neophytes will always remain
> constant. Python was built for the sake of the neophytes, 
> not to suffer the whims of the guru!

I couldn't give a rat's arse about neophytes and I consider myself a 
beginner in the world of python. I'm more interested in having a 
language that can solve my problems.

Expressiveness, simplicity, intuitiveness, all are lofty goals. But they 
are always going to be limited by the feature set of your language. And 
as it grows, as it tries to incorporate more and more features in order 
to become more and more capable of handling all types of modern software 
requirements, it will loose some of that expressivness, some of that 
simplicity and some of that intuitiveness. It's just how it is with any 
programming language.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Ian Kelly]

On Thu, Jan 22, 2015 at 7:16 AM, Steven D'Aprano
 wrote:
>> Meanwhile, there's the strange decision to implement type hints for
>> local variables # comment lines. I have an hard time wrapping my head
>> around this one. Really, comments!?
>
> Yes, really. There is plenty of prior art for machine-meaningful comments:
>
> - mypy uses it, and it works fine
> - Pascal uses {$ ...} compiler directives
> - Unix uses a special hash-bang #! comment in the first line to
>   specify the executable that runs the script
> - Python supports a special encoding declaration using #
> - doctest uses comments for directives
> - HTML puts code (Javascript usually) inside of comments
> - JMSAssert for Java uses comments for design-by-contract assertions

Perhaps even more relevant to PEP 484:

- The Closure compiler for Javascript uses JSDoc tags in comments for
static typing and analysis.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Marko Rauhamaa]

Rick Johnson :

> On Thursday, January 22, 2015 at 1:23:11 PM UTC-6, Marko Rauhamaa wrote:
> Because he's one of the more prevalent boot licking rabbid
> fanboys of GvR.

You are out of line, but then, you never pretended otherwise.


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

Re: Python is DOOMED! Again!

[Emile van Sebille]

On 1/21/2015 8:30 PM, Steven D'Aprano wrote:




Here's an example from PEP 484:

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


I've been lightly scanning and following the PEP 484 discussion, and one 
point I don't think I've seen mentioned is how you might hint a function 
that accepts different types, eg:


def adder(a,b): return a+b

This is one of the pythonic idioms that help with polymorphic functions. 
 Is there a proposal for providing hinting for these?


Thanks,

Emile


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

Re: Python is DOOMED! Again!

[Ian Kelly]

On Thu, Jan 22, 2015 at 2:56 PM, Emile van Sebille  wrote:
> I've been lightly scanning and following the PEP 484 discussion, and one
> point I don't think I've seen mentioned is how you might hint a function
> that accepts different types, eg:
>
> def adder(a,b): return a+b
>
> This is one of the pythonic idioms that help with polymorphic functions.  Is
> there a proposal for providing hinting for these?

You can use TypeVar for that.

T = TypeVar('T')

def adder(a: T, b: T) -> T:
return a + b

I'm not thrilled about having to actually declare T in this sort of
situation, but I don't have a better proposal.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Ian Kelly]

On Thu, Jan 22, 2015 at 3:08 PM, Ian Kelly  wrote:
> On Thu, Jan 22, 2015 at 2:56 PM, Emile van Sebille  wrote:
>> I've been lightly scanning and following the PEP 484 discussion, and one
>> point I don't think I've seen mentioned is how you might hint a function
>> that accepts different types, eg:
>>
>> def adder(a,b): return a+b
>>
>> This is one of the pythonic idioms that help with polymorphic functions.  Is
>> there a proposal for providing hinting for these?
>
> You can use TypeVar for that.
>
> T = TypeVar('T')
>
> def adder(a: T, b: T) -> T:
> return a + b
>
> I'm not thrilled about having to actually declare T in this sort of
> situation, but I don't have a better proposal.

Hmm, but also that hinting doesn't cover cases like adder(12, 37.5)
where two different types can be passed, and the return type could be
either. I think for full generality you would just have to forgo
hinting on this function.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Chris Kaynor]

On Thu, Jan 22, 2015 at 2:12 PM, Ian Kelly  wrote:
>>> def adder(a,b): return a+b
>>>
>>> This is one of the pythonic idioms that help with polymorphic functions.  Is
>>> there a proposal for providing hinting for these?
>>
>> You can use TypeVar for that.
>>
>> T = TypeVar('T')
>>
>> def adder(a: T, b: T) -> T:
>> return a + b
>>
>> I'm not thrilled about having to actually declare T in this sort of
>> situation, but I don't have a better proposal.
>
> Hmm, but also that hinting doesn't cover cases like adder(12, 37.5)
> where two different types can be passed, and the return type could be
> either. I think for full generality you would just have to forgo
> hinting on this function.

Or use Any, which is basically the same thing:

def adder(a: Any, b: Any) -> Any:
return a + b

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

Re: apostrophe not considered with tkinter's wordstart and wordend

[Christian Gollwitzer]

Am 05.01.15 um 14:20 schrieb Rick Johnson:

*GASP*! Of course all this could be avoided if those short-
sighted TK folks would have allowed the programmer to define
the pattern!

ಠ_ಠ


Well, it turns out you actually can. We don't have Guido's time machine, 
but still there is a configuration option in Tk, albeit a very obscure 
one: you have to set the global Tcl variables tcl_wordchars and 
tcl_nonwordchars after loading Tk to a regexp which defines the word 
boundaries:


http://wiki.tcl.tk/1655

Strangely, there is a different preset for Windows and X11. The Windows 
preset - consider everything besides space as part of the word - makes 
more sense to me than the Unix default, which only counts letters, 
numbers and underscores as part of the word. To set the Windows preset, 
do this:


tk.eval('set tcl_wordchars {\S}');
tk.eval('set tcl_nonwordchars {\s}');

(untested in Python, only tested directly from a wish shell)


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

Re: Python is DOOMED! Again!

[Mario Figueiredo]

In article <6eb91c4b-92ff-44a8-b5a9-6ef04c71f...@googlegroups.com>, 
rantingrickjohn...@gmail.com says...
> 
> So if the purpose is "static analysis", what is the
> justification for injecting new syntax into function sigs?

1. Annotations where created exactly for this purpose. So there's some 
preassure to put them to work on what they were always meant to be used 
for.

2. Docstrings are meant as source of code documentation and to fill the 
object's __doc__ attribute, as per PEP 257. As such they aren't good 
consistent candidates for type hinting for purposes of static analysis 
tools.

3. Decorators are meant as function transformation tools, as per PEP 318 
and, as such, are them too not suitable to include type annotations for 
the purpose of static analysis.

4. There is no other formal annotation mechanism, other than these 
potential three.

Arguably, you can make a case against 1. And that's my own issue with 
type hinting as it is being proposed on PEP 484. The real problem is 
annotations as they were defined are a really bad idea. To couple type 
annotations so tightly with code, just results in plain ugly and hard to 
read code.

Personally I would love to see the present annotations just go away and 
a new docstring-like structure to emerge in their place. But that's 
probably not going to happen.

What I agree can't be done though, is to use docstrings or decorators as 
a source for type annotations.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: An improper change in httplib.py

[Guohua Ouyang]

Have reported an issue http://bugs.python.org/issue23300.

"That leading underscore in the method name means it is not a public
API and thus changes are allowed without any backwards-compatibility
guarantees. Mercurial will need to update their code to handle this if
they want to continue to use the method."

I checked the official mercurial repo, it does not use the method
anymore, so I filed a bug to fedora. [1]

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1185105

On Thu, Jan 22, 2015 at 8:04 PM, Mark Lawrence  wrote:
> No problem, but out of courtesy could you please reply to the list and not
> just me.
>
> Kindest regards.
>
> Mark Lawrence.
>
>
> On Thursday, 22 January 2015, 11:51, Guohua Ouyang 
> wrote:
>
>
>
> thanks, file the issue 23300
>
> On Thu, Jan 22, 2015 at 5:06 PM, Mark Lawrence 
> wrote:
>> On 22/01/2015 03:38, Guohua Ouyang wrote:
>>>
>>> This is my first post to the list, I apologies firstly if I made any
>>> mistake.
>>>
>>> I was trying to get a package in golang behind the http or https
>>> proxy, and it reports  an error "AttributeError: httpsconnection
>>> instance has no attribute '_set_hostport'", details in the bottom.
>>> After some trace work, I found it caused by the changes in the issue
>>> issue7776.
>>>
>>> @@ -718,7 +734,7 @@
>>>  else:
>>>  self._tunnel_headers.clear()
>>>
>>> -def _set_hostport(self, host, port):
>>> +def _get_hostport(self, host, port):
>>>
>>> First, it changes the method's name, doesn't it break the
>>> compatibility for other packages, on my system,
>>> mercurial-3.0-2.fc21.x86_64 still use "_set_hostport" as the error
>>> shows.
>>>
>>> Second, I found that line 1132 of [2] still use "
>>> self._conn._set_hostport(host, port)", which should be
>>> "_get_hostport", right?
>>>
>>> [1] http://bugs.python.org/issue7776
>>> [2] https://github.com/python/cpython/blob/2.7/Lib/httplib.py
>>
>>
>> You've found a bug so please raise it on bugs.python.org :)
>>
>> --
>> 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
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Ian Kelly]

On Thu, Jan 22, 2015 at 3:27 PM, Chris Kaynor  wrote:
> Or use Any, which is basically the same thing:
>
> def adder(a: Any, b: Any) -> Any:
> return a + b

Yeah, but this just seems like extra noise since it's not going to
help the type checker at all.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Mario Figueiredo]

In article , 
ian.g.ke...@gmail.com says...
> 
> On Thu, Jan 22, 2015 at 3:27 PM, Chris Kaynor  
> wrote:
> > Or use Any, which is basically the same thing:
> >
> > def adder(a: Any, b: Any) -> Any:
> > return a + b
> 
> Yeah, but this just seems like extra noise since it's not going to
> help the type checker at all.


I agree. It's after all a fully polymorphic function. There is no reason 
to pass it through a static analyzer.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Ben Finney]

Sturla Molden  writes:

> Chris Angelico  wrote:
>
> > Uhh... if your managers and customers are stipulating non-Pythonic
> > coding styles, then it's time to find new managers/customers. If
> > they're not writing the code, code quality shouldn't be their
> > concern.
>
> I am saying the day someone requires me to write a type hint, I will
> no longer be using Python or recommending it.

Surely a more appropriate response would be to stop taking orders from
that person, and continue writing Python.

-- 
 \“The problem with television is that the people must sit and |
  `\keep their eyes glued on a screen: the average American family |
_o__) hasn't time for it.” —_The New York Times_, 1939 |
Ben Finney

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

Re: Python is DOOMED! Again!

[Paul Rubin]

Ian Kelly  writes:
> T = TypeVar('T')
> def adder(a: T, b: T) -> T:  ...
> I'm not thrilled about having to actually declare T in this sort of
> situation, but I don't have a better proposal.

Oh man, that's ugly.  Maybe a decorator would be a bit less awful:

@-typevar T
def adder(a: T, b: T) -> T: ...

I'm using @- for a hypothetical decorator that receives the AST for the
stuff on the rest of the line, instead of being evaluated as a function.

The above looks sort of like C++, which would say

  template 
  T addr (T a, T b) { ... }

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

Re: How to "wow" someone new to Python

[Grant Edwards]

On 2015-01-22, Steven D'Aprano  wrote:
> 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

Well, you know the ancient Chinese programmer's curse:

  "May you program in an interesting language".

-- 
Grant Edwards   grant.b.edwardsYow! Pardon me, but do you
  at   know what it means to be
  gmail.comTRULY ONE with your BOOTH!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Steven D'Aprano]

Marko Rauhamaa wrote:

> Python is perfect already.

I have no words.



-- 
Steven

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

Re: Python is DOOMED! Again!

[Sturla Molden]

On 22/01/15 21:03, Mario Figueiredo wrote:


That is fine. But then the problem isn't type hinting, is it? Neither I
think you are suggesting we don't introduce language because there are
bad project managers out there.

The problem is then bad project managers. That has nothing to do with
type hinting, or Python for that matter.


It has everything to do with Python if we facilitate them.

Type hinting will be mandatory because of bad managers. But then someone 
is going to ask what benefit Python has to offer:


Readabiliy? No ... down the drain.

Dynamic typing? No ... down the drain.

Speed? No ... still 200x slower than Swift.

Why go for Python? There is no benefit to it any longer.


Sturla














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

Re: Python is DOOMED! Again!

[Sturla Molden]

On 22/01/15 23:08, Ian Kelly wrote:


T = TypeVar('T')

def adder(a: T, b: T) -> T:
 return a + b

I'm not thrilled about having to actually declare T in this sort of
situation, but I don't have a better proposal.


Here is a better proposal:

def adder(a, b):
return a + b



Sturla


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

Re: Python is DOOMED! Again!

[Chris Angelico]

On Fri, Jan 23, 2015 at 11:40 AM, Sturla Molden  wrote:
> Type hinting will be mandatory because of bad managers. But then someone is
> going to ask what benefit Python has to offer:

Type hinting will never be mandatory, because bad managers are not in
charge. You can't blame the language because you're *choosing* to
continue to work for someone who demands the unreasonable. Yes, I
understand that there are reasons for not immediately quitting a job
when someone insists on something you disagree with (yaknow, reasons
like "got bills to pay", little trivialities like that); but it's
still your choice. You have to weigh up the value of the job against
the value of the philosophy. And Python's philosophy isn't changed by
that.

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

Re: Python is DOOMED! Again!

[Rick Johnson]

On Thursday, January 22, 2015 at 4:25:37 PM UTC-6, Mario Figueiredo wrote:
> 1. Annotations where created exactly for this purpose. So
> there's some preassure to put them to work on what they
> were always meant to be used for.
> 
> 2. Docstrings are meant as source of code documentation
> and to fill the object's __doc__ attribute, as per PEP
> 257. As such they aren't good consistent candidates for
> type hinting for purposes of static analysis tools.
> 
> 3. Decorators are meant as function transformation tools,
> as per PEP 318 and, as such, are them too not suitable to
> include type annotations for the purpose of static
> analysis.
> 
> 4. There is no other formal annotation mechanism, other
> than these potential three.
> 
> Arguably, you can make a case against 1. And that's my own
> issue with type hinting as it is being proposed on PEP
> 484. The real problem is annotations as they were defined
> are a really bad idea. To couple type annotations so
> tightly with code, just results in plain ugly and hard to
> read code.

Yes, i whole heartily agree!

> Personally I would love to see the present annotations
> just go away and a new docstring-like structure to emerge
> in their place. But that's probably not going to happen.
> 
> What I agree can't be done though, is to use docstrings or
> decorators as a source for type annotations.

I have a completely different idea. 


 Python Sanity Proposal: "Type Hinting Sanity"

Note: This is the closest you're going to get to a PEP from me!

Okay, i have found a solution to the type hinting problem
that will appease both sides. On one side we have those who
are proposing type hinting annotations within function sigs,
and on the other side, we have those who oppose the
implementation of type hinting via this method because of
the readability concerns. The solution is move the type
hinting syntax completely out of the source file and into
another file -- think of it as a "Python Type Hinting Header
File".


 Summary

  
(1) Agree on a file extension that python will recognize
as containing "type hint specs". Unfortunately we cannot
use ".pth", which would be the perfect acronym for "Python
Type Hints", so choose something else. :-(

(2) Define a spec for writing annotations that will map to
funcs/methods of the same name. I would argue to keep the
spec compact, but i really don't care about the spec at
this point.

  

 Simplistic Example Code utilizing two files:


  #
  # scriptA.py
  #
  def greeting(name): 
  return 'Hello ' + name 
  
  #
  # scriptA.typehints
  #
  greeting{name:str} -> str



 Benefits:


(1) Removes the noisy syntax from the source file. Python
code will remain as clean tomorrow as it is today.
  
(2) Puts the onerous on the author *NOT* on the reader.
This system utilizes a concept known as "Level Of Detail"
(or LOD). LOD means that i should not need to see a type
hint unless i *WANT* to see a type hint. You can think of
it as akin to "Java @string resources".  

(3) If i decide i don't want type hints in my code, all i
have to do is delete or rename a file, which is much less
error prone then editing source code. 

(4) Has the added benefit of aiding when debugging type hints.
  
--
  
My suggestion is the only way to implement type hints
without destroying Python! I just hope that GvR will give it
serious objective consideration.

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

Re: Python is DOOMED! Again!

[Emile van Sebille]

On 1/22/2015 5:00 PM, Chris Angelico wrote:

On Fri, Jan 23, 2015 at 11:40 AM, Sturla Molden  wrote:

Type hinting will be mandatory because of bad managers. But then someone is
going to ask what benefit Python has to offer:


Type hinting will never be mandatory,


I'm sure it will be in some places, if only to the extent that PEP8 
compliance is enforced.



because bad managers are not in charge.


But coding standards may be, and in certain sized shops, should be.  So 
as tools come of age, standards will be updated, and hinting will be 
added and hence become required.



You can't blame the language because you're *choosing* to


>sigh< It's good to have choices.

Bottom line is that the decisions being made today about type hinting 
will live on, so it's good to consider eventualities that are real.


Emile


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

Python Sanity Proposal: Type Hinting Solution

[Rick Johnson]

Note: This is the closest you're going to get to a PEP from me! 

Okay, i have found a solution to the type hinting problem 
that will appease both sides. On one side we have those who 
are proposing type hinting annotations within function sigs, 
and on the other side, we have those who oppose the 
implementation of type hinting via this method because of 
the readability concerns. The solution is move the type 
hinting syntax completely out of the source file and into 
another file -- think of it as a "Python Type Hinting Header 
File". 

 
 Summary 
 
  
(1) Agree on a file extension that python will recognize 
as containing "type hint specs". Unfortunately we cannot 
use ".pth", which would be the perfect acronym for "Python 
Type Hints", so choose something else. :-( 

(2) Define a spec for writing annotations that will map to 
funcs/methods of the same name. I would argue to keep the 
spec compact, but i really don't care about the spec at 
this point. 

  
 
 Simplistic Example Code utilizing two files: 
 

  # 
  # scriptA.py 
  # 
  def greeting(name): 
  return 'Hello ' + name 
  
  # 
  # scriptA.typehints 
  # 
  greeting{name:str} -> str 


 
 Benefits: 
 

(1) Removes the noisy syntax from the source file. Python 
code will remain as clean tomorrow as it is today. 
  
(2) Puts the onerous on the author *NOT* on the reader. 
This system utilizes a concept known as "Level Of Detail" 
(or LOD). LOD means that i should not need to see a type 
hint unless i *WANT* to see a type hint. You can think of 
it as akin to "Java @string resources".   

(3) If i decide i don't want type hints in my code, all i 
have to do is delete or rename a file, which is much less 
error prone then editing source code. 

(4) Has the added benefit of aiding when debugging type hints. 
  
-- 
  
My suggestion is the only way to implement type hints 
without destroying Python! I just hope that GvR will give it 
serious objective consideration. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Paul Rubin]

Sturla Molden  writes:
> Type hinting will be mandatory because of bad managers.

That's a pretty weird concept: I've worked for good managers and bad
ones, but so far never one who imposed any low-level code style
decisions without also being involved in writing the code.  That was
always left to project leads.  Upper management (i.e. the CTO) sometimes
made high level decisions like "the production apps will be in Java not
Python" but that's different.

> But then someone is going to ask what benefit Python has to offer:
>
> Readabiliy? No ... down the drain.

The type hints don't impair readability as far as I can tell.  Rather,
they help it, since they indicate concisely what the function does.

> Dynamic typing? No ... down the drain.

It's still dynamic in the sense of having a universal type, and the
hints can also let the compiler specialize.

> Speed? No ... still 200x slower than Swift.

I don't think it's anything like 200x now, especially with pypy.  The
type hints will allow more optimization though the language semantics
will always keep it a slower than C/C++ (dunno about Swift).  

> Why go for Python? There is no benefit to it any longer.

The type hints look like an improvement to me.  I'd use them if they
were available.  I wouldn't have any problem with a project lead
mandating them, just like they currently mandate use of specific unit
test packages, etc.  I could imagine mandating them in a project that I
was leading.  The "bad management" thing only applies when someone
mandates coding practices that they themselves don't have to follow.

I think you're imagining some terrible scenario that's not close to
reality.  Erlang has a similar feature that I've already mentioned a few
times in this thread.  I've used it and it's a good feature.  It helps
keep the code organized and it doesn't get in the way too much.  You
don't have to put a signature on every function: it's optional so you
can put them in just the important places and let the tool figure out
the rest.

If you use a seriously typeful language like Haskell, you have to design
your whole program around the static types.  But with Erlang you can
code pretty much the same way you would in Python, add a few signatures
here and there, and that's enough for the analysis tool to do some quite
useful checks.

I remember in one of the endless static-vs-dynamic debates on
comp.lang.lisp, someone mentioned a code instrumentation experiment that
found that even in dynamic languages, most functions were monomorphic in
practice.  I think that's mostly because experienced programmers
unconsciously follow an ML-like type discipline most of the time, even
when the compiler isn't enforcing it.  So having some compile-time
checking will mostly do good.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Steven D'Aprano]

Paul Rubin wrote:

> Steven D'Aprano  writes:
>> Since the "language wars" of the 1990s, dynamic languages have won.
> 
> Are you kidding?  Nothing has won, the wars are still going on, and
> dynamic and static typing both have their winning use cases and will be
> around forever.

No, I stand by my statement, on the basis that Bob Martin said it and he's
smarter than me and he actually was a participant so he knows what he's
talking about *wink*

In one sense, "language wars" still go on. Conflict never really ends, it
just shifts from place to place, and there will always be "brush wars",
like Pascal versus PL/P, Pascal versus C, C versus Java, Perl versus
Python, Python versus Ruby, etc.

But the 1990s idea was that there ought to be One Language To Rule Them All,
that there should be a single language which is the optimal language for
every programming task. The 90s brought that to a head, with Smalltalk,
Java, C, and Lisp all contenders.

Today the nature of the wars has tended to change. Naturally there are still
clueless n00bs who insist that there must be One True Language for
everything but the wars today are more about the full technology stack
(e.g. C#/.NET/IIS/Windows versus Java/J2EE/Apache/Solaris) rather than
specifically about the language.

So in the sense that people still argue about languages, you are correct
that "language wars" continue, but Martin's specific claim was that dynamic
languages *as a group* won the war in the sense that all popular static
languages now include dynamic features, while dynamic languages don't
include static features:

Popular dynamic languages include:
- Python
- PHP
- Javascript

None of them can really be characterised as having "static" features in any
meaningful sense. (The introduction of type-hints to Python won't change
that, any more than documenting the types in a docstring has changed it.)

Popular static languages include:
- Java has reflection and runtime generics
- C# has the "dynamic" keyword which is based on .Net's reflection
- C++ has dynamic dispatch and virtual functions


Go is an interesting (counter-?) example: it is a static language almost
entirely lacking in dynamic features. From the Go FAQs:

"The only way to have dynamically dispatched methods is through an
interface. Methods on a struct or any other concrete type are always
resolved statically."

http://golang.org/doc/faq#How_do_I_get_dynamic_dispatch_of_methods

(Go may have other dynamic features, but I am unaware of them.) But Go is
lacking many other features (exceptions, generics, variant types, even
basic numeric coercions. Go is either going to revolutionise programming or
it will end up just another niche language. I suspect the latter.

The point is, despite maverick languages like Go, mainstream static
languages have developed dynamic features, while dynamic languages have not
reduced their dynamicism to become more static. Instead, dynamic languages
are developing Just In Time compilers to use *runtime* type information for
efficiency (e.g. Mercury, PHP, Python, Javascript all do this).




-- 
Steven

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

[RELEASE] ‘python-daemon’ version 2.0.4 released

[Ben Finney]

Howdy all,

I am pleased to announce the release of version 2.0.4 of the
‘python-daemon’ library.

The current release is always available at
https://pypi.python.org/pypi/python-daemon/>.

The project's forums and VCS are hosted at Alioth
https://alioth.debian.org/projects/python-daemon/>.


Significant changes since the previous version
==

This is a bug fix release, addressing packaging bugs:

* Remove custom Setuptools entry points.

  This addresses a bug reported by many people (thanks!) who found
  subsequent Setuptools actions impacted by these entry points.

* Write version info metadata using Setuptools ‘egg_info’ command.


What is the ‘python-daemon’ library?


‘python-daemon’ is a Python library to implement a well-behaved Unix
daemon process.

-- 
 \  “The way to build large Python applications is to componentize |
  `\ and loosely-couple the hell out of everything.” —Aahz |
_o__)  |
Ben Finney 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Rustom Mody]

On Friday, January 23, 2015 at 2:55:38 AM UTC+5:30, Ian wrote:
> On Thu, Jan 22, 2015 at 7:16 AM, Steven D'Aprano wrote:
> >> Meanwhile, there's the strange decision to implement type hints for
> >> local variables # comment lines. I have an hard time wrapping my head
> >> around this one. Really, comments!?
> >
> > Yes, really. There is plenty of prior art for machine-meaningful comments:
> >
> > - mypy uses it, and it works fine
> > - Pascal uses {$ ...} compiler directives
> > - Unix uses a special hash-bang #! comment in the first line to
> >   specify the executable that runs the script
> > - Python supports a special encoding declaration using #
> > - doctest uses comments for directives
> > - HTML puts code (Javascript usually) inside of comments
> > - JMSAssert for Java uses comments for design-by-contract assertions
> 
> Perhaps even more relevant to PEP 484:
> 
> - The Closure compiler for Javascript uses JSDoc tags in comments for
> static typing and analysis.

I have not studied this carefully... so no opinion
However Peyton Jones is known to have said that for Haskell,
Haskell is on a Damas-Milner cusp -- basically if haskell's type system
becomes any more sophisticated, then automatic type inference becomes 
undecidable
http://repository.upenn.edu/cgi/viewcontent.cgi?article=1336&context=cis_papers

Personally I find the predecessor of Haskell, gofer, prettier than Haskell
precisely because Haskell's type system has become too 'clever':

See my answer
http://stackoverflow.com/questions/25855507/are-typeclasses-essential

What has all this to do with python?? Dunno
Just that the 'optionality' of type-hinting may not be quite straightforward


PS Ian for a hot thread like this its good to put quotes carefully
You are quoting Steven quoting somebody -- dunno who that somebody is
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python is DOOMED! Again!

[Rustom Mody]

On Friday, January 23, 2015 at 3:50:38 AM UTC+5:30, Ian wrote:
> On Thu, Jan 22, 2015 at 3:08 PM, Ian Kelly  wrote:
> > On Thu, Jan 22, 2015 at 2:56 PM, Emile van Sebille  wrote:
> >> I've been lightly scanning and following the PEP 484 discussion, and one
> >> point I don't think I've seen mentioned is how you might hint a function
> >> that accepts different types, eg:
> >>
> >> def adder(a,b): return a+b
> >>
> >> This is one of the pythonic idioms that help with polymorphic functions.  
> >> Is
> >> there a proposal for providing hinting for these?
> >
> > You can use TypeVar for that.
> >
> > T = TypeVar('T')
> >
> > def adder(a: T, b: T) -> T:
> > return a + b
> >
> > I'm not thrilled about having to actually declare T in this sort of
> > situation, but I don't have a better proposal.
> 
> Hmm, but also that hinting doesn't cover cases like adder(12, 37.5)
> where two different types can be passed, and the return type could be
> either. I think for full generality you would just have to forgo
> hinting on this function.

You are 'discovering' two bugs in python's design:
1. [1,2,3] + [4,5,6]
uses the same symbol for an unrelated operation 
1 + 4

2. 1 + 2.14
has an implicit conversion

The second is present in almost all languages so its best called 'feature' not 
bug

The first I expect will incur costs that are way out of proportion to the 
benefits
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Sanity Proposal: Type Hinting Solution

[MRAB]

On 2015-01-23 01:15, Rick Johnson wrote:


Note: This is the closest you're going to get to a PEP from me!

Okay, i have found a solution to the type hinting problem
that will appease both sides. On one side we have those who
are proposing type hinting annotations within function sigs,
and on the other side, we have those who oppose the
implementation of type hinting via this method because of
the readability concerns. The solution is move the type
hinting syntax completely out of the source file and into
another file -- think of it as a "Python Type Hinting Header
File".


  Summary


(1) Agree on a file extension that python will recognize
as containing "type hint specs". Unfortunately we cannot
use ".pth", which would be the perfect acronym for "Python
Type Hints", so choose something else. :-(

(2) Define a spec for writing annotations that will map to
funcs/methods of the same name. I would argue to keep the
spec compact, but i really don't care about the spec at
this point.



  Simplistic Example Code utilizing two files:


   #
   # scriptA.py
   #
   def greeting(name):
   return 'Hello ' + name

   #
   # scriptA.typehints
   #
   greeting{name:str} -> str



  Benefits:


(1) Removes the noisy syntax from the source file. Python
code will remain as clean tomorrow as it is today.

(2) Puts the onerous on the author *NOT* on the reader.
This system utilizes a concept known as "Level Of Detail"
(or LOD). LOD means that i should not need to see a type
hint unless i *WANT* to see a type hint. You can think of
it as akin to "Java @string resources".

(3) If i decide i don't want type hints in my code, all i
have to do is delete or rename a file, which is much less
error prone then editing source code.

(4) Has the added benefit of aiding when debugging type hints.



You also need to handle methods.

A simple way would be to use indentation:

# scriptA.py
class Greeter:
def __init__(self, name):
self.name = name

def greet(self):
print('Hello,', self.name)

def greeting(name):
return 'Hello ' + name

# scriptA.typehints
Greeter:
__init__(self, name: str)
greeting{name: str} -> str


I'm not sure about the best format for functions within functions. This
repeats the function name:

# scriptB.py
def greet(name):
def make_message():
return 'Hello,' + name
print(make_message())

# scriptB.typehints
greet(name: str)
greet:
make_message() -> str


But a shorter version might not be clear:

# scriptB.typehints
greet(name: str):
make_message() -> str


especially when the outer function has a hint for its return type!

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

Re: Python Sanity Proposal: Type Hinting Solution

[Terry Reedy]

On 1/22/2015 8:15 PM, Rick Johnson wrote:


Okay, i have found a solution to the type hinting problem
that will appease both sides. On one side we have those who
are proposing type hinting annotations within function sigs,
and on the other side, we have those who oppose the
implementation of type hinting via this method because of
the readability concerns. The solution is move the type
hinting syntax completely out of the source file and into
another file -- think of it as a "Python Type Hinting Header
File".


This idea is so brilliant that it is already an option in mypy and is 
part of the new type-hint proposal.  The separate type-hint files are 
called 'stub files'.  I don't know what the extension is.  These will be 
used for the stdlib, which will not have annotations in the .py files



(2) Define a spec for writing annotations that will map to
funcs/methods of the same name. I would argue to keep the
spec compact, but i really don't care about the spec at
this point.


It will use the one  proposed, with whatever modification still to come.
I believe stub files can also be used for functions defined in C.


  Simplistic Example Code utilizing two files:



   # scriptA.py
   def greeting(name):
   return 'Hello ' + name



   # scriptA.typehints
   greeting{name:str} -> str


I believe stub files can also be used for functions defined in C.



  Benefits:



(1) Removes the noisy syntax from the source file. Python
code will remain as clean tomorrow as it is today.


This will at least be an option.  You are and will be free to advocate 
that people always use stub files.



(2) Puts the onerous on the author *NOT* on the reader.
This system utilizes a concept known as "Level Of Detail"
(or LOD). LOD means that i should not need to see a type
hint unless i *WANT* to see a type hint.


One thing not discussed here (but was in the earlier python-ideas thread 
some months ago) is that some groups have standards for using some 
functions that is stricter than the function's full duck-typing 
generality.  A stub file allows a group to specify a restrictive use 
annotation for their static checker without putting lies into the code 
or doc of the function itself.



(3) If i decide i don't want type hints in my code, all i
have to do is delete or rename a file, which is much less
error prone then editing source code.


If the annotations are in a separate file, deleting will hardly be 
necessary since the file will be ignored until one runs software that 
uses it.



(4) Has the added benefit of aiding when debugging type hints.


I am not sure what you mean here.   It will be easier to temporarily 
comment out an incorrect annotation for a function, pending correction, 
when in a separate file.



--
Terry Jan Reedy

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

Re: Python Sanity Proposal: Type Hinting Solution

[Rustom Mody]

On Friday, January 23, 2015 at 6:45:39 AM UTC+5:30, Rick Johnson wrote:
> Note: This is the closest you're going to get to a PEP from me! 
> 
> Okay, i have found a solution to the type hinting problem 
> that will appease both sides. On one side we have those who 
> are proposing type hinting annotations within function sigs, 
> and on the other side, we have those who oppose the 
> implementation of type hinting via this method because of 
> the readability concerns. The solution is move the type 
> hinting syntax completely out of the source file and into 
> another file -- think of it as a "Python Type Hinting Header 
> File". 
> 
>  
>  Summary 
>  
>   
> (1) Agree on a file extension that python will recognize 
> as containing "type hint specs". Unfortunately we cannot 
> use ".pth", which would be the perfect acronym for "Python 
> Type Hints", so choose something else. :-( 
> 
> (2) Define a spec for writing annotations that will map to 
> funcs/methods of the same name. I would argue to keep the 
> spec compact, but i really don't care about the spec at 
> this point. 
> 
>   
>  
>  Simplistic Example Code utilizing two files: 
>  
> 
>   # 
>   # scriptA.py 
>   # 
>   def greeting(name): 
>   return 'Hello ' + name 
>   
>   # 
>   # scriptA.typehints 
>   # 
>   greeting{name:str} -> str 
> 

1. Allow in same file
2. Chage syntax slightly to
type greeting : str -> str

[type is the keyword equivalent to your other typehint file ]
 and you have essentially the Haskell solution.

The catch I expect is that haskell is strongly committed to simultaneous
definitions:

x = 1
y = x+2

is the same as
y = x+2
x = 1

and so definitions can generally be permuted around

Python is committed to the opposite extreme:
even def and class are not declarative but imperative

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

Re: Python is DOOMED! Again!

[Terry Reedy]

On 1/22/2015 7:40 PM, Sturla Molden wrote:

On 22/01/15 21:03, Mario Figueiredo wrote:


That is fine. But then the problem isn't type hinting, is it? Neither I
think you are suggesting we don't introduce language because there are
bad project managers out there.

The problem is then bad project managers. That has nothing to do with
type hinting, or Python for that matter.


It has everything to do with Python if we facilitate them.

Type hinting will be mandatory because of bad managers. But then someone
is going to ask what benefit Python has to offer:

Readabiliy? No ... down the drain.


Type hints can be put in separate stub files and will be put in separate 
files for the stdlib.  If a client want to pay you to write type stubs, 
and you cannot stand to do it for even for pay, I am sure you will be 
able to subcontract the work.  I am sure someone will write python 
probrams to make the process easier.


Many Pythonistas would be glad to see more work, not bitch about it.

Readability?  Unchanged (at least for your own code and much of the rest).


Dynamic typing? No ... down the drain.


??? Python objects will still be dynamically typed.  For the present, 
compilation will be completely uneffected.


Dynamic typing? unchanged.


Speed? No ... still 200x slower than Swift.


Sturla, I *know* you must have heard of numpy?  cython?


--
Terry Jan Reedy

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

Re: Python is DOOMED! Again!

[Grant Edwards]

On 2015-01-22, Mark Lawrence  wrote:

> What implementation?  The PEP is quite clearly marked as draft.  The
> Re-enactment of the Battle of Pearl Harbour is currently ongoing
> over on python-ideas regarding exactly what should be implemented.

I, for one, shall certainly sleep easier knowing the Batley
Townswomens' Guild is looking out for our interestes.

--
Grant


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