'module' object has no attribute 'wrap_socket' when use ssl
Python 2.7.6 (default, Jun 22 2015, 18:00:18) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ssl Traceback (most recent call last): File "", line 1, in File "/home/martin/Documents/ssl.py", line 13, in SSLError -- exception raised for I/O errors AttributeError: 'module' object has no attribute 'wrap_socket' -- https://mail.python.org/mailman/listinfo/python-list
Re: 'module' object has no attribute 'wrap_socket' when use ssl
Ho Yeung Lee wrote: > Python 2.7.6 (default, Jun 22 2015, 18:00:18) > [GCC 4.8.2] on linux2 > Type "help", "copyright", "credits" or "license" for more information. import ssl > Traceback (most recent call last): > File "", line 1, in > File "/home/martin/Documents/ssl.py", line 13, in > SSLError -- exception raised for I/O errors > AttributeError: 'module' object has no attribute 'wrap_socket' Look at the traceback again -- the ssl.py you are importing is not the one from the standard library, it's an arbitrary module, perhaps written by "martin". Once you rename Martin's ssl.py to something else and also remove the corresponding ssl.pyc you will be able to work with the desired ssl.py from the stdlib. -- https://mail.python.org/mailman/listinfo/python-list
RE: Namedtuples: some unexpected inconveniences
Deborah Swanson wrote:
> I know it's your "ugly" answer, but can I ask what the '**' in
>
> fix = {label: max(values, key=len)}
> group[:] = [record._replace(**fix) for record in group]
>
> means?
d = {"a": 1, "b": 2}
f(**d)
is equivalent to
f(a=1, b=2)
so ** is a means to call a function with keyword arguments when you want to
decide about the *names* at runtime. Example:
>>> def f(a=1, b=2):
... print("a =", a)
... print("b =", b)
... print()
...
>>> for d in [{"a": 10}, {"b": 42}, {"a": 100, "b": 200}]:
... f(**d)
...
a = 10
b = 2
a = 1
b = 42
a = 100
b = 200
Starting from a namedtuple `record`
record._replace(Location="elswhere")
creates a new namedtuple with the Location attribute changed to "elsewhere",
and the slice [:] on the left causes all items in the `groups` list to be
replaced with new namedtuples,
group[:] = [record._replace(Location="elsewhere") for record in group]
is basically the same as
tmp = group.copy()
group.clear()
for record in tmp:
group.append(record_replace(Location="elsewhere"))
To support not just Location, but also Kind and Notes we need the double
asterisk.
--
https://mail.python.org/mailman/listinfo/python-list
Re: 'module' object has no attribute 'wrap_socket' when use ssl
On Saturday, April 15, 2017 at 3:18:58 PM UTC+8, Peter Otten wrote: > Ho Yeung Lee wrote: > > > Python 2.7.6 (default, Jun 22 2015, 18:00:18) > > [GCC 4.8.2] on linux2 > > Type "help", "copyright", "credits" or "license" for more information. > import ssl > > Traceback (most recent call last): > > File "", line 1, in > > File "/home/martin/Documents/ssl.py", line 13, in > > SSLError -- exception raised for I/O errors > > AttributeError: 'module' object has no attribute 'wrap_socket' > > Look at the traceback again -- the ssl.py you are importing is not the one > from the standard library, it's an arbitrary module, perhaps written by > "martin". Once you rename Martin's ssl.py to something else and also remove > the corresponding ssl.pyc you will be able to work with the desired ssl.py > from the stdlib. thanks , it can run now, but how to create a SSL server for testing it? when I use google as server, it failed handshake python crackssl.py Traceback (most recent call last): File "crackssl.py", line 16, in wrappedSocket.connect((HOST, PORT)) File "/usr/lib/python2.7/ssl.py", line 433, in connect self._real_connect(addr, False) File "/usr/lib/python2.7/ssl.py", line 420, in _real_connect socket.connect(self, addr) File "/usr/lib/python2.7/socket.py", line 224, in meth return getattr(self._sock,name)(*args) socket.error: [Errno 111] Connection refused martin@ubuntu:~/Documents$ python crackssl.py Traceback (most recent call last): File "crackssl.py", line 16, in wrappedSocket.connect((HOST, PORT)) File "/usr/lib/python2.7/ssl.py", line 433, in connect self._real_connect(addr, False) File "/usr/lib/python2.7/ssl.py", line 423, in _real_connect self.do_handshake() File "/usr/lib/python2.7/ssl.py", line 405, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [Errno 1] _ssl.c:510: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure import socket import ssl # SET VARIABLES packet, reply = "SOME_DATA", "" HOST, PORT = 'www.google.com.hk', 443 # CREATE SOCKET sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(10) # WRAP SOCKET wrappedSocket = ssl.wrap_socket(sock, ssl_version=ssl.PROTOCOL_TLSv1, ciphers="ADH-AES256-SHA") # CONNECT AND PRINT REPLY wrappedSocket.connect((HOST, PORT)) wrappedSocket.send(packet) print wrappedSocket.recv(1280) # CLOSE SOCKET CONNECTION wrappedSocket.close() -- https://mail.python.org/mailman/listinfo/python-list
TIC TAE TOE's problem(i am beginner)
A=['1', ' ', '1']
B=['1', ' ', '2']
C=['1', ' ', '3']
D=['2', ' ', '1']
E=['2', ' ', '2']
F=['2', ' ', '3']
G=['3', ' ', '1']
H=['3', ' ', '2']
I=['3', ' ', '3']
N=int(9)
def my_func1():
X=list(input())
global N
N=N-1
if X==['1', ' ', '1']:
A="X"
my_func3()
my_func2()
if X==['1', ' ', '2']:
B="X"
my_func3()
my_func2()
if X==['1', ' ', '3']:
C="X"
my_func3()
my_func2()
if X==['2', ' ', '1']:
D='X'
my_func3()
my_func2()
if X==['2', ' ', '2']:
E="X"
my_func3()
my_func2()
if X==['2', ' ', '3']:
F='X'
my_func3()
my_func2()
if X==['3', ' ', '1']:
G='X'
my_func3()
my_func2()
if X==['3', ' ', '2']:
H='X'
my_func3()
my_func2()
if X==['3', ' ', '3']:
I='X'
my_func3()
my_func2()
def my_func2():
Y=list(input())
global N
N=N-1
if Y==['1', ' ', '1']:
A="O"
my_func3()
my_func1()
if Y==['1', ' ', '2']:
B="O"
my_func3()
my_func1()
if Y==['1', ' ', '3']:
C="O"
my_func3()
my_func1()
if Y==['2', ' ', '1']:
D="O"
my_func3()
my_func1()
if Y==['2', ' ', '2']:
E="O"
my_func3()
my_func1()
if Y==['2', ' ', '3']:
F="O"
my_func3()
my_func1()
if Y==['3', ' ', '1']:
G="O"
my_func3()
my_func1()
if Y==['3', ' ', '2']:
H="O"
my_func3()
my_func1()
if Y==['3', ' ', '3']:
I="O"
my_func3()
my_func1()
def my_func3():
if A and B and C=="X":
print("X win")
elif D=="X" and E=="X" and F=="X":
print("X win")
elif G=="X" and H=="X" and I=="X":
print("X win")
elif A=="X" and D=="X" and G=="X":
print("X win")
elif B=="X" and E=="X" and H=="X":
print("X win")
elif C=="X" and F=="X" and I=="X":
print("X win")
elif A=="X" and E=="X" and I=="X":
print("X win")
elif A=="O" and B=="O" and C=="O":
print("O win")
elif D=="O" and E=="O" and F=="O":
print("O win")
elif G=="O" and H=="O" and I=="O":
print("O win")
elif A=="O" and D=="O" and G=="O":
print("O win")
elif B=="O" and E=="O" and H=="O":
print("O win")
elif C=="O" and F=="O" and I=="O":
print("O win")
elif A=="O" and E=="O" and I=="O":
print("O win")
elif N==0:
print("DRAW")
print(A,B)
P=input("X/O:")
if P=="X":
my_func1()
else:
my_func2()
why cant function to print X or O win...
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 15/04/2017 03:35, Rick Johnson wrote: On Wednesday, April 12, 2017 at 8:44:30 AM UTC-5, bart...@gmail.com wrote: At a minimum, every language should offer the following four loop-forms (using Python semantics): while CONDITION: doSomething() for VALUE in COLLECTION: doSomething(value) loop(N): doSomething() loop(N) as i: doSomething(i) Yes, I'm constantly surprised at this, as such syntax has a very low cost (in my last compiler, supporting 'while' for example only added 30 lines to the project). Of course, it's possible to overdo it; if you look at Lisp, you'll lose yourself in the myriad looping options. But very common requirements are endless loops, and repeat N times without needing an explicit counter. The former /can/ be easily written as: while 1: body but it's more psychological; I don't want to use an idiom to denote an endless loop, I want to be able to express it directly! Python's byte-code does at least optimise out the check that '1' is true, but that's not what the reader sees, which is 'loop while 1 is true'. And one day it will be: while l: body that can be mistaken for that common idiom. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Python Environment Setup in Windows 10
I am a beginner .NET developer. But I need to use python now for a project. I need to use Scikit-Learn, Numpy, Scipy, matplotlib.pyplot, Pandas, Keras, TensorFlow etc libraries (Mostly for Machine Learning). To be more specific, I want to implement this example- http://machinelearningmastery.com/time-series-prediction-with-deep-learning-in-python-with-keras/ I want to use PyCharm as my IDE. But I am tired trying to install python, anaconda, CUDA etc etc, nothing helps me run those codes. I am sure that the problem is with environment setup. I need a complete walkthrough about the installation and other setup procedures (Including path variable changes and other details). (I will uninstall all the python related things are currently installed in my system.) I use Windows 10 (64 Bit) And I have a NVIDIA 1050 Ti GPU. (Want to use GPU installation for TensorFlow). I have Visual Studio 2015 installed in my system. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Sat, 15 Apr 2017 10:23 am, bartc wrote: > On 15/04/2017 00:40, Rick Johnson wrote: >> * `range(10)` will always produce a list of the _same_ 10 >> integers. > > You don't know if 'range' is still a range. If this has been executed > first, then the answer will be 20: > > oldrange=range > def double(x): return oldrange(x*2) > range=double Correct. It is true that *at the moment* CPython doesn't know if range has been shadowed or redefined, but Victor Stinner is working on a project, FATPython, which will. Or at least, FATPython can tell: - there's no chance that range() has been redefined, so it is safe to optimize the call to it; - or there is a chance, in which case it is not safe to optimize. >> * `for i in range(10)` will aways iterate over the _same_ >> 10 integers > > And range could be set to something else each time the loop is executed. It could, but that won't effect the loop. py> old_range = range py> for i in range(5): ... range = i*100 ... print(i) ... 0 1 2 3 4 py> range 400 >> * `answer += 1` will always increment the "current integer >> value" by 1 > > I don't know if it's possible to override __iadd__ for integers so that > +=1 does something different here. No, Python doesn't allow the built-in types to be monkey-patched. However, that's not the problem. The problem is that CPython doesn't know whether answer is a built-in int or not until runtime. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Calling dunder methods manually
On Thursday, April 13, 2017 at 2:01:41 AM UTC-5, Serhiy Storchaka wrote: > > __init__ is perhaps the most called dunder method. It is > often called from the __init__ method of subclasses. Yes, that would be one of the exceptions to the rule, but not because the rule is unsound, but because Python's super really sucks. Even to this day, i avoid super because the semantics are confusing, eaisier to just write the path in long-form. In many other languages though, super is intelligent enough to know what scope it is in. But in any event, i cannot think one one good reason to call dunder methods from outside a class definition (maybe someone can think of a few???). > __add__ also can be called from other __add__, __iadd__ or > __radd__. Some people have mentioned using the methods of the operator module to avoid calling dunders, but from the POV of consistency, i think such a policy would be a bad idea and just more evidence that Python's super is woefully inadequate. Which begs the question: "What's the point of having super if the majority are unwilling to use it?" Hmm. I suppose "for consistency's sake" would be the only legitimate answer. -- https://mail.python.org/mailman/listinfo/python-list
what type of application implemented with python?
what type of application implemented with python?...like by using java we can implement web,Standard alone app's,mobile based. Can anyone tell me is it possible to implement Standard alone applications with, if possible give any example -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Saturday, April 15, 2017 at 7:17:55 AM UTC-5, bartc wrote: > On 15/04/2017 03:35, Rick Johnson wrote: > > On Wednesday, April 12, 2017 at 8:44:30 AM UTC-5, bart...@gmail.com wrote: > > > At a minimum, every language should offer > > the following four loop-forms (using Python semantics): > > > > while CONDITION: > > doSomething() > > > > for VALUE in COLLECTION: > > doSomething(value) > > > > loop(N): > > doSomething() > > > > loop(N) as i: > >doSomething(i) > > > > Yes, I'm constantly surprised at this, as such syntax has a > very low cost (in my last compiler, supporting 'while' for > example only added 30 lines to the project). Of course, > it's possible to overdo it; if you look at Lisp, you'll > lose yourself in the myriad looping options. But very > common requirements are endless loops, and repeat N times > without needing an explicit counter. The former /can/ be > easily written as: > > while 1: > body > > but it's more psychological; I don't want to use an idiom > to denote an endless loop, I want to be able to express it > directly! A good point. I don't like the idiom of using "always True conditions" to denote an endless loop either. So it's just a matter of recognizing that loop() without an "explicit confining parameter", would be endless. loop: # This loop never ends. Of course, recognizing that at some point that the loop will need to end, or that something surprizing will cause it to end, how then would you end it in a clean manner? Which would cause the semantics to be: loop: # This loop never ends. Well "never" unless an # exception occurs; or the hardware malfunctions; or # melts; or unless nuclear war breaks out; or unless the # sun expands and envelopes the earth -- except for # those cases (and possibly a long list of others...), # it never ends. ;-) > Python's byte-code does at least optimise out the check > that '1' is true, but that's not what the reader sees, > which is 'loop while 1 is true'. And one day it will be: > > while l: > body > > that can be mistaken for that common idiom. Another good point. However that's more a consequence of using 1 as a truth value than anything else. Python has offered booleans for a lng time, so i don't understand why some of us feel the need to use 0 and 1 in place of the more intuitive (and less bug prone) False and True. The obvious solution is: while True: # This loop never ends. # (Note: see exceptions above) Integers should only be utilized for their numeric value, and nothing else. Python should never allow an integer to be used as a truth value, only booleans or expressions that evaluate to a truth value. Of course, these can perverted also. if 1 == 1: # superfluous! 1 will always equal 1 if None: # superfluous! None will always be False if True == False: # superfluous! True and False will never be equal. etc... (of course, i _hope_ those examples are rock solid. Sometimes, i forget how utterly and stubbornly dynamic this damned language can be!) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
bartc : > Of course, it's possible to overdo it; if you look at Lisp, you'll lose > yourself in the myriad looping options. Funny, in Scheme, the only looping construct I use is named-let. > The former /can/ be easily written as: > > while 1: > body Why not say it like it is: while True: body > but it's more psychological; I don't want to use an idiom to denote an > endless loop, I want to be able to express it directly! C's: for (;;) statement I would call an idiom. Python's while True: body is about as straightforward as it gets. > Python's byte-code does at least optimise I don't understand why there's so much talk about CPython's bytecode on this list. That should only be of interest to active CPython developers. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 15/04/2017 14:27, Marko Rauhamaa wrote: bartc : while 1: body Why not say it like it is: while True: body but it's more psychological; I don't want to use an idiom to denote an endless loop, I want to be able to express it directly! C's: for (;;) statement I would call an idiom. I don't like that either! Python's while True: body is about as straightforward as it gets. In the syntax I normally use (based on Algol 68), the endless loop is: do body end (well, actually I use do body od, but that may have raised some eyebrows). 'do', in the original Algol 68 syntax, was part of its 'for' statement, where you could leave out the parts you don't need. The full syntax is something like: for var := a to b by c while d do body od If you leave out the first part you get a while loop. Leave out all except 'to b do', you get a repeat-n-times loop. And so on. Elegant. (I don't do it that way, I have discrete loop types, plus my own variations. Devising syntax is so easy, the hard bit is knowing when to stop...) Python's byte-code does at least optimise I don't understand why there's so much talk about CPython's bytecode on this list. That should only be of interest to active CPython developers. What proportion of Python implementations depend on executing byte-code? -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: TIC TAE TOE's problem(i am beginner)
>
> P=input("X/O:")
> if P=="X":
> my_func1()
> else:
> my_func2()
>
>
>
> why cant function to print X or O win...
>
As a beginner I'd try to code using Python idioms rather than writing
Python using BASIC idioms.
Try to understand how this code works:
https://codereview.stackexchange.com/questions/108738/python-tic-tac-toe-game
Note that one of the answers on that page has improved the original
poster's code.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
bartc writes: > 'do', in the original Algol 68 syntax, was part of its 'for' > statement, where you could leave out the parts you don't need. The > full syntax is something like: > > for var := a to b by c while d do body od FOR name FROM e1 BY e2 TO e3 WHILE cond DO body OD The significant part is the the name is bound to a value and can't be assigned in the body. (You don't say it can be but "var := a" makes var look like a plain Algol68 variable.) -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On 04/15/2017 08:37 AM, bartc wrote: > What proportion of Python implementations depend on executing byte-code? Presumably Nuitka does not depend on any byte code at all. Jython uses JVM byte codes. Iron Python uses .net VM bytecodes. While CPython's byte codes do take their form in part because of Python and its syntax. But that doesn't mean that Python itself as a language is necessarily dependent on the specifics of the CPython byte code interpreter and architecture, though I concede that for some aspects of Python, the behavior of the language is defined by the CPython implementation. The two aspects are definitely linked, but not as solidly as you seem to think. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Command Line Arguments
On 2017-04-14, Bernd Nawothnig wrote: > He should switch to argparse in any case because getopt is no longer > supported and does only receive bugfixes. In my book, "receiving bug fixes" means it's still supported. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
New implementation(patterns)
So.Basically recently I just faced with some problem. I wanted to create my
own data type. I created new class put something in it. But I really wanted to
set items in it like so:
>>>datatype[0][0][1]=1
As you could see I used 3 keys But magic method __setitem__ alows me only
to do something like this:
===
>>>datatype[0,0,1]=1
===
And that's a little bit uncomortable.
Also...I know that probably everyone sometime wanted to 'hide' class name when
you create object and not to write this:
===
>>>var=MyClass('David')
===
...And instead to write this:
===
>>>var=
>>>var
<__main__.MyClass object at 0x006242B13748>
===
I think that would be much easier and glamourus.
So here I present you special type of object: pattern
Example:
===
>>>&mypattern='<'str'>'
==
Here I created variable that stored pattern
This pattern allows me to write '<>' with string in this
For example from that momemnt if I type ''
Nothing will happen.
Also patterns can have commands in them:
==
>>>&mynewpattern='#'list'#'
>>> def &mynewpattern:
... return MyClass(list)
==
Here I gave pattern 'mynewpattern' functionality. Now it RETURNS CLASS!!!
This way we could make shorter and more beautiful.In the example list is type
of data like string or integer. And now I made that when I type lists with '#'s
program returns class MyClass.
That's concludes explanation of patterns
P.S. Ask me in comments if you didnt understand something.
--
https://mail.python.org/mailman/listinfo/python-list
how to get image url from django form
i have create a simple django form where the authentication user can select one
of personal images where have upload before and i want do something with that
request in my views.py.
but i dont know how to take the image url from that request in my view because
first i using request.user in the form to take only self user images and i dont
know how to continue and finaly i take that images url.
the form work great show me only the self user images
any idea ?
here the code
views.py
@login_required(login_url="login/")
def carlist(request):
Myform = MyModelForm(user=request.user)
return render(request,'about.html',{'Myform':Myform})
select django form :
class MyModelForm(ModelForm):
def __init__(self, *args, **kwargs):
# extract "user" from kwrags (passed upon form init)
if 'user' in kwargs:
self.user = kwargs.pop('user')
super(MyModelForm, self).__init__(*args, **kwargs)
# generate the choices as (display, value). Display is the one that'll
be shown to user, value is the one that'll be sent upon submitting (the "value"
attribute of )
choices = MyModel.objects.filter(user=self.user).values_list('upload',
'id')
self.fields['upload'].widget = Select(choices=choices)
class Meta:
model = MyModel
fields = ('upload',)
html :
{% csrf_token %}
{{ Myform}}
--
https://mail.python.org/mailman/listinfo/python-list
Re: what type of application implemented with python?
Hello, Python's own website contains a non-exhaustive list of applications implemeted in Python: https://www.python.org/about/apps/ Regards Rambius On Sat, Apr 15, 2017 at 4:13 PM, kondaiah sinha wrote: > what type of application implemented with python?...like by using java we can > implement web,Standard alone app's,mobile based. > Can anyone tell me is it possible to implement Standard alone applications > with, if possible give any example > -- > https://mail.python.org/mailman/listinfo/python-list -- Tangra Mega Rock: http://www.radiotangra.com -- https://mail.python.org/mailman/listinfo/python-list
super() is super [was Re: Calling dunder methods manually]
On Sat, 15 Apr 2017 10:50 pm, Rick Johnson wrote: > Even to this day, i avoid super because the > semantics are confusing, If super() is confusing, it is because *inheritance* is confusing, and that goes triple for multiple inheritance. If it is not *easy* to use super() to manage your class' inheritance, that's a sign that your class hierarchy is complicated and confusing and you're in a nightmare whether you use super() or not. But for the simple cases, using super() in Python 3 couldn't be easier. If you have code that looks something like this: class MyClass(ParentClass): def method(self, arg): result = ParentClass.method(self, arg) you replace the last line with: result = super().method(arg) If you have: class MyClass(A, B): def method(self, arg): A.method(self, arg) B.method(self, arg) you replace the last two lines with: super().method(arg) See also: https://rhettinger.wordpress.com/2011/05/26/super-considered-super/ > eaisier to just write the path in long-form. Easier and wrong. If you have multiple inheritance, and don't use super(), then your code is buggy, whether you have realised it or not. Manually calling your parent class is only acceptable if you can absolutely guarantee that your class, all its parent classes, and all its subclasses will ONLY use single inheritance. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Sun, 16 Apr 2017 12:37 am, bartc wrote: > What proportion of Python implementations depend on executing byte-code? My guess is 100%. Pretty much all modern interpreters of any language execute some form of byte-code or another. The bad old days where interpreters repeatedly parsed and executed each line of source are long gone. PyPy generates some sort of byte-code, with a JIT compiler to generate machine code on the fly for sufficiently "hot" code. IronPython uses byte-code for the .Net virtual machine. Jython uses byte-code for the Java virtual machine. CPython uses byte-code for its own virtual machine. There was a project for a Python interpreter for the Parrot VM, but I think that's no longer in development. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: super() is super [was Re: Calling dunder methods manually]
On Sun, Apr 16, 2017 at 10:35 AM, Steve D'Aprano wrote: > >> eaisier to just write the path in long-form. > > Easier and wrong. > > If you have multiple inheritance, and don't use super(), then your code is > buggy, whether you have realised it or not. > > Manually calling your parent class is only acceptable if you can absolutely > guarantee that your class, all its parent classes, and all its subclasses > will ONLY use single inheritance. Plus, it's fragile in that it names the parent class everywhere. class A: def __init__(self): ... def __add__(self, other): ... def __or__(self, other): ... class B(A): def __init__(self): A.__init__(self) def __add__(self, other): A.__add__(self, other) ... Every method you subclass-and-call-parent needs to say the name of the parent class. With super, they all just say super(). I know which one I'd rather do. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: New implementation(patterns)
On Sun, 16 Apr 2017 05:34 am, Debiller 777 wrote: > >>> &mypattern='<'str'>' That's a syntax error. Are you sure that's the actual, real, working code you are using? > >>> def &mynewpattern: > ... return MyClass(list) That's also a syntax error. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Looping [was Re: Python and the need for speed]
On Sat, 15 Apr 2017 10:17 pm, bartc wrote: > On 15/04/2017 03:35, Rick Johnson wrote: >> On Wednesday, April 12, 2017 at 8:44:30 AM UTC-5, bart...@gmail.com >> wrote: > >> At a minimum, every language should offer >> the following four loop-forms (using Python semantics): >> >> while CONDITION: >> doSomething() >> >> for VALUE in COLLECTION: >> doSomething(value) >> >> loop(N): >> doSomething() >> >> loop(N) as i: >>doSomething(i) What an extravagant, unnecessary waste of syntax. The last two just duplicate the functionality of the second. AND Rick has forgotten about the do...while form that executes the block at least once. I've used, and to be honest really enjoyed using, a language with multiple loop syntax like this. I can see some advantage in offering specialist English-like loops in a programming language for non-programmers and amateurs. But having a plethora of forms for what is essentially the same thing is not so helpful for more skilled programmers who are more comfortable with composing code rather than memorising fixed statements. repeat forever: ... is no more expressive than while True: ... since they're both just the same thing. You can mechanically and trivially translate one to the other with no intelligence needed. So it becomes a mere matter of personal taste as to which you prefer. > Yes, I'm constantly surprised at this, as such syntax has a very low > cost (in my last compiler, supporting 'while' for example only added 30 > lines to the project). That's the advantage of writing your own private language and having no users except for yourself. You get to cut corners. Python has tens of thousands of users, and doesn't have that luxury. For language developers with responsibilities to users, the job doesn't stop at just implementing the feature in the language. It also needs to be tested and documented. As a general rule of thumb, every line of production code should expect to add at least ten lines of test code (unit tests, regression tests, integration tests, functional tests, doc tests, etc). So for your "30 lines" feature, that adds 300 lines of tests, and probably another page or two of documentation: - describing the various syntax forms; - explaining how they differ; - tutorials for beginners showing each form; plus the on-going burden for every single user of the language, for ever, in having to decide which form they need to use in any specific circumstance. The more choices you offer, the harder that decision becomes: - numeric Pascal or C-style loop - foreach style loop - repeat while condition (test at start) - repeat until condition (test at start) - do ... while condition (test at end) - do ... until condition (test at end) - repeat forever I don't remember the language, but I remember seeing one generalisation of the repeat/do loop that puts the test in the middle, rather than at the start or end of the loop. If I remember it was something like: DO setup code # executed once only REPEAT loop body # before the test WHILE condition # test loop body # after the test thus combining both the repeat while condition: ... and do: ... until condition styles of looping in one handy syntax. > Of course, it's possible to overdo it; if you look at Lisp, you'll lose > yourself in the myriad looping options. "Myriad"? As I understand it, Lisp offers just *one* more loop construct than the number you agree is the "minimum" needed: five. loop loop for do dotimes dolist https://www.tutorialspoint.com/lisp/lisp_loops.htm > But very common requirements are endless loops, and repeat N times > without needing an explicit counter. If by "very common" you mean "occasionally", I agree. > The former /can/ be easily written > as: > > while 1: > body > > but it's more psychological; I don't want to use an idiom to denote an > endless loop, I want to be able to express it directly! "Express it directly" is an idiom, and "while True" is just as direct as "repeat forever". > Python's byte-code does at least optimise out the check that '1' is > true, but that's not what the reader sees, which is 'loop while 1 is > true'. And one day it will be: > > while l: > body > > that can be mistaken for that common idiom. The problem there is not the loop, but the foolish use of lowercase l as a variable name. It is simply poor programming practice to use easily confused names, and the problem here is not the use of `while`. No more than it is the use of `while` that makes this code bad: while O000IlI1III111IllOO: something() O000IlI1III11I1II1IllOO = False print(O00OIlI1III111IllOO) Given: mylist.append(l) x += l if l: ... do you also conclude that the problem lies with append, += and `if` ? -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure e
Re: super() is super [was Re: Calling dunder methods manually]
Steve D'Aprano wrote: But for the simple cases, using super() in Python 3 couldn't be easier. The only "simple" use of super() is in the single inheritance case. But that's also the case where it gains you the least over an explicit inherited method call. If you have multiple inheritance, and don't use super(), then your code is buggy, whether you have realised it or not. Manually calling your parent class is only acceptable if you can absolutely guarantee that your class, all its parent classes, and all its subclasses will ONLY use single inheritance. I don't agree with that at all. It's quite possible to write code that uses multiple inheritance, doesn't use super() and works perfectly correctly. Someone else might use my class in an inheritance network in a way that results in misbehaviour, but if it happens, *they* wrote that bug, not me. You could argue that I *should* write my code so that anyone can mix it with anything in any way without having to think about the consequences, but that sounds more like a moral judgement than a technical argument. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Static typing [was Re: Python and the need for speed]
On Sat, 15 Apr 2017 11:55 am, Rick Johnson wrote: > apparently, the py-devs believe we > only deserve type declarations that do nothing to speed up > code execution (aka: type-hints), instead of type > declarations that could actually speed up the code. Go > figure! > > I'm not a fan of forced static typing, but i am a fan of > optional static typing. Are you aware that optional static typing CANNOT be used for optimization? Since it is *optional*, it is only a hint, not a fact. You can tell the compiler that you believe that n will be an int, but it's not guaranteed. As the Dude says, the type hint is that's, like, only your opinion man and the compiler cannot trust it. It must still guard the operation with a runtime check that n actually is an int, and so you lose most or all of the benefit of telling the compiler that it's an int. There are clever Just In Time compiler tricks that can optimize the code, which is what Psycho did and PyPy still does, but they don't need type hints. Type hints are superfluous to a JIT compiler, since it already knows the runtime type information. But JIT compilers have their limitations, like the necessity of warm up time, increased complexity, and much heavier memory requirements. If you want to use type hints for the purposes of compile-time optimizations, then typing must be compulsory and enforced by the compiler. No longer optional hints, but mandatory statements of indisputable fact. (That doesn't necessarily mean that you have to use type declarations, like in C, Pascal and Java. A good modern compiler can infer types, like in ML and Haskell.) Python's gradual typing is not about optimization, it is about testing program correctness and helping to find bugs at compile time*. As such, the fact that type hints are optional and "only your opinion" doesn't matter. The promise made by the type checker is: IF what you say is true (the type hints are correct) THEN this code will be sound (or alternatively, it's unsound because you have a type mismatch, and get a compile-time error). As a fallback, you still have the runtime dynamic type checks. Unit and functional tests are great, and necessary. Just because your code compiles in C, Java or Pascal doesn't mean that it is correct. You still have to run the code and test that it does what you expect. "It compiles! Quick, ship it!" -- attributed to Microsoft developers Nevertheless, the problem with testing is that it can only prove the presence of bugs, not their absence. A test that fails proves that your code has at least one bug. A test that passes doesn't prove that there are no bugs. Static type checking helps to shrink the gap between "all of my tests pass, so there are no known bugs" and "there are no unknown bugs". And that's an important and powerful tool, especially for large and complex programs. Python's type-hints are for writing correct code, not fast code. I find it amusing when people argue that Python's type hints are pointless or useless. Do they realise they're effectively arguing that correct, bug-free code is pointless? "Your code is buggy. It calculates the wrong result." "Maybe so, but look how fast it does it!" -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
